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