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

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

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

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

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

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

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

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