Привет! Меня зовут Александр Апазиди, я руковожу в СИБУРе цифровизацией процессов головного офиса. Сегодня я расскажу, как мы приводили IT-проекты в огромном нефтегазохимическом холдинге к одной модели, пытались примирить Agile и Waterfall, да и в целом, ускорить выполнение проектов. Тема ухабистая, так что пристегнитесь, и поехали!
Немного цифр: с 2021 по 2022 количество наших IT-проектов увеличилось с 70 до 200. При таких объёмах без портфельного управления проектами не обойтись, поэтому мы начали с единой методологии управления проектами и внедрили единую гейтовую модель из 5 шагов: Идея-Проверка-Гипотезы-Проектирование-Реализация-Мониторинг (мы их называем L1-L5). В них мы частично скопировали подход P3.Express.
Сделаю оговорку на всякий случай: не существует “правильной” методологии проекта, которая гарантированно приведет его к успеху, ведь проекты всегда выходят за рамки стандартных моделей. При этом есть некоторые техники, которые помогают улучшать проект. Одна из них – цикличность, которая как раз наглядно представлена в P3.Express. Её суть в том, что если сделать некоторые задачи руководителя проекта регулярными (и цикличными, да), то большинства ошибок можно избежать.
Эту технику мы применили в проектах по трансформации – ввели регулярные синхронизации, встречи с командой и едиными ответственными лицами, придумали ролевую модель проекта.
В целом, вместо полноценного внедрения какого-либо фреймворка бывает продуктивно тестировать отдельные шаги. Например, еще один из постулатов P3.Express гласит, что планировать проект должна вся команда, а не один менеджер проекта.
После первого такого планирования в одном из проектов результаты нас очень впечатлили, поэтому мы решили делать это постоянно. Теперь раз в квартал распределённая команда этого проекта проводит выездные планирования, детально планирует ближайший квартал, проводит ретроспективу и мини-тимбилдинг.
Благодаря этому у всех есть понимание, чем вообще занимается команда, и почему установлены именно такие сроки. Это, конечно, стоит расходов на командировки – но расходы окупаются эффектами от ускорения проекта. В упомянутом проекте применение одной этой практики позволило вытащить проект из красно-бордовой зоны в ярко-зеленую (я ещё не упоминал наше цветовое кодирование, но оно вроде и так понятно :)).
Теперь возвращаемся на уровень сотен проектов. Поскольку они отчаянно нуждаются в грамотном управлении, у нас появилась идея применять некую мягкую силу, при которой на руководителей проекта нет активного давления, но при этом они понимают, что контроля меньше не становится, и стараются не растягивать сроки.
Благодаря этой идее наша главная метрика – процент закрытых в срок проектов – держится на сильной отметке. Механика удивительно простая: когда менеджеры проектов понимают, что не успевают завершить проект, они должны получить подтверждение на увеличение сроков. Такой практики раньше не было, и эффект превзошёл ожидания.
Затем к мягкой силе, которая собирает статусы проектов, мы начали подключать технические средства. Благодаря внедрению единой системы хранения знаний о проектах мы можем скомбинировать все важные метрики и сделать выводы о реализации проекта без лишних вопросов к руководителям.
И всё же, сроки – вечная боль в любом проекте. Поэтому о них расскажу подробнее.
Как мы разбирались со сроками
Сперва мы посмотрели, как и почему происходят отклонения. Мы поставили задачу не контролировать сроки в последний момент, а разобраться в проблемах и рисках проектов. Посмотрели, с какими отделами возникают типовые проблемы, собрали глав этих отделов и стали еженедельно проводить ревью с руководителями проектов. На этих ревью подробно сверялись по статусам.
За месяц успевали отсмотреть весь портфель, и дальше начинали новый цикл месяца. После применения этой практики мы поняли, что не хватает более точной и объективной информации, поэтому решили вытаскивать из каждого смежного с проектом процесса любые данные, на основе которых можно предположить, где случилась проблема. Например, если мы говорим про закупки, то метрика – своевременность подачи заявки на закупку. Так мы прошли по всем областям, а их у нас одиннадцать.
Данные позволяют составить «карту здоровья», а карта – следить только за проектами, у которых есть проблемы в каких-то областях. Причём проблемы будут видеть не только руководители проектов, но и главы отделов. Например, если часто происходят сбои со стороны информационной безопасности, главу этого отдела нужно будет оповестить о происходящем. Так мы не только смотрим на информацию о портфеле в целом, но и помогаем коллегам оценивать здоровье процесса.
Это хороший подход, и он пришелся по душе нашим коллегам из смежных функций, но по времени было крайне затратно. Поэтому начали думать, как упростить процесс, чтобы он, к тому же, не стал очередной формальностью. Сошлись на целевом видении, когда руководитель проекта отчитывается по конкретной метрике или конкретному действию, а мы подсвечиваем проблемные зоны.
Важно подчеркнуть, что мы не лезем в организацию работы внутри проекта. Обычно мы только предлагаем руководителю проекта набор инструментов, с помощью которых он может строить внутренние процессы. Внутрь мы погружаемся лишь в том случае, когда проект попадает в красную зону. Тогда мы уже включаем ежедневные встречи, еженедельные статусы для всех стейкхолдеров и другие практики из P3.Express.
В красной зоне project manager часто сообщает, что у него все плохо, в последний момент. Для таких проектов мы выделили одиннадцать метрик, покрывающих все сферы, связанные с проектом — эта наша предиктивная диагностика.
Например, если менеджер проекта запланировал работу пяти человек на следующую неделю, а фактически списалось двадцать часов вместо двухсот, то это сразу будет видно в метрике “Списания”, и руководителю придется объяснять расхождение. Таким образом, каждый руководитель знает, что любые нестыковки будут видны, и старается их минимизировать.
Про эффекты
Наша ключевая метрика — процент проектов, закрывающихся в срок. Ее можно назвать искусственной, ведь она не направлена на бизнес-ценность, но пока так. У нас получилось поднять эту метрику с 61% в 2020 году до более чем 90% в прошлом году.
Было бы логично отойти от этой метрики на следующем эволюционном витке, потому что мы должны измерять ценность, которую проект приносит бизнесу. Но у нас есть и проекты, которые не приносят прямых количественных эффектов, так что расчёт метрик тоже стоит подтянуть. Это может быть комплекс показателей: и выполнение в срок, и эффекты, и employee NPS, и customer NPS, и другие.
Как упорно мы шли к этому всему
Чтобы всё описанное выше не выглядело как лёгкое достижение мегауспешных супергероев, расскажу честно, как мы пришли к единой гейтовой модели управления проектами сквозь годы и множество препятствий.
Lean-подходы начали внедряться на наших предприятиях в 2016 году, а в 2017 началась программа цифровой трансформации, для которой в компании создали отдельную функцию. Тогда мы столкнулись с внутренним культурным противоречием: коллеги из “старого IT” с компетенциями по 1С, SAP, MES и другим энтерпрайз-решениям находились с отдельном юрлице от “нового ИТ” с инхаус-разработкой на .Net, Java, Python и др. Даже правила по дресс-коду были разные – часть IT-специалистов ходила в костюмах, другая часть – в худи и шапках-бини.
Эти культурные разногласия, конечно, немного усложняли работу в проектах по цифровизации. Кроме того, к 2020 году эти проекты стали давать привлекательные эффекты, компания перешла от точечных инициатив к цифровизации сквозных процессов, а общее число проектов с IT-составляющей выросло до 70. В сроки мы тогда, скажем честно, не очень укладывались.
Но тогда же, в 2020 году, весь IT объединили в одном СИБУР Диджитал. И, на удивление, это быстро «примирило» культуры – объединённые команды стали обмениваться опытом, и оказалось, что джависту интересно общаться с ABAP-ерами и узнавать их лучшие практики (заодно стало проще делать интеграции). Так что проблема с противоречием культур отчасти решилась, но вот с проектными подходами ещё нужно было работать и работать.
С появлением СИБУР Диджитал мы как раз начали объединять продуктовую и проектную среду, создавать единый проектный офис для всех, вне зависимости от методологии. Мы даже видели это как проектный сервис, в который любая команда и по любой боли может прийти за помощью.
То есть, раньше у команд был либо Waterfall, либо Agile. Третьего не дано. Приходишь к продуктовой команде, а тебе говорят: “Слушайте, мы True Agile, мы работаем по стандартам, которые приняты в индустрии. Вот у нас спринты, работать можно только так.” Приходишь к другой команде (в костюмах), и тебе говорят: “Слушайте, мы всю жизнь работали по долгим функционально-техническим требованиям, давайте так и делать”.
Мощный пинок импульс для изменений придавал рост числа проектов – в 2021 году их стало уже 140, в 2 раза больше. Поэтому мы разбили все проекты по портфелям, которые относились к направлениям бизнеса, и ввели совместные цели для инициаторов проекта со стороны бизнеса и IT-команды. Поскольку от этих целей зависит премирование, команды получили стимул к продуктивному взаимодействию вместо перекидывания горячей картошки задач. И это начало приносить плоды!
Параллельно мы проводили эксперимент с методологией P3.Express, и он был неплохим, так что мы масштабировали его для решения проблемы. В процессе, конечно, у нас был миллион обсуждений, но в итоге все пришли к одному мнению: чего спорить, в IT стандартно работают по спринтам. Спринты отлично зашли и в проектах Waterfall, причём даже лучше, чем в классических продуктах.
Но к 2022 году число проектов снова выросло, а ещё всплыл неожиданно накопленный с годами бэклог из 2500 чендж-реквестов от пользователей по разным системам (в первую очередь по производственным), которые мы называем ЗнИ (запросы на изменения).
Нам пришлось переработать весь процесс этих реквестов и отказаться от них в пользу организационных проектов с подтвержденными эффектами, ограниченными сроками и бюджетом. Такие проекты валидируются руководителями от бизнес-направлений, так что они точно нужны компании, в отличии от большинства ЗнИ, которые после реализации не использовались пользователем или открывались 1-2 раза (хотя во время простоя в бэклоге были, конечно, нужны очень срочно).
В общем, к этому моменту мы уже научились управлять портфелями проектов и даже выполнять их в срок, и на этом можно было бы завершить рассказ и откланяться, но в управлении проектами всегда есть, кхм, простор для развития.
Например, к 2023 году нам предстояло решить проблему, которая всё это время маячила на фоне: управление ресурсами команд. Многие IT-компетенции – разработчики, дизайнеры, аналитики, тестировщики (и др.) – у нас были административно отделены от функциональных направлений вроде цифровизации производства. Это приводило к ситуации, когда несколько руководителей проекта приходили к одному и тому же руководителю компетенции, – например, по JavaScript, – и говорили, что им срочно нужен фронтенд, прямо сейчас, мол, проект уже запущен, а часики-то тикают. У руководителя компетенции в итоге управление командой превращалось в некий тетрис.
Это требовало решительных мер, и внедрили новую организационную модель, вдохновившись опытом Spotify. Мы сформировали в функциональных направлениях объединённые команды, так что IT-специалисты, которые чаще всего работали над проектами и продуктами по цифровизации закупок, например, или корпоративных процессов перестали переключаться на другие направления. Это облегчило приоритизацию задач и проектов внутри каждого из направлений.
Какой из этого можно сделать вывод, если ограничиться одним? Не стоит бояться эволюционного развития, даже если вы в большой корпорации!
Всё практики, которые мы внедрили, широко известны, но если бы мы попробовали внедрить все и сразу – это бы напоминало карикатурную "agile-революцию", которые часто заканчиваются разочарованием (и мемами). Мы внедряем улучшения шаг за шагом, и за 3 года уровень управления проектами поднялся хоть и постепенно, но уверенно.
Надеюсь, наш опыт был полезен! Также приглашаю делиться в комментах вашими рецептами управления IT-проектами в крупных компаниях – уверен, что будет много интересного :)