8.2 Уроки из провалившихся проектов
Как бы тщательно ни планировался проект, провал всё равно возможен. Но провал — не только конечный результат: он несёт уроки, которые стоит сохранить для следующего раза.
В этом разделе мы пройдёмся по типичным причинам и тревожным сигналам, которые проявляются в провальных проектах, под несколькими углами, чтобы вы могли замечать их раньше и не давать им расходиться.
1. Цели были нечёткими или сместились по ходу
- Разные стейкхолдеры держали в голове противоречивые ожидания, которые так и не были согласованы
- Бизнес-цели нигде чётко не были записаны, поэтому каждая сторона трактовала их по-своему
- Приоритеты компании поменялись посередине проекта, и изначальный смысл уплыл
Без устойчивого направления даже проект, выпущенный в срок, может остаться в памяти разочарованием.
2. Риски и проблемы плохо передавались
- Трекер задач превратился в формальность — заполняли, но не работали с ним
- Голоса с мест не доходили до тех, кто принимает решения
- План митигации рисков и плана «Б» не было либо они были поверхностные
Культура замалчивания — или откладывания трудных разговоров на потом — делает работу с ранними рисками почти невозможной.
3. Человеческие факторы упускались из виду
- PM или другие ключевые лидеры назначались слишком поздно или вообще никак
- Ревью и согласования превращались в формальное «штампование»
- Текучка участников оставляла передачи незавершёнными
Стабильные люди и понятная зона ответственности значат не меньше, чем расписание. Потеряете одно — и всё остальное начинает шататься.
4. Управление проектом не работало
- Ситуация была понятна, но решения откладывались или избегались
- Согласованные правила — ревью, апдейты по прогрессу — на деле не соблюдались
- Отчёты сдавались, но они не приводили к действию
«Знали, но не действовали» — один из самых распространённых паттернов провала проекта.
Кейс: переделка интернет-магазина (розничная компания)
Обзор: 8-месячная полная переработка B2C-сайта e-commerce, в итоге свёрнутая ближе к запуску.
- KPI были непрозрачны, требования постоянно менялись с самого начала
- Координация со стороны пользователей была слабой, и подтверждение спецификации всё время уезжало
- Ключевые члены команды уволились, и непрерывность с передачей знаний оборвалась
- Проблемы с качеством накопились ближе к релизу, и проект отменили
Этот кейс собрал в себе размытые цели, провалы в лидерстве и слабую коммуникацию — каждое в отдельности можно было пережить, но вместе они отправили проект за точку, откуда восстановить его уже было нельзя.
Вывод: провал — это паттерн пропущенных сигналов
Провал проекта вызывается не одной ошибкой. Он — результат накопленных сигналов, отложенных решений и разговоров, которые так и не состоялись.
Поэтому замечать дискомфорт рано — и иметь смелость и систему, чтобы поставить на паузу, обсудить и починить, — и есть настоящая профилактика.
Как это выглядит в AB
У каждого режима провала выше есть аналог в AB Project Management: размытый объём → описание проекта плюс страница Wiki «Out of Scope» дают объёму одно место, откуда он не сдвигается; скрытые риски → задачи типа Risk с регулярными чек-инами держат риски живыми, а не похороненными в таблице; поздние эскалации → вкладка истории изменений автоматически показывает изменения статуса и исполнителя, поэтому эскалация не превращается в отдельный отчёт; силосы знаний → страницы Wiki, комментарии и вложения остаются с проектом, а не разбросаны по дискам и почте; непонятная зона ответственности → поле исполнителя обязывает на каждую задачу повесить имя. AB не предотвращает провалы — но делает их видимыми раньше, пока их ещё дёшево исправить.
→ Далее перейдите к статье 9.0 Часто задаваемые вопросы (FAQ), чтобы пройтись по типичным сложностям и практическим вопросам реальной проектной работы.