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

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

Краткая суть проекта

• Фиксируйте цель и измеримый результат: что изменится после запуска (лиды, продажи, заявки, записи).
• Опишите аудитории и их задачи, иначе функции будут спорить с контентом и дизайном.
• Разделяйте требования на Must/Should/Could и закрепляйте критерии приёмки.
• Сценарии пользователя важнее перечня страниц: они показывают, что реально должно работать.
• Нефункциональные требования (безопасность/доступность/производительность) должны быть проверяемыми.
• Интеграции, доступы и ограничения хостинга - частая причина срывов сроков, пропишите заранее.

Цели проекта и целевая аудитория

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

Когда подходит

• Есть понятный результат запуска (например, заявки, регистрации, бронирования) и владелец продукта, который принимает решения.
• Нужно синхронизировать ожидания: заказчик, дизайнер, разработчик, контент, SEO, интеграторы.

Когда лучше не писать "толстое" ТЗ

• Проект в discovery/прототипировании: вместо полного ТЗ уместнее короткий бриф + прототипы + backlog.
• Нет согласованной цели и ответственного: документ не спасёт, пока не определён владелец требований.

Мини-шаблон формулировок (вставка)

• Цель: "Сайт должен обеспечивать получение заявок на услугу X через формы Y и звонки; основное действие - отправка заявки".
• Аудитории: "Аудитория A - выбирает по цене/срокам; аудитория B - по кейсам/экспертизе. Для каждой - отдельный путь к целевому действию".
• Границы проекта: "В рамках этапа 1 не делаем личный кабинет и оплату; предусмотрим возможность расширения без переделки ядра".

Функциональные требования и пользовательские сценарии

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

Что подготовить заранее (доступы, материалы, ограничения)

• Домен/регистратор, хостинг/сервер (или требования к ним), доступы к DNS.
• Счётчики и аналитика (например, аккаунт системы аналитики, цели/события), требования к cookie-баннеру при необходимости.
• Контент-источники: текущий сайт, презентации, прайсы, фото/видео, брендбук, тональность.
• Интеграции: CRM, рассылки, телефония, платёжные системы, карты, виджеты, SSO.
• Ограничения: сроки, бюджетные рамки, обязательные технологии/политики ИБ.

Сценарии (формат для ТЗ)

1. Сценарий "Заявка": "Пользователь открывает страницу услуги, нажимает "Оставить заявку", заполняет имя/телефон, подтверждает согласие, получает сообщение об успехе; заявка уходит в CRM и на почту".
2. Сценарий "Поиск и фильтр": "Пользователь вводит запрос, применяет фильтры, видит количество результатов, может сбросить фильтры; при отсутствии результатов показывается подсказка и альтернативы".
3. Сценарий "Админка/контент": "Контент-менеджер создаёт страницу по шаблону, заполняет SEO-поля, добавляет изображения с alt, публикует и откатывает версию при необходимости".

Таблица приоритизации и критериев приёмки

Область	Требование (пример формулировки)	Приоритет	Критерий приёмки (как проверяем)
Форма заявки	"Форма содержит поля: Имя, Телефон, Комментарий; обязательные поля валидируются; согласие на обработку данных обязательно"	Must	"При пустом телефоне отправка невозможна; при успешной отправке создаётся лид в CRM и отображается экран успеха"
Поиск	"Поиск работает по заголовкам и тексту; поддерживает опечатки на уровне UI (подсказки/варианты)"	Should	"По запросу из тестового набора выдаются ожидаемые страницы; при нуле результатов показывается блок с рекомендациями"
Админка	"Редактор может менять контент без разработчика: тексты, изображения, блоки на страницах по шаблонам"	Must	"Пользователь с ролью "Редактор" создаёт/редактирует страницы, не имея доступа к настройкам и коду"
Интеграция CRM	"Заявки отправляются в CRM с UTM-метками и источником; при ошибке - ретраи и логирование"	Must	"В CRM видно: дата, страница-источник, UTM, телефон; при отключении CRM запись попадает в очередь/лог"

Нефункциональные требования: производительность, безопасность и доступность

Этот блок делает техническое задание на сайт пример пригодным для приёмки: требования становятся измеримыми и проверяемыми. Ниже - безопасные шаги, которые можно повторить на любом проекте.

1. Зафиксируйте модель угроз и данные, которые обрабатывает сайт

   Определите, какие персональные данные собираются (например, телефон, e-mail), где они хранятся и кто имеет доступ. Это влияет на логи, формы, доступы и интеграции.

   • Пример: "Сайт не хранит платёжные данные; персональные данные из форм передаются в CRM и не сохраняются в открытом виде в логах".
2. Опишите требования к доступам, ролям и журналированию

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

   • Пример: "Доступ в админку только по персональным учётным записям; запрещены общие логины; действия администраторов логируются".
3. Задайте требования к защите и обновлениям

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

   • Пример: "Резервные копии выполняются по расписанию; предусмотрен сценарий восстановления на тестовом стенде".
4. Установите критерии производительности и ограничения по контенту

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

   • Пример: "Изображения загружаются в web-форматах; для геро-блоков установлен лимит веса; включены кэширование и сжатие".
5. Добавьте базовые требования доступности

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

   • Пример: "Все интерактивные элементы доступны с клавиатуры; обязательные поля форм имеют понятные сообщения об ошибках".

Быстрый режим

1. Соберите входные данные: цели, аудитории, список интеграций, ограничения и материалы.
2. Опишите 3-7 сценариев: лидогенерация, поиск/каталог, контент-редактирование, регистрация (если нужна).
3. Разбейте требования по Must/Should/Could: сразу добавьте критерии приёмки к Must.
4. Закройте риски: доступы/роли, бэкапы, защита форм, правила обновлений, ограничения контента.
5. Согласуйте карту сайта и приоритеты: подтверждение от стейкхолдеров в одном месте (комментарий/протокол).

Информационная архитектура, карта сайта и приоритизация контента

Проверяйте результат через карту сайта и приоритет контента на ключевых страницах. Это быстрый способ понять, готово ли ТЗ к дизайну/разработке или ещё "плавают" смыслы.

• На каждую ключевую аудиторию есть отдельный вход (страница/раздел/посадочная) и понятный путь к целевому действию.
• Карта сайта фиксирует типы страниц (шаблоны), а не только список URL: "услуга", "категория", "карточка", "статья", "контакты".
• Для каждого шаблона задан состав блоков и контент-ответственный (кто предоставляет текст/фото/кейсы).
• Есть правила навигации: меню, хлебные крошки, перелинковка, поиск (если нужен).
• Определены "обязательные" и "опциональные" блоки страницы, чтобы не спорить на верстке.
• Для форм и CTA указаны места размещения и тексты (микрокопирайт), включая сообщения об ошибках.
• SEO-минимум описан: шаблоны title/description, ЧПУ, мета-данные для карточек, индексирование служебных страниц.
• Учтены юридические страницы и элементы: политика, согласия, контакты, реквизиты (если применимо).

Технические спецификации: стек, интеграции, API и хостинг

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

1. Не указан контур окружений: нет разделения на dev/stage/prod и правил переноса изменений.
2. Не зафиксированы доступы: кто даёт доступ к DNS/хостингу/CRM и в какие сроки; нет ответственных.
3. Интеграции описаны словами без протокола: не указаны методы API, форматы, поля, вебхуки, обработка ошибок.
4. Не определены ограничения хостинга: версии ПО, лимиты, требования к почте (SMTP), SSL, бэкапы.
5. Отсутствует политика секретов: ключи API в коде/репозитории, нет ротации и разграничения окружений.
6. Не описан импорт/миграция: откуда берём данные, как сопоставляем поля, кто отвечает за качество.
7. Не зафиксированы требования к логированию: нет формата логов, сроков хранения, доступа и маскирования данных.
8. Не оговорены требования к письмам/уведомлениям: шаблоны, отправители, SPF/DKIM, антиспам-риски.

Примеры формулировок (вставка)

• Интеграция: "Отправка лидов в CRM выполняется через API; при недоступности CRM запросы ставятся в очередь и повторяются, ошибки фиксируются в логах без персональных данных".
• Хостинг: "На проде включён SSL; настроено автоматическое продление сертификата; доступ по SSH выдаётся только ответственным лицам".
• Почта: "Письма отправляются через SMTP/транзакционный сервис; шаблоны писем согласуются; сообщения об ошибке отправки логируются".

Готовые формулировки требований и шаблоны для быстрой вставки

Выберите формат документа под ситуацию. Если нужен тз на сайт образец, берите вариант 1; если проект сложнее - вариант 2 или 3. Везде оставляйте критерии приёмки рядом с требованиями, чтобы "техническое задание на сайт пример" сразу превращалось в чек-лист тестирования.

Вариант 1: Одностраничное ТЗ (для лендинга/простого корпоративного)

• Уместно: 1-3 ключевых сценария, минимум интеграций.
• Шаблон: "Цель → аудитории → сценарии → структура страниц → формы/интеграции → критерии приёмки Must".
• Формулировка: "Сайт содержит страницы: Главная, Услуги, Кейсы, Контакты; основная конверсия - форма заявки с отправкой в CRM".

Вариант 2: ТЗ + прототипы (самый практичный формат)

• Уместно: когда много нюансов по блокам, формам, состояниям интерфейса.
• Шаблон: "ТЗ фиксирует правила и требования, прототипы показывают экраны и состояния (ошибки/пустые результаты/успех)".
• Формулировка: "Состав блоков и приоритеты контента на страницах описаны в прототипах; в ТЗ приведены критерии приёмки и нефункциональные требования".

Вариант 3: Backlog требований (для итеративной разработки)

• Уместно: продуктовая разработка, несколько релизов, постоянные изменения.
• Шаблон: "Epic → User Story → Acceptance Criteria; отдельные политики: безопасность, доступы, обновления, контент-ограничения".
• Формулировка: "Каждая история содержит критерии приёмки в формате проверяемых условий; приоритет задаётся Must/Should/Could".

Вариант 4: Заказное ТЗ у специалиста (когда стоит делегировать)

• Уместно: много интеграций/сложная админка/несколько стейкхолдеров/нет времени на детализацию.
• Как формулировать запрос: "Нужно заказать техническое задание на сайт с описанием сценариев, критериев приёмки и нефункциональных требований; входные данные: цели, аудитории, список интеграций, ограничения".
• Граница ответственности: "Согласование требований и финальная приёмка - на стороне владельца продукта; исполнитель готовит структуру, формулировки и артефакты".

Частые затруднения и готовые решения

Какой объём ТЗ считается достаточным?

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

Как описывать дизайн в ТЗ, чтобы не задушить креатив?

Фиксируйте ограничения (бренд, сетка, адаптив, состояния UI) и примеры референсов, а не "рисуйте" пиксели текстом. Детали интерфейса лучше задавать прототипами.

Что делать, если требования меняются в процессе?

Введите версионирование: дата, автор правки, что изменилось и почему, что влияет на сроки/стоимость. Новые требования добавляйте как Should/Could до согласования.

Как не забыть нефункциональные требования?

Используйте шаги из раздела про производительность, безопасность и доступность и добавляйте критерии проверки. Если требование нельзя проверить - переформулируйте.

Нужно ли включать SEO в ТЗ?

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

Как принять работу по ТЗ, если вы не технарь?

Принимайте по сценариям и критериям: "действие → ожидаемый результат → куда ушли данные". Для интеграций требуйте демонстрацию на тестовых лидах и выгрузку логов без персональных данных.

Можно ли использовать готовый шаблон, если нужен "техническое задание на сайт пример"?

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