Гибридные подходы к управлению проектами. Обзор вариантов гибридизации

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

Меня зовут Павел Алферов, я профессор бизнес-практики московской школы управления «Сколково». Больше 20 лет я занимаюсь четырьмя направлениями: управление проектами, управления знаниями, управление изменениями и цифровая трансформация бизнеса.

Сейчас много преподаю в разных местах, до этого работал в крупных российских и международных компаниях – ТНК-BP, X5 Retail Group, Альфа групп. Почти 5 лет проработал в оргкомитете Сочи-2014 и до сих пор являюсь экспертом Международного олимпийского комитета по управлению проектами и управлению знаниями.

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

Популярность методологий

За 2019 год есть исследования по состоянию Agile в мире и в России. Общемировое исследование проводила компания VersionOne. А исследование по состоянию Agile в России – компания ScrumTrack.

• В 2019 году из общемировых компаний, работающих по Agile, Scrum применяли 54%. Практически такие же показатели показал опрос Agile-сообщества в России – применяющих Scrum за 2019 год тоже около 50%.

• Вторым по распространенности оказался гибридный подход – и в мире, и в России. Причем в мире популярность гибридных подходов – 14%, а у нас – 30%, в два раза больше. Все-таки у нас больше принято изобретать свой собственный велосипед.

При этом Agile – штука неоднородная, есть целое семейство практик Agile.

Эта картинка называется Agile forest – «лес Agile» из разных фреймворков. Этот “лес” сформировал в своем блоге голландский методолог Хенни Портман. Начиналось все с десятка деревьев, а сейчас вы видите, что лес разросся, есть под сотню разных методик разных уровней.

Из всех этих методик знаком широкой аудитории и ассоциируется с Agile только Scrum. Но Scrum – это один из многочисленных фреймворков реализации Agile, который находится на уровне команд вместе с Канбаном (кстати авторы Канбан теперь говорят, что Канбан это не Agile).

При этом часть этих методик вообще не про проект.

• Например, методики в блоке Team-targeted ориентированы на команду.

• В блоке Culture-targeted – на культуру. С точки зрения этих методик, проекта, как такового, не существует. Там нет такого объекта для управления – проект. Соответственно и управления проектом тоже нет.

• То же самое в блоке SAFe – я сертифицирован по методологии SAFe, и могу сказать, что она также не признает наличие проектов. У них там есть такой объект управления как ART (Agile Release Train), а проектов нет.

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

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

Обобщая эти исследования, я выделил пять способов: как выстроить гибридную систему управления проектами – как управлять проектом в гибридном подходе, соединяя элементы классики и Agile.

Подход 1. Через неопределенные элементы скоупа

Логика гибридизации через неопределенные элементы скоупа проста:

• Сначала строим стандартную структурную декомпозицию работ и результатов и выстраиваем определенный верхнеуровневый план с низкой детализацией. Тратим при этом минимум сил.

• Далее определяем для каждого элемента, какой из них явный, а какой – неопределенный.

  • Для определенных элементов, например, обучения, составляем список участников, рассылаем приглашения и тестируем. Все предиктивно, неопределенности особой нет.

  • Или берем неопределенный элемент – например, разработка сложного ПО. То, что нам понятно, делаем по классике, делаем детальный план. А то, что непонятно – делаем по Agile.

• Ключевой вопрос в этом подходе – как синхронизировать классические и гибкие элементы и установить между ними связи.

Этот подход описан в Манифесте гибридного управления проектом.

В пику манифесту Agile, компания BinFire (производитель ПО для управления проектами) выпустила свой манифест о том, как применять гибридные подходы по вышеописанной логике, когда:

• мы берем определенные требования к продукту;

• разбиваем продукт на компоненты;

• по каждому компоненту делаем структурную декомпозицию;

• у нас формируется бэклог;

• и мы спринтами его крутим.

Коллеги из BinFire не только описали этот подход, но и проанализировали, какие ИТ-системы лучше всего его поддерживают.

Вы удивитесь, но лучше всего гибридный подход к управлению проектом поддерживает продукт компании BinFire. Все производители ПО уже давно поняли: хочешь продвигать свой продукт – придумай методологию, которая будет ему соответствовать. Но если исключить продукт BinFire и посмотреть на остальное, то:

• Wrike – один из наиболее продвинутых продуктов с точки зрения гибридной функциональности.

• SmartSheet я бы поднял повыше – это очень мощное приложение.

• Тут можно спорить, насколько правильно по осям x и y находятся эти приложения, но еще я бы добавил на слайд Jira с важным уточнением: Jira без дополнительных плагинов – точно не гибридное приложение. Но плагины вроде BigPicture действительно превращают Jira в продукт для гибридов. Я считаю, что Jira хороша с точки зрения Collaboration (Взаимодействие) и довольно высоко с точки зрения Hybrid Functionality (Функциональность для Гибрида). Я бы ее поставил на этой схеме чуть ниже Wrike. Единственный нюанс – для айтишников Jira довольно хорошо заходит, а простые люди при виде этих жутких карточек с гигантским количеством полей впадают в ступор. Поэтому Jira для гибридного управления ИТ-проектами достаточно хорошо подходит, а для бизнеса, боюсь, это будет не очень хороший выбор.

Я сейчас показываю логичный подход сверху, как строить проект по гибридным методологиям заранее. Но это – действительно факт, очень часто гибридный подход складывается сам по себе, когда пытаются начать жить по Agile, обламываются и придумывают, как его соединить с контрольными точками. Я считаю, это самый правильный подход. Или, наоборот, действуя по предиктивному подходу, понимают, что не получается, и вносят элементы Agile.

Подход 2. По уровням управления – разделение подходов на разных уровнях управления

Разделение подходов по уровням управления отражено в британском стандарте Prince2 Agile. И есть российский стандарт Андрея Малахова – Парацельс ПиЭм (Paracelsus PM).

Общая логика одна и та же. Рассмотрим на примере Prince2.

• У нас есть уровень руководства, и тут классика: у нас отмечены управляющие комитеты, мы ставим контрольные точки, отчитываемся.

• Промежуточный уровень управления проектом – Project Manager,

• И нижний уровень – Delivery (Поставка). На уровне Delivery мы крутим спринты по Agile.

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

Интересный пример по гибридному подходу от компании SPLAT Cosmetics. Используя гибридный подход к управлению, компания разрабатывала разные зубные пасты. Подробнее об этом внедрении для SPLAT можно почитать в статье. Есть еще один пример применения этой логики – рассказ о том, как разрабатывали «Спасибо» для Сбербанка.

Как строятся проекты по разработке новых продуктов с использованием гибридных подходов?

На верхнем уровне у руководства:

• в ИТ-системе был определенный дашборд по портфелю всех этих проектов по разработке новых продуктов;

• был отдельный график, где отслеживались определенные контрольные точки (вехи);

• была физическая доска, куда это переносили для наглядности;

• и проводились регулярные управляющие портфельные комитеты, где рассматривалось, как идет движение.

На нижнем уровне у участников команды:

• был индивидуальный дашборд с плановыми задачами, определенными сроками для этих задач, контрольными точками и блокираторами (обсуждалось, как их снять);

• и проводились сессии.

«Клеем» между верхним уровнем и нижним выступил руководитель проекта, который сводил вместе то, что делается в команде, с тем, что видит руководство. Для этого он использовал:

• календарно-сетевое планирование с контрольными точками;

• командные доски;

• и еженедельные совещания.

Подход 3. Через факторы сложности

Третий вариант – нестандартный, он родился, когда мы с коллегами делали документ «Agile-подход в государственном управлении». В этом документе мы обобщили, как Agile используется в госорганах, к сожалению, в основном, иностранных: в России примеров на 2021 год очень мало.

Рекомендую прочитать эту книгу даже тем, кто не имеет отношение к госорганам. Там базовым образом объяснено, что такое Agile. Специально попытались написать так, чтобы любой простой сотрудник госорганов мог это понять.

Во время работы над документом встал вопрос о границах применения. Были жаркие дискуссии: коллеги настаивали на том, что Agile как база должен быть везде. Я говорил о том, что так может не получиться.

Я предложил систематизировать эту дискуссию через модель управленческой сложности. Есть такая модель, она выложена на сайте Центра оценки и развития проектного управления (ЦОРПУ). Она описывает, что делает проект сложным. Причем, она применима для всех типов проектов – не только для ИТ-шных.

В итоге мы с коллегами прошлись по модели управленческой сложности, определяя, почему использовать в проекте Agile может быть сложно.

Возьмем пример: фактор сложности – длительность проекта.

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

• Если проект длится больше 12 месяцев, то по умолчанию использовать Agile уже нельзя, нужно подстраивать его под особенности. И это – только для опытных Agile-команд, потому что начинающие с этим, скорее всего, не справятся. Опытная команда должна разбить на три месяца задачи по спринтам, а остальные девять месяцев разбить по контрольным точкам.

И по каждому виду сложности в документе приведены свои рекомендации: даже если Agile внедрить сразу не получается, как его все-таки приспособить, какие лайфхаки применить для того, чтобы это работало.

Мы уже посмотрели три подхода:

• Через неопределенные элементы скоупа

• По уровням управления – выделяя на верхнем уровне классические подходы, а на нижнем – Agile

• Через факторы сложности, определяя, что нам мешает применить Agile по умолчанию, обходя подводные камни, которые не дают течь потоку Agile-трансформации.

Подход 4. Режимы по этапам

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

На слайде – модель Cynefin, которая классифицирует системы по степени сложности и неопределенности. Она широко используется специалистами по Agile, чтобы показать, где Agile хорошо сработает.

• Agile хорошо работает в запутанном домене – когда высокая неопределенность и не понятно, что делать.

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

• Для простых систем работает простейший плановый подход.

• И самый тонкий момент – это хаотические системы. За ними, я думаю, будущее теоретических изысканий на тему: как правильно организовать работу в хаотическом режиме. Это – штабной режим. Те, кто внедрял крупные системы ERP или CRM, знают, что есть этап проектирования, а потом появляется точка go-live, когда все планы реализованы и нужно превращать в порядок хаос, который привносят пользователи.

Можно использовать подходы Agile на отдельных этапах проекта.

Классический пример – использование при проектировании атомной электростанции. Считается, что по Agile атомные электростанции строить нельзя, и это правильно, строить пока не научились, а вот проектировать можно.

Летом 2016 года шла большая дискуссия между Россией и Финляндией на тему, не построить ли нам, России, атомную станцию в Финляндии.

Финны говорят, что это хорошая идея, но американцы и французы уже разорились на стройке. Наши были уверены в успехе, у нас уже был проект системы, сейчас такую же построили в Беларуси и в Ленинградской области – все прекрасно работает.

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

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

В итоге пошли по пути Agile:

• ввели роли – старший продакт-оунер, главный администратор и представитель заказчика;

• разбили проект на группы – нормативы и требования к безопасности, архитектурно-строительные решения, компоновочные решения, вентиляция и отопление, защита от тер. угроз;

• в каждой группе был: технический лидер – так они назвали продакт-оунера; администратор – так в Росатоме назвали Scrum-мастера; и команда – дернули людей из Нижнего Новгорода, из Питера, из Москвы и посадили вместе в эти группы.

А дальше – классическая Agile-история: доски, общее рабочее пространство, места для переговоров. Вот этот мощный мужчина – первый Scrum-мастер Росатома. В интернете есть его детальный рассказ, как это все работало.

В итоге получили очень успешный проект, сократился на 26% объем зданий ядерного острова, из-за чего удалось сэкономить миллиарды рублей, сотни миллионов евро.

Все требования были учтены, три месяца шел проект, и закончился успешно.

Дальше проект вернулся в жесточайшую классическую рамку.

Подход 5. Через выбор актуальных инструментов

Последний вариант мне наиболее близок – это когда мы не строим глобальную рамку, а выбираем инструменты под ту ситуацию, которая сложилась.

Я работал с крупной ритейловой компанией, у которой была программа пилотных проектов: 10 пилотов, каждый – с отдельным стартапом, от виртуальной реальности до Data Science.

Ритейлер хотел запустить четырехмесячные проекты-пилоты и протестировать, насколько хорошо они работают. Я должен был помочь спроектировать систему управления этими проектами и обучить ей.

Мы оперативно набросали профиль для управления инновационными пилотами.

• У каждого пилота три этапа: подготовка, реализация и завершение.

• Внутри всех этапов крутятся спринты: на первом этапе два спринта, на последнем – тоже, а остальные спринты на этапе реализации.

• Выделили роли, полномочия и ответственных – кто что должен делать.

• Выделили необходимые совещания: стартовые совещания, регулярные встречи команды, еженедельные встречи с трекером от фонда Сколково, который помогал это все реализовывать.

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

Минимум документов:

• паспорт пилота (устав проекта – 5 слайдов);

• итоговая презентация по пилоту;

• И рабочие документы – еженедельный отчет команды и еженедельный отчет трекера.

Плюс – базовые ИТ-инструменты.

Фактически под ситуацию была сверстана система управления, которая достаточно хорошо себя зарекомендовала.

С точки зрения пятого подхода система управления выстраивается, исходя из тех инструментов, которые у вас есть. И эти инструменты закрывают проблемы и потребности, с которыми вы столкнулись.

По ссылке можно скачать список самых популярных инструментов, из которых можно собирать такие системы.

Зеленым на этой схеме обозначены инструменты классических методологий, синим – инструменты Agile, а серым – смешанные.

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

Вопросы

Не кажется ли вам, что статистика о том, что у нас гибридных подходов в стране 30%, не очень хорошо собрана? Потому что у нас проекты, которые реализуются абы как, называются гибридами.

Эту статистику собирала компания Scrum Trek. Я эту компанию очень люблю, они большие молодцы, но они радикальные аджалисты. Поэтому они собирали мнения среди аджалистов. Поэтому выбор и сдвинут в сторону тех, кто в Agile пошел достаточно активно.

И еще важно то, что у нас нет определения тому, что такое гибрид. ГОСТа на гибридные технологии пока нет. Поэтому сейчас можно называть гибридом все подряд.

Поэтому с одной стороны, вы правы. Да, эта статистика явно завышена. А с другой стороны, что-то она отражает.

Можете ли вы прокомментировать утверждение о том, что в России не работают на 100% классические схемы?

Для ответа на этот вопрос есть отдельное направление исследования. И я обычно все свои курсы всегда начинаю с отдельного блока – национальные особенности управления. И там я как раз разбираю, что у нас объективно они есть, и именно эти национальные особенности не позволяют западным практикам применяться AS IS, как в книге написано. Поэтому – да, я согласен с утверждением, что 100% классические схемы, как написано в PMBoK, в России не работают. Они мутируют.

Вообще любые управленческие практики, применяющиеся на Западе с 17 века, при переносе на нашу почву мутируют. Нам приносят одно, а приживается другое.

Я думаю, что гибриды – это то, куда мы идем. Это будет основным. Те пять вариантов гибридизации, которые я рассмотрел, не единственные. То, что мы сейчас видим с гибридами – это Emergent Practice в терминах модели Cynefin. Практики, которые рождаются в запутанном домене, когда люди разбираются, как это все работает.

Я уверен, что через 5-7 лет гибридные подходы станут уже более-менее стандартными, и даже ГОСТ, я думаю, появится. Но пока это формируется на глазах.

ГОСТов по гибридам нет. Но изучать их нужно. Вопрос – как?

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

Для гибридизации через неопределенные элементы скоупа имеет смысл изучать те подходы, которые уже описаны. Тот самый «лес Agile». Здесь можно посмотреть:

• PRINCE2 Agile – очень хороший документ, правда, на иностранном языке.

• Есть документ PMI-ACP (DAD) – Disciplined Agile Delivery. PMI купил разработчика этой Agile-практики и сделал ее своей. Эта книга переведена на русский, называется «Как использовать Agile-практики в проектах».

• И посмотрите Парацельс ПиЭм – разработку Андрея Малахова. Она тоже очень интересная.

Статья написана по итогам доклада (видео), прочитанного на онлайн-митапе, посвященном гибридным подходам к управлению ИТ-проектами.