Чек-лист проблемного web-проекта
Диагностический чек-лист: подрядчик затягивает разработку, проект трудно передать, портал ломается после релизов и нет документации.
Открыть чек-листПодрядчик
Подрядчик не справляется с разработкой: как проверить без конфликта
Когда кажется, что подрядчик не справляется, важно не начинать с обвинений. Сначала нужно проверить факты: что реально готово, где это можно посмотреть, какие дефекты открыты, что мешает релизу, хватает ли документации и можно ли управлять проектом дальше.
Ситуация
Что обычно происходит
Бизнес видит, что разработка идёт медленно, статусы меняются, релиз откладывается, а результат сложно принять. Подрядчик может говорить, что команда работает, но собственник не видит понятной картины: что сделано, что не сделано и почему проект застрял.
В такой ситуации опасно сразу решать, что подрядчик плохой. Иногда причина в подрядчике, иногда - в постановке задач, архитектуре, интеграциях, старом коде, незафиксированных решениях или отсутствии технического контроля на стороне бизнеса.
Признаки проблемы
- подрядчик говорит, что работы идут, но не показывает проверяемый результат
- статусы звучат общо: «в работе», «почти готово», «остались мелочи»
- демо нет или оно не показывает ключевые бизнес-сценарии
- дефекты возвращаются, а причины не фиксируются
- сроки и оценки меняются без критического пути и списка блокеров
- документация, доступы и решения остаются у подрядчика
- бизнес не понимает, продолжать работу, усиливать контроль или готовить смену команды
Чек-лист
Материал для самостоятельной проверки
Чек-лист контроля подрядчика
Набор вопросов для собственника и руководителя проекта: как проверить подрядчика по статусам, срокам, релизам, документации, доступам и рискам.
Открыть чек-листПричины
Почему это может происходить
подрядчик действительно не вытягивает проект: не хватает экспертизы, процессов или ресурсов
требования и критерии готовности не были зафиксированы до разработки
проект сложнее, чем казался: есть старый код, интеграции, данные, роли и скрытые зависимости
нет прозрачного статуса по задачам, дефектам, релизам и блокерам
бизнес принимает решения без технической позиции на своей стороне
подрядчик стал единственным источником правды по коду, доступам, документации и архитектуре
Диагностика
Симптом, проверка и рабочий артефакт
| Симптом | Что проверить | Что получить |
|---|---|---|
| Подрядчик говорит, что работа идёт | Демо, тестовый доступ, список завершённых задач, критерии готовности | Проверяемый статус результата |
| Статусы размыты и меняются | Backlog, статусы задач, блокеры, критический путь, решения со стороны бизнеса | Письменный статус проекта |
| Результат нельзя принять | Дефекты, критерии приёмки, сценарии пользователей, готовность релиза | Список исправлений до приёмки |
| Подрядчик объясняет всё технической сложностью | Архитектура, интеграции, данные, технический долг, решения и ограничения | Карта технических причин |
| Есть мысль менять подрядчика | Код, доступы, окружения, документация, открытые задачи, риски передачи | Решение: продолжать, контролировать, остановить этап или готовить передачу |
Карта контроля
Что проверять у подрядчика
Контроль подрядчика строится не на конфликте, а на регулярных артефактах: сроках, архитектуре, релизах, документации и рисках.
Сроки
Критический путь
Какие задачи блокируют релиз и почему изменилась оценка.
- блокеры
- зависимости
- демонстрация результата
Архитектура
Риск решений
Какие модули ограничивают развитие и где уже накоплен долг.
- карта модулей
- интеграции
- сложные зоны
Релиз
Критерии готовности
Что входит в релиз, как проверяется качество и есть ли план отката.
- тесты
- ошибки
- приёмка
Документы
Передача знаний
Можно ли подключить новую команду без повторного расследования.
- бизнес-логика
- доступы
- деплой
Итог Результат: собственник получает понятные вопросы и видит, где нужен внешний технический контроль.
Первые шаги
Порядок действий без хаоса
Независимый контроль нужен, если бизнесу нужно принять решение об оплате, сроке, релизе или смене подрядчика, но внутри компании нет технической роли, которая может проверить ответы подрядчика по фактам.
Отделить ощущение от фактов
Зафиксировать, что именно вызывает тревогу: нет результата, нет демо, сдвигаются сроки, растёт бюджет, дефекты повторяются или подрядчик не передаёт контекст.
Запросить проверяемый статус
Попросить подрядчика дать список задач, демо, блокеры, дефекты, риски, критический путь и решения, которые нужны от бизнеса.
Проверить технические причины
Понять, проблема в команде подрядчика, постановке, архитектуре, интеграциях, данных, релизном процессе или отсутствии контроля со стороны бизнеса.
Выбрать сценарий
Если факты есть - продолжать с контрольными точками. Если фактов мало - подключить технический контроль. Если фактов нет и зависимость растёт - готовить передачу проекта.
Что не делать
Решения, которые лучше не принимать вслепую
- не обвинять подрядчика до проверки статуса, демо, дефектов и блокеров
- не оплачивать спорный этап только по устному отчёту
- не запускать новые крупные доработки поверх незакрытых проблем
- не менять команду без кода, доступов, окружений и карты проекта
- не принимать технические объяснения без артефактов, которые можно проверить
- не сводить всё к конфликту, если сначала нужна диагностика управляемости
Следующий шаг
Что сделать с этой ситуацией
Выберите ближайший маршрут: собрать факты, проверить подрядчика, подготовить AI-ready основу или спроектировать систему заново.
Проверить подрядчика без конфликта
Если ответы по срокам, рискам и релизам стали размытыми, нужен контроль по артефактам, а не микроменеджмент.
- статус и блокеры
- архитектура и релизы
- документация и передача
Начать с диагностики проблемного проекта
Если сроки, бюджет или стабильность перестали быть предсказуемыми, сначала нужно собрать факты и карту рисков.
- технический тупик
- срывы сроков
- нестабильные релизы
Понять, готов ли проект к AI
Если хочется AI-ассистента, RAG или автоматизацию, сначала стоит проверить данные, роли, документы и критерии качества.
- источники данных
- права доступа
- метрики качества
Связанные материалы
Куда перейти дальше
Как понять, что подрядчик не справляется
Подробная диагностика признаков, вопросов подрядчику и проверки до конфликта.
Подрядчик затягивает разработку
Как выбрать между продолжением работы, техническим контролем и подготовкой смены подрядчика.
Технический контроль подрядчика
Если подрядчик продолжает работу, но бизнесу нужна прозрачность по срокам, рискам и решениям.
Подрядчик не даёт прозрачности
Порядок действий, если статусы, сроки, релизы и документация остаются непроверяемыми.
Проверка перед оплатой этапа
Что проверить, если подрядчик просит оплатить этап, но результат, дефекты и риски неясны.
Аудит проблемного проекта
Если проект уже потерял управляемость и нужно понять причину, а не спорить о симптомах.
Чек-лист контроля подрядчика
Вопросы для первичной проверки статуса, сроков, релиза, документации и рисков.
Кейс смены подрядчика
Обезличенный сценарий, где сначала готовили техническую картину, а потом принимали решение.
Как контролировать подрядчика
Статья с вопросами, которые помогают собственнику вести разработку без микроменеджмента.
FAQ
Частые вопросы
Как понять, что подрядчик действительно не справляется?
Проверить, может ли подрядчик показать результат, статус задач, дефекты, блокеры, причины задержек, документацию и план до релиза. Если вместо фактов остаются общие формулировки, проект теряет управляемость.
Стоит ли сразу менять подрядчика?
Не всегда. Сначала нужно понять, проблема в команде, архитектуре, требованиях, коммуникации или управлении со стороны бизнеса. Смена без подготовки часто переносит старый хаос новой команде.
Как проверить подрядчика без конфликта?
Говорить не через обвинения, а через артефакты: демо, backlog, критерии готовности, список дефектов, блокеры, релизный план, доступы и документацию. Это переводит разговор из эмоций в факты.
Какие документы и материалы запросить?
Backlog, статус задач, критерии готовности, список дефектов, карту интеграций, список доступов, описание окружений, актуальные требования, релизный план и список технических рисков.
Когда нужен технический контроль подрядчика?
Когда подрядчик продолжает работу, но бизнес не может проверить готовность, сроки, качество, архитектуру, документацию или риски без независимой технической позиции.
Заявка
Проверить подрядчика по фактам
Опишите проект, подрядчика, сроки, что уже показано в демо и какое решение нужно принять: продолжать, оплачивать этап, усиливать контроль или готовить передачу.
Дмитрий Зугаев web/AI-архитектор, CTO