Техническое задание на сайт: структура, требования и критерии приёмки

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

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

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

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

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

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

Определите, кто готовит тексты, фотографии, юридические страницы и переводы. Укажите обязательные title, description, заголовки, канонические адреса и правила формирования sitemap.

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

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

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

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

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

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

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

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

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

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

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

Тестирование должно охватывать не только привлекательный снимок главной. Составьте сквозные сценарии: найти услугу, отправить заявку, получить запись в CRM, открыть письмо подтверждения; для магазина — оформить заказ и корректно обработать отказ платежа. Укажите окружение и тестовые данные, чтобы процедуру можно было повторить.

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

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

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

Слабое требование звучит так: «Форма должна быть современной и удобной». Оно не определяет ни поведение, ни качество. Более полезная формулировка: «На странице услуги посетитель может отправить имя, контакт и текст задачи; система проверяет обязательные поля, не теряет введённые данные при ошибке сети и показывает подтверждение только после успешной записи на сервер».

К этому требованию добавляют состояния интерфейса, текст ошибок, способ защиты от спама и правила доступа к сохранённым данным. Указывают, кто получает уведомление и как выполняется тестовая отправка. Команда дизайна видит нужные экраны, разработчик — контракт поведения, заказчик — конкретный критерий приёмки.

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

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

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

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