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

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

Готовые формулировки, которые экономят недели

• "Успех проекта измеряется: пользователь выполняет ключевой сценарий без обращения в поддержку; метрики и способ измерения указаны в разделе "Цели и метрики"."
• "Каждая функция описывается как: роль → действие → результат → сообщения об ошибках → данные → права доступа."
• "Все интеграции перечислены с ответственными сторонами: кто выдаёт доступы, кто оплачивает, кто поддерживает после запуска."
• "Приёмка проходит по тестовым сценариям из ТЗ; если сценарий проходит - работа считается выполненной."
• "Любая "автоматика" (уведомления, статусы, задачи) считается реализованной только при описанных триггерах, шаблонах сообщений и логировании."

Цели проекта и измеримые метрики успеха

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

Пример формулировки: "Цель сайта - поддержать продажи/обращения: пользователь должен иметь возможность выбрать услугу, оставить заявку и получить подтверждение; команда должна видеть заявки в административной части и выгружать их в CRM."

Что фиксируем	Плохая формулировка	Рабочая формулировка (проверяемая)	Как проверяем
Цель	"Сделать современный сайт"	"Сайт обеспечивает: каталог услуг → карточка → заявка → подтверждение → запись в CRM"	Прогон сценария от выбора до записи в CRM
Результат для бизнеса	"Увеличить продажи"	"Сократить время обработки обращения: заявка сразу попадает в CRM и содержит обязательные поля"	Проверка состава данных и маршрута
Границы проекта	"Сделать всё под ключ"	"В проект не входят: разработка брендбука, настройка рекламных кампаний, наполнение контентом сверх N страниц (указать)"	Сопоставление с перечнем работ

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

Когда НЕ стоит делать "толстое" ТЗ: если вы тестируете гипотезу на одной странице без интеграций - достаточно короткого "техническое задание на сайт пример" на 1-2 страницы с критериями приёмки.

Описание целевых пользователей и ключевые сценарии

Цель блока: чтобы дизайнер, фронтенд и бэкенд делали одно и то же "для кого" и "зачем", а не спорили о вкусе.

Что понадобится заранее (доступы/материалы):

• Доступ к текущей аналитике (если есть): Метрика/GA, CRM-воронка, логи обращений.
• Список продуктов/услуг и ограничения: регионы, цены, правила доставки/оказания.
• Контент и источники: тексты, фото, документы, ответственный за согласование.
• Доступы к интеграциям: CRM, платёжный провайдер, почта/SMTP, SMS, чат, 1С/ERP (если есть).
• Ограничения по инфраструктуре: хостинг/сервер, домен, SSL, корпоративные политики безопасности.

Пример формулировки сценариев:

• "Пользователь "Новый клиент" заходит с мобильного, изучает услугу, оставляет заявку; обязательные поля: имя, телефон, согласие; после отправки видит номер заявки и получает письмо."
• "Пользователь "Менеджер" в админке видит список заявок, фильтрует по источнику, меняет статус, делает экспорт в CSV."

Персона	Задача	Критичность	Замечания к реализации
Новый клиент	Найти услугу и оставить заявку	Must	Мобильный сценарий приоритетен; минимум шагов
Повторный клиент	Быстро повторить обращение	Should	Автоподстановка данных при авторизации/по ссылке
Менеджер	Обработать заявки и выгрузить	Must	Роли и права; аудит изменений статуса

Функциональные требования: шаблоны формулировок

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

1. Соберите список страниц/разделов как карту сайта

   Перечислите разделы и типы страниц, а не дизайн. Для каждого типа страницы укажите назначение и обязательные блоки.

   • Шаблон: "Тип страницы: Карточка услуги. Обязательные блоки: заголовок, описание, цена (если есть), FAQ по услуге, форма заявки, контакты."
2. Опишите каждую функцию через "роль → действие → результат"

   Так подрядчик не придумает поведение сам. Обязательно добавьте состояния успеха/ошибки и куда уходят данные.

   • Шаблон: "Роль: Гость. Действие: отправляет форму. Результат: создаётся заявка со статусом "Новая", отправляется уведомление менеджеру и письмо клиенту."
3. Задайте поля форм и правила валидации

   Фиксируйте обязательность, формат, ограничения длины, подсказки, тексты ошибок. Это критично для приёмки.

   • Шаблон: "Поле "Телефон" - обязательное, формат: +7XXXXXXXXXX, маска ввода, сообщение об ошибке: "Введите номер в формате +7..."."
4. Определите роли, права и административные операции

   Перечислите роли (админ, менеджер, редактор), что они могут делать, какие данные видеть, какие действия логируются.

   • Шаблон: "Роль "Менеджер" видит заявки своего отдела, может менять статус, оставлять комментарий; удаление запрещено; изменения статуса записываются в журнал."
5. Зафиксируйте уведомления и шаблоны сообщений

   Укажите триггеры, каналы (email/SMS/мессенджер), получателей, темы и минимальный состав текста.

   • Шаблон: "При создании заявки отправить email клиенту: тема "Заявка принята", текст содержит номер, контакты, время ответа."
6. Пропишите интеграции как контракты данных

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

   • Шаблон: "Интеграция с CRM: при создании заявки отправлять поля name, phone, source, page_url; при ошибке - запись в лог и уведомление на почту техподдержки."
7. Опишите контент-операции: кто и как наполняет

   Решите, что наполняет заказчик, что - подрядчик, и какие инструменты нужны (редактор, шаблоны, импорт).

   • Шаблон: "Контент вводит редактор через админку; нужен импорт услуг из CSV по шаблону; изображения автоматически ресайзятся."

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

1. Запишите 3-5 ключевых сценариев (кто, что делает, какой результат) и объявите их основой приёмки.
2. Составьте карту сайта: типы страниц + обязательные блоки на каждом типе.
3. Для всех форм: поля, валидация, тексты ошибок, куда уходит заявка.
4. Список интеграций: что передаём, как, кто выдаёт доступы, что делать при ошибках.
5. Критерии готовности: чек-лист нефункциональных требований и список тестовых сценариев.

Зона ТЗ	Что написать (короткий шаблон)	Приоритет	Что чаще всего забывают
Форма заявки	"Поля/валидация/ошибки/успех/куда уходит"	Must	Тексты ошибок и повторная отправка
Личный кабинет	"Роли/права/сущности/операции/журнал"	Should	Логи и права на экспорт
Интеграции	"События/поля/API/ошибки/ответственные"	Must	Кто даёт доступы и тестовый контур

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

Цель блока: договориться о качестве и рисках до разработки, а не после. Используйте чек-лист как критерии проверки результата.

• Производительность: в ТЗ указано, какие страницы считаются "критичными" и как именно вы проверяете скорость (инструмент/условия/устройства).
• Нагрузка: описаны ожидаемые пиковые сценарии (что одновременно делают пользователи) и что считается деградацией.
• Безопасность: определены требования к паролям/сессиям, ограничению попыток входа и хранению секретов (ключи не в коде/репозитории).
• Доступность: описаны минимальные требования к контрасту, фокусу клавиатуры и текстовым альтернативам изображений.
• Логи и аудит: зафиксировано, какие действия пишутся в журнал (логин, смена прав, экспорт, удаление) и кто имеет доступ.
• Резервные копии: определено, что бэкапится (БД/файлы), как проверяется восстановление и кто отвечает.
• Ошибки: есть требования к страницам 404/500, обработке недоступности внешних сервисов и пользовательским сообщениям.
• Правовые требования: описано, где размещаются политики/согласия и как фиксируется факт согласия (с датой/версией).

Архитектура, интеграции и ограничения реализации

Цель блока: снизить переделки из-за "не договорились про технологию/границы". Это особенно важно, если вы планируете заказать техническое задание на сайт у аналитика или студии и хотите проверяемую структуру.

• Не определяют "источник истины" для данных: где главный статус заявки - на сайте или в CRM.
• Путают среды: нет разделения dev/stage/prod и правил, что можно тестировать на проде (обычно - нельзя).
• Не описывают миграции: что делаем со старым контентом/URL/редиректами/SEO-структурой.
• Забывают про права доступа к внешним сервисам и кто их выдаёт (и когда).
• Не фиксируют формат обмена (поля, кодировки, справочники) - интеграция превращается в "передайте как-нибудь".
• Не описывают ограничения по CMS/фреймворку/хостингу - потом выясняется, что нужная функция невозможна без смены платформы.
• Нет стратегии ошибок интеграций: ретраи, очередь, ручная обработка, уведомления.
• Слишком общие требования к админке: не перечислены фильтры, статусы, экспорт, массовые операции.
• Не определяют, кто и как обновляет зависимости/плагины и что считается поддержкой после релиза.

Подход к интеграциям	Когда уместен	Плюсы	Риски/что прописать в ТЗ
API (онлайн)	Нужно "сразу" в CRM/ERP	Быстрая синхронизация	Лимиты, ошибки, ретраи, таймауты, логирование
Вебхуки	Событийная модель, минимум опросов	Просто масштабировать события	Подпись/проверка запросов, повторная доставка, идемпотентность
Файловый обмен (CSV)	Слабое/закрытое API, ручные процессы	Дешево и быстро стартовать	Формат, кодировка, расписание, валидация, обработка дублей

Критерии приёмки, тестовые сценарии и чек-листы

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

• Вариант A: приёмка по сценариям (рекомендуется почти всегда). Уместно, когда есть формы, личный кабинет, интеграции. В ТЗ фиксируете 10-30 сценариев и принимаете по их прохождению.
• Вариант B: приёмка по User Story + Definition of Done. Уместно для итеративной разработки, когда требования уточняются в процессе. В ТЗ закрепляете формат истории, критерии, требования к тестам и демо.
• Вариант C: приёмка по прототипам экранов. Уместно для контентных сайтов без сложной логики. В ТЗ фиксируете прототипы и поведение компонентов, плюс минимальный список сценариев для форм.
• Вариант D: приёмка по спецификации API (если сайт - часть системы). Уместно при плотных интеграциях. В ТЗ описываете контракты, примеры запросов/ответов и коды ошибок.

Мини-шаблон тестового сценария (вставляйте в ТЗ): "Предусловия → Шаги → Ожидаемый результат → Данные (тестовые) → Примечания (интеграции/логи)".

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

Типичные сомнения подрядчиков и короткие ответы

Нужен ли большой документ, если есть "тз на сайт образец" из интернета?

Нужна структура и проверяемость, а не объём. Используйте образец как форму, но наполняйте его вашими сценариями, интеграциями и критериями приёмки.

Что писать в ТЗ, если дизайн ещё не готов?

Пишите сценарии, блоки на типах страниц, состав данных и поведение форм/состояний. Визуальные решения можно вынести в прототипы и UI-kit как приложение.

Как правильно сформулировать требования, чтобы их можно было оценить по срокам?

Формулируйте через "роль → действие → результат", плюс поля, ошибки, права и интеграции. Это превращает "пожелание" в задачный объём, пригодный для оценки.

Чем отличается "техническое задание на сайт пример" от ТЗ, по которому реально разрабатывать?

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

Можно ли составить ТЗ на сайт без аналитика?

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

Когда имеет смысл заказать техническое задание на сайт отдельно от разработки?

Когда вы выбираете подрядчика по понятному объёму работ или хотите сравнить оценки разных команд. Отдельное ТЗ снижает риск "дешево в смете - дорого в изменениях".

Что делать, если заказчик постоянно меняет требования?

Зафиксируйте базовую версию ТЗ и введите порядок изменений: заявка на изменение → оценка влияния → согласование сроков/стоимости → внесение в документ.