Подрядчик не справляется: как понять

Короткий ответ

Понять, что подрядчик не справляется с разработкой, можно не по раздражению в переписке и не по одному сорванному сроку. Важнее проверить, может ли подрядчик показать управляемую картину проекта: что готово, что не готово, что заблокировано, где посмотреть результат, какие дефекты открыты и что мешает релизу.

Если вместо фактов вы слышите только “почти готово”, “остались мелочи”, “команда работает”, “сложная интеграция” и “ещё немного времени”, ситуация требует проверки. Это ещё не значит, что подрядчика нужно срочно менять. Но это значит, что бизнес не должен принимать решения вслепую: оплачивать этап, соглашаться на новый срок, запускать релиз или расширять бюджет без независимой картины.

Рабочий порядок такой:

• отделить реальные красные флаги от нормальной сложности проекта;
• запросить у подрядчика проверяемые артефакты;
• понять, где причина: команда, постановка задач, архитектура, коммуникация, интеграции или отсутствие контроля;
• выбрать сценарий: продолжать с контрольными точками, подключить технический контроль подрядчика или готовить передачу проекта.

Почему одного ощущения недостаточно

В web/digital-проектах легко попасть в эмоциональную ловушку. Собственник видит, что релиза нет, задачи двигаются медленно, подрядчик отвечает общими словами, а внутри компании растёт тревога. Из этого быстро рождается вывод: “подрядчик не справляется”.

Иногда это правда. Но иногда проект действительно сложнее, чем выглядел в начале: старый код, неочевидные роли пользователей, нестабильная интеграция с 1С или CRM, изменившиеся требования, неготовые данные, незафиксированные решения. В таких случаях подрядчик может ошибиться в оценке, но ситуацию ещё можно вернуть в управляемость.

Поэтому первый вопрос не “кто виноват”, а “можно ли сейчас проверить состояние проекта по фактам”.

Если можно, проблему можно разбирать спокойно. Если нельзя, риск уже серьёзный: бизнес не управляет разработкой, а зависит от объяснений подрядчика.

Семь признаков, что подрядчик может не справляться

1. Нет демо, которое можно проверить

Отчёт о проделанной работе не заменяет демонстрацию результата. Если подрядчик говорит, что функциональность готова, но её нельзя посмотреть в тестовом контуре, пройти пользовательский сценарий или сравнить с критериями приёмки, готовность остаётся неподтверждённой.

Нормальная ситуация: демо есть, но показывает не всё, потому что часть функций зависит от интеграции или данных.

Плохой признак: демо регулярно переносится, показываются отдельные экраны без рабочего сценария, а вопрос “где это можно проверить” остаётся без ответа.

2. Статусы задач не дают управленческой картины

Формулировки “в работе”, “почти готово”, “на финальной стадии” и “остались мелочи” не помогают принять решение. Они не показывают, что готово, что заблокировано, где риск и что требуется от бизнеса.

Хороший статус должен отвечать хотя бы на пять вопросов:

• что завершено;
• что не завершено;
• что заблокировано;
• какой риск влияет на срок;
• какое решение нужно от бизнеса или подрядчика.

Если такого статуса нет, проблема может быть не только в разработке, но и в управлении проектом.

3. Сроки двигаются без критического пути

Сложные проекты иногда требуют пересмотра сроков. Это не всегда плохо. Плохо, когда новый срок называется без причин, зависимостей и списка задач, которые реально ведут к релизу.

Перед тем как соглашаться на новый срок, стоит запросить:

• что именно не успели сделать;
• почему это не было видно раньше;
• какие задачи блокируют релиз;
• что входит в новый срок;
• что может снова сдвинуть дату;
• какие решения нужны от вашей стороны.

Если подрядчик не может объяснить критический путь, новый срок становится просто новой надеждой.

4. Дефекты возвращаются, но причины не фиксируются

Повторяющиеся ошибки сами по себе не доказывают слабость подрядчика. Но если одни и те же проблемы возвращаются после исправлений, а причины не анализируются, проект будет терять время на повторную ручную проверку.

Важно увидеть не только список багов, но и логику работы с ними:

• дефект принят или отклонён;
• к какой задаче он относится;
• почему возник;
• что сделано, чтобы не повторился;
• как проверяется исправление;
• влияет ли дефект на релиз.

Если дефекты живут только в чате, качество становится неуправляемым.

5. Решения не фиксируются

Частая причина хаоса - решения принимаются на встречах и в переписках, но не попадают в требования, backlog, документацию или критерии приёмки. Через несколько недель участники помнят ситуацию по-разному.

Это опасно не только для текущего подрядчика. Если проект придётся передавать, новая команда будет восстанавливать логику по обрывкам переписки.

Минимум, который стоит фиксировать:

• изменения в составе этапа;
• бизнес-правила;
• ограничения интеграций;
• решения по ролям и правам;
• спорные допущения;
• договорённости о переносах и приёмке.

6. Документация и доступы остаются у подрядчика

Если подрядчик является единственным носителем знаний о проекте, бизнес зависим. Даже если отношения сейчас нормальные, любая смена команды, отпуск ключевого разработчика или конфликт по оплате превращаются в риск.

Проверьте, есть ли у вас:

• доступ к репозиторию;
• доступ к хостингу, доменам, окружениям и внешним сервисам;
• список интеграций и владельцев доступов;
• описание деплоя;
• актуальный backlog;
• краткое описание архитектуры и бизнес-логики;
• список открытых технических рисков.

Если этого нет, подрядчик может работать, но проект уже нельзя безопасно контролировать.

7. Каждый следующий шаг требует новой оплаты, но старый результат не принят

Оплата нового этапа до проверки предыдущего - один из частых способов углубить проблему. Подрядчик может честно считать, что работа выполнена, но бизнес должен проверить это не по словам, а по артефактам.

Перед оплатой стоит отдельно посмотреть материал как проверить подрядчика перед оплатой этапа. Общий принцип простой: сначала демо, критерии приёмки, дефекты, документация и риски, потом решение об оплате или продолжении.

Что может быть нормальной сложностью, а не провалом подрядчика

Не каждый неприятный симптом означает, что подрядчик слабый. В реальных проектах бывают объективные причины:

Разница между нормальной сложностью и слабым управлением в прозрачности. Если подрядчик показывает факты, риски и варианты действий, с ним можно работать. Если сложность используется как универсальное объяснение без артефактов, проект нужно проверять глубже.

Вопросы подрядчику до конфликта

Разговор лучше строить не как претензию, а как запрос управленческой картины. Ниже вопросы, которые помогают быстро понять состояние проекта.

По результату

• Что конкретно готово на текущий момент?
• Где это можно посмотреть?
• Какие пользовательские сценарии уже проходят полностью?
• Какие сценарии пока не работают?
• Что входит в ближайшее демо или релиз?

По срокам

• Почему изменился срок?
• Какие задачи лежат на критическом пути?
• Какие блокеры мешают завершить этап?
• Что может снова сдвинуть дату?
• Какой план до релиза по неделям или контрольным точкам?

По качеству

• Какие дефекты сейчас открыты?
• Какие дефекты критичны для запуска?
• Как проверяется исправление?
• Есть ли регресс после доработок?
• Кто принимает результат со стороны бизнеса?

По документации и передаче

• Где хранится актуальный backlog?
• Где зафиксированы бизнес-правила и решения?
• Есть ли описание окружений и деплоя?
• Кто владеет доступами?
• Можно ли передать проект другой команде без расследования?

По дальнейшему сценарию

• Что вы предлагаете: продолжить, изменить scope, перенести срок, выделить отдельный релиз или остановить спорный этап?
• Что будет результатом следующей недели?
• Как мы поймём, что ситуация улучшилась?
• Какие риски вы считаете самыми серьёзными?
• Что вам нужно от бизнеса для завершения этапа?

Если подрядчик отвечает предметно, это хороший сигнал. Если ответы снова остаются общими, нужна внешняя проверка.

Что проверить до конфликта

Перед тем как жёстко спорить, прекращать работы или менять подрядчика, стоит собрать минимальный пакет фактов. Он пригодится в любом сценарии.

Эта проверка часто показывает, что проблема не в одном человеке и не в одном сроке. Иногда нужно не менять подрядчика, а вернуть проекту управляемость.

Как выбрать следующий шаг

Продолжать с текущим подрядчиком

Этот сценарий подходит, если подрядчик показывает результат, признаёт риски, фиксирует решения и готов работать по контрольным точкам.

Что важно закрепить:

• новый план до ближайшего релиза;
• критерии готовности;
• регулярный статус по задачам, дефектам и блокерам;
• список решений со стороны бизнеса;
• формат демонстраций;
• условия приёмки этапа.

Подключить технический контроль

Этот сценарий подходит, если результат частично есть, но бизнес не может сам проверить качество, архитектуру, риски и готовность к оплате или релизу.

Технический контроль помогает перевести разговор из “доверяем или не доверяем” в управляемую картину:

• что готово по фактам;
• что не готово;
• где технический риск;
• какие вопросы задать подрядчику;
• можно ли принимать этап;
• что нужно исправить до следующего шага.

Для этого есть отдельная услуга технический контроль подрядчика и практический чек-лист контроля подрядчика.

Готовить передачу проекта

Этот сценарий нужен, если подрядчик не показывает проверяемый результат, не передаёт доступы, не фиксирует решения, переносит сроки без плана и каждый следующий шаг увеличивает зависимость бизнеса.

Передача не должна начинаться с резкой смены команды. Сначала нужно собрать код, доступы, окружения, документацию, открытые задачи, карту интеграций и список рисков. Иначе новая команда начнёт не с разработки, а с восстановления контекста.

Подробный маршрут есть на странице нужно сменить подрядчика и в статье как сменить подрядчика без остановки проекта.

Ошибки, которые ухудшают ситуацию

• Платить за этап только потому, что “почти всё готово”.
• Соглашаться на новый срок без критического пути и списка блокеров.
• Начинать конфликт до того, как собраны факты.
• Менять подрядчика без доступа к коду, окружениям и документации.
• Запускать новый scope поверх незакрытых дефектов.
• Оценивать подрядчика только по активности, а не по готовому результату.
• Держать все решения в чатах и устных договорённостях.

Минимальный запрос подрядчику

Если нужно начать спокойно, можно отправить подрядчику короткий запрос:

Чтобы принять решение по следующему этапу, нам нужна проверяемая картина проекта. Пожалуйста, пришлите список готовых задач, демо или тестовый доступ, открытые дефекты, блокеры, причины переноса срока, состав ближайшего релиза, список недостающих решений с нашей стороны, актуальные доступы и документацию, которая нужна для поддержки проекта.

Этот текст не обвиняет команду. Он переводит обсуждение в предметную плоскость. Дальше всё зависит от качества ответа.

Материалы по теме

Проверить ситуацию с подрядчиком