Очень странный Agile | Harvard Business Review Russia
Управление изменениями

Очень странный Agile

Стив Бланк
Очень странный Agile
JON SHIREMAN/GETTY IMAGES

AgileFall — ироничный термин, описывающий такой метод управления управления проектами, при котором вы пытаетесь быть адаптивным и гибким, но продолжаете пользоваться каскадной моделью разработки Waterfall. Часто это дает результат, похожий на смесь паркетного воска и кондитерского топпинга.

Я столкнулся с AgileFall, сидя на одном из совещаний по управлению проектами. Правда, всего несколько изменений, внесенных в процесс, вернули нас в нужное русло.

Совещание проходило в компании, входящей в первую десятку списка крупнейших компаний по версии журнала Fortune. Мы помогаем им преобразовать одну из важнейших производственных линий в существующем подразделении, используя гибкие методы управления вместо каскадирования.

Наш клиент, руководитель по продукту компании-заказчика, оказался умным, склонным к инновациям и мотивированным человеком. Его компания столкнулась с натиском конкурентов, и он понял, что традиционный каскадный метод управления неуместен, когда в уравнении с проблемой и ее решением слишком много неизвестных.

На производственной линии, которой он занимается, работают 15 менеджеров, управляющих 60 проектами. За последние несколько месяцев мы помогли руководителю внедрить в эти проекты основные принципы бережливости (по методу Lean). Все проекты относятся к первому или второму горизонтам (подробнее о модели горизонтов читайте здесь), что подразумевает разработку новых функциональностей для продуктов, нацеленных на существующих клиентов, или перепрофилирование существующих продуктов, инструментов и технологий для новых клиентов. На данный момент команды создают продукты с минимальной функциональностью (MVP), вживую общаются с пользователями и заинтересованными сторонами, прежде чем резко сменить стратегию или предпринять иные действия. Все это составляет основу концепции бережливости.

Однако во время последнего совещания я понял, что руководитель по продукту все еще управляет своими менеджерами по каскадному методу. Команды отчитывались — вы только представьте — раз в три месяца на официальном итоговом совещании. Клиент как-то упомянул, что участники команд жалуются на объем бумажной работы, которую они вынуждены выполнять при подготовке к совещанию. Он же бы недоволен качеством отчетов и полагал, что большинство из них были написаны накануне ночью. Руководитель спрашивал нас, как ему получать еще больше показателей эффективности и своевременной отчетности от менеджеров проектов.

Поначалу я даже подумал: «Действительно, чем плохо иметь большое количество данных? Решения, основанные на фактах, — не к этому ли мы стремимся?» Я чуть было не соблазнился этой идеей, но вовремя осознал, что у нашего клиента процесс до сих пор выстроен таким образом, что успех измеряется отчетами, а не результатами. Это был все тот же процесс, где эффективность проектов измерялась по линейной, пошаговой каскадной системе.

Полная версия статьи доступна подписчикам
Вы уже подписаны?
Тогда авторизуйтесь
советуем прочитать
Хотите научиться думать?
Мариэтта Чудакова
Ваша компания слишком осторожна
Дэн Ловалло,  Тим Коллер,  Роберт Уланер,  Дэниел Канеман
Как наладить эффективные продажи во время кризиса
Яков Сергиенко,  Александр Каменсков