Расскажите о проекте, который пошёл не по плану. Как вы справились?

Проект в кризисе: реальный кейс управления рисками

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

Контекст и планы

Это был проект миграции с легасии платежного движка на новую архитектуру. Планировалось:

• Длительность: 4 месяца
• Бюджет: 500 тыс рублей
• Команда: 1 BA, 3 разработчика, 1 QA
• Сроки: жесткие, так как нужно было уложиться в квартал
• Критичность: высокая, от проекта зависела стабильность платежей

Момент истины: что пошло не так

На неделе 4 из 16:

• Обнаружилось, что легасии система намного сложнее чем мы предполагали
• Документация была неполной (многое жило только в голове старых разработчиков)
• Обратная совместимость требовала намного больше работ
• Интеграции с партнерскими платежными системами работали не по стандартам
• Требования stakeholders начали меняться

Метрики кризиса:

• Velocity упала на 40 процентов
• Обнаружены критичные баги в тестировании
• Появились 15 новых требований, о которых раньше не знали
• Проект был под угрозой срыва на 2+ недели

Мои действия как BA

1. Быстрая диагностика и честный анализ (День 1-2)

Первое что я сделал — провел встречу с командой без фильтров:

• Давайте честно скажем в чем проблема
• Выявил технические блокировки
• Выслушал боли разработчиков
• Документировал все риски

Потом встреча с Product Owner:

• Показал числа
• Объяснил что плана придется пересматривать
• Предложил варианты решения

2. Переоценка требований (День 3-4)

Создал матрицу всех требований с приоритизацией. Обозначил что является:

• Must Have (критичное для MVP)
• Should Have (важное)
• Could Have (желательное)
• Wont Have (отложено)

Вывод: Сократили scope на 25 процентов, отложив нежелательное на следующий квартал

3. Переплан спринтов (День 5)

Пересчитал velocity на основе новых данных:

• Спринт 2-3: базовая миграция (критично)
• Спринт 4: обратная совместимость (критично)
• Спринт 5: optimization (высокий приоритет)
• Спринт 6+: enhancement (дополнительные функции)

4. Управление stakeholders (День 6-7)

Организовал встречу со всеми stakeholders:

Честный разговор: Объяснил что нужно выбирать: быстро, качественно или полный функционал.

Варианты:

• Сценарий A: Отложить на 2 недели, сделать все как планировали
• Сценарий B: Выпустить базовую версию в срок, расширение позже (рекомендовал)
• Сценарий C: Нанять больше разработчиков (дорого и рискованно)

Результат: Выбрали Сценарий B — MVP в срок, фазы после

5. Управление рисками (День 8+)

Создал Risk Register с приоритизацией всех выявленных рисков:

• Баги в интеграциях: Нанять дополнительного QA
• Ключевой разработчик болен: Документировать, парное программирование
• Требования еще поменяются: Change Control Process
• Performance issues: Load testing, profile early

6. Повышение коммуникации

• Ежедневные синхро: Вместо еженедельных отчетов
• Daily standups с stakeholders: 15 минут, статус проекта
• Weekly risk review: Пересматриваем что изменилось
• Transparent dashboard: Все видят прогресс в real-time

Результаты

Что произошло дальше:

1. Спринты 2-4: Команда работала на 110 процентов, но в sustainable pace

   • Фокусировались на критичном функционале
   • Отложили nice-to-have функции
   • Качество было отличное — критичных багов найдено мало

2. Спринт 5: Юзер фидбек и оптимизация

   • Некоторые новые требования были валидны и мы их добавили
   • Другие были просто пожелания — оставили на потом

3. Go-live: На 5 дней позже оригинального плана

   • Система стабильна
   • Обработка платежей работает корректно
   • Stakeholders были удовлетворены

4. Post-project: В следующих квартальных планах добавили остальной функционал

Ключевые уроки которые я извлек

1. Реалистичное планирование

• Недооценивал сложность интеграций
• Нужно больше buffer на unknown unknowns
• Диагностировать проблемы рано

2. Honesty побеждает панику

• Когда я честно сказал что плана придется менять, stakeholders оценили это
• Скрывать проблемы — худший вариант
• Лучше плохая новость в срок чем хорошая — слишком поздно

3. Stakeholder management критичен

• Когда люди видят что ты контролируешь ситуацию и у тебя есть план, они расслабляются
• Предложить варианты больше чем просить помощь
• Вовлечь stakeholders в решение = они становятся союзниками

4. Гибкость лучше чем rigidity

• Agile подход помог нам адаптироваться быстро
• Если бы мы были в Waterfall, было бы намного хуже
• Регулярные review points спасают проекты

5. Команда — главное

• Мотивированная команда может сделать невозможное
• Убрать препятствия важнее чем давить дедлайны
• Признание работы команды очень важно

Что я делаю иначе теперь

• Planning pointers: Увеличил buffer для неизвестных факторов
• Risk identification: Проводим детальный discovery в начале проекта
• Early stakeholder engagement: Встречаюсь со stakeholders до планирования
• Transparent communication: Всегда честен о рисках и возможностях
• Continuous monitoring: Слежу за velocity и рисками каждый спринт
• Lessons learned: После каждого проекта проводим review

Вывод

Этот проект научил меня что лучший BA — это не тот кто идеально планирует (невозможно), а тот кто быстро адаптируется к реальности, честно общается и находит win-win решения.

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

1. Рано обнаружили проблемы
2. Честно их признали
3. Быстро адаптировались
4. Вовлекли всех в решение
5. Сфокусировались на критичном
6. Поддерживали и мотивировали команду