Почему не следует сочетать agile с традиционными методами управления

Agilefall – остроумный термин, описывающий такой метод управления проектами, при котором вы пытаетесь быть адаптивным и гибким, но продолжаете пользоваться каскадной моделью разработки waterfall. Agile – система гибкого управления проектами, на основе которой были разработаны популярные методы scrum, kanban и др. Ключевой принцип – разработка короткими итерациями (циклами), в конце каждого из которых заказчик получает рабочий код или продукт. А waterfall – методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.

Часто сочетание agile и waterfall дает результат, похожий на смесь паркетного воска и кондитерского топинга.

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

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

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

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

Справедливости ради стоит отметить, что команда этого руководителя – островок бережливости в море каскадного управления, преобладающего в компании. Люди, перед которыми держит отчет этот руководитель, пока не понимают принципов адаптивного и бережливого обучения и его потенциала. Им достаточно видеть движение на бумаге.

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

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

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

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

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

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

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

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

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

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

В конце совещания руководитель спросил свою команду, что лучше – бережливый или каскадный процессы? Они ответили, что для управления бережливым процессом потребуется меньше людей, чем раньше, главное – чтобы они умели работать в хаотичной среде постоянного обучения.

Об авторе: Стив Бланк – преподаватель Стэнфордского университета, старший научный сотрудник Колумбийского университета.

Оригинал статьи здесь.