У нас было:

• 11 общебанковских целевых сервисов, называемых платформой или платформенными сервисами,

• 75 бизнес-продуктов с бэкграундом в виде форков не поддерживаемых легаси сервисов,

• 583 строчки/задачи в Google Таблицах в виде продукт/платформенный сервис, на который ему надо перейти/срок завершения перехода.

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

Итак, меня зовут Алевтина, я РМ в Альфа-Банке, канале ЮЛ, и в моей жизни случился такой проект. В этой статье расскажу, как решала проблему прозрачности легаси-проекта, какие шаги предпринимала для того, чтобы проект сдвинулся с мёртвой точки, и какой результат был достигнут по итогам рефакторинга проекта. 

Что «Дано» понятно, а что надо сделать?

Завершить проект до конца года. 

С такой постановкой задачи мне был передан проект, который длился 3 года. По методике «слово даю» он был выполнен на 85%. А те самые последние 15% были запланированы на 2025 год. 

По канонам PMBook работа началась с определения цели проекта: что мы хотим получить по итогу? 

После долгих «раскопок», общений с бизнесом и ИТ цель была определена: мы хотим, чтобы продукты использовали платформенные сервисы и не использовали легаси. 

Критерии выполнения перехода: 

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

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

Почему нельзя было оставить, как есть, спросите вы? 

Переходом на целевые сервисы и отказом от легаси решалось несколько проблем и задач. 

Экономия: 

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

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

Стабильность:

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

Единообразие:

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

• Все одновременно получают один и тот же функционал.

Актуальность: 

• Сервисы гарантируют, что они всегда «на пике моды» и следят за нововведениями в нормативных документах (например, продукту можно не обращать внимания на часто меняющиеся требования по ведению электронного документооборота, команда платформенного сервиса всё актуализирует и предупредит, если что-то надо дополнительно доработать).

Одни плюсы! 

Что ж, половина дела сделана, но проект с 85% выполнения откатился на 79%.

Почему и за что?

Потому что представитель продукта раньше ПИСЬМОМ подтверждал, что закончил работы.

А потом никто не проверял, так ли это на самом деле. 

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

Проблемы, выявленные при проведении аудита проекта:

1. Поквартальное планирование — продукт озвучивал квартал, в течение которого он завершит переход на тот или иной целевой сервис. РМ раз в квартал приходил и уточнял статус: перешли — здорово, закрываем задачу, не перешли — какой новый срок перехода? И так из квартала в квартал. Некоторые продукты 1,5 года переносили сроки.

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

3. Отсутствие технического подтверждения выполнения задачи — словесное подтверждение представителем продукта, что работы завершены. 

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

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

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

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

Что было сделано: 

Для отслеживания прогресса в рамках спринтов/месяцев расширена статусная модель до этапов жизненного цикла фичи.

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

Задачи в Jira позволили отслеживать статус в реальном времени, но не тут то было. Несмотря на единый flow, каждая команда по своему использовала типы задач, декомпозицию. Поэтому проект продолжил жить в Google Таблицах, но теперь мы могли проводить промежуточный контроль завершения этапов в соответствии с новой статусной моделью.

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

Итого были сформированы шаблоны отчетности 3 уровней:

• Верхнеуровневый статус для высшего руководства (процент выполнения и светофор по депертаментам) —слайд в презентации.

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

• Операционная таблица по департаменту для исполнителей задач, с комментариями и уточнениями от РМ — GoogleDocs таблиц.

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

«0» — эскалации не требуется.

«1» — ушло напоминание исполнителю через 2 рабочих дня «игнора» (добавляем  Владельца продукта со стороны бизнеса и Тим-лида со стороны техники).

«2» — эскалация на руководителя. Ушло письмо сотруднику и его руководителю после 2-х рабочих дней после «1» (Добавляем Руководителя владельца продукта и ИТ-лида).

«3» — эскалация на руководителя. Напоминание через 2 рабочих дня после «2» (Добавляем руководителя подразделения).

«4» — эскалация на руководителя руководителя. Через 2 рабочих дня после «3» (добавляем руководителя департамента и назначаем встречу с руководителем подразделения).

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

К чему это привело: 

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

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

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

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

Многие моменты в управлении проекта были упущены как мной, так и моими предшественниками — часть задумок разбились о бюрократию и/или желание быстрее закрыть проект, часть можно было почерпнуть из книжек, но личный опыт убеждает лучше любой книги. 

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

Сейчас проект стабилизировался и двигается по намеченному плану, но с другими сроками и постановкой цели. 

Несмотря на то, что проект был пересмотрен и многие процессы автоматизированы, на проекте всё ещё остались зоны, требующие внимания:

• Высокий уровень микроменеджмента.

• Ручное ведение таблиц и смена статусов переходов.

• Постоянные переносы сроков из-за переприоритизации бизнесовых задач.

• Новые вводные из-за специфических архитектурных решений.

Но Москва не сразу строилась, и мы будем последовательно решать проблемы. 

Продолжение смотрите в следующей серии.