Короткий ответ
Если подрядчик по web/digital-разработке не даёт прозрачности, не начинайте с конфликта и не принимайте решение о смене команды на эмоциях. Сначала нужно собрать проверяемые факты: backlog, статус задач, причины переносов, критерии готовности, риски релиза, документацию, доступы и технические решения.
Непрозрачность сама по себе ещё не доказывает, что подрядчик работает плохо. Иногда команда действительно столкнулась со сложной архитектурой, неясными требованиями или зависимостями от бизнеса. Но если подрядчик не может объяснить ситуацию конкретно, проект становится неуправляемым для собственника или CEO.
Задача первого шага - получить картину:
- что реально готово;
- что находится в работе;
- что заблокировано;
- почему сдвигаются сроки;
- какие риски влияют на ближайший релиз;
- каких документов и доступов не хватает;
- какой формат нужен дальше: контрольная встреча, технический контроль подрядчика, аудит IT/digital-отдела или подготовка к смене подрядчика.
Почему непрозрачность не всегда означает плохого подрядчика
В сложных web-проектах прозрачность может теряться по разным причинам. Подрядчик может быть слабым, но причина может быть и в другой части системы: требования меняются, бизнес не фиксирует решения, архитектура уже перегружена, интеграции работают нестабильно, а документация не велась годами.
Поэтому опасно сразу делать вывод “подрядчик не справляется”. Более полезный вопрос: можно ли по текущим данным управлять проектом?
Если подрядчик даёт факты, показывает риски и объясняет последствия решений, ситуацию можно выправить рабочим контролем. Если ответы остаются общими, бизнес фактически принимает решения вслепую: оплачивает этапы, согласует переносы, запускает релизы и меняет приоритеты без понимания реального состояния проекта.
Признаки, что прозрачности не хватает
| Признак | Что это может означать | Что запросить |
|---|---|---|
| “Почти готово” повторяется несколько недель | Нет критериев готовности или результата, который можно принять | Список готовых задач, демонстрацию и критерии приёмки |
| Сроки переносятся без причин | Не видны зависимости, блокеры и критический путь | Причины переноса, новый план и риски следующего срока |
| Отчёт показывает только активность | Команда много делает, но бизнес не видит готовность | Статус: готово / не готово / заблокировано / риск |
| Нет понятного релиза | Неясно, что именно будет поставлено и как это проверять | Состав релиза, тестовые сценарии, план отката |
| Документация “будет позже” | Проект зависит от памяти подрядчика | Список недостающих документов и срок передачи |
| Технические решения объясняются общими словами | Бизнес не понимает последствия для бюджета и развития | Варианты решений, плюсы, риски и ограничения |
| Доступы и репозитории не передаются | Передача проекта будет дорогой и рискованной | Реестр доступов, владельцев сервисов и окружений |
Если совпадает один признак, можно начать с письменных вопросов. Если признаков несколько, лучше рассматривать независимую проверку.
Что сделать в первые 1-2 дня
Не нужно сразу устраивать большой аудит. В первые дни достаточно собрать основу, которая покажет, насколько ситуация управляемая.
- Составьте список обещанных сроков, этапов и переносов.
- Соберите последние отчёты, переписки, протоколы встреч и демо.
- Зафиксируйте, какое решение нужно принять: оплатить этап, продолжать работы, менять срок, запускать релиз, подключать контроль или готовить передачу.
- Разделите эмоции и факты: что точно известно, что утверждает подрядчик, что пока нельзя проверить.
- Отправьте подрядчику письменный запрос по статусу, рискам, релизу и документации.
Письменный формат важен не для давления. Он снижает потери смысла: подрядчик видит конкретные вопросы, а бизнес получает ответы, которые можно сравнить с задачами и договорённостями.
Порядок действий
1. Собрать текущий backlog
Первый вопрос - где находится единый список работ. Если задачи живут в чатах, таблицах, письмах и устных договорённостях, прозрачность уже снижена.
Попросите подрядчика показать:
- список задач в работе;
- список готовых задач;
- задачи на критическом пути;
- задачи, которые ждут решения бизнеса;
- задачи, которые влияют на ближайший релиз;
- задачи, по которым изменилась оценка.
Backlog нужен не для контроля каждого разработчика. Он показывает, чем реально занята команда и какие задачи ведут к бизнес-результату.
2. Запросить статус в проверяемом формате
Статус “работаем” не помогает принимать решения. Нужен формат, где по каждой важной задаче понятно:
- что сделано;
- что не сделано;
- почему не сделано;
- что мешает;
- кто должен снять блокер;
- какой риск появляется;
- какой следующий шаг.
Если подрядчик не может дать такой статус, проблема может быть не только в коммуникации. Возможно, внутри команды тоже нет управляемой картины.
3. Зафиксировать причины переносов
Сроки в разработке могут меняться. Вопрос не в том, чтобы запретить переносы, а в том, чтобы понять их причину.
По каждому переносу нужно увидеть:
- что именно сдвинулось;
- какая причина;
- когда причина стала известна;
- можно ли было обнаружить её раньше;
- кто влияет на решение;
- какие варианты есть сейчас;
- что будет, если ничего не менять.
Если причины каждый раз звучат по-разному и не фиксируются письменно, руководитель не может отличить объективную сложность от слабого управления.
4. Проверить ближайший релиз
Если подрядчик не даёт прозрачности, ближайший релиз становится зоной риска. Нужно понять не только дату, но и состав поставки.
Запросите:
- что входит в релиз;
- какие сценарии будут проверены;
- какие ошибки известны заранее;
- какие ошибки предлагают перенести;
- кто принимает результат со стороны бизнеса;
- есть ли тестовый контур;
- есть ли план отката.
Если релиз нельзя описать коротким списком, принимать его будет сложно. Если нет плана проверки, бизнес может получить новые проблемы вместо готового результата.
5. Запросить документацию и доступы
Документация и доступы нужны не “на случай конфликта”. Они нужны, чтобы проект не зависел от памяти конкретных людей.
Минимум для проверки:
- репозиторий и актуальная ветка;
- окружения и инструкция запуска;
- домен, хостинг, серверы, внешние сервисы;
- интеграции с CRM, 1C, API, платёжными и почтовыми сервисами;
- карта ключевых модулей;
- роли пользователей и основные сценарии;
- список известных технических рисков.
Если подрядчик откладывает передачу этих материалов, это не повод для немедленного разрыва. Но это риск, который нужно явно учитывать.
6. Отделить сложность проекта от слабого управления
Не всякая задержка означает плохую работу. В B2B-портале, личном кабинете, CRM, e-commerce, интеграциях или AI-функциях могут быть объективно сложные зоны.
Нужно понять, что именно происходит:
- проект оказался сложнее, чем ожидали;
- требования изменились;
- старая архитектура мешает развитию;
- не хватает данных или решений от бизнеса;
- команда подрядчика не справляется;
- нет человека, который связывает бизнес и технические решения;
- подрядчик не показывает риски, хотя видит их внутри.
Этот разбор помогает выбрать следующий шаг без лишнего конфликта.
7. Задать подрядчику письменные вопросы
Письменные вопросы должны быть конкретными. Например:
- Какие задачи реально готовы и где их можно проверить?
- Какие задачи заблокированы и кем?
- Почему изменился последний срок?
- Какие риски есть у ближайшего релиза?
- Какие технические решения уже приняты и как они повлияют на развитие?
- Какие документы актуальны, а каких не хватает?
- Какие доступы находятся у подрядчика?
- Какие части проекта будет сложно передать другой команде?
- Что нужно решить со стороны бизнеса в ближайшие 7 дней?
- Какие работы нельзя продолжать без уточнения архитектуры или требований?
По качеству ответов часто видно, есть ли управляемость внутри команды.
8. Выбрать формат контроля
После сбора фактов не всегда нужен большой аудит. Варианты могут быть разными:
| Ситуация | Подходящий формат |
|---|---|
| Подрядчик дал ясные ответы, но нужно дисциплинировать статусы | Контрольная встреча и новый формат отчёта |
| Есть сомнения по срокам, релизу, архитектуре или документации | Технический контроль подрядчика |
| Проблема затрагивает роли, backlog, несколько проектов или подрядчиков | Аудит IT/digital-отдела |
| Проект уже застрял и непонятна причина | Аудит проблемного проекта |
| Доверие снижено, но передача не подготовлена | Подготовка к смене подрядчика |
Главное - не выбирать формат до фактов. Иначе можно лечить не причину, а самый заметный симптом.
Когда достаточно контрольной встречи
Контрольной встречи достаточно, если подрядчик готов открыто показать задачи, причины переносов, риски и план релиза. Тогда проблема может быть в формате коммуникации, а не в самой команде.
На такой встрече полезно зафиксировать:
- единый формат статуса;
- список регулярных артефактов;
- критерии готовности крупных задач;
- правила переноса сроков;
- формат фиксации рисков;
- владельцев решений со стороны бизнеса и подрядчика.
Если после этого прозрачность появляется, внешний контроль может не понадобиться.
Когда нужен технический контроль подрядчика
Технический контроль нужен, если ответы подрядчика остаются общими или бизнесу нужно принять дорогое решение: оплатить этап, принять релиз, продолжать разработку, менять условия или готовить передачу.
В таком формате внешний эксперт помогает:
- проверить статусы и готовность задач;
- разобрать причины переносов;
- оценить риски релиза;
- запросить документацию;
- сформулировать вопросы подрядчику;
- отделить технические причины от управленческих;
- дать руководителю понятный вывод.
Это не замена подрядчика и не микроменеджмент команды. Это техническая позиция на стороне бизнеса.
Когда нужен аудит IT/digital-отдела
Если подрядчик - только один из симптомов, лучше смотреть шире. Аудит IT/digital-отдела нужен, когда:
- несколько подрядчиков дают разные статусы;
- внутри нет владельца технических решений;
- backlog перегружен и не имеет приоритетов;
- нет понятного roadmap;
- релизы зависят от нескольких систем;
- документация не ведётся;
- CEO регулярно принимает технические решения без фактов;
- планируются AI-функции, но данные, роли и процессы не готовы.
В такой ситуации контроль одного подрядчика может временно улучшить отчётность, но не решит причину хаоса.
Когда готовиться к смене подрядчика
Смена подрядчика становится рабочим вариантом, если после фиксации фактов видно:
- подрядчик не может показать состояние проекта;
- критичные сроки срываются без объяснимой причины;
- документация и доступы не передаются;
- технические решения создают зависимость от одной команды;
- релизы регулярно ломают соседние сценарии;
- бизнес не может принимать результат по критериям;
- доверие снижено настолько, что продолжение работ дороже подготовки передачи.
Но даже в этом случае сначала нужно подготовить проект: доступы, репозиторий, окружения, документацию, карту интеграций, открытые задачи и список рисков. Без этого новая команда начнёт с повторного расследования.
Практический вывод
Непрозрачность подрядчика - это сигнал к диагностике, а не автоматический повод для конфликта. Сильная позиция руководителя строится на фактах: задачах, сроках, рисках, релизах, документации и последствиях технических решений.
Начните с письменного запроса и минимального набора артефактов. Если подрядчик даёт конкретные ответы, можно настроить регулярный контроль. Если ответы остаются непроверяемыми, подключайте технический контроль подрядчика или более широкий аудит IT/digital-отдела.
Для первичной самопроверки используйте чек-лист контроля подрядчика. Если нужно понять, не потеряла ли управляемость вся digital-разработка, смотрите хаб IT/digital-отдела и кейс наведение порядка в digital-команде и подрядчиках.
Материалы по теме
| Материал | Когда смотреть |
|---|---|
| Как понять, что подрядчик не справляется с разработкой | Если нужно проверить признаки до конфликта, оплаты этапа или смены команды |
| Как проверить подрядчика перед оплатой этапа | Если нужно решить, оплачивать ли этап при размытом статусе и рисках |
| Подрядчик затягивает разработку: продолжать, контролировать или менять | Если нужно выбрать сценарий после переносов сроков и размытых обещаний |
| Технический контроль подрядчика | Если нужно проверить статусы, сроки, релизы, документацию и риски подрядчика |
| Как контролировать подрядчиков в digital-разработке | Если нужен широкий разбор системы контроля подрядчиков |
| Чек-лист контроля подрядчика | Если нужен список вопросов для первичной проверки |
| Как читать технический отчёт подрядчика | Если отчёты есть, но они не показывают риски и готовность |
| Аудит и настройка IT/digital-отдела | Если проблема шире одного подрядчика |
| Кейс про порядок в digital-команде и подрядчиках | Если нужен обезличенный сценарий наведения управляемости |
| Как сменить подрядчика без остановки проекта | Если после проверки нужно готовить передачу проекта |
