Передача — это смена ответственного, а не переезд
Слово «передать» звучит как перенос файлов, и от этого задача кажется большим проектом с простоем и риском потерять данные. На деле переходит управление: кто владеет доменом, кто платит за хостинг, у кого лежит код и кто имеет право его менять. Площадка при этом может остаться прежней — менять её имеет смысл, когда проблема именно в ней, а не в том, что ушёл человек.
Дальше — возражения, из-за которых передачу откладывают месяцами, и что стоит за каждым из них на самом деле.
«Никто не возьмётся за чужой код»
Это утверждение про подрядчика, а не про ваш код. «Проще написать заново» можно услышать раньше, чем кто-то открыл ваши исходники. Разобраться в чужом проекте — отдельная работа, её надо сделать до первой правки, и по внешнему виду сайта она не оценивается. Новый проект считается по знакомой схеме, а разбор чужого кода в эту схему не укладывается. Поэтому «переписать» — самый удобный ответ.
Рабочий выход — развести разбор и правки. Сначала чтение проекта: что там написано, совпадает ли код с сервером, что зависит от мест, которые придётся трогать. По результату видно, какие задачи решаются внутри существующего кода, а какие упираются в архитектуру. Это тот порядок, в котором мы берём чужие проекты, — как он устроен, описано на странице доработки сайта после другого разработчика.
«Пока передаём, сайт ляжет»
Не ляжет, если площадка не меняется. Страницы продолжают отдаваться так же, как отдавались вчера: смена паролей и владельца учётных записей не трогает работающий код. Страх обоснован ровно в той мере, в какой передачу путают с переездом.
Ломаются при этом не страницы, а то, что завязано на чужие учётные записи: отправка писем с форм, приём оплаты, рассылка кодов, карта на странице контактов. Всё это работает через ключи, оформленные на конкретную учётную запись, и когда доступ прежнего подрядчика отзывают, ключи уходят вместе с ним. Поэтому такие точки проверяют сразу после смены доступов, а не потом, по жалобе клиента.
«Прежний разработчик не отдаёт доступы»
Всё решает один факт: на кого оформлены домен, хостинг и почта. Проверяется он без чужого участия. Если на вашу компанию, рычага у подрядчика нет — разговор о доступе переносится к регистратору и хостеру, туда, где у вас есть документы, а не только просьба. Если на него — это первое, что нужно вернуть себе, до всяких правок: развивать сайт на чужом домене значит вкладываться в чужой актив.
Отдельно стоит проверить, на чьи почтовые ящики заведены сторонние сервисы: аналитика, платёжный шлюз, отправка писем, карты. Учётная запись, восстановление пароля к которой приходит на адрес подрядчика, формально ваша, а фактически — нет.
«Проще сделать новый сайт, чем разбираться в старом»
Иногда это действительно так, и честный подрядчик скажет об этом прямо. Но новый сайт — это новый срок, новая приёмка и новый исполнитель, о котором вы пока ничего не знаете. Вместе со старым сайтом уходят адреса страниц и их место в поиске, накопленный контент, настроенные интеграции и привычки постоянных клиентов. Ситуация «сделали заново, а спустя время снова некому развивать» — это та же история по второму разу, только дороже.
Заменять действительно дешевле, когда сломано одинаково по всему проекту: движок нельзя обновить, потому что тему правили поверх его файлов; одно и то же значение продублировано в разных местах; правка в одном разделе непредсказуемо меняет соседний. Такое видно из чтения кода, а не из разговора о нём, и решение принимаете вы — с разбором на руках, а не под давлением срока.
«Мы не поймём, всё ли нам передали»
Это возражение снимается списком, а не доверием. Передача считается состоявшейся не тогда, когда прислали архив, а когда по каждой строке ниже вы можете сказать «да» самостоятельно, не спрашивая никого.
| Что переходит | Где это лежит | Признак, что перешло |
|---|---|---|
| Домен | у регистратора | владелец и администратор — ваша компания, вход в кабинет ваш |
| DNS-записи | у регистратора или хостера | вы видите записи и можете их изменить |
| Хостинг или сервер | у провайдера | договор и оплата на вас, доступ к панели или к серверу ваш |
| Почта на домене | у почтового провайдера | ящики заводите и удаляете вы |
| Код | репозиторий | репозиторий принадлежит вам, история изменений целиком |
| База данных | на сервере | выгрузка есть, и она разворачивается на копии |
| Учётные записи сервисов | аналитика, оплата, рассылки, карты | восстановление пароля идёт на вашу почту |
Отдельная строка, которую забывают, — совпадает ли переданный код с тем, что работает на сервере. Если сайт долго правили срочно, часть изменений могла уйти прямо на боевую площадку, минуя исходники. Пока это не сверено, первая же правка откатит чужую работу молча. Как проверять принятую работу, не читая код самому, разобрано отдельно: как принять работу, если вы не инженер.
«Новый подрядчик запрёт нас так же»
Возражение честное: вы уже один раз оказались в зависимости и не хотите повторения. Проверяется оно не обещаниями, а условиями, которые видно до начала работ.
- •Правки идут в вашем репозитории и на вашем сервере, а не на площадке подрядчика,
- •Домен, хостинг и почта оформлены на вас и в процессе работ на исполнителя не переоформляются,
- •История изменений остаётся у вас целиком: видно, кто, что и когда менял,
- •Уйти можно в любой момент, ничего не выкупая и никого не упрашивая.
Эти же пункты стоит записать в приёмку до старта, а не выяснять в день сдачи. Что входит в доработку, а что нет, разобрано по пунктам в статье доработка сайта: что входит, а что нет.
Что делать сразу после передачи
Смена разработчика закрывает вопрос «кто возьмёт задачу», но не вопрос «кто заметит, что сломалось». Тихие поломки — истёкший сертификат, переставшая отправлять письма форма, необновлённое ядро движка — не приходят заявкой от клиента, их находят проверками. Когда такие проверки нужны, а когда без них можно обойтись, разобрано здесь: техническое сопровождение сайта: когда нужно.
Если сайт уже нужно передать, а с доступами непонятно — с этого и начнём: доработка и сопровождение существующих сайтов.
Частые вопросы
С чего начинать, если прежний разработчик перестал отвечать?
Не с поиска нового подрядчика, а с описи: на кого оформлены домен, хостинг и почта, где лежит код, есть ли выгрузка базы. Пока это неизвестно, любой разговор о работах упирается в «а доступ будет?». Опись делается без подрядчика и сразу показывает, что у вас уже есть, а что придётся возвращать.
Нужно ли переносить сайт на другой хостинг при смене разработчика?
Не нужно, если с хостингом нет отдельной проблемы: передаётся управление, а не площадка. Переезд оправдан там, где сервер оформлен на подрядчика, версия окружения не обновляется или площадка не даёт вам полного доступа. В остальных случаях переезд добавляет риск, не решая исходную задачу.
Домен оформлен на подрядчика. Это тупик?
Нет, но это первое, что нужно вернуть себе, — до правок, а не после. Пока владелец домена не вы, любая договорённость держится на доброй воле человека, с которым вы уже не смогли договориться. Разговор о доступе стоит перевести к регистратору и хостеру, где у вас есть документы, а не только просьба.
Как понять, что нам отдали актуальный код, а не старую копию?
Сравнить переданные исходники с тем, что реально работает на сервере: совпадают ли файлы, есть ли правки, сделанные напрямую на боевой площадке. Так бывает там, где правили срочно и мимо репозитория. Проверять это надо до первой правки, иначе вы откатите чужую работу, не зная об этом.
Можно ли передать сайт частями?
Доступы — нет: забирают все, не оставляя ни одного про запас, иначе остаётся рычаг. Это про объём, а не про темп: сами пароли меняют по одному, проверяя формы и почту после каждого. Задачи — да: разумно начать с одной понятной правки, а не с полного списка. Она показывает состояние проекта обеим сторонам, и дальнейший разговор идёт с фактами, а не с ощущениями.
Сколько стоит принять чужой сайт?
Стоимость определяет не сам приём, а объём чтения проекта до первой правки: насколько он документирован и насколько исходники совпадают с тем, что работает на сервере. Поэтому цену честно называть после этого чтения, а не до него: до него любая цифра будет угадыванием. Заодно чтение показывает, что чинится внутри существующего кода, а что упирается в архитектуру.