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

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

Что такое гибридные методы

Гибридные методы управления проектами — это такие методы проджект-менеджмента, которые используются, с одной стороны, при наличии жестких ограничений (в сроках, ресурсах, бюджете), с другой, в ситуациях, когда мало что понятно и все быстро меняется, например, в условиях пандемии, санкций и т. п. В экономике происходят радикальные изменения, и появляется необходимость развивать новые компетенции. Например, с появлением ChatGPT многие компании оказались вынуждены быстро адаптироваться к его возможностям, в том числе по выполнению аналитической и даже интеллектуальной работы.

Американский Институт управления проектами (PMI) одним из первых назвал совмещение разных подходов, позволяющее работать в условиях неопределенности, гибридным в своем исследовании Pulse of Profession в 2015 году. Далее этот термин стал распространяться в проектном сообществе и сейчас уже фактически является общепринятым. Согласно исследованию PMI от 2021 года, гибридные методы используются компаниями в 45% случаев и занимают второе место.

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

Почему коробочные методы теряют свою актуальность

Большинство методов, доступных на рынке, — коробочные. В отличие от кастомных, адаптированных под конкретную компанию или ситуацию, коробочные методы представляют собой уже готовый комплект различных элементов (про состав элементов я расскажу дальше). К коробочным методам можно отнести такие, как Scrum, P3.Express, Prince2 и другие. Им можно обучиться на открытых тренингах, пройти сертификацию или прочитать книгу. 

Главный недостаток уже готовых методов — они явно не отвечают на вопрос «Для чего применяется тот или иной инструмент?» Также они не могут обосновать, для чего необходимы конкретные управленческие совещания, документы или иные требуемые артефакты, процессы и процедуры. Кроме того, не до конца понятно, почему эти элементы необходимо использовать все сразу, поэтому при внедрении возникает сильное сопротивление со стороны сотрудников и руководителей.

У коробочных методов есть и другие недостатки. В частности, эти методы:

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

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

• «Вам нужно все, что требует метод». На практике многие предлагаемые инструменты могут быть слишком трудоемкими, не соответствовать культуре организации или тормозить процесс.
• «Метода достаточно для успеха сейчас и в будущем». Со временем большинство компаний упираются в ограниченность конкретного метода и начинают заимствовать элементы из других методов (например, Scrum превращают в Scrumban) либо переходить на другие методологии целиком.
• «Опыт авторов метода ценнее опыта и знаний компании». Коробочные методы предлагают опираться на внешний опыт. Однако в любой компании, которая давно реализует проекты, есть свой успешный и болезненный опыт, который можно преобразовать в полезные знания. К сожалению, он часто не систематизирован и не задокументирован, но аккуратное его извлечение из голов сотрудников и архивов документов и превращение в стандартизированные инструменты может существенно повысить успешность большинства проектов. Поэтому не стоит оставлять за бортом накопленный опыт своих лучших менеджеров и успешных проектов, превознося ценность внешних практик и инструментов. 

Как создать идеальный кастомный метод для вашей компании

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

Начнем с того, что нельзя соединить Agile и Waterfall, что называется, «в лоб». Такой подход не работает — по причине слабой совместимости ролей и противоречивости требований. Недаром руководство по совмещению подходов Agile и Prince2 составляет более 350 страниц. Гораздо более эффективным будет подобрать инструменты к контексту ситуации и к особенностям компании или проекта. Зная основные принципы, вы сможете самостоятельно собрать нужный набор, который будет работать в конкретных условиях.

Прежде чем сформировать тот подход, который мы в PMLogix рекомендуем сейчас, мы использовали следующие:

• Стандарт + адаптация. Для этого подхода сравниваются между собой различные стандарты/методы/фреймворки и выбирается оптимальный для компании с точки зрения контекста, доступности обучения, возможности сертификации и т. д. Затем метод «докручивается» — к нему добавляют недостающие инструменты. Это приводит к «религиозным войнам» внутри компании и вызывает сопротивление как у сторонников невыбранных методов, так и у приверженцев модифицируемого.
• Анализ процессов + оптимизация. Ключевой смысл этого подхода — превратить работу над проектами в процесс, чтобы затем найти способы устранения рисков. Однако проектная деятельность плохо описывается процессами.  И если на уровне руководства всего проекта, где принимаются ключевые решения (гейтов и жизненного цикла проектов), это еще можно сделать, то все, что происходит ежедневно внутри проекта, в виде процесса описать невозможно — слишком много параллельных и цикличных действий.
• Внедрение отдельных инструментов. Самый рабочий подход из всех трех. Вместо того чтобы внедрять какой-то метод целиком или адаптировать его под компанию, мы берем конкретные проектные инструменты, решающие определенные проблемы, и внедряем их. Таким инструментом, например, может быть проведение сессий ретроспектив (сбор и анализ опыта, выработка мероприятий, стандартизация отчетности по проекту). Однако, двигаясь от инструмента к инструменту, можно получить только локальный эффект. Такой набор инструментов сложно поддерживать без единой логики, особенно когда таких инструментов становится не один-два, а десятки. А внедрение всех необходимых инструментов может растянуться на длительный срок.  

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

• Принцип итерационного улучшения. Первая версия собственного метода редко бывает идеальной. В нее изначально заложена возможность постоянного улучшения. Через несколько месяцев можно добавить, скорректировать и даже удалить некоторые инструменты.
• Принцип целостности системы. Ни один из элементов не случаен. Разработанная методология должна отвечать проблемам, вызовам, критериям успеха проектов компании. Все инструменты должны иметь ответственных за их исполнение после того, как завершено внедрение. Все управленческие совещания (события) необходимо подкреплять артефактами (документами), все артефакты должны быть востребованы в ходе проекта.
• Договоренность важнее идеальности. Группа ключевых пользователей в процессе разработки должна договориться между собой, как будет выглядеть методология с учетом того, что нужно и того, что возможно, с учетом доступных ресурсов и зрелости компании. Также требуется утвердить ключевые изменения с топ-менеджментом. Если остались разногласия, которые нельзя оперативно разрешить, то такие вопросы и спорные инструменты откладываются на будущее. 
• Максимум конкретики. В методологии не должно быть текста, который избыточен для понимания используемой терминологии или применения инструментов, попросту «воды». Только четкие ответы на вопросы «Зачем?», «Что?», «Когда?», «Кто?» и «Как?».
• Главное — не мешать клиенту. Очень важно дать возможность команде экспертов со стороны клиента использовать наработки, которые уже есть в компании. Если эту экспертизу эффективно препарировать, это позволит сильно продвинуться в разработке собственной методологии. Внешняя экспертиза может быть полезна как в навигации по процессу разработки методологии, так и в расширении управленческого кругозора за счет внешних инструментов и кейсов. 
• Принцип «черного ящика». Он означает, что не стоит без надобности влезать в работу руководителя проектов. Метод должен быть описан таким образом, чтобы основной акцент делался на видимые доказательства качественного управления (актуальный план, наглядный прогресс, работающий продукт), а не труднопроверяемый процесс. В конце концов, это дело руководителя проекта, как обеспечить нужное качество результата. И только если оно не устраивает, стоит конкретизировать технологию.

Ключевые понятия для сборки гибридного метода

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

Что такое аспект и где его искать? 

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

Когда дело касается проекта, словосочетание «уделять внимание» означает:

• Фиксирование договоренностей; 
• Распределение ответственности;
• Наличие обсуждений и решений;
• Планирование действий;
• Контроль.

В любом проекте важно определить аспекты. Аспект — это то, чему мы уделяем внимание, самые важные области для успеха проекта, или то, из-за чего проекты чаще всего проваливаются.

Существует три области, в которых мы рекомендуем искать аспекты:

• Критерии успеха. По их достижении мы понимаем, успешен проект или нет, не только с точки зрения руководителя, но и всей компании. К критериям успеха можно отнести достижение определенных финансовых целей, накопление опыта, формирование репутации, выход на новый рынок. 
• Критерии неуспеха. Важно ответить на вопрос: при нарушении каких ограничений проект терпит неудачу (несоблюдение требований информационной или экологической безопасности, невыполнение условий контракта и т. п.)? 

Однако даже если критерии неуспеха соблюдены, это не гарантия успеха.

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

Примеры аспектов: знания (анализ, использование и передача опыта), риски (проработка и унификация способов реагирования на негативные факторы), команда (проектные роли, распределение ответственности и управление). Определения аспектов индивидуальны для каждого конкретного случая. 

Аспекты можно подсмотреть в различных стандартах и руководствах. В Prince2 они называются «Темы» («Бизнес-кейс», «Организация», «Качество», «Планы», «Риски», «Изменения», «Прогресс»), а в PMBOK-6 и ISO 21500 — «Области знаний» («Содержание», «Расписание», «Стоимость» и т. д.). При этом не стоит прямолинейно заимствовать аспекты из этих стандартов, лучше аккуратно сформировать их перечень и определить их для своей организации. Это позволит работать с избыточностью и недостаточностью управленческих инструментов, которые будут включены в методологию в дальнейшем.

Если аспект отвечает на вопрос «Чему уделять внимание?» (или «Для чего нам конкретные инструменты в методологии?»), то элемент пооясняет, из каких частей мы собираем наш метод, чтобы он был практичным и полезным.

Мы можем выделить четыре ключевых элемента любого метода:

1. Роль (кто?). Это действующие лица, которые назначаются в проект. Их необходимо определить, чтобы понять, кто за что отвечает, какими полномочиями обладает.
2. Структура (когда?). Она опирается на «жизненный цикл» проекта. Наличие структуры помогает понять, в какой момент (на каком этапе, фазе, спринте) нужно использовать тот или иной инструмент, принимать решение.
3. Инструменты (что?). Есть два вида инструментов — события (встречи и процедуры) и артефакты (документ, отчет, версия продукта). Артефакты могут быть физическими (опытный образец смартфона, макет здания) или информационными (устав в текстовом файле, карточка проекта в ИСУП, задача в Jira, ежедневный статус в Telegram-чате) 
4. Техника (как?). Определяет алгоритм того, как мы готовим и проводим события и выполняем действия, в результате которых возникают артефакты. Такой подход помогает предотвратить напрасную трату времени и бюрократию, то есть избежать ситуаций, когда мы проводим совещания и создаем артефакты формально, не выполняя необходимую подготовку и в итоге теряя исходный смысл того или иного инструмента. Техника может быть выработана внутри компании или взята извне (например, из стандарта или книги).

Разрабатываем и внедряем кастомную методологию управления проектами за восемь шагов

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

Шаг 1. Выявляем аспекты (Вопрос: «Зачем?»)

• Определяем критерии успеха/неуспеха.
• Определяем и ранжируем проблемы.
• Формулируем аспекты, уточняем их приоритеты.

Примечание: за самыми важными аспектами будут следовать самые важные (обязательные) требования к управлению.

Шаг 2. Задаем структуру (Вопрос: «Когда?»)

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

Шаг 3. Подбираем инструменты — артефакты, события (Вопросы: «Что?», «Когда?»)

• Определяем и описываем артефакты и события. Пытаемся понять, какие инструменты уже работают. Собираем банк потенциальных инструментов. Привлекаем внешний опыт, если не хватает внутреннего. 
• Привязываем инструменты к структуре проекта (например, к его жизненному циклу или частоте использования). Определяем, как они связаны с аспектами, есть ли оговорки по их применению ко всем проектам организации (размер бюджета, вовлечение внешнего подрядчика и т. п.).
• Уточняем обязательность и состав MVP.

Шаг 4. Распределяем ответственность (Вопрос: «Кто?»)

• Формируем список ролей.
• Определяем их цель и зоны ответственности.
• Определяем ответственность (события, артефакты).

Шаг 5. Детализируем инструменты (вопросы: «Что?», «Как?») 

• Определяем, какой перечень артефактов и событий минимально достаточен для работы.
• Определяем степень детализации: насколько мы можем продумать технологию, описать образ результата в формате критериев готовности (Definition of Done)?
• Отвечаем на вопрос, насколько мы уверены, что зрелость компании позволит внедрить тот или иной инструмент прямо сейчас. Исходя из ответа, делим инструменты на два блока: MVP, которые будем запускать сейчас, и бэклог, куда мы отложим все остальные инструменты. 
• По первым определяем требования (шаблон, инструкция, чек-лист и т. д.).

Шаг 6. Пилотируем 

Обычно этот этап длится 1-2 месяца, в течение которых мы:

• Запускаем изменения (определяем, как тестируем процесс, какие роли есть, кто какие инструменты использует);
• Инструктируем людей;
• Делаем «привязку к местности». Определяем, в каких проектах и в каком объеме мы применяем новую методологию;
• Собираем обратную связь;
• Вносим корректировки.

Шаг 7. Запускаем цикл постоянных улучшений

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

• Добавляем / убираем артефакты.
• Добавляем / убираем события.
• Корректируем практики, чтобы методология не превратилась в бюрократию.
• Корректируем роли и закрепленную за ними  ответственность.
• Актуализируем базу знаний и шаблоны.

Шаг 8. Проверяем целостность и достаточность

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

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

Преимущества и ограничения кастомного метода управления проектами

Как и другие методы, кастомный имеет свои достоинства и недостатки.

Преимущества кастомного метода:

• Нет ничего лишнего (минимально достаточный и одновременно необходимый набор);
• Не устаревает (обновление и корректировка элементов возможна без консультантов и в реальном времени);
• Используется доступный опыт (внешний и внутренний);
• Можно осмысленно развивать (добавление или удаление  элементов всегда сопровождается ответом на вопрос «Зачем?»);
• Легко приживается (придумано «нами и для нас»);
• Легко объяснить — если возникает сопротивление, всегда есть ответ на вопрос «Зачем?».

Ограничения кастомного подхода:

• Дольше идти до образа результата. На старте не совсем понятен целостный образ результата, но не переживайте, вы к нему придете в процессе. Чтобы снять сомнения, мы показываем живые примеры и рассказываем пошаговый алгоритм разработки;
• Требуется вовлечение ключевых сотрудников. Это касается не столько времени, сколько осознанности решений, которые требуют вникания экспертов как в технологию разработки, так и в выбор и приземление конкретных инструментов;
• Неготовность выбрать «непроверенный» фреймворк. Для многих оказывается шокирующей информация, что разработанный фреймворк будет уникальным для каждого клиента. Создается ощущение, что он окажется непроверенным, сырым. На самом деле большинство используемых инструментов многократно опробованы на практике, в них не стоит опасаться серьезных инноваций. Просто все инструменты собираются в единую логичную систему.
  

Эффективность кастомного метода

Вот как отзываются о процессе разработки кастомных методов наши клиенты:

Выводы

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

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

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