Как спасти проваливающийся IT-проект
Продвинутое3 минРедакция Innovialabs
Коротко
Остановитесь и найдите корневую причину, сократите объем до того, что действительно нужно к запуску, честно пересогласуйте сроки и восстановите доверие через короткие циклы с видимым результатом.
Короткий ответ
Проваливающийся проект спасают не ускорением, а паузой и диагностикой. Добавить людей или потребовать переработок — самый частый и почти всегда неработающий ход. Порядок действий такой:
- Зафиксировать реальное состояние проекта.
- Найти корневую причину, а не симптомы.
- Сократить объем до минимально ценного результата.
- Пересогласовать сроки на основе фактов.
- Перейти на короткие циклы с регулярной демонстрацией результата.
Признаки, что проект в беде
- Сроки сдвигаются уже не первый раз, а новые оценки никто не воспринимает всерьез.
- Статус «почти готово» держится неделями.
- Количество багов растет быстрее, чем их исправляют.
- Заказчик и команда общаются через претензии, а не через задачи.
- Никто не может четко сказать, что именно войдет в первый релиз.
Если вы узнали два-три пункта — пора действовать, а не ждать, что ситуация выправится сама.
Шаг 1. Аудит реального состояния
Соберите факты, а не мнения:
- Что реально работает — проверьте на стенде, а не по отчетам.
- Состояние кода — есть ли тесты, документация, понятная архитектура. Если сомневаетесь, закажите независимый технический аудит.
- Доступы и активы — репозиторий, серверы, домены, аккаунты сервисов. Всё должно принадлежать заказчику.
- Бэклог — сколько задач осталось и насколько они описаны.
Шаг 2. Найти корневую причину
Симптомы похожи, причины — разные. От причины зависит лечение.
| Корневая причина | Как проявляется | Что делать |
|---|---|---|
| Размытые требования | Постоянные переделки, споры «мы это не так поняли» | Зафиксировать требования и критерии приемки |
| Раздутый объем | Задачи добавляются быстрее, чем закрываются | Жестко приоритизировать, остальное — в следующие этапы |
| Слабая команда или нехватка компетенций | Низкое качество, медленный прогресс | Усилить ключевые роли или сменить исполнителя |
| Технический долг | Каждое изменение ломает что-то еще | Выделить время на стабилизацию и тесты |
| Нет управления | Никто не отвечает за приоритеты и сроки | Назначить одного ответственного за продукт |
| Плохая коммуникация | Сюрпризы на каждом созвоне | Регулярные демо и единый канал статуса |
Чаще всего причин несколько. Начните с той, что блокирует остальные.
Шаг 3. Пересобрать объем
Ответьте на вопрос: какой минимальный результат принесет пользу бизнесу? Всё, что не входит в этот ответ, переносится на потом.
Практический прием — разделить бэклог на три группы:
- обязательно к запуску — без этого продукт бессмыслен;
- важно, но после запуска;
- хотелось бы — откладывается без сожалений.
Сокращение объема — это не поражение, а способ получить работающий продукт раньше и начать учиться на реальных пользователях.
Шаг 4. Пересогласовать сроки
Новый план строится на фактической скорости команды, а не на желаемой. Чтобы оценка была честной:
- разбейте оставшиеся задачи на небольшие части;
- заложите время на стабилизацию и тестирование;
- договоритесь о контрольных точках, на которых план пересматривается.
Если меняется объем или сроки, зафиксируйте это письменно — дополнением к договору или обновленным планом.
Шаг 5. Восстановить доверие
Доверие возвращается не обещаниями, а видимым прогрессом:
- короткие итерации с демонстрацией работающего результата;
- прозрачный статус: что сделано, что в работе, какие риски;
- плохие новости сообщаются сразу, а не накануне дедлайна;
- одна ответственная сторона, к которой можно прийти с вопросом.
Чего не делать
- Добавлять людей в горящий проект — новичкам нужно время на погружение, а команде — на их обучение.
- Искать виноватых вместо причин.
- Молча продолжать по старому плану в надежде успеть.
- Менять подрядчика без доступов и документации — новая команда начнет с нуля.