Как принимать сайт после разработки?

Что проверить при приёме готового сайта:

• Сначала сверяют сайт с техническим заданием, макетами и согласованным списком функций

• Затем проверяют путь пользователя от первого действия до итогового результата

• Ошибки нужно описывать воспроизводимо: действие, ожидаемый результат и фактическое поведение

• Новые пожелания важно отделять от недостатков согласованной работы

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

В Ameton рекомендуем начинать подготовку к приёмке ещё до разработки: вместе с заказчиком фиксировать критичные сценарии и критерии готовности. Это позволяет в конце проекта последовательно проверять согласованный результат

Приёмка начинается с согласованных критериев

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

Для небольшого корпоративного сайта критериями могут быть структура разделов, формы заявок, адаптация для мобильных устройств и публикация материалов. Для интернет-магазина этого недостаточно: нужно проверить корзину, оформление заказа, оплату, доставку, уведомления и обработку данных о товарах. Для B2B-портала добавляются права пользователей, персональные условия и работа с документами

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

Какие сценарии нужно проверить перед приёмкой

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

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

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

Как организовать проверку без хаоса

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

Студия Ameton рекомендует назначить со стороны заказчика человека, который знает ключевые процессы бизнеса и может подтвердить результат. Менеджер, маркетолог и сотрудник отдела продаж часто смотрят на сайт по-разному: один проверяет содержание, другой — путь посетителя, третий — обработку обращения

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

Как правильно фиксировать замечания

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

Для каждого замечания полезно указать:

• страницу или раздел сайта

• роль пользователя, под которой выполняется действие

• последовательность шагов

• ожидаемый результат

• фактический результат

• приложенный скриншот или запись экрана, если это помогает понять проблему

• критичность для запуска

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

Пример из практики Ameton: при проверке личного кабинета заказчик сообщил, что «не открываются документы». Команда воспроизвела проблему только после уточнения роли пользователя и конкретного действия: документ был доступен в одном статусе заказа, но исчезал после изменения статуса во внешней системе. Чёткое описание сценария помогло найти и устранить ошибку в связанной функции без избыточных проверок

Чем недостаток отличается от новой доработки

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

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

Что должен передать подрядчик после завершения разработки сайта

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

Обычно передаются:

• доступы к административной части сайта

• доступы к домену и хостингу или порядок их передачи

• исходный код и доступ к репозиторию, если это предусмотрено договором

• учётные записи внешних сервисов, которые используются для работы сайта

• резервная копия или согласованный способ восстановления

• документация по нестандартным решениям и интеграциям

• инструкции для сотрудников, если работа с сайтом требует отдельного порядка

Если студия организовала покупку лицензии 1С-Битрикс или включила её в смету, лицензию следует зарегистрировать на компанию-заказчика как на конечного пользователя. Порядок оплаты и продления лучше заранее закрепить в договоре, чтобы доступ к обновлениям и документам не зависел от смены подрядчика

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

Когда можно принимать сайт с замечаниями

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

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

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

Как меняется объём приёмки для простого сайта и сложного проекта

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

Для информационного сайта достаточно проверить публикацию страниц, отображение контента, формы, ссылки и мобильную версию. У интернет-магазина к этому добавляются каталог, корзина, оформление заказа, оплата, доставка, уведомления и обработка заказа после оформления. В B2B-портале отдельно проверяют роли пользователей, персональные условия, документы и доступ к закрытым разделам

Если сайт обменивается данными с учётной системой, CRM или внешними сервисами, в сценарии приёмки включают не только действия пользователя в интерфейсе, но и результат обмена: передались ли заказ, цена или статус, не появились ли дубли и как система обрабатывает ошибку

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

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