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