Главный риск — не в исходном коде
При смене подрядчика внимание почти всегда сосредоточено на репозитории. Но работающий продукт зависит не только от кода. Домен может быть оформлен на сотрудника подрядчика, сервер — оплачиваться с его карты, ключи внешнего API — храниться на личном аккаунте, а публикация мобильного приложения — быть доступна только прежнему разработчику.
Поэтому передачу лучше рассматривать как восстановление контура владения. Для каждого ресурса нужно ответить на четыре вопроса: кому он принадлежит, у кого есть административный доступ, как восстановить доступ и что произойдёт, если перестать платить за сервис.
Что должно быть в реестре передачи
Удобнее собирать не сообщения в чате, а единый реестр. В нём для каждого объекта указывают адрес сервиса, назначение, владельца, способ входа, уровень полученных прав, контакт для восстановления и дату проверки.
Код и выпуск новой версии
- Репозитории со всей историей изменений, ветками и актуальным кодом.
- Права владельца или администратора организации в GitHub, GitLab либо другом хранилище.
- Инструкции по локальному запуску, сборке и развёртыванию.
- CI/CD: сценарии сборки, переменные окружения, подключённые runners и права на запуск.
- Список окружений: production, staging, тестовые стенды и их назначение.
Инфраструктура и данные
- Облачные кабинеты, виртуальные серверы, контейнеры и панели управления хостингом.
- Домены, DNS-зоны, SSL-сертификаты и контакты регистранта.
- Базы данных, файловые хранилища и очереди сообщений.
- Расписание резервного копирования, место хранения копий и инструкция восстановления.
- Мониторинг, журналы ошибок, уведомления и список получателей аварийных сообщений.
Внешние сервисы и бизнес-операции
- Платёжные кабинеты, онлайн-касса и права на управление интеграцией.
- Почта, SMS, push-уведомления, телефония и сервисные адреса отправителей.
- CRM, 1С, аналитика, рекламные кабинеты и системы продуктовых событий.
- Ключи и кабинеты внешних API, лимиты, тарифы и контакт технической поддержки.
- App Store Connect, Google Play Console, сертификаты подписи и аккаунты публикации.
Как проверить передачу, а не просто принять список
Каждый критичный доступ нужно проверить действием. Если аккаунт открывается, но компания не может добавить нового администратора, изменить платёжные данные или восстановить пароль без подрядчика, контроль ещё не передан.
Войти с корпоративной учётной записью и проверить уровень прав.
Добавить второго администратора со стороны компании, чтобы не создавать новую единственную точку отказа.
Проверить корпоративную почту и телефон в настройках восстановления.
Собрать проект по инструкции в чистом окружении, а не на компьютере прежнего разработчика.
Развернуть тестовую версию и пройти один критичный пользовательский сценарий.
Восстановить копию базы или файлов на отдельном стенде и убедиться, что резервирование действительно работает.
Проверить, кто получает счета, уведомления об ошибках и предупреждения об окончании тарифа.
Минимальный комплект нормальной передачи
| Объект | Что должно остаться у компании | Как проверить |
|---|---|---|
| Код | Репозиторий, история изменений, права владельца | Новая команда клонирует и собирает проект |
| Инфраструктура | Административный доступ и описание окружений | Можно выпустить тестовую версию без прежнего подрядчика |
| Данные | Доступ к базе и резервным копиям | Копия восстанавливается на отдельном стенде |
| Домены и сервисы | Корпоративный владелец, контакты восстановления и биллинг | Компания может менять настройки и продлевать услуги |
| Знания | Схема системы, известные ограничения, незавершённые задачи | Новая команда понимает, где искать причину сбоя и как выпускать релиз |
Полезно завершить передачу совместной технической сессией. Предыдущая команда показывает путь изменения от задачи до production, объясняет критичные зависимости и перечисляет известные проблемы. Запись встречи помогает, но не заменяет текстовую инструкцию: через несколько месяцев искать ответ в длинном видео будет неудобно.
Если часть доступов уже потеряна
Сначала разделите недостающие доступы по последствиям. Потеря доступа к аналитике неприятна, но обычно не останавливает продукт. Потеря управления доменом, production-сервером, базой или магазином приложений может заблокировать работу бизнеса.
Зафиксируйте, что доступно сейчас, чтобы не потерять оставшийся контроль.
Определите юридического владельца каждого критичного ресурса и обратитесь в поддержку сервиса по официальной процедуре восстановления.
Сделайте доступные резервные копии кода, данных и конфигурации до любых изменений.
Подготовьте временный способ выпуска критичных исправлений, если штатный процесс не воспроизводится.
После восстановления перенесите владение на корпоративные аккаунты и обновите реестр.