Scrum и его особенности
Прочитал культовую книгу Сазерленда «Scrum. Революционный метод управления проектами» и теперь всем обязательно советую.
Я влияние подобных книг оцениваю по количеству заметок оттуда в моем телефоне. А тут их по итогу оказалось прилично.
С вами делюсь малой частью крутых практичных тезисов из книги, которые особенно сильно совпадают с текущим моим видением работы и опытом (интерпретация моя, вольная):
1. Многозадачность отупляет. Если делать много дел одновременно, то получится и плохо и медленно.
2. Долгосрочные проектные графики устарели. Какой смысл большой отрезок времени делать и дальше еще согласовывать то, что потом на практике становится не актуальным спустя месяц после начала работ. Двигаться надо поэтапно.
3. Большие команды это вред. Часто переизбыток людей в рабочей группе только замедляет ее эффективность. Оптимально 6-8 качественных специалистов в группе.
4. У каждого в проекте должна быть своя роль, ответственность и полномочия. Люди с полномочиями и без ответственности мешают процессу. А у тех на ком ответственность, но нет полномочий, наоборот рискуют остаться неуслышанными.
Там еще была гипотеза «с порванными визитками» и отказом от званий и иерархии в рамках проектных работ, но это немного «ту мач» на мой взгляд для нашей системы бизнеса.
5. Сделанное наполовину - не сделано. Все, что выполнено частично уже забрало на себя множество денег, времени и других ресурсов, при этом не принеся никакой практической пользы компании.
6. Чем чаще мы выдаем готовым продукт, тем лучше для него и для вас. У нас формируется шанс собирать обратную связь и нивелировать недочеты. Пока мы держим продукт у себя в столе, пытаясь сделать его идеальным, мир убегает вперед вместе с актуальностью наших изначальных идей.
7. Делать все правильно с первого раза. Совершив ошибку, надо сразу же вернуться и исправить ее, отложив все другие дела. Устранение дефекта спустя некоторое время займет в 20 раз больше сил и энергии, чем немедленное исправление.
8. Если слишком усердно работать, то работы становится только больше. Слишком усердный труд приводит к усталости, а она в свою очередь к ошибкам в задачах и к потере эффективности.
9. Задачи надо выполнять без героизма (одна из самых крутых мыслей для меня). Если для реализации проекта вам нужны герои, то у вас проблемы. Эти сверх усилия - индикатор того, что вы изначально ошиблись в планировании.
10. Хватит гадать. Надо по классическому циклу Демпинга планировать, действовать, проверять, корректировать. И этого будет достаточно для принятия верных решений, непрерывно улучшающих систему работы и сам продукт.
Эту SCRUM методику работы с проектами легко переложить в плоскость девелопмента во многих областях. Например, на проект по ребрендингу компании. Или на подготовку нового проекта к старту продаж. Но особенно релевантно на мой взгляд использовать эту систему в рамках планирования самого процесса строительства объекта.
В общем, всем спринтов, мастеров, гибкости и всего прочего эффективного. А книгу прочитайте.
Прочитал культовую книгу Сазерленда «Scrum. Революционный метод управления проектами» и теперь всем обязательно советую.
Я влияние подобных книг оцениваю по количеству заметок оттуда в моем телефоне. А тут их по итогу оказалось прилично.
С вами делюсь малой частью крутых практичных тезисов из книги, которые особенно сильно совпадают с текущим моим видением работы и опытом (интерпретация моя, вольная):
1. Многозадачность отупляет. Если делать много дел одновременно, то получится и плохо и медленно.
2. Долгосрочные проектные графики устарели. Какой смысл большой отрезок времени делать и дальше еще согласовывать то, что потом на практике становится не актуальным спустя месяц после начала работ. Двигаться надо поэтапно.
3. Большие команды это вред. Часто переизбыток людей в рабочей группе только замедляет ее эффективность. Оптимально 6-8 качественных специалистов в группе.
4. У каждого в проекте должна быть своя роль, ответственность и полномочия. Люди с полномочиями и без ответственности мешают процессу. А у тех на ком ответственность, но нет полномочий, наоборот рискуют остаться неуслышанными.
Там еще была гипотеза «с порванными визитками» и отказом от званий и иерархии в рамках проектных работ, но это немного «ту мач» на мой взгляд для нашей системы бизнеса.
5. Сделанное наполовину - не сделано. Все, что выполнено частично уже забрало на себя множество денег, времени и других ресурсов, при этом не принеся никакой практической пользы компании.
6. Чем чаще мы выдаем готовым продукт, тем лучше для него и для вас. У нас формируется шанс собирать обратную связь и нивелировать недочеты. Пока мы держим продукт у себя в столе, пытаясь сделать его идеальным, мир убегает вперед вместе с актуальностью наших изначальных идей.
7. Делать все правильно с первого раза. Совершив ошибку, надо сразу же вернуться и исправить ее, отложив все другие дела. Устранение дефекта спустя некоторое время займет в 20 раз больше сил и энергии, чем немедленное исправление.
8. Если слишком усердно работать, то работы становится только больше. Слишком усердный труд приводит к усталости, а она в свою очередь к ошибкам в задачах и к потере эффективности.
9. Задачи надо выполнять без героизма (одна из самых крутых мыслей для меня). Если для реализации проекта вам нужны герои, то у вас проблемы. Эти сверх усилия - индикатор того, что вы изначально ошиблись в планировании.
10. Хватит гадать. Надо по классическому циклу Демпинга планировать, действовать, проверять, корректировать. И этого будет достаточно для принятия верных решений, непрерывно улучшающих систему работы и сам продукт.
Эту SCRUM методику работы с проектами легко переложить в плоскость девелопмента во многих областях. Например, на проект по ребрендингу компании. Или на подготовку нового проекта к старту продаж. Но особенно релевантно на мой взгляд использовать эту систему в рамках планирования самого процесса строительства объекта.
В общем, всем спринтов, мастеров, гибкости и всего прочего эффективного. А книгу прочитайте.