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

Что такое «гибридные подходы» к управлению проектами?

Гибридные проекты стали «возникать на радаре» где-то примерно с 2015 года. Но, вероятно, они существовали намного раньше. Сегодня у нас нет общепринятого определения, что такое гибридный проект или гибридный подход. Никаких стандартов или сводов знаний на гибридные технологии пока нет. Поэтому сейчас можно называть гибридом все подряд. И даже проекты, которые реализуются «абы как», можно смело называть гибридными, ведь они используют не только классические методы управления проектами, а и что-то уникальное, возможно «доморощенное».

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

Agile – это очень сильно неоднородный подход, существует целое семейство практик Agile. На рисунке 1 показан «лес Agile» (Agile forest), который нарисовал голландский методолог Хенни Портман. Эта схема начиналась с десятка деревьев (методов), а сейчас вы видите, что лес разросся до сотни методик разных уровней.

Рис. 1. «Лес Agile» – семейство практик Agile

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

• методики в блоке Team-targeted ориентированы на команду;
• методики в блоке Culture-targeted ориентированы на культуру.

С точки зрения этих методик не существует такого объекта для управления, как проект. То же самое в блоке SAFe, эта методология также не признает проекты. Вместо этого объект управления в ней – ART (Agile Release Train).

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

Другое возможное определение гибридных подходов к управлению проектами фокусируется на неопределенности:

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

Кейс компании Intel: Проблемы с запуском процессоров

Гибридные проекты — это поиск выхода и адаптация к сложной реальности. Давайте посмотрим на конкретный кейс. История разработки компанией Intel одного из поколений процессоров Pentium хорошо иллюстрирует сложность и вызовы управления крупными проектами.

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

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

Эффект снежного кома проблем. График напряженный и все это понимают. Нет возможности сказать «я не успею», но некоторые недоработки и баги, если они явно не видны, можно передать по цепочке другим подразделениям, пусть они разбираются.

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

Замкнутый круг авралов. Жесткие сроки без права на перенос привели к системным переработкам специалистов: ночная работа стала нормой. Последствия такого подхода — дефекты в итоговом продукте. Возник риск попасть в ситуацию, когда процессоры, несмотря на окончание проекта разработки, требовали доработок уже на стадии внедрения.

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

Что помогло разорвать замкнутый круг авралов? Руководство компании Intel предприняло системные меры для преодоления «порочной петли». Команды провели детальный анализ ситуации и проблем и пришли к выводам о том, что необходимо изменить в планировании и работе с проблемами.

1. Реалистичность обязательств, итерации и соответствующий горизонт. Команда должна брать обязательства, только если уверена в их достижении. И если мы требуем от членов команды подписываться под тем, во что они не верят, то это не сработает, они вообще не будут отвечать ни за какой план. Однако как же взять обязательства за такой сложный проект в целом? На ранней стадии оценки показывали заметную вероятность превышения сроков и руководитель проекта чувствовал себя совсем неуверенным в достижении целей. И когда он попытался взять обязательства на весь горизонт, команды сказали «нет, мы не готовы». В итоге командам был предложен подход коротких итераций, с коротким горизонтом обязательств, не превышающим 4–6 недель. И только через 6 месяцев такой работы команды были готовы взять обязательства до конца проекта и дать точные сроки окончания проекта.
2. Совместное планирование итераций. Планирование итераций стало обязанностью не одного менеджера, а всей команды. Каждая маленькая команда берет обязательства вокруг того, что понимает, и на срок итерации, а также дает оценки по поводу того, что будет дальше. Такой подход дал возможность каждому участнику проекта брать на себя ответственность, что снижало вероятность превышения сроков и повышало управляемость.
3. Планирование и «сверху вниз» и «снизу вверх». Оптимальная модель планирования требовала учета как директивных сроков сверху, так и реалистичных оценок снизу. Давление только сверху демотивировало команды, а отсутствие контроля сверху вело к бесконечным срокам. В результате был найден компромисс: команды ориентировались на общий дедлайн, но имели свободу в рамках каждодневных целей и допущений.
4. Планирование – это обмен допущениями. Выстраивание допущений в рамках метода покерного планирования (техника оценки, основанная на достижении договорённости, используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач) стало ключевым фактором успеха. Это позволило согласовать ожидания: если одна подгруппа оценивает задачу в четыре недели, а другая в одиннадцать, выравнивание позиций помогает значительно уточнить план.
5. Культура открытого диалога о проблемах. Для эффективного управления была введена практика регулярных обсуждений проблем. Страх перед признанием ошибок исчез, когда команды поняли: ошибки позволяют улучшать проект. Руководство не критиковало сотрудников за сложности, а помогало решать их. Это укрепило доверие между всеми уровнями управления.
6. Траектория движения небольшими «победами». Каждое выполненное обязательство – «победа» команды — стало частью траектории «побед», что давало мотивацию, для достижения цели следующей итерации.
7. Героизм ради соблюдения сроков – это ненормально. Команды сконцентрировались на устранении причин авралов, а не на их преодолении сверхусилиями. Уменьшение уровня авралов позволило удерживать лучших сотрудников, что напрямую повлияло на улучшение результата и снижение количества дефектов.

После внедрения новых практик Intel удалось сократить отклонение сроков от запланированного до +/- 10% вместо прежних 40%. Количество багов и претензий от клиентов значительно уменьшилось, а качество конечного продукта заметно улучшилось. Этот кейс иллюстрирует, как важно корректировать подходы к управлению для сложных проектов.

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

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

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

1. Сложные и междисциплинарные проекты. Если проект включает в себя не только внедрение ИТ-системы, но и изменения в бизнес-процессах, найм персонала и даже строительство инфраструктуры, классическое управление проектами вполне эффективный инструмент. Такой проект сложно представить без четкой структуризации и последовательного подхода.
   Классическое проектное управление позволяет эффективно справляться с проектами, где взаимосвязанность элементов критична, а успешный результат требует слаженной работы всех компонентов: бизнес-процессов, ИТ-систем и команды.
2. Ограничения и рамки. Жесткие временные и финансовые ограничения – это еще одно основание для выбора классических подходов. Например, регуляторные требования, которые требуют соблюдения множества правил и жесткого соблюдения сроков. Здесь нет места компромиссам, поскольку нарушение сроков может обернуться санкциями или серьезными штрафами.
3. Ограниченная доступность спонсора проекта. Часто проектные команды сталкиваются с минимальной вовлеченностью заказчика и здесь подходят классические методы управления, которые включают значительный элемент бюрократии могут стать единственно возможным вариантом. Если обратная связь от заказчика ограничена и фрагментирована, то необходимо фиксировать договоренности письменно и тщательно согласовывать каждый этап. Например, команда, работающая над крупным проектом внедрения ERP-системы, с трудом получала ответы от заказчика, сталкиваясь с постоянными переносами встреч. Решением стало четкое документирование ключевых этапов и фиксация результатов на каждом из них.
4. Высокая цена ошибки. Бывают проекты, где цена ошибки запредельно велика и ставит под угрозу весь проект и даже больше. Представьте себе запуск марсохода: нельзя допустить критической ошибки, ее невозможно будет исправить в разумные сроки. Если хоть один компонент не готов, миссия проваливается. Подобные проекты требуют детального управления рисками, где подходит именно классический подход.
5. Работа с незрелыми и временными командами. На практике часто приходится вести проекты с временными командами или людьми, занятыми параллельно другими задачами. Такая ситуация отлично подтверждает: в условиях распределенных усилий и незрелости команды классический проектный менеджмент с его строгими рамками действует эффективно.

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

1. Изменчивые и нечеткие требования. Нечеткие требования были и раньше и классическое проектное управление разработало целый набор методов перевода их в четкие и определенные. Однако такая тактика исходит из того, что четкие требования должны быть сформулированы, просто должны быть по определению. Желание вполне оправданное, однако, реалии современного мира все чаще заставляют сомневаться в том, что это возможно в действительности. Для изменчивости требований ситуация аналогичная.
   
   Тот новый уровень изменчивости требований, который диктует сегодняшнее окружение проекта не может быть «отработан» инструментами классического проектного управления.
2. Изменчивая внешняя среда. Современные реалии, включая санкции, пандемии и экономические сдвиги, требуют, чтобы проекты мгновенно адаптировались к новой ситуации. Ситуация быстро изменяется, планы корректируются, а ресурсы перераспределяются.
   
   Но классическое проектное управление не готово к этому: оно недостаточно гибкое, чтобы адекватно отреагировать на неожиданные вызовы.
3. Новые технологии. Работа с инновационными решениями, такими как искусственный интеллект, добавляет к проекту исследовательскую составляющую. Отсутствие опыта и готовых прототипов усложняет прогнозирование и планирование. Это подчеркивает необходимость существенных изменений в проекте и обеспечения высокой гибкости.
4. Сильное сопротивление людей и влияние человеческого фактора. Когда проект требует изменений в поведении или подходах, человеческий фактор выходит на первый план. Сопротивление сотрудников — от саботажа до откровенного отказа — создает серьезные барьеры.

На основе этот списка характеристик можно попробовать определить, что такое гибридный подход к управлению проектом

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

***

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

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