Короткий ответ
Смена подрядчика не должна начинаться с поиска новой команды. Сначала нужно понять, что именно передаётся: код, инфраструктура, база данных, интеграции, документация, текущие задачи, известные проблемы и бизнес-логика.
Если этого не сделать, новый подрядчик получает не проект, а набор неизвестных рисков. Тогда он либо закладывает большой запас в оценку, либо начинает работу с ошибок, которые можно было увидеть заранее.
Безопасная смена подрядчика строится в три этапа: техническая инвентаризация, управляемая передача, затем план первых изменений.
Когда смена подрядчика действительно нужна
Подрядчика стоит менять не из-за одного сорванного срока или неудобной коммуникации. Сначала нужно отделить управленческую проблему от технической.
Смена может быть оправдана, если:
- подрядчик не может объяснить состояние проекта;
- сроки регулярно сдвигаются без понятной причины;
- нет актуальной документации и карты архитектуры;
- релизы создают новые ошибки;
- команда не фиксирует риски и технический долг;
- бизнес не понимает, какие работы реально выполнены;
- подрядчик не готов к прозрачной передаче проекта.
Если проблема только в коммуникации, иногда достаточно технического контроля подрядчика. Если же проект уже потерял управляемость, лучше начинать с аудита проблемного проекта.
Что нужно зафиксировать до передачи
Перед сменой команды важно собрать минимальную техническую картину. Она не обязана быть идеальной, но должна отвечать на базовые вопросы новой команды.
Код и репозиторий. Где находится актуальная версия, какие ветки используются, как устроены релизы, есть ли незакоммиченные изменения.
Инфраструктура. Где размещён проект, какие окружения есть, как устроены домены, SSL, резервные копии, cron-задачи, очереди, фоновые процессы.
База данных. Какие таблицы критичны, где источник истины, как выполняются миграции, импорты, выгрузки и синхронизации.
Интеграции. CRM, 1C, ERP, платёжные системы, почтовые сервисы, внешние API, аналитика, личные кабинеты партнёров.
Бизнес-логика. Роли пользователей, статусы, права, исключения, ручные операции, сценарии поддержки.
Текущие задачи. Что в работе, что обещано бизнесу, что не принято, где есть спорные места.
Если документации почти нет, это не повод останавливать передачу. Но тогда сначала нужно восстановить хотя бы карту проекта. Подробнее об этом есть в статье документация перед сменой подрядчика.
Какие вопросы задать текущему подрядчику
Запрос лучше формулировать не как конфликт, а как подготовку к передаче. Цель - получить факты, а не доказать чью-то ошибку.
Полезно спросить:
- какая версия проекта сейчас считается актуальной;
- есть ли незавершённые ветки или локальные изменения;
- какие зоны проекта команда считает рискованными;
- какие задачи нельзя делать без предварительной подготовки;
- какие интеграции чаще всего создают проблемы;
- где лежит инструкция по деплою и откату релиза;
- какие доступы ещё не переданы бизнесу;
- какие ошибки известны, но не исправлены;
- какие решения были временными и требуют пересмотра.
Если ответы расплывчатые, это сигнал к независимой диагностике. Важно не спорить о формулировках, а собрать технические факты.
Как выбрать новую команду
Новая команда должна оценивать не только список задач, но и состояние проекта. Если подрядчик готов назвать цену без изучения кода, интеграций и рисков, это тоже риск.
Перед выбором команды стоит передать ей:
- краткое описание бизнес-целей;
- карту модулей и интеграций;
- список известных проблем;
- текущий backlog;
- ограничения по срокам и критичным релизам;
- список доступов, которые уже есть;
- ожидания по документации и коммуникации.
Хороший подрядчик после этого задаст уточняющие вопросы. Если вопросов нет, вероятно, сложность проекта ещё не понята.
Для бизнеса полезно подключить независимую техническую роль: внешнего CTO или экспертный контроль на этапе выбора подрядчика.
Чего не стоит делать
Самая частая ошибка - объявить смену подрядчика и сразу поставить новой команде задачу “просто продолжить”. В сложном web-проекте так почти не работает.
Не стоит:
- менять доступы без резервной копии и фиксации текущего состояния;
- удалять старую команду из контуров до завершения передачи;
- требовать от новой команды точную оценку без аудита;
- начинать крупные доработки до технической инвентаризации;
- переносить конфликт в техническую плоскость;
- считать отсутствие документации виной только одной стороны.
Смена подрядчика - управленческое решение. Но его последствия технические: доступы, релизы, данные, интеграции, поддержка, риски.
Минимальный план перехода
- Зафиксировать причины смены и бизнес-цели.
- Собрать доступы, репозитории, инфраструктуру и список сервисов.
- Запросить у текущего подрядчика карту рисков и незавершённых работ.
- Провести технический аудит или экспресс-диагностику.
- Составить карту проекта: модули, интеграции, данные, релизы.
- Выбрать новую команду по вопросам и подходу, а не только по цене.
- Передать проект по этапам: сначала доступы и документация, потом критичные зоны, затем backlog.
- Первые изменения делать малыми релизами с понятной приёмкой.
Если проект уже нестабилен, безопаснее использовать подход восстановления web/AI-проекта: сначала стабилизация, потом развитие.
Практический вывод
Смена подрядчика без подготовки почти всегда дороже, чем кажется. Но если сначала собрать факты, восстановить карту проекта и зафиксировать риски, переход можно сделать без остановки разработки и без потери управляемости.
Для самопроверки полезен чек-лист контроля подрядчика и страница проблемы нужно сменить подрядчика.
