Как стать автором
Обновить

Метод быстрого прохода в управлении проектами. Редкий успешный кейс

Время на прочтение 5 мин
Количество просмотров 10K

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

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

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

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

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

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

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

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

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

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

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

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

Автоматизация расчета ЧКО по овердрафтам ЮЛ

201 дней

Пн 10/08/20

Пн 17/05/21

Написание БТ

20 дней

Пн 10/08/20

Пт 04/09/20

Согласование БТ

15 дней

Пн 07/09/20

Пт 25/09/20

Работы в АБС

166 дней

Пн 28/09/20

Пн 17/05/21

Написание ФТ АБС

20 дней

Пн 28/09/20

Пт 23/10/20

Согласование ФТ АБС

10 дней

Пн 26/10/20

Пт 06/11/20

Собственная разработка АБС

60 дней

Пн 09/11/20

Пт 29/01/21

Написание тест-кейсов

8 дней

Пн 01/02/21

Ср 10/02/21

Согласование тест-кейсов

10 дней

Чт 11/02/21

Ср 24/02/21

Функциональное тестирование АБС

20 дней

Чт 25/02/21

Ср 24/03/21

Поддержка ПСИ АБС

15 дней

Чт 25/03/21

Ср 14/04/21

Тиражирование АБС

23 дней

Чт 15/04/21

Пн 17/05/21


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

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

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

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

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

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

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

Автоматизация расчета ЧКО по овердрафтам ЮЛ

161.88 дней

Пн 10/08/20

Пн 22/03/21

Написание БТ

20 дней

Пн 10/08/20

Пт 04/09/20

Согласование БТ

15 дней

Пн 07/09/20

Пт 25/09/20

BIQ-6685 0-й ЭТАП Автоматизация расчета ЧКО по овердрафтам ЮЛ

57.06 дней

Пн 28/09/20

Ср 16/12/20

Написание ФТ

2 дней

Пн 28/09/20

Вт 29/09/20

Согласование ФТ

3 дней

Ср 30/09/20

Пт 02/10/20

Собственная разработка

10 дней

Пн 05/10/20

Пт 16/10/20

Написание тест-кейсов

4 дней

Пн 19/10/20

Чт 22/10/20

Функциональное тестирование

8 дней

Пт 23/10/20

Вт 03/11/20

Поддержка ПСИ

16 дней

Ср 04/11/20

Ср 25/11/20

Тиражирование

12 дней

Пн 30/11/20

Ср 16/12/20

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

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

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

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

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

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

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

Автоматизация расчета ЧКО по овердрафтам ЮЛ

122 дней

Пн 10/08/20

Пн 25/01/21

Написание БТ

20 дней

Пн 10/08/20

Пт 04/09/20

Согласование БТ

15 дней

Пн 07/09/20

Пт 25/09/20

BIQ-6685 0-й ЭТАП Автоматизация расчета ЧКО по овердрафтам ЮЛ

57.06 дней

Пн 28/09/20

Ср 16/12/20

Написание ФТ

2 дней

Пн 28/09/20

Вт 29/09/20

Согласование ФТ

3 дней

Ср 30/09/20

Пт 02/10/20

Собственная разработка

10 дней

Пн 05/10/20

Пт 16/10/20

Написание тест-кейсов

4 дней

Пн 19/10/20

Чт 22/10/20

Функциональное тестирование

8 дней

Пт 23/10/20

Вт 03/11/20

Поддержка ПСИ

16 дней

Ср 04/11/20

Ср 25/11/20

Тиражирование

12 дней

Пн 30/11/20

Ср 16/12/20

BIQ-6685 ОСНОВНОЙ ЭТАП Автоматизация расчета ЧКО по овердрафтам ЮЛ

102 дней

Пн 07/09/20

Пн 25/01/21

Написание ФТ

21 дней

Пн 07/09/20

Пт 02/10/20

Согласование ФТ

8 дней

Пн 05/10/20

Ср 14/10/20

Собственная разработка

50 дней

Пн 05/10/20

Пт 11/12/20

Написание тест-кейсов

10 дней

Чт 15/10/20

Ср 28/10/20

Согласование тест-кейсов

7 дней

Чт 29/10/20

Пт 06/11/20

Функциональное тестирование

15 дней

Пн 14/12/20

Пт 01/01/21

Поддержка ПСИ

10 дней

Пн 04/01/21

Пт 15/01/21

Тиражирование

6 дней

Пн 18/01/21

Пн 25/01/21

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

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

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

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

Теги:
Хабы:
+5
Комментарии 5
Комментарии Комментарии 5

Публикации

Информация

Сайт
www.rshb.ru
Дата регистрации
Дата основания
Численность
свыше 10 000 человек
Местоположение
Россия
Представитель
Юлия