Привет, Хабр! Меня зовут Андрей, руковожу проектами в РСХБ-Интех. В бэкграунде 6 лет управления проектами, портфелями проектов в интехе, ритейле, сертификация PME, PRIME. Сегодня я хочу рассказать о редком успешном кейсе использования метода быстрого прохода, и что это дало заказчику.

Итак, погнали!

Рождение задачи

В июле 2020 г. решили обновить продуктовую линейку кредитной линии для клиентов юридических лиц. Основным драйвером была необходимость автоматического расчета лимита кредитования на следующий месяц на основании трат/поступлений предыдущего месяца плюс всякие нюансы для автоматизации. Звучит сложно, в двух словах: большие обороты – хорошая кредитная линия, обороты падают – сигнал для того, что есть потенциальные риски с возвратом кредитных средств. Этого функционала не было в дистрибутивной реализации Автоматизированной Банковской Системы (АБС), а без него на ручной расчет лимитов и сопровождение кредитов тратится огромное количество Ч\Ч.

Первоначальное планирование

В соответствии с регламентами, принятыми у нас, которые разрабатывались на основе PMBOK, запустился жизненный цикл доработки:

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

2. Сформировали оценки по всем системам, сложили их, получили примерную стоимость и потенциальную длительность работ.

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

4. Одновременно с этим руководитель проекта начинает рисовать «колбаски» в проджект-офисе.

По стандартному жизненному циклу разработки (написание БТ (бизнес-требований) – согласование БТ – написание ФТ (функциональных требований) – согласование ФТ – разработка – тестирование систем – тестирование интеграций между системами – ПСИ ( приемо-сдаточные испытания) – тираж) получился срок реализации 200 рабочих дней, а календарных с учетом праздников – 9 месяцев.

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

Но руководитель проектов уверен, что если 1 женщина может родить 1 ребенка за 9 месяцев, то 9 женщин могут родить 1 ребенка за 1 месяц. Зная заранее, что заказчик не согласится с первоначальными сроками, приступаем к магии, чтобы сократить критический путь.

Оптимизация плана — разбиение на этапы

Сначала немного терминологии:

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

Также будем использовать разбиение работ на этапы, но сейчас речь не про декомпозицию – она у нас в плане есть. Сейчас мы берем часть из фреймворка гибких методологий. А именно создаем MVP — минимально жизнеспособный продукт. Хотя, в чистом виде, это тоже не MVP. Мы даем заказчику хоть что-то, несущее business value (бизнес ценность), максимально быстро, потом переходим на реализацию основного этапа.

Мы помним, что заказчик тратит огромное количество ресурсов на ручной расчет. На оптимизацию плана накладываются ограничения – релизная политика. Все доработки АБС перед тем, как попасть на промышленную среду, должны пройти череду тестирований, потом приемку у заказчика, потом сертификацию у производителя АБС, и в заранее запланированную дату установки обновлений на промышленную среду быть готовыми.

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

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

Что же… Идем к заказчику и объявляем:

Не 10 000 баксов, но это не суть как важно, получаем одобрение на увеличение расходов, приступаем к оптимизации сроков по основному функционалу.

Оптимизация плана — быстрый проход

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

Тем не менее, чтобы действовать последовательно, в соответствии с PMBOK определяем риск. Добавляем его в нашу матрицу рисков. Оцениваем и определяем стратегию реагирования (а у нас здесь возможно только принятие этого риска –ни минимизировать, ни уклониться никак нельзя). В случае возникновения риска мы не попадем в планируемую дату тиража, то есть проект у нас не соблюдет сроки. Кто наиболее заинтересован в соблюдении сроков? – опять-таки заказчик.

Вот у нас и определился владелец риска. В очередной раз идем к заказчику, получаем согласование на этот риск и в результате имеем следующий план:

Таким образом мы сократили длительность разработки почти в 2 раза.

Быстрый проход — итоги

Обычно использование метода быстрого прохода влечет за собой ком проблем, как на КДПВ. Однако в этот раз у нас все получилось! Мы смогли уменьшить длительность разработки в 2 раза, а самое главное — сократили time2market от идеи до тиража с 9 месяцев до 5 (этот параметр очень важен для оценки эффективности ДИТ, он может быть зашит в KPI подразделения). И самое лучшее, что произошло — не сработал риск уменьшения качества, не сработали никакие другие риски, к примеру, болезнь или увольнение ключевых сотрудников.

А у вас были реальные успешные кейсы быстрого прохода или сжатия в управлении проектами?