Agile-менеджмент. Лидерство и управление командами

С такой же смешанной реакцией столкнулась и методология, изложенная в «Руководстве к своду знаний об управлении проектами» (Guide to Project Management Body of Knowledge, PMBOK), издаваемом и поддерживаемом Институтом управления проектами. Интересно, что это руководство первоначально возникло как описание лучших практик в области проектного менеджмента в целом. С момента первого издания в 1987 году оно подверглось нескольким переработкам и стало ближе к идеологии Agile в качестве реакции на успехи, достигнутые проектными менеджерами, практикующими гибкие методологии. В отличие от CMMI, методология, продвигаемая в рамках PMBOK, предлагает проектным менеджерам конкретные рекомендации относительно управления проектами. И хотя рекомендуемые ею практики не всегда хорошо сочетаются с принятыми в гибких методологиях, многие проектные менеджеры предпринимают активные попытки преодолеть имеющиеся расхождения. То же самое можно сказать о PRINCE2 – похожей методологии, издаваемой и поддерживаемой британским министерством государственной торговли. Эта методология используется главным образом в Европе.

Последним важным направлением в этом списке будет унифицированный процесс разработки ПО, наиболее известный в версии унифицированный процесс Rational (Rational Unified Process, RUP). Он был разработан в 1997 году компанией Rational Software (сейчас принадлежит IBM). Для разработчиков ПО процесс RUP будет тем же, чем для проектных менеджеров стали методологии, изложенные в руководстве PMBOK. В нем содержится описание стандартизированных методов проектного управления, которые могут (и должны) адаптироваться к конкретным проектам; однако документация составлена таким образом, что весь подход зачастую воспринимается как бюрократический. Сторонники гибких методологий считают, что процесс разработки формируется в ходе проекта, начинаясь с минимального числа практик. В рамках RUP продвигается противоположный подход, в котором изначально предписывается большое количество практик с сопровождающей их рекомендацией, что в ходе проекта от ненужных практик можно отказаться. (Я часто сравниваю этот подход с покупкой Boeing 747, который владелец затем разбирает на части, чтобы собрать велосипед для поездок за покупками.) Неудивительно, что на фоне многочисленных успехов Agile-методологий этот подход подвергся нескольким ревизиям с целью сделать его более гибким, в результате чего возникли такие его модификации, как гибкий унифицированный процесс (Agile Unified Process, AUP), открытый унифицированный процесс (OpenUP) и минимально необходимый гибкий процесс (Essential Agile Process, EssUp). Но ни один из них не нашел широкого применения, сравнимого с распространением Agile-методологий.

Препятствие на пути Agile-методологий

Эмпирические данные вновь и вновь подтверждают, что Agile-методологии, если правильно ими пользоваться, обеспечивают огромный возврат инвестиций [Rico 2009]. Но если эти методологии дают столь блестящие результаты, то почему далеко не все ими пользуются? И почему столько проектов по разработке ПО во всем мире все еще заканчиваются неудачами?

В опросе, посвященном оценке текущего состояния Agile-методологий, проведенном в 2009 году компанией VersionOne, респонденты в качестве причин, препятствующих принятию компаниями гибких методологий, указали следующие: «менеджмент настроен против изменений», «опасение утратить управленческий контроль», «недостаточная техническая дисциплина», «команды настроены против изменений» и «недостаточный уровень компетентности разработчиков». Параллельно упоминается потребность организаций в планировании, предсказуемости и документировании своих действий [VersionOne 2009].

Подождите… Давайте еще раз вглядимся в эти причины: тут говорится об управленческом контроле, управлении организационными изменениями, выращивании талантов…

Простите, возможно, я не прав, но… разве все это не прямые функции менеджмента? Не значит ли это, что именно менеджеры по всему миру будут основным препятствием на пути внедрения Agile-методологий?

Как менеджера меня расстраивает этот вывод.

А как автора – радует.

Я думаю, что гибкие методологии упустили из поля зрения важность линейного менеджмента. Если менеджеры не знают, чем им заниматься и чего ожидать от внедрения гибких методологий в своих организациях, то почему они должны поддерживать переход к этим методологиям? В чем состоит послание Agile-методологий этим менеджерам? В том, что «менеджеры нам не нужны»? Тогда неудивительно, что внедрение этих методологий наталкивается на препятствия во всем мире.