Техническое задание на сайт: что написать до оценки и как принять результат

В первом абзаце опишите, зачем бизнесу сайт сейчас. Например: «Посетитель должен сравнить три услуги, выбрать подходящую и оставить заявку; менеджер должен увидеть услугу и источник обращения в CRM». Такая формулировка даёт команде проверяемый результат. Фраза «нужен современный сайт» не объясняет, что именно должно измениться.

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

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

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

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

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

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

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

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

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

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