Как сменить подрядчика и передать проект без потерь

Сменить подрядчика без потерь можно, если до объявления о расставании собрать все доступы и права на стороне компании, провести технический аудит проекта и договориться о периоде совместной работы, в течение которого старая команда передаёт знания новой. Главный риск смены — не код, а знания и доступы, которые остались только у уходящей команды.

Разберём, как подготовиться, что передаётся и как новой команде безопасно принять проект.

Когда пора менять подрядчика?

Пора менять подрядчика, когда проблемы повторяются и не исправляются после прямого разговора: сроки регулярно срываются, качество падает, прогресс не виден, а на вопросы нет конкретных ответов. Смена — дорогое решение, поэтому сначала стоит понять причину: иногда задержки происходят из-за ожидания решений со стороны заказчика.

Признаки, что проблема на стороне подрядчика:

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

Если вы только выбираете нового исполнителя, пригодится чек-лист из статьи как выбрать подрядчика для разработки.

Что подготовить до разговора с текущим подрядчиком?

До разговора о смене нужно убедиться, что все критичные доступы уже находятся у компании: репозиторий, хостинг, домены, база данных, внешние сервисы. Если этого не сделать заранее, передача может затянуться или стать предметом торга.

Что проверить	Где обычно находится	Что должно быть
Репозиторий с кодом	Аккаунт подрядчика или компании	Компания — владелец, полная история изменений
Хостинг и облако	Аккаунт подрядчика	Аккаунт компании, подрядчик — участник
Домены и DNS	Регистратор, часто на подрядчике	Регистрация на компанию
Базы данных и бэкапы	Серверы подрядчика	Доступ и свежая проверенная копия
Внешние сервисы	Платежи, почта, аналитика, карты	Аккаунты компании, ключи известны
Магазины приложений	Аккаунт разработчика	Аккаунт компании
Документация	Вики, трекер, почта	Выгрузка и доступ

Права на код и порядок передачи стоит сверить с договором: если там есть пункт о передаче проекта, опирайтесь на него.

Фото: Unsplash

Что должна передать уходящая команда?

Уходящая команда должна передать не только код и доступы, но и знания: как развернуть проект, как устроена архитектура, какие есть известные проблемы и незавершённые задачи. Без этого новая команда будет месяцами восстанавливать то, что можно рассказать за несколько встреч.

Чек-лист передачи:

1. Код со всей историей изменений и актуальными ветками.
2. Инструкция по развёртыванию проекта с нуля и по выкладке на продакшен.
3. Описание архитектуры, интеграций и нестандартных решений.
4. Список известных ошибок, технического долга и незавершённых задач.
5. Доступы ко всем окружениям, сервисам и мониторингу.
6. Все ключи и секреты — с последующей их заменой новой командой.
7. Несколько встреч с разработчиками, которые знают систему.

Период совместной работы

Лучший вариант — несколько недель, когда старая команда ещё доступна для вопросов, а новая уже работает с проектом. Этот период стоит оплатить и закрепить в договорённостях: он окупается многократно, потому что снимает риск остаться с системой, которую никто не понимает.

Как новой команде безопасно принять проект?

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

Порядок приёма:

• развернуть проект на новом окружении по инструкции — всё, что не сработало, фиксируется;
• заменить все пароли и ключи, которые знала старая команда;
• проверить бэкапы и восстановление из них;
• провести аудит и составить список рисков;
• выпустить первое небольшое изменение, чтобы проверить путь до продакшена.

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

Какие ошибки делают при смене подрядчика?

Самая дорогая ошибка — объявить о расставании, пока доступы и код находятся у уходящей команды. Вторая — отказаться от периода совместной работы ради экономии и потом месяцами восстанавливать знания о системе.

Другие ошибки:

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

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

Коротко

• Прежде чем объявлять о смене, соберите все доступы и права на стороне компании.
• Уходящая команда передаёт код, инструкции, описание архитектуры, известные проблемы и знания.
• Оплатите период совместной работы — он окупается многократно.
• Новая команда начинает с аудита, замены ключей и проверки бэкапов.
• Не переписывайте всё сразу и не требуйте фиксированной цены до аудита.