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

Подрядчик прислал ссылку на готовый сайт. Главная страница выглядит аккуратно, фотографии открываются, кнопки меняют цвет. Заказчик пишет «всё нравится», а через неделю обнаруживает, что заявка из формы приходит без выбранной услуги. Внешний осмотр оказался слишком коротким.

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

Ниже восемь проверок для владельца бизнеса. Их можно пройти вместе с подрядчиком на тестовом адресе. Этот маршрут поможет собрать понятные замечания и определить, что осталось до запуска. Он дополняет техническое тестирование команды разработки.

1. Сверьте состав сайта с договорённостями

Выпишите страницы и действия из согласованного документа. Напротив каждого пункта укажите адрес, где его можно проверить. Если вместо конкретной страницы в таблице остаётся запись «будет позже», уточните срок и влияние на запуск.

Сравнивайте сайт с последней принятой версией задания. За время работы могли появиться новые требования и отказ от части старых. Переписка помогает восстановить изменения, но для приёмки удобнее один актуальный список. Иначе участники будут спорить о разных версиях проекта.

Отдельно отметьте сведения, которые должен предоставить заказчик. Временные фотографии, пример адреса и черновое описание услуги могут выглядеть как недоделка подрядчика, хотя команда ещё ждёт материалы. В списке должно быть видно, кто закрывает каждый пункт.

Для учебного сайта мастерской таблица может выглядеть так.

Что согласовано	Где проверяем	Что считается готовым
Страница ремонта	Адрес услуги	Реальные условия и форма обращения
Выбор филиала	Форма заявки	Выбранный адрес приходит менеджеру
Редактирование графика	Панель управления	Сотрудник меняет часы без разработчика
Страница контактов	Раздел контактов	Телефон и маршрут соответствуют филиалу

Такая таблица даёт основу для разговора о дополнительных пожеланиях. Если после просмотра появилась новая функция, внесите её отдельной задачей с оценкой. Обнаруженный дефект согласованной функции останется замечанием к приёмке. Подробности этапов полезно сверить с разбором разработки лендинга.

2. Пройдите маршрут нового клиента без подсказок

Начните со страницы, на которую человек попадёт из рекламы или поиска. Иногда приёмку проводят только с главной, хотя рекламная ссылка ведёт сразу на услугу. У такой страницы должны быть понятные контакты и следующий шаг даже для посетителя, который никогда не видел остальной сайт.

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

Не объясняйте проверяющему, куда нажимать. Если без подсказки маршрут теряется, это наблюдение для обсуждения. Его можно проверить на нескольких сотрудниках, которые не участвовали в разработке. Их реакции дадут конкретные замечания, но ещё не будут исследованием всей аудитории.

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

Полезно сохранить краткую запись проверки. Укажите устройство, страницу входа, задачу и место затруднения. Замечание «пользоваться неудобно» оставляет слишком много вариантов исправления. Запись «на странице ремонта не нашли адрес выбранного филиала» уже направляет разговор к конкретному блоку.

3. Отправьте заявку и найдите её у сотрудника

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

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

Проверьте и поведение при неполном вводе. Оставьте обязательное поле пустым, затем исправьте его. Посмотрите, сохранились ли остальные данные. Если форма очищается целиком, человек вынужден вводить всё заново. Запишите точные шаги и ожидаемый результат.

Ещё один сценарий связан с медленной отправкой. Нажмите кнопку один раз и дождитесь ответа. Пользователь должен видеть, что действие выполняется. Поведение при повторном нажатии и сбое соединения отдельно уточните у разработчика, особенно если форма создаёт заказ или бронирование.

Передача источника обращения требует своей проверки. Если в задании есть аналитика рекламы, используйте тестовую размеченную ссылку и сравните поля заявки. Общая схема описана в материале о передаче UTM в CRM. На приёмке проверяйте именно тот способ хранения источника, который согласован для вашего сайта.

4. Откройте реальные страницы на телефоне

Эмулятор телефона в браузере разработчика полезен, но приёмку стоит дополнить обычным устройством. На нём есть экранная клавиатура, привычный браузер и реальный способ ввода. Проверьте хотя бы один длинный заголовок, меню, форму и страницу контактов.

При открытии клавиатуры посмотрите, остаётся ли видна текущая строка ввода. Пройдите форму до конца, закройте клавиатуру, отправьте данные. Обратите внимание на кнопки возле края экрана и элементы, которые перекрывают друг друга.

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

Если замечание воспроизводится на одном устройстве, запишите модель и браузер. Подрядчику будет проще повторить ситуацию. Скриншот показывает результат, но последовательность действий объясняет, как вы к нему пришли. Для сложной ошибки короткая запись экрана обычно полезнее нескольких неподписанных изображений.

Feature IT разрабатывает сайты с учётом маршрута обращения. До начала работы можно согласовать набор устройств и сценариев приёмки. Это поможет заранее понять, какие проверки входят в задачу и кто их выполняет.

5. Дайте сотруднику изменить рабочую информацию

Если в проект входит панель управления, попросите будущего редактора выполнить обычную задачу. Например, обновить график филиала, заменить фотографию или добавить услугу. Разработчик наблюдает и отвечает на вопросы, затем сотрудник повторяет действие самостоятельно.

Проверьте полный цикл публикации. Изменение сохранено в панели, появилось на странице и корректно выглядит на телефоне. Если обновление требует дополнительной команды или ожидания, этот порядок должен быть описан в инструкции.

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

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

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

6. Проверьте контакты и обещания на всех страницах

Телефон в шапке, кнопка внизу страницы и адрес в разделе контактов могут храниться в разных местах. Измените тестовое значение там, где это предусмотрено, и убедитесь, что оно обновилось везде по согласованному правилу. Затем верните реальную информацию.

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

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

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

Если страницу готовили под продвижение, заголовок и содержание должны описывать одну услугу. Полезные критерии выбора исполнителя и обсуждения результата есть в материале о студии разработки. На приёмке вернитесь к конкретным обещаниям вашего проекта.

7. Запишите замечания так, чтобы их можно было повторить

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

Например, «На странице записи выбрать второй филиал, заполнить телефон и отправить форму. В письме приходит первый филиал. Ожидается выбранный второй». Здесь достаточно сведений, чтобы повторить ошибку и проверить исправление.

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

После исправления повторите тот же сценарий. Отметка разработчика «готово» сообщает о выполненной работе, но приёмка заканчивается проверкой результата. Если исправление меняло общий блок, откройте ещё одну страницу, где этот блок используется.

8. Согласуйте запуск и первые действия после него

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

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

К запуску подготовьте короткий список действий.

• Подтвердить окончательные тексты и контакты.
• Закрыть замечания, мешающие работе клиента.
• Повторить заявку после публикации.
• Проверить вход сотрудника в панель управления.
• Указать канал связи на случай ошибки после запуска.

Если часть улучшений остаётся на потом, сохраните их отдельным списком с владельцем и приоритетом. Так согласованная первая версия будет понятна обеим сторонам. Для нового проекта можно обсудить разработку и приёмку с Feature IT, начиная с одного маршрута клиента и результата, который должен получить ваш сотрудник.

Читайте также

• Что проверить в Mini App перед запуском.
• Как устроен контроль ошибок веб-приложения.
• Почему заявки требуют проверки всей интеграции.