Все, что нужно управленцу, чтобы минимизировать риски потери денег и эффектов от проекта – это понятная отчетность с достоверными данными о его прогрессе. Если все идет по плану – отлично, а если что-то пошло не так и сроки растягиваются – быстро разбираемся в причинах проблемы, принимаем нужные решения и едем дальше.
Но что делать, если вам нужно реализовать критически важный и масштабный проект длительностью несколько лет и стоимостью миллиарды рублей в ограниченные сроки, но оценить прогресс его выполнения не получается из-за постоянно меняющегося содержания?
В этой статье делюсь кейсом создания методологии отслеживания прогресса в масштабной ИТ-программе по разработке и внедрению ПО в крупнейшей телекоммуникационной компании. Данное решение было единственно возможным, чтобы решить проблему заказчика, и я подробно расскажу о нем и как мы к нему пришли ниже.
Начну с краткого описания ситуации: перед руководством компании стоит задача импортозаместить западное ПО (продукты SAP) в связи с международными санкциями. А так как текущее ПО реализовывает ежедневные управленческие процессы (финансы, кадры, снабжение и т.д.), его функционирование невозможно остановить даже на один день – это приведет к огромным убыткам, а возможно и к штрафам от контрольно-надзорных органов. Поэтому реализовать программу и перейти на новое ПО необходимо в ограниченные сроки – есть четыре года до планового отключения всех замещаемых продуктов.
Но так как российских аналогов большинства используемых продуктов SAP не существует, руководством было принято решение создать и внедрить уникальное ПО с высокой долей собственной разработки. Выделено несколько команд, отвечающих за разработку частей целевой системы в различных подразделениях (более десятка), и частично код пишется с нуля.
Однако функциональность создаваемого ПО, требования и объем работ постоянно меняются из-за сложной архитектуры бизнес-процессов организации и огромного количества кросс-системных интеграций. Поэтому продукт разрабатывается в рамках Agile – путем постоянных итераций и улучшений. Так что, понимания, каким будет финальное ПО, на которое компания сможет перейти через четыре года, у разработчиков нет.
При этом руководству критически важно понимать прогресс программы, так как в разработку будут инвестированы миллиарды рублей, а сроки ее реализации жестко ограничены. Поэтому нужна железобетонная уверенность, что через четыре года компания полностью перейдет на целевые ИТ-системы и откажется от замещаемых, без нанесения урона ежедневным управленческим процессам.
Спустя год разработки субъективная, экспертная оценка показала прогресс команд 20%, но руководству нужно не только частное мнение, но и «материальные» результаты прогресса по программе. Но даже верхнеуровневый план разработчики предоставить не могут в силу высокой сложности создаваемого продукта (об этом я подробнее расскажу ниже).
Поэтому в компании было принято решение внедрить методологию отслеживания прогресса программы, чтобы опираться не только на экспертную оценку разработчиков, но и на артефакты – доказательства достигнутых результатов.
С этой целью нас, команду консультантов PMLogix, и пригласили. В статье ниже подробно расскажу, с чего мы начали, почему внедрить методологию отслеживания на программе было практически невозможно и к какому единственно возможному компромиссу мы пришли, чтобы решить проблему заказчика.
Также поделюсь, как наше методологическое решение работает на практике.
Поиск решений и первый провал
Мы сразу поняли, что применить классический подход для отслеживания прогресса с опорой на общий объем работ здесь не получится. Потому что для этого нам нужно знать, что является 100% результата. Понятно, что 100% результата программы является работающий продукт, на который организация перейдет через четыре года, но… Точного понимания состава даже укрупненных блоков, функций ИТ-продукта и количества интеграций на данном этапе разработки нет.
Мы решили пойти по другому пути и попробовать выстроить отслеживание на основе артефактов типового технологического процесса создания ИТ-продукта, который утвержден в компании. То есть использовать для мониторинга прогресса последовательность шагов, которые обязательно выполняются на протяжении всех этапов разработки – от исследований до финального релиза продукта. Таким образом, если у нас есть дедлайн (четыре года) и технология разработки, то гипотетически мы можем запланировать, какие шаги и в какой последовательности нужно выполнить для получения финального результата.
Проверяя жизнеспособность этой теории, мы столкнулись с новыми сложностями.
Во-первых, данную методику отслеживания сроков (на основе плана производственного процесса) уже пытались внедрить до нас, когда руководство поставило задачу разработчикам начать оценивать прогресс фактологически, а не только экспертно. Однако унифицировать каждый этап процесса (например, разработка занимает 50% от общего объема работ, а тестирование 10%) не удалось, потому что эти цифры не учитывают сложность, объем и контекст разрабатываемого продукта. И даже под примерной процентовкой каждого этапа прямо сейчас разработчики не могут подписаться, потому что через несколько месяцев требования, количество интеграций и в итоге объем работ, скорее всего, сильно изменятся.
Во-вторых, последовательность фаз и этапов разработки не всегда соблюдается согласно внутренним нормативам производственного процесса, и разработчики подходят к процессу крайне творчески (и это норма для подобного проекта по разработке продукта, где сроки жестко ограничены).
Например, три команды оказались в процессе реинжиниринга бизнес-процессов, несмотря на то, что разработка уже велась. Или же этап формирования архитектуры продукта и его встраивания в общую ИТ-архитектуру организации пропускается, так как состав продукта еще будет много раз уточняться, и вписывать его в общую схему оптимальнее всего будет ближе к концу разработки.
Так что, выстроить последовательность шагов, завершение которых будет подтверждаться артефактами (результатами), тоже невозможно.
В-третьих, артефакты на самой длительной фазе (разработка) используются не всегда – на усмотрение команд. И обычно главный разработчик каждого продукта сам принимает решения о том, что уже можно закончить, а что нужно стартовать. Это значит, что завершение какой-либо фазы или этапа разработки часто подтверждается не конкретным документом о результате, а релизом продукта. А сказать, сколько будет релизов, тоже не получается: можно запланировать 1 релиз, а их будет 3, или наоборот.
Мы поняли, что с учетом всех сложностей и специфики разработки продуктов никак не получится выстроить идеальную, точную систему отслеживания прогресса. И после нескольких недель исследований и общения с разработчиками мы смогли найти единственный компромиссный выход из этой ситуации – методологическое решение мониторинга программы на основе обязательных артефактов производственного процесса.
Как нам все-таки удалось это реализовать и как методология работает на практике, читайте ниже.
Как управлять сроками и сохранить гибкость. Модифицированный Метод набегающей волны
Учитывая то, что нам неизвестен финальный объем работ, а также производственный процесс имеет свои сложности и специфику, мы решили прибегнуть к модифицированному Методу набегающей волны. Ниже поясню подробнее.
В нашем проекте разработки неизменными остаются только сроки, поэтому за 100% программы мы решили взять этот параметр – четыре года. Мы разбили этот период на четыре равных отрезка по одному году и вместе с разработчиками определили контрольные точки готовности функционала от команд – то, что должно быть запущено в конце каждого года независимо от количества и содержания технических блоков согласно четырехлетнего плана.
При этом мы применяем набегающую волну – планируем подробно только год, но каждые полгода уточняем план на оставшиеся шесть месяцев, так как требования и объем работ в течение года будут точно меняться.
Таким образом, мы разбили всю четырехлетнюю программу на отрезки и детально расписали один отрезок, то есть ближайший год, в виде обязательных артефактов, при этом у команды есть возможность пересматривать количество и состав артефактов раз в полгода.
Как это решение выглядит на практике?
Ниже покажу пример расчета прогресса о этой методологии.
Как я уже писал выше, для разработки продукта руководство компании выделило команды, которые отвечают за свою часть целевой системы – управление персоналом, финансы, снабжение и т.д. На основании утвержденного бюджета каждому подразделению был присвоен свой вес от общей программы – например, части ПО для реализации процессов финансового подразделения выделяется 20%. При этом функциональный объем всей программы поделен на элементы мигрируемых систем (далее - элементы) с сервисами, которые обязательно должны быть поставлены.
Получается, что команда подразделения, объем работы которой оценили в 20% от общей программы (выделенного бюджета), делит этот вес равными долями на четыре отрезка (четыре года) – по 5% на каждый год (или неравными, доли распределяются на усмотрение команд, в зависимости от доступности ресурсов и прочих факторов).
Так как программа поделена на элементы, у команды есть некоторое представление, сколько элементов она должна поставить спустя 4 года. Например, два элемента. И так как вес от общей программы у подразделения 20%, то в зависимости от содержания элементов (количества сервисов внутри) команда должна присвоить каждому из них свой вес – например, у одного элемента вес будет 12% от общей программы, а у другого 8%.
Таким образом, чтобы составить годовой план работ, команда делит вес каждого элемента на 4 года. И так как к концу первого года должно быть выполнено 5% от всей программы, то ¼ каждого элемента соответствует 3 и 2% программы этого года.
А дальше начинается расчет количества и состава артефактов, которые команда должна обязательно предоставлять в течение первого года, чтобы можно было проверить, реально ли достигнуть запланированный прогресс.
Для примера возьму тот же элемент, который имеет вес от общей программы 12%. Как я уже писал выше, это значит, что к концу года команда должна выполнить ¼ от этого веса, то есть 3% прогресса программы. Если в этот элемент входит 4 сервиса (функциональности), то к концу первого года разработчики должны сделать один сервис, что соответствует 3% от общего прогресса программы (общий вес элемента делится на количество сервисов). И согласно контрольным точкам, необходимым для реализации одного сервиса, команда утверждает количество обязательных артефактов в течение года – функциональные требования, архитектура сервиса и т.д. Их количество и состав команда определяет самостоятельно.
Если команда утвердила 5 артефактов для реализации одного сервиса одного элемента, то каждому артефакту также присваивается вес. На этом примере получается, что у одного артефакта будет вес 0,6% от общей программы.
Стоит добавить, что не у всех команд получилось одинаковое количество и состав артефактов. Они унифицированы для создания единой шкалы оценки прогрессы, но у одной команды может быть 100% артефактов, а у другой 80%. Например, если для одного продукта требуется разработка интерфейса, а для другого нет, то этого артефакта, подтверждающего завершение этапа, не будет в общем составе артефактов реализуемого сервиса.
Конечно, расчет я показываю упрощенный, и на деле данная методология представляет собой сложносочиненную математическую модель.
Таким образом рассчитывается вес артефактов всех сервисов всех элементов мигрируемых систем, на которые разделена программа.
Что дальше? Раз в месяц проектный офис приходит к командам и запрашивает подтверждение прогресса в виде артефактов, на основе которых можно смотреть, насколько выполняется годовой план программы в процентах. Так, учитывая вес каждого артефакта, картина прогресса становится более прозрачной, чем раньше, когда разработчики оценивали его только экспертно.
В конце года, если команда реализовала не все сервисы и вместо 5% выполнила меньше, то детальный план на следующий год расписывается по такой же схеме, с учетом невыполненного процента.
Что в итоге?
На мой взгляд, это решение – единственный способ получить реалистичную оценку прогресса на данной программе. Но у него есть свои минусы:
высокая трудоемкость и сложность первичной декомпозиции элементов на сервисы, чтобы определить их вес от общей программы; и делать эту нужно раз в полгода с уточнением плана на оставшиеся 6 месяцев;
грубая погрешность в процессе за счет большего количества объектов учета и сложности контроля корректности распределения общего веса между объектами оценки.
При этом внедрение этого метода вовсе не исключает из процесса мониторинга прогресса экспертную оценку, так как эксперты команды видят прогресс до того, как артефакт будет полностью готов и принят. Кроме этого, дополнение экспертной оценки к фактологической позволяет избежать «скачкообразного» представления прогресса, которое возникает из-за неравномерного процесса подготовки артефактов в течение года.
Однако теперь появились некоторые ограничители в виде фактически подтвержденных событий – например, 2% прогресса команды привязывается к согласованию ИТ-архитектуры продукта. До наступления этого события эксперт дает свою оценку, но «официально» пройти отметку команда сможет только после предоставления документа, подтверждающего результат (например, ИТ-архитектура согласована).
Таким образом мы выстроили систему, в которой соблюдается работа по Agile
с итерационным уточнением прогнозов, и при этом есть возможность контролировать сроки получения результатов.
«В начале работы мы, конечно, столкнулись с огромным сопротивлением со стороны команд, и в целом их можно понять – у них и так высокая ненормированная загрузка и разработка масштабного, сложного ПО (в котором, кстати, еще должен быть задействован ИИ) с ограниченными сроками. А тут пришли мы, внешние эксперты, и начали погружаться в их процессы – задавать миллион вопросов и пытаться получить ответы, которых у них нет. Еще, так как мы работали с проектным офисом компании, было также непросто – методологи не обладают нужным авторитетом, чтобы повлиять на позицию разработчиков в духе “мы художники, мы так видим, по-другому объяснить ничего не можем”. Но за несколько недель постоянного общения и погружения в продукты коллеги все-таки «смягчились» и пошли на встречу, понимая, что мы не пытаемся заставить их сделать что-то ненужное и что мы решаем общую проблему.» Андрей Малахов, директор проекта по разработке методологии и управляющий партнер PMLogix.
Что в итоге: для руководства компании внедрение этого метода отслеживания стало очень большим шагом, чтобы иметь возможность получать информацию о прогрессе проекта не только на основании субъективной оценки в, казалось бы, абсолютно неуправляемой ситуации.
Оценка прогресса на основании подтвержденных артефактов, которые разработчики самостоятельно будут утверждать каждый год, это в первую очередь возможность подстраховаться от риска невыполнения программы.
Конечно, если окажется, что вместо 5 гарантированных артефактов команда предоставила в течение года только 3, это еще не значит, что годовой план программы провален. Однако это повод обратить внимание руководства на ход разработки и выяснить, пошло ли что-то не так и если да, то принять нужные решения для устранения проблемы.
Коллеги, подписывайтесь на мой телеграм канал Андрей Малахов | от проектов к изменениям, где я постоянно делюсь своими консалтинговыми кейсами по разработке методологий для крупнейших российских компаний, настройке и автоматизации проектного управления, внедрения ресурсного планирования и реализации сложных масштабных проектов в качестве проектного офиса на аутсорсе. Например, недавно делился кейсом реализации программы ИТ-трансформации из восьми ИТ-систем (включая ERP) в международной логистической компании за девять месяцев.
Также в канале делюсь проверенными инструментами, мыслями о менеджменте и инсайтами от работы с заказчиками, а также фишками моего авторского метода управления проектами Парацельс ПМ с результатоориентированным подходом, вместо классического процессного (в этом году будет доступно бесплатное обучение по нему и сертификация). Жду вас в канале!
