Техническое задание на разработку сайта: структура, примеры и чек-лист

Что такое ТЗ — и почему шаблон на 40 страниц не гарантирует результат

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

Сильное ТЗ не заменяет прототип, дизайн и техническое проектирование. Оно связывает их: бизнес-цель превращается в пользовательские сценарии, сценарии — в страницы и данные, а затем — в критерии проверки. Для сложного продукта документ развивается после discovery, но изменения должны оставаться видимыми.

Что заказчик должен подготовить сам

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

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

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

Структура рабочего ТЗ на сайт

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

Писать сценарии, а не список кнопок

Фраза «добавить личный кабинет» не определяет объём. Кто входит: клиент, сотрудник или партнёр? Как создаётся учётная запись? Что делать при забытом пароле? Какие данные видит каждая роль? Можно ли удалить профиль и выгрузить данные? Что происходит при недоступности внешней системы? Ответы превращают название функции в продуктовый сценарий.

Используйте короткий шаблон: «Как [роль], я хочу [действие], чтобы [результат]». Затем добавьте предусловия, основной путь, исключения и критерии приёмки. Не все детали известны сразу — спорные места помечают вопросом и назначают владельца решения.

Как формулировать критерии приёмки

Критерий должен проверяться однозначно. Вместо «форма удобная» напишите: обязательные поля имеют видимые подписи, ошибки показываются рядом с полем, введённые корректные данные не исчезают, успешная отправка создаёт обращение в CRM и событие аналитики, повторная отправка не создаёт незаметные дубли.

Для производительности не ограничивайтесь словом «быстро». Укажите метод и среду измерения, перечень ключевых шаблонов и целевые показатели. Google описывает Core Web Vitals как реальные метрики загрузки, отзывчивости и стабильности; их удобно включить в контур наблюдения, но не использовать как единственную характеристику качества.

SEO, аналитика и доступность должны быть в ТЗ сразу

SEO-требования включают индексируемые шаблоны, управляемые title и description, один осмысленный H1, canonical, языковые связи, sitemap, robots, редиректы и сохранение ценных URL при замене сайта. Контентная команда должна знать, какие страницы и материалы нужны до разработки шаблонов.

Карта аналитики связывает бизнес-вопрос с событием: не просто «установить счётчик», а различать просмотр предложения, начало формы, ошибку, успешную заявку и квалификацию в CRM. Для доступности используйте WCAG 2.2 как ориентир: клавиатура, фокус, подписи, контраст, альтернативный текст и понятные ошибки проектируются вместе с интерфейсом.

Интеграции описываются через данные и ответственность

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

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

Безопасность и данные: минимум, который нельзя дописывать после релиза

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

OWASP ASVS даёт проверяемый набор требований к безопасности веб-приложений, а NIST SSDF — практики для жизненного цикла разработки. Не нужно механически включать все пункты. Выберите обоснованный уровень и зафиксируйте, какие проверки входят в приёмку.

Как управлять изменениями, не замораживая продукт

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

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

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

Пример из сложного продукта: требования начинаются с ролей

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

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

Чек-лист перед отправкой ТЗ подрядчикам

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

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