Когда проект считается проблемным
Проблемный проект — это не обязательно катастрофа. Чаще он выглядит как работа, которая формально продолжается, но не приближает бизнес к результату. Команда занята, задачи двигаются, встречи проходят, но сроки переносятся, новые ошибки появляются быстрее исправлений, а решения принимаются на ощущениях.
В такой ситуации собственнику или руководителю проекта нужен не новый спор с подрядчиком, а независимая диагностика: что действительно происходит, какие риски критичны и какой первый шаг безопасен.
Типовые симптомы
- сроки сорваны, но никто не может показать реальную причину;
- подрядчик говорит, что “почти готово”, но готовность нельзя проверить;
- каждая новая доработка вскрывает старые проблемы;
- команда спорит о требованиях, архитектуре или ответственности;
- документация отсутствует или устарела;
- бизнес уже думает о смене подрядчика, но не понимает, что передавать новой команде;
- проект стал дорогим, но результат не стал предсказуемым;
- AI, портал или личный кабинет запущены формально, но пользователи не получают пользы.
Не всегда виноват подрядчик
В проблемном проекте легко свести всё к вопросу “подрядчик справляется или нет”. На практике причина может быть смешанной:
- архитектура не выдерживает новые требования;
- бизнес-логика была описана неполно;
- интеграции оказались сложнее, чем оценивались на старте;
- нет единого владельца решений;
- подрядчик работает без ясных критериев приёмки;
- требования меняются быстрее, чем команда успевает стабилизировать систему.
Такой разбор помогает не обострять конфликт без необходимости. Иногда текущую команду можно сохранить, если дать ей понятные решения и контрольные точки. Иногда смена подрядчика оправдана, но её нужно готовить технически.
Что делать в первые 7 дней
- Зафиксировать текущий статус проекта: что готово, что не готово, что работает нестабильно.
- Собрать документы, договорённости, backlog, список интеграций и открытых вопросов.
- Отделить бизнес-критичные сценарии от второстепенных доработок.
- Попросить подрядчика дать список блокеров и технических рисков в письменном виде.
- Не запускать крупные новые доработки, пока не ясна причина задержек.
- Провести независимый разбор архитектуры, процессов и коммуникации.
- Сформировать короткую дорожную карту стабилизации.
Что проверяется
- где именно проект потерял управляемость;
- есть ли архитектурная причина, а не только проблема исполнения;
- можно ли безопасно продолжать с текущей кодовой базой;
- какие документы и решения нужно восстановить;
- какие работы стоит остановить до прояснения картины;
- что спрашивать у текущего подрядчика;
- как подготовить проект к передаче, если смена команды неизбежна.
Результат диагностики
Клиент получает независимую картину состояния проекта и план: что сохранить, что перепроектировать, что проверить у подрядчика и как двигаться дальше без лишних затрат.
На выходе обычно появляются:
- карта причин технического или управленческого тупика;
- список критичных рисков;
- вопросы подрядчику;
- план стабилизации на ближайший этап;
- рекомендации по продолжению, остановке, передаче или восстановлению проекта.
Связанные материалы
- Обезличенный сценарий: B2B-портал зашёл в технический тупик.
- Обезличенный сценарий: бизнес готовился сменить подрядчика.
- Обезличенный сценарий: проект передавали без документации.
- Если нужно не только разобраться, но и восстановить управляемость, смотрите восстановление web/AI-проекта.
- Если проблема шире одного проекта и затрагивает весь IT/digital-отдел, подходит аудит и настройка IT/digital-отдела.
- Если вопрос в работе команды, полезна услуга технического контроля подрядчика.
- Общий подход описан в методологии диагностики.
