Как сменить подрядчика по разработке в середине проекта
Практика3 минРедакция Innovialabs
Коротко
Сначала заберите все доступы и код под свой контроль, затем закажите независимый аудит, и только после этого передавайте проект новой команде — с периодом параллельной работы и планом на случай сбоя.
Короткий ответ
Сменить подрядчика посреди проекта можно без остановки продукта, если соблюдать порядок: контроль над активами → аудит → передача → параллельная работа → полный переход. Главная ошибка — объявить о расторжении раньше, чем у вас на руках оказались доступы, исходный код и документация.
Шаг 1. Заберите доступы и код
До любых резких разговоров проверьте, что всё критичное принадлежит вам, а не подрядчику:
- Репозиторий (GitHub, GitLab и т.п.) — владелец организации должен быть вашим аккаунтом.
- Хостинг и облако — аккаунт оформлен на компанию, платёжный метод ваш.
- Домен и DNS — регистратор, доступ к панели управления.
- Базы данных и бэкапы — актуальная копия у вас.
- Сторонние сервисы: платёжные системы, почтовые рассылки, SMS, аналитика, магазины приложений, API-ключи.
- Дизайн-макеты и документация.
Составьте таблицу: сервис, кто владелец, у кого есть доступ, когда проверено. Пароли храните в менеджере паролей компании. После передачи смените все ключи и пароли, к которым имел доступ прежний подрядчик.
Шаг 2. Проведите независимый аудит
Прежде чем новая команда начнёт писать код, ей нужно понять, что она получает. Аудит отвечает на вопросы:
- Собирается и запускается ли проект по инструкции «с нуля»?
- Совпадает ли код в репозитории с тем, что работает на сервере?
- Есть ли тесты, CI/CD, описание архитектуры?
- Какие уязвимости и устаревшие зависимости есть в проекте?
- Какие задачи реально сделаны, а какие только отмечены как готовые?
Итог аудита — честная картина: что можно оставить, что нужно переписать и сколько ещё осталось работы.
Шаг 3. Организуйте передачу знаний
Даже при плохих отношениях попробуйте договориться о периоде передачи: несколько встреч, на которых прежняя команда показывает развёртывание, архитектуру и известные проблемы. Это стоит закрепить в договоре или допсоглашении.
Минимальный пакет передачи:
| Что | Зачем |
|---|---|
| Инструкция по развёртыванию | Новая команда сможет запустить проект |
| Схема архитектуры и интеграций | Понятно, что с чем связано |
| Список известных багов и долгов | Не придётся находить их заново |
| Переменные окружения (без секретов в чатах) | Проект заработает на новом сервере |
Шаг 4. Избегайте простоя
- Не меняйте инфраструктуру и команду одновременно. Сначала новая команда работает на текущем сервере, переезд — отдельный этап.
- Заморозьте крупные релизы на время передачи; выпускайте только исправления.
- Подготовьте план отката: актуальный бэкап и возможность вернуть предыдущую версию.
- Дайте новой команде стартовые задачи небольшого размера — так они разберутся в коде без риска.
Частые ошибки
- Расторгнуть договор до получения доступов.
- Ждать, что новая команда сразу продолжит в прежнем темпе.
- Не проверить права на код: в договоре должна быть передача исключительных прав.
- Оставить старые доступы активными «на всякий случай».