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

Почти никогда это не злой умысел. Это просто отсутствие передачи как отдельной работы.

Что обязано входить

Доступы ко всему, оформленные на вас. Репозиторий, сервер, домен, почта, платёжный провайдер, аккаунты в сторах. Не «мы вам дадим», а изначально ваши, с нашим доступом как подрядчика.

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

Инструкция по выкатке и откату. Как выпустить изменение и как вернуть предыдущую версию. Проверенная при вас, а не описанная.

Восстановление из бэкапа, выполненное на ваших глазах. Бэкап, из которого ни разу не восстанавливались, — это надежда по расписанию.

Сквозные тесты на главные пути. Иначе следующая команда будет бояться трогать код так же, как боялись вы.

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

Как проверить заранее, а не в конце

Не ждите финала проекта. Попросите провести передачу на любом промежуточном этапе: пусть подрядчик покажет, как выкатывается изменение и как оно откатывается, прямо при вас. Команда, у которой с этим порядок, воспримет просьбу спокойно. Реакция «зачем это сейчас» — сама по себе ответ.

Второй приём: попросите на неделю отдать вам управление релизом. Если без подрядчика ничего не выкатывается, значит передача не сделана, как бы она ни называлась в договоре.

Как выглядит передача, которая прошла хорошо

Признак один и он проверяемый: **ваш человек разворачивает систему сам, при нас,

до окончания работ.** Не читает инструкцию, не смотрит запись — делает.

За этим одним действием стоит всё остальное: доступы у вас, а не у нас;

инструкция написана так, что по ней можно идти, а не вспоминать; секреты лежат

там, где их найдут; окружение поднимается с нуля, а не «как-то живёт с

позапрошлого года».

Мы ставим эту репетицию на пятую неделю из восьми — не в конце. Причина простая:

на пятой неделе есть время починить то, что вскроется, а на восьмой остаётся

только пообещать.

Пять вопросов до подписания договора

Задайте их до начала работ, а не в конце: в конце у вас нет рычага.

1. На кого оформлены аккаунты? Домен, хостинг, платёжный провайдер, аккаунты

разработчика в сторах, почта. Правильный ответ — на вас, с первого дня.

2. Где лежит репозиторий? В вашей организации, а не «у нас, потом

перенесём».

3. Что будет в инструкции? Хороший ответ перечисляет: как развернуть с нуля,

как выкатить, как откатить, что делать, если упало ночью.

4. Есть ли тесты и запускаются ли они у нас? [Сьют, который живёт только у

подрядчика](/ru/services/test-automation), — не ваш актив.

5. Что происходит, если мы расходимся на середине? Ответ «у вас остаётся

работающий кусок и все доступы» и ответ «придётся начинать заново» — это два

разных типа подрядчика, и узнать это лучше сейчас.

Почему мы делаем это частью цены

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

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

Если сейчас вы в положении «система есть, а доступов нет», это чинится: мы разбираем такие проекты — забираем инфраструктуру под контроль, описываем и передаём вам. Часто это оказывается дешевле, чем кажется в момент паники.

Вопрос, который стоит перед этим: своя разработка или готовая коробка: как выбрать за неделю.