Почему приёмка — это список, а не впечатление
Самый частый спор при сдаче проекта выглядит так: заказчик говорит «мне не нравится», подрядчик отвечает «в договоре этого не было». Обе стороны правы по-своему, потому что критерии не были зафиксированы заранее.
Приёмка работает, когда превращается в набор воспроизводимых проверок: что открыть, что нажать, что должно произойти. Такой список можно составить до старта работ — и тогда он влияет на то, как проект проектируется, а не только на финал.
Хорошая новость: большинство проверок не требует технических знаний. Достаточно последовательно пройти сценарии и зафиксировать результат. Плохая новость: именно эти проверки чаще всего пропускают, а исправление части дефектов после запуска стоит дороже, чем вся приёмка.
Что должно быть передано
Начните не с внешнего вида, а с передачи прав и доступов. Если этот блок не закрыт, всё остальное теряет смысл: вы не сможете ни доработать сайт, ни сменить подрядчика.
| Что | Как проверить | Частая проблема |
|---|---|---|
| Домен | Домен и доступ к регистратору оформлены на вас | Домен зарегистрирован на подрядчика |
| Хостинг | Доступ к панели или серверу, понятный владелец аккаунта | Сайт на личном аккаунте сотрудника |
| Код | Репозиторий или архив с исходниками, доступ у вас | Передан только собранный сайт |
| Админка | Учётные записи с нужными ролями | Один общий логин на всех |
| Аналитика | Доступ к счётчикам и целям на ваш аккаунт | Счётчик создан на аккаунт подрядчика |
| Документация | Инструкция по типовым изменениям | Инструкции нет, правки только через подрядчика |
Отдельно уточните, что именно считается «передачей кода»: архив собранного сайта и исходный проект — разные вещи. Если вы планируете развивать сайт, нужен исходный проект и понятная инструкция по сборке.
Технический чек-лист
Технические проверки стоит делать на реальном домене, а не на тестовом: часть проблем проявляется только после переноса — например, редиректы, сертификат или кодировка.
- Все основные страницы открываются, отдают код 200 и не содержат ошибок в консоли браузера
- Страница 404 существует и выглядит как часть сайта, а не как стандартная заглушка сервера
- HTTPS работает, сертификат действителен, HTTP перенаправляется на HTTPS
- Адреса без www и с www не создают дублей: один вариант перенаправляется на другой
- Нет горизонтальной прокрутки на экранах 360, 768, 1280 и 1920 px
- Длинные заголовки, длинные названия товаров и цены с копейками не ломают вёрстку
- Пустые состояния: нет результатов поиска, нет товаров в категории, нет заказов в кабинете
- Формы: неверный телефон, пустое обязательное поле, сбой отправки — понятные сообщения
- Скорость: страницы открываются приемлемо на мобильной сети, изображения оптимизированы
- Резервные копии настроены и хотя бы одна проверена восстановлением
Последний пункт часто воспринимают как формальность. Проверить его просто: попросите показать восстановление из копии. Если восстановление никогда не выполнялось, копии могут оказаться бесполезными.
SEO-основа: что должно быть на месте
SEO-основа — это не продвижение, а техническая база, без которой продвижение не работает. Проверять её нужно на всех типах страниц: главная, услуга, карточка, статья, контакты.
- Уникальные заголовки и описания, без пустых и дублирующихся значений
- Корректные адреса: короткие, латиницей, без случайных символов
- Canonical указывает на правильный адрес страницы
- robots.txt не закрывает важные разделы, sitemap.xml сформирован и доступен
- Хлебные крошки и логичная структура разделов
- Разметка Organization и, где уместно, BreadcrumbList, Article, FAQPage
- Изображения с атрибутом alt и указанными размерами
- Редиректы со старых адресов, если сайт переносился
- Страница 404 не отдаёт код 200 и не индексируется
Подробнее о том, что входит в этот блок и что стоит заказывать отдельно, — в статье SEO-основа при разработке сайта.
Формы и заявки: проверить всю цепочку
Форма, которая «работает на тесте», может не работать на проде: письма уходят в спам, CRM недоступна, вебхук не настроен. Проверять нужно не факт отправки, а весь путь заявки.
- Заполните форму как клиент и отправьте заявку
- Убедитесь, что появилось подтверждение для пользователя
- Проверьте, что заявка пришла на рабочую почту, а не только на тестовую
- Проверьте запись в CRM или другом месте, куда должна попадать заявка
- Проверьте уведомление ответственному сотруднику
- Проверьте, что событие зафиксировано в аналитике
- Отправьте форму с ошибкой в поле и убедитесь, что введённое не стирается
Отдельно проверьте номера телефонов и ссылки в мессенджеры: опечатка в одной цифре обнаруживается через недели, когда выясняется, что часть обращений уходила в никуда.
Мобильная версия
Мобильную версию нельзя оценивать «на глаз» в эмуляторе. Откройте сайт на реальном телефоне, при плохой связи, и пройдите основной сценарий целиком: от входа до отправки заявки.
- Меню открывается и закрывается, пункты доступны пальцем
- Кнопки не перекрываются плавающими элементами и не уезжают за экран
- Клавиатура не закрывает поля формы и кнопку отправки
- Таблицы и длинные списки читаются без горизонтальной прокрутки
- Всплывающие окна закрываются, в том числе на маленьком экране
- Страница не «прыгает» при загрузке изображений и шрифтов
Если у сайта есть сложные разделы — каталог, калькулятор, кабинет — проверьте их отдельно: именно там чаще всего остаются десктопные решения, перенесённые без адаптации.
Контент и тексты
Контент — часть результата, а не «допишем потом». Проверьте, что тексты не содержат заглушек, вымышленных обещаний и чужих названий, а описания услуг соответствуют тому, что компания действительно делает.
- Нет текстов-заглушек и служебных подписей вроде «Lorem ipsum» и «Текст описания»
- Названия услуг и цены совпадают с тем, что подтверждает компания
- Нет выдуманных отзывов, кейсов и цифр, которые нельзя подтвердить
- Юридические страницы заполнены и доступны: политика, согласие, условия
- Контакты, реквизиты и адрес указаны верно
- Даты и сроки в текстах не устарели на момент запуска
Последний пункт стоит проверять отдельно: сайты, которые делались месяцами, часто запускаются с текстами «в этом году», написанными в прошлом.
Как оформить замечания
Замечания работают, когда они конкретны и воспроизводимы. Формулировка «сделайте красивее» не помогает: подрядчик не знает, что менять. Формулировка «на экране 360 px кнопка формы перекрыта блоком cookie, из-за чего нельзя отправить заявку» решает вопрос с первого раза.
- Одно замечание — одно наблюдение, с адресом страницы и шагами воспроизведения
- Скриншот или короткая запись экрана, если проблема визуальная
- Классификация: блокирует запуск, ошибка, недочёт оформления
- Ссылка на пункт договора или ТЗ, если требование там зафиксировано
- Срок и порядок повторной проверки
Список замечаний стоит вести в одном месте. Переписка в мессенджере быстро превращается в кашу, и часть дефектов теряется между сообщениями.
Приёмка по этапам, а не в конце
Самая дорогая приёмка — та, что делается один раз в конце проекта. На этом этапе любое замечание означает переделку, а сроки уже поджимают. Поэтому проверки стоит распределять по этапам: тогда дефекты находятся, когда их исправление ещё дешёвое.
- После прототипа: проверяются сценарии и состояния, а не оформление
- После дизайна: сверяются экраны со списком требований, включая пустые и ошибочные состояния
- После вёрстки: адаптив, длинные тексты, формы, консоль браузера
- Перед запуском: домен, SSL, редиректы, аналитика, резервные копии
- После запуска: контрольная проверка через сутки и через неделю
Такая схема требует дисциплины от обеих сторон, но экономит нервы: к финалу остаются только мелкие замечания, а не споры о том, что «входило в объём».
Что происходит после приёмки
Приёмка не заканчивается подписанием акта. Полезно сразу договориться о трёх вещах: гарантийный период и что в него входит, порядок доработок и кто отвечает за обновления.
- Гарантия на исправление дефектов, которые относятся к работе подрядчика
- Порядок новых задач: оценка, приоритет, сроки
- Обновления платформы, зависимостей и серверной части
- Резервное копирование и мониторинг: кто и как реагирует на сбой
- Передача знаний: короткая инструкция и разбор одного типового изменения
Если вы принимаете сайт «под ключ» и планируете работать самостоятельно, попросите разбор одного изменения вместе с вашим сотрудником. Это дешевле, чем разбираться по документации через полгода.
Как устроен процесс работы по этапам, описано на странице процесс работы, а состав работ и порядок цен — в разделе цены. Если нужна независимая проверка готового сайта, её можно обсудить через форму обсуждения проекта.
Если дефектов много
Иногда список замечаний оказывается таким длинным, что подписывать акт не имеет смысла. В этом случае полезно разделить дефекты на три группы — это помогает разговаривать предметно, а не эмоционально.
- Блокирующие: сайт не выполняет основную задачу — не отправляются заявки, не работает оплата, не открываются ключевые страницы
- Существенные: задача выполняется, но с ошибками и обходами — сломанная мобильная версия, неверные цены, отсутствующие разделы
- Оформление и удобство: не мешает запуску, но влияет на восприятие и конверсию
Блокирующие исправляются до запуска, существенные — в оговорённый срок, оформление — по приоритету. Если подрядчик не согласен с частью замечаний, помогает ссылка на конкретный пункт договора или ТЗ: спорить о формулировках проще, когда есть документ.
И ещё: зафиксируйте итог письменно. Согласованный список с датами закрывает вопрос «мы это обсуждали» и защищает обе стороны.