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