Передача проекта другому подрядчику: что забрать, пока старая команда ещё отвечает

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

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

Сразу оговорка. Статистики по тому, как часто такие передачи проходят плохо, у меня нет, и придумывать её я не буду. Ниже - порядок, в котором я сам принимаю чужой проект на Bitrix. Он пригодится и владельцу магазина, и новой команде.

Сначала доступы, потом код

Код можно восстановить с сервера. Доступ к домену, если он оформлен на бывшего подрядчика, восстанавливается долго и неприятно.

Поэтому первый список - не про архитектуру. Он про то, на кого что оформлено:

  • домен и DNS;
  • хостинг или сервер, включая root или sudo;
  • репозиторий и права администратора в нём;
  • лицензия Bitrix и личный кабинет партнёра;
  • платёжный шлюз, служба доставки, SMS и почтовые сервисы;
  • обмен с 1С: логин, пароль и кто его настраивал;
  • аналитика и вебмастера.

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

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

Сверьте прод с репозиторием

Репозиторий показывает, каким проект задумывали. Прод показывает, какой он на самом деле.

На старых проектах Bitrix эти две версии расходятся чаще, чем хотелось бы. Кто-то поправил шаблон прямо на сервере. Кто-то поменял настройку модуля в админке, и в Git этого нет и быть не может.

Что я делаю в первые дни:

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

Если окажется, что Git отстаёт от прода, это не катастрофа. Но об этом лучше узнать до первого деплоя, а не после.

Найдите то, что не записано

Самое опасное в передаче - не код. Это то, что работает в фоне и о чём никто не вспомнит, пока не сломается.

В Bitrix-проекте я ищу:

  • cron на сервере и агенты Bitrix: что запускается и как часто;
  • обмен с 1С: в какую сторону, по какому расписанию, кто следит за ошибками;
  • выгрузки для маркетплейсов и рекламы;
  • ручные операции, которые кто-то делает по понедельникам и считает «само собой разумеющимся».

Последний пункт обычно не найти в коде. Его можно узнать только от людей.

Поговорите со старой командой, пока она отвечает

Окно, в котором старый подрядчик ещё готов отвечать на вопросы, короткое. Используйте его по максимуму.

Вопросы, которые я бы задал:

→ что в проекте самое хрупкое и чего вы боялись трогать; → какие задачи остались незаконченными; → какие решения были временными и так и остались; → как выкатывается релиз: руками, скриптом, через CI; → кто со стороны бизнеса согласовывал изменения.

Важно и то, как идёт этот разговор. Если старая команда отвечает спокойно, это хороший знак. Если клиент не может объяснить, почему прошлый подрядчик «пропал», я отношусь к проекту осторожнее и сначала предлагаю короткий разбор, а не оценку. Почему - писал в статье про оценку проекта по рискам, а не по часам.

Ответы записывайте сразу. Не в чат, а в документ, который останется у вас. Как я сам храню такие знания между проектами, рассказывал в статье про Claude Code и Obsidian.

Не начинайте с переписывания

Новая команда почти всегда видит в чужом коде много плохого. Иногда она права. Но предложение «давайте перепишем» в первую неделю обычно значит, что в проекте ещё не разобрались.

Legacy на Bitrix бывает тяжёлым, но он продаёт. Первая задача новой команды - не сломать то, что работает. Вторая - понять, где на самом деле болит.

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

Потом беру один небольшой участок работы. По нему видно, как команда работает с этим кодом, и при этом риск для магазина маленький. Подробнее - в статье про первый work slice.

Если же заказчик сам приходит со словами «уходим от старого подрядчика и заодно переписываем», я разделяю эти две задачи. Смена команды - это transfer of ownership. Переписывание - отдельный проект со своим scope. Разбирал это в статье «Rewrite - это не scope».

Короткий чек-лист передачи

→ домен, хостинг, репозиторий, лицензия Bitrix и внешние сервисы оформлены на вас; → пароли сменены после передачи; → прод сверен с репозиторием, расхождения записаны; → есть бэкап базы, и его хотя бы раз восстановили; → найдены cron, агенты, обмен с 1С и ручные операции; → ответы старой команды записаны в документ, который остаётся у вас; → первая задача новой команды маленькая и не трогает checkout.

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