Короткий ответ
Если подрядчик затягивает разработку, не стоит сразу выбирать между “терпеть” и “менять команду”. Сначала нужно понять, есть ли у бизнеса проверяемая картина проекта: что готово, что не готово, почему срок сдвинулся, какие риски остались и что произойдёт после оплаты или нового бюджета.
После такой проверки обычно остаётся три рабочих сценария:
- продолжать с текущим подрядчиком, если задержка объяснима и есть план;
- подключить технический контроль подрядчика, если факты есть частично, но бизнес не может сам проверить готовность;
- готовить смену подрядчика, если проект держится на обещаниях, доступы и документация не передаются, а новый срок снова нельзя проверить.
Это не юридическая инструкция и не способ давить на подрядчика. Это управленческая проверка, которая помогает собственнику не платить, не ждать и не менять команду вслепую.
Почему ситуация выглядит одинаково, а решения разные
Снаружи многие проблемные проекты выглядят похоже: срок перенесли, релиза нет, подрядчик говорит “почти готово”, просит оплатить этап или объясняет, что задача оказалась сложнее. Но причина может быть разной.
Иногда подрядчик действительно столкнулся с объективной сложностью: неописанная бизнес-логика, нестабильная интеграция, грязные данные, старый код, отсутствие решений со стороны бизнеса. Тогда проект можно вернуть в управляемость через новый план и контрольные точки.
Иногда проблема в прозрачности: команда что-то делает, но не показывает статус так, чтобы собственник мог принять решение. В этом случае может помочь независимый контроль: перевести разговор из “мы почти закончили” в список фактов, рисков и условий приёмки.
А иногда проект уже опасно продолжать в прежнем формате. Если подрядчик не показывает результат, не фиксирует решения, не передаёт доступы и каждый перенос заканчивается новым счётом, бизнесу нужно параллельно готовить передачу проекта.
Первый шаг: собрать факты, а не спорить о доверии
Главная ошибка в такой ситуации - начинать разговор с оценки подрядчика: хороший он или плохой. Это быстро переводит общение в конфликт и не помогает понять состояние проекта.
Более рабочий вопрос: можно ли сейчас принять управленческое решение по фактам?
Для этого нужно собрать минимум:
- какой срок был обещан изначально;
- какие сроки уже переносились;
- что входило в текущий этап;
- что подрядчик считает готовым;
- где можно посмотреть готовый результат;
- какие дефекты, блокеры и ограничения известны;
- что подрядчик просит: оплату, новый срок, новый бюджет, изменение объёма;
- какие документы, доступы и артефакты уже переданы бизнесу.
Если эти данные собрать невозможно, проблема уже не только в сроке. Проблема в управляемости проекта.
Таблица решений
| Ситуация | Что это означает | Что делать |
|---|---|---|
| Подрядчик показывает демо, список задач и причины задержки | Есть факты, задержку можно проверить | Продолжать работу с новым планом и контрольными точками |
| Есть результат, но непонятно, можно ли его принимать | Нужна проверка готовности и рисков | Подключить технический контроль перед оплатой или релизом |
| Подрядчик просит оплатить этап, но не показывает результат | Оплата будет решением вслепую | Сначала проверить этап: демо, приёмку, дефекты, документацию |
| Новый срок назван без критического пути | Есть риск повторного переноса | Запросить план до релиза, блокеры, зависимости и решения бизнеса |
| Новый бюджет объясняется общими словами | Неясно, что изменилось в объёме | Разделить старый scope, новые требования и ошибки оценки |
| Доступы, код и документация не передаются | Передача проекта будет рискованной | Готовить пакет передачи параллельно с переговорами |
| Каждый разговор заканчивается “ещё немного подождите” | Проект живёт на обещаниях | Остановить спорные работы и провести независимую проверку |
Эта таблица не заменяет аудит, но помогает быстро понять, какой сценарий ближе к вашей ситуации.
Сценарий 1. Продолжать с текущим подрядчиком
Продолжать работу можно, если подрядчик даёт достаточно фактов и готов перестроить управление проектом.
Признаки, что сценарий рабочий:
- есть демонстрация готового результата;
- понятен список задач, которые входят в ближайший релиз;
- подрядчик показывает блокеры и зависимости;
- причины задержки описаны предметно;
- новый срок связан с конкретными задачами, а не с общей надеждой;
- подрядчик готов фиксировать решения письменно;
- есть критерии приёмки этапа.
В этом случае задача бизнеса - не усиливать давление, а сделать новый план проверяемым.
Что нужно зафиксировать:
- Состав ближайшего релиза.
- Критерии готовности по ключевым задачам.
- Открытые дефекты и ограничения.
- Ответственных за решения со стороны бизнеса и подрядчика.
- Контрольные точки: что будет показано и когда.
- Условия, при которых срок может снова измениться.
Если всё это есть, задержка неприятна, но управляемая.
Сценарий 2. Усилить контроль подрядчика
Контроль нужен, когда проект ещё можно продолжать, но бизнес не может самостоятельно проверить техническую часть.
Типовые признаки:
- подрядчик показывает активность, но не показывает готовность;
- отчёты есть, но они не помогают принять решение;
- нужно понять, оплачивать ли этап;
- есть сомнения по релизу, интеграциям, архитектуре или документации;
- внутри компании нет CTO или технического руководителя;
- подрядчик не конфликтует, но отвечает слишком общо.
В этом сценарии не нужно сразу менять команду. Нужно поставить проверку между бизнесом и подрядчиком.
Контроль должен ответить на конкретные вопросы:
- что реально готово;
- что можно принять;
- что нужно исправить до оплаты;
- что несёт риск для следующего этапа;
- какие решения должен принять бизнес;
- можно ли запускать релиз;
- какая документация нужна, чтобы не зависеть от подрядчика полностью.
Для первичной самопроверки подойдёт чек-лист контроля подрядчика. Если вопрос связан с оплатой этапа, отдельно смотрите материал как проверить подрядчика перед оплатой этапа.
Сценарий 3. Готовить смену подрядчика
Смена подрядчика - не первый эмоциональный шаг, а управленческое решение после проверки. Менять команду без подготовки опасно: новая команда может получить тот же хаос, только без контекста старой.
Пора готовить передачу, если:
- подрядчик не показывает проверяемый результат;
- переносы сроков повторяются без нового плана;
- документация не ведётся или откладывается “на потом”;
- доступы, репозитории и окружения остаются у подрядчика;
- бизнес не понимает, за что платит;
- новый бюджет появляется без разбора старого объёма;
- подрядчик не фиксирует решения письменно;
- невозможно понять, что будет сломано при передаче.
Подготовка к смене не означает немедленный разрыв. Это означает, что бизнес начинает снижать зависимость:
- Собирает доступы.
- Проверяет актуальность кода.
- Фиксирует окружения и домены.
- Восстанавливает карту модулей и интеграций.
- Выгружает backlog и список открытых дефектов.
- Готовит вопросы текущему подрядчику.
- Даёт новой команде возможность оценить проект по фактам.
Подробнее этот сценарий разобран на странице нужно сменить подрядчика и в статье как сменить подрядчика без остановки проекта.
Что запросить у подрядчика перед решением
Перед тем как продолжать, оплачивать, усиливать контроль или менять подрядчика, стоит запросить один короткий пакет.
| Что запросить | Зачем это нужно |
|---|---|
| Список задач текущего этапа | Понять, что именно должно быть готово |
| Статус по задачам | Увидеть готово / не готово / заблокировано / риск |
| Демонстрацию результата | Проверить продукт, а не отчёт |
| Список открытых дефектов | Понять, что переносится дальше |
| Причины переноса срока | Отличить объективные причины от размытых объяснений |
| Новый план до релиза | Проверить, есть ли критический путь |
| Список изменений объёма | Отделить исходные работы от новых пожеланий |
| Документацию и доступы | Снизить зависимость от подрядчика |
| Риски следующего этапа | Не переносить проблему в новый бюджет |
Если подрядчик даёт этот пакет спокойно и предметно, проект можно обсуждать конструктивно. Если пакет собрать невозможно, это сильный сигнал в пользу внешней проверки.
Как не принять плохое решение
В проблемных проектах бизнес часто выбирает слишком резкий или слишком пассивный сценарий.
Решения, которых лучше избегать:
- оплачивать этап только потому, что “люди работали”;
- принимать “почти готово” без демо и критериев приёмки;
- соглашаться на новый срок без блокеров и критического пути;
- начинать новый объём работ, пока старый не принят;
- менять подрядчика без доступа к коду, окружениям и документации;
- спорить о виноватых до того, как собраны технические факты;
- ждать следующего переноса, если уже понятно, что контроль потерян.
Хорошее решение обычно выглядит спокойнее: сначала факты, затем сценарий, затем действие.
Когда нужен внешний эксперт
Внешний эксперт нужен не для того, чтобы “разоблачить подрядчика”. Его задача - помочь бизнесу увидеть техническую картину и принять решение без лишнего давления.
Подключение имеет смысл, если:
- внутри компании нет технической роли;
- нужно решить вопрос оплаты этапа;
- подрядчик просит новый бюджет;
- сроки сдвигаются, а причины неочевидны;
- релиз рискованный для пользователей или внутренних процессов;
- документации мало;
- возможна смена подрядчика;
- собственнику нужен независимый вывод.
Формат может быть разным: короткая проверка этапа, технический контроль подрядчика, аудит проблемного проекта или более широкий аудит IT/digital-отдела, если проблема затрагивает не только одного исполнителя.
Практический вывод
Если подрядчик затягивает разработку, главный вопрос не “верить или не верить”. Главный вопрос - можно ли управлять проектом по фактам.
Если факты есть, проект можно продолжать с новым планом. Если фактов мало, нужен технический контроль. Если фактов нет, а зависимость от подрядчика растёт, нужно готовить передачу.
Начать можно со страницы подрядчик затягивает разработку и чек-листа контроля подрядчика. Если решение уже упирается в оплату, используйте отдельный порядок: как проверить подрядчика перед оплатой этапа.
Материалы по теме
| Материал | Когда смотреть |
|---|---|
| Как понять, что подрядчик не справляется с разработкой | Если нужно отделить нормальную сложность проекта от признаков потери управляемости |
| Подрядчик затягивает разработку | Если нужно быстро разобрать текущую ситуацию и понять, какие факты запросить |
| Подрядчик не справляется | Если нужно понять, проблема в команде, постановке, архитектуре или управлении |
| Технический контроль подрядчика | Если нужно проверить статус, сроки, релиз, документацию и риски |
| Как проверить подрядчика перед оплатой этапа | Если подрядчик просит оплатить этап после задержки |
| Если подрядчик не даёт прозрачности | Если ответы по статусам, срокам и релизам остаются общими |
| Как контролировать сроки разработки | Если нужно выстроить регулярный контроль сроков без микроменеджмента |
| Нужно сменить подрядчика | Если нужно готовить безопасную передачу проекта |
| Чек-лист контроля подрядчика | Если нужен список вопросов для первичной самопроверки |
