Добрых дней и приятных ночей! Меня зовут Наталия Курченкова, я Project Manager с 10+ опытом управления проектами. Хочу поделиться опытом анализа кризисной ситуации на проекте и выстраивания шагов по исправлению ситации.
Когда я присоединилась к проекту по разработке мобильного приложения, ситуация выглядела тревожной. Формально процессы были выстроены: мы работали по Scrum с дейликами, ретроспективами и планированием покером. Но на практике каждый ежемесячный релиз задерживался на 1-3 недели, технический долг рос как снежный ком, а бюджет уходил в глубокий минус. В последний месяц команда потратила более 1000 часов только на исправление старых багов.
Передо мной стояла непростая задача - не искать виноватых, а разобраться в причинах и найти пути исправления ситуации. В этой статье я поделюсь своим опытом диагностики проблем и методами, которые помогли стабилизировать проект.
Тревожные сигналы в управлении проектом
Хронические задержки релизов
Несмотря на ежемесячный график выпуска обновлений, ни один релиз не выходил вовремя. Постоянные переносы на 1-3 недели стали нормой, а дополнительно требовалось время на согласования и выкладку. Это указывало на системные проблемы:
- Нереалистичные оценки сроков
- Неучтенные работы в процессе
- Отсутствие контроля за выполнением этапов
Неконтролируемый рост технического долга
Каждое обновление не только добавляло новый функционал, но и оставляло после себя неисправленные баги. В результате:
- Разработчики тратили сотни часов на исправление старых ошибок
- Тестирование не охватывало все критические сценарии
- Качество продукта неуклонно снижалось
Критический перерасход бюджета
Проект ушел в серьезный минус из-за постоянных доработок, экстренного привлечения дополнительных специалистов и финансовых последствий срывов сроков.
Пути решения проблем
1. Глубокий аудит процессов
Мы провели детальный анализ:
- Выявили этапы, на которых происходят задержки. В нашем случае это было слабое планирование, нереалистичные оценки, и отсутствующая система управления рисками.
- Определили основные источники багов
- Пересмотрели подход к оценке задач. Теперь клиент получал первоначальную оценку в виде возможного "диапазона" стоимости/часов, и если был согласен с ней, то мы проводили более углубленное изучение задачи, и давали финальную оценку только после серии командных исследований. Это позволило не тратить время на то, что не слишком важно для клиента, а нам делать более точные оценки.
2. Усиление контроля качества
Были внедрены важные изменения:
- Обязательный код-ревью перед слиянием изменений, который должен проводиться не позднее 1 рабочего дня после создания реквеста, чтобы не задерживать слияние кода.
- Расширение покрытия автотестами ключевых сценариев. Это существенно освободило время тестировщиков на новые фичи
- Выделение специального времени в спринтах на исправление багов
3. Оптимизация планирования
Мы пересмотрели подход к релизам:
- Уменьшили объем функционала в каждом обновлении + 30 процентов времени от всего релиза было выделено на багофикс
- Добавили буферный спринт для стабилизации версии
- Жестко зафиксировали правила Code Freeze. После старта Code Freeze - никаких заливок. И точка. Все что не попало - переходит в другой спринт
4. Улучшение коммуникации
Особое внимание уделили:
- Регулярной синхронизации с заказчиком
- Прозрачной системе приоритезации задач. Мы ввели дополнительные регулярные звонки с клиентом для выяснения приоритетов с обязательным письменным подтверждением результатов от клиента
- Своевременному информированию о рисках + был переформатирован процесс управления рисками - был введен реестр риском с регулярным мониторингом, что позволяло заранее продумывать стратегию
Ключевые уроки
- Хронические задержки - это симптом системных проблем, требующих глубокого анализа.
- Технический долг нельзя игнорировать - его рост неизбежно ведет к ухудшению качества продукта.
- Честность и прозрачность в коммуникации с заказчиком помогают избежать многих проблем.
Заключение
Ситуация, когда проект постоянно выбивается из графиков и бюджетов, знакома многим. В нашем случае системные изменения подходов к планированию и контролю качества позволили стабилизировать разработку и начать выпускать релизы в срок.
А вам приходилось сталкиваться с похожими проблемами? Какие решения оказались наиболее эффективными в вашей практике? Делитесь опытом в комментариях - возможно, ваш совет поможет другим читателям.
#IT-проекты #Управление командой #Эффективность разработки #Бюджет проекта #Сроки проекта #Управление качеством