Как передать сайт новому подрядчику: чек-лист приемки

Какие доступы нужны, чтобы передать сайт

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

Домен и лицензии — единственные пункты, которые нельзя восстановить своими силами. Все остальное при худшем раскладе восстанавливается из копии сайта; домен, оформленный на чужое лицо, придется передоговаривать с этим лицом.

В каком порядке передавать

1. Проверить, на кого оформлены домен и лицензии. Если не на вас — начать с этого, остальное подождет.
2. Забрать доступы к хостингу и панели сайта и сменить пароли, включая те, о которых прежний подрядчик мог не сказать.
3. Снять полную копию: файлы и база на одну и ту же дату. Не «есть бэкап у хостера», а скачанный и проверенный архив.
4. Собрать список сторонних сервисов и убедиться, что кабинеты открываются вашими учетными записями.
5. Запросить код проекта и описание окружения: версии, зависимости, фоновые задания, расписание.
6. Передать все новому подрядчику и дать ему время на разбор — до того, как ставить первую задачу.
7. Отозвать доступы прежнего подрядчика последним шагом, а не первым: пока проект не поднят на новом стенде, они могут понадобиться.

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

Что делать, если подрядчик пропал

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

1. Восстановить доступ к хостингу через владельца аккаунта: обычно это юридическое лицо, на которое оформлен договор.
2. Снять копию файлов и базы прямо с работающего сайта.
3. Восстановить управление доменом у регистратора — по документам компании, если домен оформлен на нее.
4. Собрать проект в репозиторий заново: с этого момента история изменений ведется у вас.
5. Поднять стенд и убедиться, что сайт на нем поднимается. Пока сайт не поднялся на стенде, у вас набор файлов, а не система.
6. Сменить все пароли и ключи, включая ключи интеграций.

Единственная невосполнимая потеря в таком сценарии — история изменений: почему код написан так, а не иначе. Она не восстанавливается ниоткуда, и разбираться приходится по самому коду. Это и есть настоящая цена работы без репозитория.

Как выглядит нормальный прием проекта

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

• Первичный разбор кода и окружения

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

• Сборка проекта в репозиторий

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

• Подъем стендов

  Копия сайта, на которой можно проверять работу, не трогая живой. До этого шага любая правка идет сразу посетителям.

• Резервное копирование

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

• Инвентарь интеграций

  Что и куда ходит: 1С, оплаты, доставка, аналитика. У чужих систем свои сроки жизни ключей и протоколов, и лучше узнать о них заранее.

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

Сколько это занимает и стоит

Сроки зависят от того, в каком состоянии система. Небольшой сайт с понятной структурой принимается за несколько дней; магазин с интеграциями и дописанным ядром — за одну-две недели.

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

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

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

Что должно остаться у вас при любом подрядчике

• Домен, оформленный на компанию, а не на человека и не на подрядчика.
• Лицензии платформы и модулей — на вашу организацию.
• Доступы к хостингу или серверу и ко всем сторонним сервисам.
• Записанное в договоре условие: на каких условиях и в какие сроки вы получаете исходники проекта.
• Описание окружения: версии, зависимости, фоновые задания.
• История задач и оценок — то, за что вы платили.

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

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