Контроль подрядчика

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

Чек-лист помогает подготовить разговор с подрядчиком по фактам: что реально готово, почему сдвигаются сроки, какие риски есть у релиза, какие документы и доступы должна показать команда.

Кому подходит

Когда использовать этот материал

Чек-лист помогает быстро собрать признаки и подготовить разговор с командой, подрядчиком или внешним экспертом.

  • нет внутреннего CTO, но нужно контролировать сложную разработку
  • подрядчик говорит “почти готово”, но не показывает проверяемый результат
  • подрядчик переносит сроки и объясняет причины слишком общо
  • нужно проверить готовность релиза перед оплатой или запуском
  • проект готовится к передаче или смене команды

Карта контроля

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

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

Сроки

Критический путь

Какие задачи блокируют релиз и почему изменилась оценка.

  • блокеры
  • зависимости
  • демонстрация результата
Архитектура

Риск решений

Какие модули ограничивают развитие и где уже накоплен долг.

  • карта модулей
  • интеграции
  • сложные зоны
Релиз

Критерии готовности

Что входит в релиз, как проверяется качество и есть ли план отката.

  • тесты
  • ошибки
  • приёмка
Документы

Передача знаний

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

  • бизнес-логика
  • доступы
  • деплой
Итог Результат: собственник получает понятные вопросы и видит, где нужен внешний технический контроль.

Чек-лист

Что проверить

Сроки и статус

Сроки нужно обсуждать через задачи, зависимости и блокеры, а не через общее ощущение готовности.

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

Если подрядчик не даёт прозрачности

Когда статусы остаются общими, нужно переводить разговор в конкретные артефакты, а не спорить о доверии.

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

Архитектура и технический долг

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

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

Релизы и качество

Релиз должен иметь критерии готовности и проверку бизнес-сценариев.

  • какие функции войдут в релиз
  • какие сценарии нужно проверить перед запуском
  • какие ошибки команда предлагает перенести
  • есть ли план отката
  • кто принимает результат со стороны бизнеса

Документация

Документация нужна не как отчёт, а как инструмент управления и передачи проекта.

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

Доступы и передача

Если доступы и владельцы сервисов не понятны, проект становится зависимым от отдельных людей.

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

Риски следующего месяца

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

  • какие решения могут увеличить бюджет
  • какие задачи нельзя оценить без исследования
  • какие ошибки могут повториться после релиза
  • какие внешние зависимости могут сорвать срок
  • какой вопрос нужно решить на уровне бизнеса

Ограничение

Что важно понимать

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

Связанные материалы

Куда перейти дальше

Внешний CTO

Независимая техническая роль между бизнесом и командой разработки.

Заявка

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

PDF-версию можно открыть на странице. Оставьте контакт и кратко опишите проект, если нужно понять, какие вопросы задать подрядчику перед оплатой этапа, релизом или передачей проекта.

Дмитрий Зугаев
Дмитрий Зугаев web/AI-архитектор, CTO
Заявка уйдёт на email Дмитрия.