Гибридные подходы к управлению проектами

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

Рис 2. Пять вариантов как можно выстроить гибридную систему управления проектами

Вариант 1. Agile в неопределенных элементах объема проекта (scope)

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

1. Сначала строим стандартную структурную декомпозицию работ и результатов и выстраиваем верхнеуровневый план с низкой детализацией. И на это тратим минимум сил.
2. Далее определяем для каждого элемента, какой из них ясный и понятный (например, закупка серверов для новой ИТ-системы), а какой – неопределенный и непонятный (например, доработка сложного функционала бизнес-приложения при неясных требованиях).
3. Для ясных и понятных элементов, которые предсказуемы, используем классические методы: планируем работы, выполняем и проверяем.
4. Для неопределенных и непонятных элементов, которые не предсказуемы, то, что непонятно делаем по Agile, а то, что понятно (если такое есть), делаем по классическим подходам.

Очевидно, что ключевая проблема этого варианта – как синхронизировать классические и гибкие элементы и установить между ними связи. Вариант этого описан в документе с любопытным названием «Манифест гибридного управления проектом», который выпустила компания BinFire (производитель ПО для управления проектами). Это манифест о том, как делать гибридную систему управления проектом по этой логике (рис. 3):

• мы берем определенные требования к продукту;
• разбиваем продукт на компоненты;
• по каждому компоненту делаем структурную декомпозицию;
• формируем бэклог задач;
• далее выполняем его последовательными спринтами.

Рис. 3. Реализация варианта 1 гибридизации по версии компании BinFire

Вариант 2. Разделение подходов по разным уровнях управления

Разделение классических подходов и Agile по уровням управления отражено в британском стандарте PRINCE2 Agile. Он выделяет три уровня управления (рис. 4):

• Уровень руководства. Тут используются классические подходы: управляющие комитеты, четкие планы, контрольные точки и т.д.;
• Уровень управления проектом. Здесь тоже используются классические подходы и практики управления;
• Уровень поставки продукта проекта (Delivery). На этом уровне мы работаем по Agile и организуем итерации.

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

Рис. 4. Разделение подходов по разным уровням управления в PRINCE2 Agile

Интересный пример реализации этого варианта гибридного управления можно увидеть в компании SPLAT Cosmetics, которая использовала «гибрид» для разработки новых зубных паст. На верхнем уровне у руководства компании:

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

На уровне руководителя проекта, а также нижнем уровне у команды:

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

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

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

Вариант 3. Agile ограничен факторами сложности проекта

Этот вариант родился в результате дискуссий о границах применения Agile. Хотя многие настаивали на том, что Agile, как базовый подход, должен быть везде, однако, это слишком поверхностная точка зрения. Как и любые другие методы и концепции Agile имеет свою область применения. Существует «Модель управленческой сложности проектов», которая разработана Павлом Алферовым, профессором бизнес-практики бизнес-школы Сколково. Она описывает, факторы, которые делают проект сложным и применима для всех типов проектов. Например:

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

И модель управленческой сложности может показать, почему не получится использовать в проекте подходы Agile. Возьмем, например, такой фактор сложности, как «длительность проекта» (рис. 5).

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

Рис. 5. Ограничение использования Agile-подходов факторами сложности проекта

Вариант 4. Разные подходы на разных этапах проекта

Четвертый вариант исходит из того, что на различных этапах жизненного цикла проекта могут потребоваться различные подходы. Как к этому можно подойти? Один из самых интересных вариантов — использование фреймворка Cynefin («Киневин») Дейва Сноудена (Dave Snowden). Мы не ставим целью всесторонний рассказ о фреймворке Cynefin (о нем можно прочитать на сайте Всложности), но напомним основные моменты. Фреймворк Cynefin делит все системы на четыре типа:

• ясные (clear) или очевидные (obvious);
• усложненные (complicated);
• сложные (complex);
• хаотичные (chaotic).

Это глубокое разделение систем проводится на основе природы системы и, прежде всего, нашего знания ее причинно-следственных связей (рис. 6).

Рис. 6. Причинно-следственные связи между элементами систем и типы систем во фреймворке Cynefin

1. Ясные и очевидные (иногда их называют простые) — это системы с понятными причинно-следственными связями между элементами. Например, табуретка на 4 ножках: отпилишь две ножки — и табуретка не сможет стоять и упадет. Все ясно и понятно.
2. Усложненные (иногда их называют упорядоченные сложные) — это системы причинно-следственные связи в которых не всегда понятны и надо потратить время, чтобы разобраться самому в системе, или привлечь эксперта, который объяснит, как все это работает. Например, автомобиль, вряд ли все читатели детально разбираются в своих автомобилях, за нас с вами это делают профессиональные автомеханики. Или самолет, в котором более миллиона деталей, но, несомненно, есть эксперты, которые в них разбираются.
3. Сложные (иногда их называют запутанные) — это системы причинно-следственные связи которых запутаны и сейчас нам непонятны. Например, лягушка. Когда ее тыкают палочкой, у нее дергается лапка. Непонятно, от чего, и наука до сих пор разбирается с деталями и особенностями функционирования ее нервной системы. Когда разберется, появятся эксперты по лягушкам и эта система перейдет в класс усложненных систем.
4. Хаотические — это системы, в которых все настолько непонятно и размыто, что говорить о причинно-следственных связях крайне сложно, все смешалось и не удается выделить причины и следствия из них. Да еще, к тому же, система динамично изменяется.

Еще раз отметим, что это лишь краткое введение, подробнее о фреймворке Cynefin можно прочитать на сайте Всложности.

И это важный момент, так как подходы Agile работают в условиях повышенной неопределенности. Это позволяет использовать фреймворк Cynefin, чтобы показать, где хорошо сработает Agile. По версии Павла Алферова, вот какие практики хорошо работают в различных системах фреймворка Cynefin (рис. 7):

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

Рис. 7. Область запутанных и комплексных систем фреймворка Cynefin, где эффективен Agile

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

Но вернемся к различным этапам жизненного цикла проекта – по ходу своего жизненного цикла проект, как система, может переходить из одной области фреймворка Cynefin в другую. Классический пример – использование Agile при проектировании атомной электростанции. Летом 2016 года Финляндия и Россия договаривались о стройке атомной электростанции в Ханхикиви (Финляндия). К тому времени американцы и французы уже разорились на этой стройке, у России был проект станции, такую же построили в Беларуси и в Ленинградской области. Однако Финляндия потребовала учесть в проекте все европейские нормы, что вылилось в 4 тыс. дополнительных требований к строительству станции. Как решать такую задачу? Что делать? Это случай, когда строительство станции перешло из упорядоченно сложной области, где все было понятно экспертам, в запутанную и комплексную.

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

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

Три месяца шел проект и закончился успешно. Все требования и европейские нормы были учтены. В итоге получили очень успешный проект, объем строительства зданий ядерного острова сократился на 26%, из-за чего удалось сэкономить сотни миллионов евро. И затем проект строительства станции вернулся в жесточайшую классическую проектную форму. Этот пример показывает, как можно использовать Agile-подходы, если проект перешел в область высокой неопределенности. Фреймворк Cynefin сейчас широко используется адептами Agile, чтобы показать, где Agile хорошо работает. А хорошо он работает в запутанном домене, когда высокая неопределенность и непонятно, что делать.

Рис. 8. Самых популярные инструменты, из которых можно собирать гибридные системы управления проектами

Вариант 5. Выбор адекватных проектных инструментов под ситуацию

Все четыре предыдущих варианта – это подход «сверху», как строить управление проектом по гибридным методологиям заранее. Последний вариант, как можно выстроить гибридную систему управления проектами, – это когда мы не строим глобальную рамку, а выбираем инструменты под ту проектную ситуацию, которая сложилась. Это подход от конкретного момента, от «здесь и сейчас», а не от общей концепции. И, это факт, очень часто гибридный подход складывается сам по себе, когда пытаются начать жить по Agile, не получается и придумывают, как его соединить с плановыми контрольными точками. Или, наоборот, действуя по четкому плану, понимают, что не получается, и вносят элементы Agile. И пятый вариант управление проектом по гибридным методологиям: система управления выстраивается, исходя из тех проблем, потребностей и инструментов, которые у вас есть. От того, с чем мы столкнулись.

Павел Алферов приводит список самых популярных с его точки зрения инструментов, из которых можно собирать подобные гибридные системы управления проектами (рис. 8). Зеленым на этой схеме обозначены инструменты классических методологий, синим – инструменты Agile, а серым – смешанные. В таком варианте Agile выступает в качестве дополнительного ящика с инструментами, из которого руководитель проекта может набирать нужные ему.

***

Гибридные подходы к управлению проектами – это наше будущее. И очень интересное будущее. Современный мир управления проектами не может ограничиваться только традиционными или только гибкими подходами. Именно их адаптация к конкретным задачам и контексту делает проектное управление сложным. Однако те пять вариантов гибридизации, которые рассмотрены в статье, не единственные. Они возникают прямо сейчас, как и любые Emergent Practice в запутанном и комплексном домене фреймворка Cynefin, когда люди разбираются, как это все работает. Такое сейчас время. Через 5-7 лет гибридные подходы станут уже более-менее стандартными. Но пока они формируются на глазах.

Комментарии 0