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