Как человека, который учился менеджменту в среде программистов, меня удивляет интересный момент управления бизнесом.
В программировании последние двадцать лет используется подход «гибкой» разработки, при котором работа ведется сплоченной командой, планирующей не на год вперед, а на спринт 1-4 недельной длины. Значение придается результату на каждый спринт и подходу оценки направления движения команды. Убирается бюрократия и устраняются «начальники». В итоге получается добиться удовлетворяющих заказчика результатов, экономится бюджет, сокращаются сроки. Тысячи примеров успеха убедили миллионы программистов работать только в такой модели.
Вопрос, который меня волновал: почему такие гибкие подходы не используются при построении, управлении и развитии самого бизнеса. Поработав в разных российских компаниях я убедился, что даже в ИТ-компаниях, где разработчики применяют гибкие методологии, руководство бизнес-подразделений и акционеры смотрят на развитие бизнеса как на процесс детального планирования и прогнозирования, жесткого контроля и регламентации даже на этапе становления.
К счастью, я узнал, что методология гибкой разработки программ родилась во многом из бережливого производства, уходящего корнями в Toyota и реальное производство, то есть как раз вышла из бизнес-механики. Затем я попал во ФРИИ, где учат молодых предпринимателей быстрее достигать целей и развивать свой бизнес. Наверное, вы догадались — там учат как раз такому гибкому подходу к развитию бизнеса.
И вот на русском языке вышла книга Джеффа Сазерленда «Scrum: революционный метод управления проектами« (Манн, Иванов и Фербер, 2016). Для непрограммистов поясню, что Scrum — это самая популярная на сегодняшний день Agile-методология разработки. Книга примечательна тем, что Джефф — автор методологии Scrum, а не просто ее последователь.
Просто взять и начать применять гибкие методологии сложно даже в среде программистов, где основные участники процесса любят процессы и регламенты. Насколько же возможно применять такие методы с «обычными» людьми? Как перестроиться и поверить, что эта методология может помочь? И ее ли нужно выбирать? Конечно, процесс смены всегда болезнен, полон ошибок и неудач, поэтому крайне важно постоянно следить за тем, как и что происходит, по верному ли пути идет развитие команды и проекта, над которым она работает.
Книга изобилует фактами о истории рождения этого подхода, результатах, которые показывала система в совершенно разных ситуациях, включая проекты государственных федеральных компаний, а также раскрываеют нюансы ответами на вопросы «почему именно так». Получилось достаточно полное, хотя и во многом теоретически-вдохновенческое чтиво, которому не хватает конкретики, но являющееся важной основой для понимания отличия методологии от классической. Во многом эта книга рассказывает уже о философии, то есть о том фундаменте, который лежит в основе подхода, и потому станет отличным входом в технологию. Затем уже можно будет изучить все на практике по более детальным инструментам и пособиям, но в этой книге можно получить ответ на главный вопрос — стоит ли пытаться и что это дает, а также кому подходит такая методология.
В особенности рекомендую почитать ее не-программистам, которые делают бизнес. Удивитесь, насколько эффективно программисты, считающиеся повсеместно интровертами, продвинулись в менеджменте.
От себя отмечу, что выход книги поразительно совпал с началом моей работы в двух новых проектах, в которых, конечно же, мы начали работать как раз по Scrum. Начинать такое всегда тяжело, но конкретные сильные результаты мы получили буквально за пару недель.
Возможно, напишу об этом отдельный пост, а пока же — прочитайте эту книгу, лишней она не будет никому 🙂