Чеклист запуска и приемки сайта: ТЗ, доступы, QA и передача без рисков
Проблемы с сайтом редко начинаются в день релиза. Чаще они закладываются раньше: когда ТЗ остается размытым, состав работ не зафиксирован, формы не проверены, ownership не закреплен, а акт приемки превращается в формальность. В итоге бизнес принимает не готовый актив, а набор обещаний, которые придется дособирать уже за свой счет.
Короткий вывод: безопасная приемка сайта начинается не после разработки, а на этапе подготовки проекта. Если вы заранее не зафиксировали ТЗ, состав работ, интеграции, критерии приемки и передачу доступов, в конце почти всегда появятся сюрпризы.
Запуск сайта без внятного ТЗ и сценария приемки похож на подписание акта по квартире без проверки ключей, документов и счетчиков. Формально объект передан. По факту риски только начинаются.
Ниже собран единый флагманский чеклист: что должно входить в разработку сайта под ключ, как подготовить ТЗ, что проверить до запуска и какие пункты должны быть закрыты до подписания акта.
С чего начинается нормальный проект: ТЗ и границы работ
Слабый проект почти всегда стартует с фразы “сделаем современный сайт, потом разберемся по ходу”. Звучит удобно, но для бизнеса это ловушка. Без письменной фиксации объема работ невозможно честно сравнить сметы, проверить сроки и доказать, что подрядчик действительно взял на себя обещанный результат.
Минимальное ТЗ не обязано быть на 50 страниц. Но в нем должны быть цели проекта, страницы, структура блоков, ключевые сценарии пользователя, обязательные интеграции, требования к мобильной версии, базовому SEO, аналитике и передаче доступов. Также должны быть прописаны критерии приемки: как именно вы поймете, что форма работает, лид доходит, блог редактируется, а мультиязычность или каталог собраны корректно.
Если ТЗ не существует, в конце неизбежно возникнут фразы вроде “это не входило”, “мы поняли задачу иначе” и “это уже отдельная доработка”. Именно поэтому приемка начинается еще до разработки: с фиксации того, что вы вообще принимаете.
Что реально должно входить в разработку сайта под ключ
| Этап | Что должно быть на выходе | Зачем это бизнесу |
|---|---|---|
| Аналитика и структура | карта страниц, цели, оффер, сценарии, базовое ТЗ | чтобы проект не ушел в переделки после первого показа |
| Дизайн и прототип | экраны, состояния, адаптация под мобильные | чтобы заранее проверить логику и ожидания по интерфейсу |
| Разработка | страницы, формы, интеграции, аналитика, SEO-база | чтобы релиз был не “демкой”, а рабочим активом |
| QA и релиз | проверка сценариев, mobile QA, акт фиксации багов | чтобы не ловить критические сбои уже на трафике |
| Передача проекта | доступы, ownership, инструкции, резервные копии | чтобы сайт действительно принадлежал заказчику |
Если хотя бы один из этих блоков вынесен “за скобки”, проект нельзя считать полноценным “под ключ”. Это не значит, что такой формат всегда плох. Но это значит, что вы должны видеть, чего именно в нем нет, и не принимать неполную услугу за завершенный актив.
Как подготовить ТЗ без бюрократии, но с пользой
ТЗ нужно не для красоты и не для юриста. Его главная функция — синхронизировать ожидания. Хорошее ТЗ отвечает на вопросы: зачем нужен проект, какие страницы и сценарии обязательны, какие интеграции критичны, кто отвечает за контент, как выглядит успешный релиз и что вы проверяете на приемке.
Самый удобный формат для малого и среднего бизнеса — блоками. Для каждой ключевой задачи фиксируете: цель, URL или экран, пользовательский сценарий, ожидаемый результат, способ проверки. Например: “страница цен”, “пользователь оставляет телефон”, “лид приходит в CRM и на email”, “проверка через тестовую отправку и логи”. Уже этого достаточно, чтобы перевести проект из режима догадок в режим измеримых критериев.
Типовые ошибки в ТЗ всегда одинаковые: общие формулировки, отсутствие перечня интеграций, игнор мобильной версии, отсутствие требований к SEO и неописанный порядок правок после демо и после релиза. Именно из этих дыр потом вырастают перерасход, конфликт по срокам и спор о том, “доделан” сайт или нет.
Что проверить до запуска: не только дизайн, но и рабочие сценарии
Запуск сайта — это не публикация красивой страницы. Это момент, когда на проект может пойти трафик, а значит каждая ошибка уже стоит денег. До релиза нужно проверить не только визуальную часть, но и весь путь пользователя: открытие страницы, скорость первого экрана, работу форм, запись лидов, корректность мобильной версии, события аналитики, юридические документы и передачу доступов.
- Формы: тестовая отправка с реальным попаданием в CRM, почту или другой канал.
- Аналитика: фиксируются ключевые события, отправки и клики на целевые действия.
- SEO-база: title, description, H1, canonical, sitemap.xml, robots.txt, индексация ключевых URL.
- Мобильная версия: читабельность, кликабельность CTA, отсутствие критических сдвигов и багов.
- Ownership: домен, хостинг, репозиторий, аналитика и внешние сервисы оформлены корректно.
- Документы: политика, согласия и cookie-практика соответствуют реальной обработке данных.
Часть этих пунктов может казаться “технической мелочью”, пока не выясняется, что реклама уже запущена, а лиды не доходят, формы не сохраняют данные, robots.txt блокирует индексацию или документы в футере не соответствуют реальной обработке персональных данных.
Что должно быть в акте приемки
Акт приемки нужен не для того, чтобы просто закрыть проект. Он фиксирует, что именно было передано, какие баги закрыты, какие доступы получены и по каким критериям проект считается завершенным. Если в акте только общая фраза “работы выполнены”, он почти не защищает заказчика.
Минимум, который стоит фиксировать в акте:
- Список страниц, функций и интеграций, входивших в проект.
- Список переданных доступов: домен, хостинг, репозиторий, аналитика, CRM, почта.
- Факт прохождения тестовых сценариев: формы, уведомления, критические пользовательские пути.
- Список оставшихся некритичных правок, если они согласованы после релиза.
- Дата релиза, версия проекта и договоренность по пострелизной поддержке.
Этот блок особенно важен, если проект включает несколько подрядчиков, маркетинг, CRM или рекламу. Чем больше зависимостей, тем дороже обходится “устная приемка”.
7 ошибок, из-за которых бизнес принимает недоделанный сайт
- Подписывает акт до проверки форм и передачи лидов.
- Не забирает репозиторий, домен или доступы к хостингу.
- Не фиксирует, какие баги считаются критичными до релиза.
- Принимает проект без mobile QA.
- Не проверяет документы по ПДн и cookie-практику.
- Сравнивает сметы без единого ТЗ и потом удивляется разному объему работ.
- Путает демо-версию с завершенным активом.
Главный паттерн здесь один: бизнес принимает впечатление вместо результата. Чтобы этого не происходило, приемка должна быть привязана к сценариям, цифрам и переданным активам, а не к субъективному ощущению “ну вроде уже готово”.
Когда запуск лучше остановить, даже если сроки горят
Есть ситуации, когда пауза перед релизом полезнее, чем запуск “как есть”. Например: не передаются лиды, не оформлен ownership, нет финального ТЗ или акта, документы по персональным данным не совпадают с реальной логикой форм, а подрядчик обещает “доделать потом”. Для бизнеса это не мелкие недочеты. Это точки прямого риска: потеря лидов, юридические проблемы, конфликт по оплате и зависимость от подрядчика.
Даже если реклама уже куплена, иногда выгоднее сдвинуть запуск на несколько дней, чем потом потратить месяцы на переделку того, что изначально можно было принять правильно.
FAQ
Можно ли принимать сайт без репозитория?
Нет, если код и инфраструктура должны перейти заказчику. Без доступа к репозиторию вы не контролируете актив и зависите от подрядчика.
Можно ли обойтись без ТЗ, если проект небольшой?
Даже для небольшого проекта нужна хотя бы краткая письменная фиксация объема работ, интеграций и критериев приемки. Иначе спорить придется уже после релиза.
Что важнее на приемке: дизайн или рабочие сценарии?
Рабочие сценарии. Дизайн можно дорабатывать итеративно, а сломанные формы, ownership и неработающая аналитика бьют по бизнесу сразу после запуска.
Что обязательно должно входить в проект под ключ?
Как минимум: структура, дизайн, разработка, формы, базовое SEO, тестирование, релиз, передача доступов и ясный порядок поддержки после запуска.
Внутренние ссылки
Цены и этапы оплаты · Кейсы · Как выбрать подрядчика · 152-ФЗ для сайта
Schema и источники
Для статьи подходит связка HowTo + FAQPage + Article. Внешняя проверка обычно опирается на Google Search Central, web.dev и применимые требования по обработке персональных данных.
Нужен аудит ТЗ, запуска или финальной приемки перед оплатой подрядчику? Отправить проект на проверку.