Приёмка сайта у разработчика: как проверить результат и подписать акт

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

Что входит в приёмку сайта у разработчика и где её границы

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

Приёмка как процедура, а не разовый осмотр

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

Приёмка опирается на три опоры: договор, техническое задание и проектную документацию. Техническое задание отвечает на вопрос «что нужно заказчику», проектная документация — на вопрос «как это достигается». В ТЗ, помимо целей и требований, должен быть описан порядок проведения испытаний и приёмки-сдачи работ. Если такого раздела нет, его стоит согласовать до начала проверки, иначе каждая сторона будет понимать приёмку по-своему.

Что относится к приёмке, а что — к соседним задачам

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

Границы приёмки стоит зафиксировать заранее. Обычно в неё входят: проверка по ТЗ, проверка ключевых сценариев, проверка доступов и исходников, проверка документации и инструкций. Не входят: развитие функциональности, изменение требований «по ходу» и работы, которых не было в договоре.

Какие исходные данные подготовить до начала приёмки

Приёмка проваливается чаще не из-за плохого сайта, а из-за неподготовленных входных данных. Если у заказчика нет под рукой ТЗ, договора и списка доступов, проверка превращается в разговор по памяти. Поэтому подготовку стоит начать за несколько дней до встречи.

Договор, ТЗ и проектная документация

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

Отдельно отметьте всё, что менялось после подписания ТЗ: письма, согласования в мессенджерах, дополнительные договорённости. Если изменение не зафиксировано письменно, на приёмке его сложно предъявить как требование.

Доступы, стенды и тестовые данные

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

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

Проверка результата по ТЗ: попунктное сопоставление

Самый надёжный способ принять работу — идти по ТЗ пункт за пунктом и отмечать статус каждого требования. Это дисциплинирует обе стороны и не даёт забыть про мелочи, которые легко упустить при беглом осмотре.

Как превратить ТЗ в проверяемый список

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

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

Что делать с расхождениями формулировок

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

Полезно разделять замечания по критичности. Критичное — то, что мешает запуску или ломает сценарий. Некритичное — косметика и улучшения, которые можно вынести в список после запуска. Это помогает не застрять на приёмке из-за мелочей.

Доступы, исходники и инфраструктура: что переходит заказчику

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

Домены, хостинг, панели управления

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

Если сайт работает на Битрикс, порядок доступов и настроек удобно сверить с материалом про Администрирование сайта на Битрикс — доступы, данные и настройки. Там описано, какие роли и данные важно передать заказчику.

Резервные копии и восстановление

До подписания акта стоит убедиться, что резервное копирование настроено и что копию можно восстановить. Наличие бэкапа без проверенного восстановления — это надежда, а не гарантия. Уточните, где хранятся копии, как часто создаются и кто отвечает за их проверку.

Если сайт на Битрикс, полезно заранее разобраться, как устроено Резервное копирование сайта на Битрикс — хранение и восстановление.

Функциональная проверка: сценарии, формы, интеграции

Функциональность проверяют действием, а не по скриншотам. Скриншот показывает, что кнопка есть, но не показывает, что она работает. Поэтому ключевые сценарии стоит пройти руками — от начала до конца, как это сделает реальный пользователь.

Проверка действием, а не по скриншотам

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

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

Интеграции с внешними сервисами

Если сайт связан с внешними сервисами — оплатой, доставкой, CRM, аналитикой, — проверьте каждую связку отдельно. Убедитесь, что данные передаются в обе стороны и что при сбое внешнего сервиса сайт ведёт себя предсказуемо, а не теряет заявку.

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

Проверка на устройствах, скорость и техническая гигиена

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

Мобильные устройства и разные браузеры

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

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

Базовая техническая гигиена

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

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

Учебный пример приёмки сайта на Битрикс

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

Входные условия

Условная компания заказала корпоративный сайт на Битрикс. В ТЗ зафиксированы: разделы каталога, форма заявки с уведомлением на почту отдела продаж, интеграция с CRM, перенос контента со старого сайта, передача доступов заказчику. Исполнитель объявил работы выполненными и предложил подписать акт.

Со стороны заказчика назначены: руководитель проекта, который ведёт приёмку, маркетолог, отвечающий за формы и контент, и технический специалист, отвечающий за доступы и резервные копии.

Ход проверки

Руководитель проекта разбил ТЗ на проверяемые пункты и прошёл по ним. Из разделов каталога один оказался пустым. Форма заявки работала, но письмо уходило на общий адрес, а не на почту отдела продаж. Интеграция с CRM передавала заявки, но не передавала поле «источник обращения». Доступы к административной панели у заказчика были, а к управлению доменом — нет.

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

Результат и проверка

Все находки были занесены в протокол приёмки с указанием критичности. Критичными признали: пустой раздел каталога, неверный адрес уведомлений и отсутствие доступа к домену (или невозможность управления им). Некритичными — поле комментария на мобильной версии и отсутствие поля «источник обращения» в интеграции (если это не влияет на аналитику).

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

Протокол приёмки: как фиксировать замечания и подписывать акт

Протокол приёмки — это рабочий документ, который превращает разговор в список конкретных пунктов. Без него замечания теряются, а спорные моменты вспоминаются по-разному.

Структура протокола

В протокол стоит включить: дату проверки, состав участников, перечень проверенных пунктов ТЗ со статусами, описание замечаний, критичность, ответственного за устранение и срок повторной проверки. Чем конкретнее формулировка замечания, тем проще его закрыть.

Формулировка «форма работает плохо» бесполезна. Формулировка «при отправке формы без заполненного поля „телефон“ появляется сообщение об ошибке на английском языке» — проверяема и закрываема.

Отдельные акты и порядок подписания

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

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

Типичные ошибки при приёмке и ограничения метода

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

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

У метода есть ограничения. Приёмка проверяет соответствие договорённостям, но не гарантирует, что сайт будет удобен всем пользователям или что он решит все бизнес-задачи. Часть выводов — про удобство, тексты, структуру — требует отдельного разбора. Если нужен взгляд на качество и риски уже работающего сайта, стоит рассмотреть Аудит сайта на Битрикс: как проходит и что вы получите как отдельную задачу.

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

Чек-лист приёмки сайта у разработчика

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

Разработка сайтов на битрикс