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

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

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

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

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

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

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

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

(Справедливости ради стоит отметить, что его команда — островок бережливости в море каскадного управления, до сих пор преобладающего в компании. И хотя руководителю по продукту удалось изменить образ мышления и ритм движения организации, люди, перед которыми он держит отчет, пока не понимают глубинных принципов адаптивного и бережливого обучения и его потенциала. Им достаточно видеть движение на бумаге.)

Чтобы продвинуть проект среди сотрудников и среди руководителей, требуются два разных подхода к управлению.

Во время обсуждения мы договорились внедрить несколько принципов адаптивного и бережливого управления проектами (избегая при этом самих слов «адаптивный» и «бережливый»).

1. Ценность создают люди (именно они находят решение или приходят к выводу, что оно соответствует миссии), а не процессы и отчеты.

2. Тем не менее процесс и отчетность – это важные составляющие управления организацией и проектами.

3. На ранних стадиях работы над проектами создание продуктов с минимальной функциональностью и затем их поступательное улучшение важнее документации и отчетности.

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

5. Путь к результату (решение/соответствие миссии) нелинеен, и все команды идут по нему с разной скоростью.

Долго убеждать не пришлось: наш клиент согласился на то, чтобы вместо ежеквартальных проверок команда руководителей еженедельно собиралась с 4-5 менеджерами и они вместе обсуждали развитие 16-20 проектов. Это значило, что итерационный цикл — хоть и по-прежнему длинный — сократится с трех месяцев максимум до одного.

Еще важнее то, что мы решили: разговор будет идти о результатах, а не об отчетах. Так устная коммуникация начнет превалировать над бумажной. Обзорные совещания будут посвящены частоте поставок, постепенному развитию и устранению препятствий. Команда нашего клиента будет продолжать составлять отчеты и делиться ими с другими командами для взаимного обучения.

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

Я понял, что участники совещания окончательно поняли, что я имею в виду, лишь к концу встречи. Клиент спросил свою команду: «Если пойти дальше, кто из членов команды сможет управлять бережливым, а не каскадным процессом?». Меня порадовало, когда они решили, что для управления бережливым процессом потребуется меньше людей, чем раньше, главное — чтобы они умели работать в хаотичной среде постоянного обучения.

Жду не дождусь нашей следующей встречи.

Об авторе. Стив Бланк (Steve Blank) — преподаватель Стэнфордского университета, старший научный сотрудник Колумбийского университета и лектор Калифорнийского университета в Беркли. Автор книги «Четыре шага к озарению», сооснователь или один из первых сотрудников восьми высокотехнологичных стартапов.