Как добавить гибкость в «жесткие» проекты?

Немного о себе.

• Более 17 лет в управлении проектами.

• Начинал с проектов в производстве, логистике, внедрял системы управления предприятием.

• После этого руководил проектными офисами в банках.

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

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

О чем сегодня будем говорить:

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

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

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

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

Немного статистики

Начнем со статистики. Где-то с 2015 года американский институт PMI (институт управления проектами) стал ловить гибридные методы управления на своем радаре, в своих исследованиях.

Есть ежегодное исследование «Pulse of profession PMI» (Пульс профессии) – в нем гибридные методы появились примерно с 2015 года. И с этого момента институт PMI регулярно каждый год мониторит гибридные методы.

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

Это микс классических и гибких методик. В исследованиях института PMI проекты, сделанные по гибридным методам, конкурируют с Agile примерно на равных:

• В 2018 году они составляли 25-23% от общего числа проектов.

• За 2020 год гибридных проектов около 20% – они идут практически вровень с Agile-подходами.

Если мы посмотрим на статистику по гибким методам, которые нам дает исследование «Agile в России», там есть такой вот интересный блок, который называется «собственный подход».

• Даже на уровне команд – это примерно 30%. Это не Скрам, не Канбан, не Скрамбан – это что-то свое.

• А если мы говорим про масштабирование на уровне компании, процент использования своих подходов еще больше – примерно 40%. Я более чем уверен, что в этом большом проценте как раз есть эти самые гибридные методы.

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

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

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

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

Давайте поговорим о том, с какими проектами классно работает классическое управление проектами.

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

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

• Еще одно свойство проекта, которое предполагает классическое управление – это жесткие ограничения, прописанные в контракте. Срок, стоимость, какие-то другие критичные требования, например, к информационной безопасности. При этом, есть огромная часть того, что не всегда понятно.

• Сюда же относится ограниченная доступность заказчика или его неготовность или нежелание активно участвовать. Если у вас заказчик говорит: «Вы – эксперты, специалисты, у вас есть ТЗ. Принесите мне готовый продукт».

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

• Ну и еще три важных и стандартных, довольно частых пункта. Это:

  • незрелая команда;

  • команда, которая выделена только на ограниченный период времени;

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

Со всем этим классно работает классический проектный менеджмент. А по поводу всего остального – традиционный Project Management ограничивается управлением рисками. Всё, что идет не по плану, туда.

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

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

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

• Дальше – изменчивые или нечетко сформулированные требования. У меня на одном из проектов ERP главный заказчик говорил так: «Я вам скажу, то вы сделали или не то, только тогда, когда вы мне предъявите готовый продукт». И это – в проекте, работа по которому длится примерно от года до полутора. Действительно, заказчики так воспринимают – они понимают, что им нужно, только тогда, когда они видят продукт, настроенный под них.

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

Критерии отнесения к гибридам

Что же все-таки такое гибридные проекты и какие проекты можно отнести к гибридным?

Давайте начнем с гибких проектов. К ним относятся:

• запуск инновационных продуктов;

• развитие ИТ-продуктов;

• короткие образовательные программы;

• консалтинг.

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

Классика хорошо работает, когда вы:

• можете четко документировать требования;

• можете достаточно хорошо все заранее спланировать;

• тиражируете какие-то эти решения;

• создаете четкие понятные объекты инфраструктуры.

А гибрид хорошо работает, когда:

• проекты связаны с внедрением ERP-систем в условиях высокой степени неопределенности или при наличии сопротивления людей;

• проекты реализуются на стыке разработки программного обеспечения и создания какого-то железа инфраструктуры; у нас будет кейс про Intel – там как раз ситуация, когда и разработка и аппаратного обеспечения, и программного;

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

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

Кейсы гибридизации

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

• первый кейс у нас будет про компанию Intel;

• а второй – про сегмент B2O от компании Ростелеком.

Кейс компании Intel касается разработки одного из поколений процессоров Intel Pentium.

Кейс заключается в следующем. Компания реализует проект. Длительность проекта примерно 15 месяцев. Огромная трудоемкость – 500 человеколет. Это сложно вообразить, но тем не менее.

И из-за одной из команд, которая занимается периферийными устройствами и занимает не более 10% в общем объеме трудоемкости, проект отстает на 40% по времени – то есть на 5 или 6 месяцев.

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

Начали разбираться. Выяснили, что проблема связана с некоторым порочным кругом. А в чем же это порочный круг?

• Проект начинается с директивного плана с жесткими фиксированными дедлайнами. Менеджмент говорит: «Должно быть сделано тогда-то» – это связано с договоренностями с заказчиками и сроками проведения выставок. И руководители проектов подбираются такие же, которые готовы принять дедлайн и не готовы или не хотели бы его оспаривать. А если оспаривают, то: «Следующий!»

• Такой план спускается на команду. Команда немного сопротивляется, но обсуждать сроки, которые есть, тем не менее, не принято. При этом уже на старте план воспринимается как нереалистичный.

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

• Итого – жертвуем качеством.

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

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

• График давит еще больше.

• Начинаются переработки, еще большее давление.

Это в итоге приводит к продукту с багами, который выпущен почти что в срок (хотя нет, конечно, не в срок).

• Когда менеджмент об этом узнает, он устанавливает новый жесткий дедлайн, опять-таки, сильно не обсуждая.

• Команда в очередной раз не верит в новый план, и это все в сумме заново запускает ранее озвученный порочный круг.

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

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

Итого, это еще больше усиливает этот порочный круг.

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

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

Что же это такое?

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

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

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

• Планирование – это не всегда просто выдача оценок, зачастую это также обмен и обсуждение допущений. Кто-то считает, что нам нужно одно качество проектной документации, а кто-то – что нужно вылизать все до блеска. Кто-то считает, что часть работ можно запараллелить, а кто-то – что работу нужно делать исключительно последовательно. И один из способов синхронизировать эти допущения – это так называемый “Плэннинг покер” (в Scrum), когда мы даем оценки, сколько будет делаться каждая задача, присваиваем ей какие-то очки и дальше обсуждаем, почему оценки именно такие. При планировании обсуждаем, какие допущения мы закладываем в оценки.

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

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

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

В итоге, сделав эти выводы и изменив практику работы с командой, в Intel пришли к тому, что:

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

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

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

• Коллеги столкнулись с тем, что у них очень сильно вырос портфель ИТ-проектов – примерно с одной сотни до нескольких.

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

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

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

При этом на момент 2019-2020 года в сегменте сформировались следующие предпосылки:

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

• Но часть команд к тому моменту уже начала практиковать гибкий подход – работу с использованием фреймворка Scrum.

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

Коллеги решили, что для некоторых проектов можно совместить оба подхода.

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

• Например, в производстве, в создании самого продукта, в разработке – использовать Scrum.

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

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

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

• Заменили на демо формальные процедуры подготовки программы и методики испытаний и приемосдаточных испытаний.

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

• Ну и внедрили еще процедуру единого ретро по проекту в целом.

Итого, в марте 2021 года они утвердили эту гибридную методологию и уже запустили первые проекты, в которых:

• часть команд живет по Scrum;

• часть реализуют свою часть именно в классике – по требованиям и жестким планам;

• и где-то 30-40% проектов в этом сегменте планируют реализовывать именно в таком гибридном формате.

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

Если мы посмотрим на первые два этапа – этап инициации и этап планирования, то на этапе инициации все почти по классике.

• сформировано предварительное техноэкономическое обоснование,

• утверждены верхнеуровневые бизнес-требования, ключевые показатели, архитектура;

• и тут же появляется первая версия roadmap – то, что уже перекидывает мостик Agile.

На втором этапе, на планировании, у нас уже добавляется больше гибких артефактов:

• добавляется календарь спринтов – команды определяют, с какой частотой они будут выпускать продукт;

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

• продуктовые метрики;

• и утверждается roadmap.

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

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

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

• Следующее – это возможность работы с выделенной командой. Если это подрядчик – работаем по Time & Materials. Либо работаем с полностью собранной внутренней командой. Важно именно выделение команды как таковой и фокус именно на отдельном проекте.

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

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

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

Примеры гибридных методов

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

• Первое – это Last Planner System, система «Последний планировщик», которая родилась в строительстве. Она позволяет синхронизировать работу на длинном временном горизонте, планирование директивное от вех, контрольных событий к планированию на самом ближайшем временном горизонте (неделя). И синхронизация этой работы, реализация того самого совместного планирования. Эта система вполне применима и для ИТ-проектов, и для организационных проектов. Тут самое важное – идеология, а не отрасль.

• Следующее – это Oracle Unified Method. Это подход к созданию сложных информационных продуктов, которые не так хорошо делимы, и которые нельзя делать исключительно по Scrum, когда мы создаем последовательно – сначала прототип, а потом – версии продукта. В каком-то смысле, это эволюция Rational Unified Process, который вполне неплохо работает. Тоже рекомендую с этим ознакомиться.

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

Выводы

Суммируя сказанное:

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

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

• Но, конечно, здравый смысл в создании своего метода пока еще никто не отменял.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse