Какой был самый неудачный проект?

Самый неудачный проект — уроки, которые я извлёк

Я верю в честность при обсуждении неудач. На протяжении 10+ лет управлял проектами, где были серьёзные проблемы. Расскажу о одном из самых показательных.

Ситуация: система управления контентом (CMS) для крупной сетевой компании

Что произошло: Проект стартовал с энтузиазмом и оптимистичными сроками. Заказчик хотел большого функционала в сжатые сроки. Бюджет был ограниченный, на команду давили сроки. Результат был предсказуем — проект задержался на 6 месяцев, перевысил бюджет на 40%, и качество кода оставляло желать лучшего.

Корневые причины

1. Плохое начало (планирование и требования)

• Требования были расплывчатыми и постоянно менялись
• Не провёл должных интервью с пользователями
• Не привлекал заказчика к планированию
• Недостаточно времени на анализ рисков

2. Неправильная оценка сложности

• Недооценил интеграцию с существующими системами
• Упустил, что архитектура требует переработки
• Не учёл кривую обучения команды на новых технологиях

3. Проблемы в управлении

• Не было чётких метрик прогресса; сроки обновлялись каждую неделю
• Качество контроля было слабым — баги находились поздно в разработке
• Коммуникация между командой и заказчиком была нечастой
• Не проводил регулярные ревью с заказчиком

4. Давление на сроки

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

Что я изменил

Немедленные действия:

• Переговор с заказчиком о реалистичном сроке и бюджете
• Сокращение скопа на 30% — перенос некритичных функций на следующий релиз
• Введение двухнедельных спринтов с чёткими демо для заказчика
• Дополнительное тестирование и code review

Долгосрочные изменения в моём подходе:

• Требования: теперь провожу семинары с заказчиком и пользователями
• Оценка: использую трёхточечную PERT-оценку и добавляю резерв на неопределённость
• Коммуникация: еженедельные стендапы, минимум раз в две недели демо
• Качество: вводю code review на ранних этапах, автотесты, CI/CD
• Метрики: слежу за скопом, сроками, качеством и настроением команды

Результат и выводы

Вторая половина проекта прошла лучше. Хотя сроки уже были упущены, мы стабилизировали процесс и поставили качественный продукт.

Главные уроки:

1. Требования важнее сроков — лучше медленнее, но с ясными требованиями
2. Коммуникация решает всё — частые встречи предотвращают неприятные сюрпризы
3. Скоп — главный рычаг — когда давят на сроки, сокращаем функционал, не качество
4. Люди > планы — выгоревшая команда никогда не будет эффективной
5. Ранний контроль качества — баги в конце проекта убийственны

Сейчас эти уроки — основа моего подхода к управлению любым проектом.