Меня зовут Андрей, руковожу проектами в РСХБ-Интех. В бэкграунде 6 лет управления проектами, портфелями проектов в интехе, ритейле, сертификация PME, PRIME. Сегодня я хочу рассказать о редком успешном кейсе использования метода быстрого прохода, и что это дало заказчику.
Итак, погнали!
1) Экспресс-анализ бизнес-инициативы. На этом этапе технолог определяет системы, которые необходимо доработать. Аналитики этих систем оценивают в майках, сколько потребуется ресурсов на разработку.
2) Сформировали оценки по всем системам, сложили их, получили примерную стоимость и потенциальную длительность работ.
3) Отправили оценку на согласование заказчику. После того, как заказчик сказал, что ему нужен этот функционал за эти деньги, технологи начинают писать бизнес-требования — перенос бизнес-хотелки из двух строк в формализованный артефакт.
4) Одновременно с этим руководитель проекта начинает рисовать «колбаски» в проджект-офисе.
По стандартному жизненному циклу разработки (написание БТ (бизнес-требований) – согласование БТ – написание ФТ (функциональных требований) – согласование ФТ – разработка – тестирование систем – тестирование интеграций между системами – ПСИ ( приемо-сдаточные испытания) – тираж) получился срок реализации 200 рабочих дней, а календарных с учетом праздников – 9 месяцев.
Ниже представлена часть плана из критического пути, вокруг которого были налеплены остальные работы.
Но руководитель проектов уверен, что если 1 женщина может родить 1 ребенка за 9 месяцев, то 9 женщин могут родить 1 ребенка за 1 месяц. Зная заранее, что заказчик не согласится с первоначальными сроками, приступаем к магии, чтобы сократить критический путь.
Быстрый проход (Fast Tracking) – метод сжатия расписания проекта, изменяющий логику сети путем наложения друг на друга фаз, которые в обычной ситуации выполнялись бы последовательно, например, фазы проектирования и фазы строительства, или разработки и тестирования.
Также будем использовать разбиение работ на этапы, но сейчас речь не про декомпозицию – она у нас в плане есть. Сейчас мы берем часть из фреймворка гибких методологий. А именно создаем MVP — минимально жизнеспособный продукт. Хотя, в чистом виде, это тоже не MVP. Мы даем заказчику хоть что-то, несущее business value (бизнес ценность), максимально быстро, потом переходим на реализацию основного этапа.
Мы помним, что заказчик тратит огромное количество ресурсов на ручной расчет. На оптимизацию плана накладываются ограничения – релизная политика. Все доработки АБС перед тем, как попасть на промышленную среду, должны пройти череду тестирований, потом приемку у заказчика, потом сертификацию у производителя АБС, и в заранее запланированную дату установки обновлений на промышленную среду быть готовыми.
Сначала мы выделили из всего функционала то, что точно успеем сделать, чтобы попасть в ближайший тираж, и назвали это нулевым этапом. Ручная работа остается, но что-то уже не надо делать руками:
Мы изменили скоуп работ – добавили доп. работы на тестирование, тиражирование, да и сроки тоже планируем сокращать – их увеличивать нельзя. Мы помним о тройственной ограниченности в управлении проектам: содержание, стоимость, время.
Что же… Идем к заказчику и объявляем:
Не 10 000 баксов, но это не суть как важно, получаем одобрение на увеличение расходов, приступаем к оптимизации сроков по основному функционалу.
Тем не менее, чтобы действовать последовательно, в соответствии с PMBOK определяем риск. Добавляем его в нашу матрицу рисков. Оцениваем и определяем стратегию реагирования (а у нас здесь возможно только принятие этого риска –ни минимизировать, ни уклониться никак нельзя). В случае возникновения риска мы не попадем в планируемую дату тиража, то есть проект у нас не соблюдет сроки. Кто наиболее заинтересован в соблюдении сроков? – опять-таки заказчик.
Вот у нас и определился владелец риска. В очередной раз идем к заказчику, получаем согласование на этот риск и в результате имеем следующий план:
Таким образом мы сократили длительность разработки почти в 2 раза.
habr.com
Итак, погнали!
Рождение задачи
В июле 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 раза, а самое главное — сократили time2market от идеи до тиража с 9 месяцев до 5 (этот параметр очень важен для оценки эффективности ДИТ, он может быть зашит в KPI подразделения). И самое лучшее, что произошло — не сработал риск уменьшения качества, не сработали никакие другие риски, к примеру, болезнь или увольнение ключевых сотрудников.
Метод быстрого прохода в управлении проектами. Редкий успешный кейс
Привет, Хабр! Меня зовут Андрей, руковожу проектами в РСХБ-Интех. В бэкграунде 6 лет управления проектами, портфелями проектов в интехе, ритейле, сертификация PME, PRIME. Сегодня я хочу рассказать о...
habr.com