Техническое задание на сайт: как написать, чтобы вас поняли с первого раза

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

Краткая сводка обязательных требований

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

Цели проекта и измеримые бизнес-результаты

Кому подходит. Этот формат ТЗ полезен, если сайт влияет на лиды/продажи/обслуживание клиентов, есть несколько стейкхолдеров и планируется передача работ подрядчику (внутреннему или внешнему). Именно здесь чаще всего возникает запрос "тз на сайт образец", но "образец" должен быть привязан к вашим целям и ограничениям.

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

• Формулировка цели (пример). "Сайт должен увеличивать количество заявок на услугу X; успех - рост доли заявок из органики и из платного трафика при сохранении качества лидов".
• Граница проекта (пример). "В проект не входит: CRM, коллтрекинг и сквозная аналитика - только интеграция с существующими системами через API/вебхуки".

Целевая аудитория, сценарии использования и пользовательские потоки

Чтобы составить техническое задание на сайт без "провисаний", заранее соберите входные данные и доступы. Это уменьшает количество допущений и спорных решений.

• Материалы: текущая аналитика (если есть), список услуг/товаров, УТП и ограничения, бренд-гайд/тон оф войс, примеры конкурентов и референсы.
• Доступы: домен/хостинг или облако, текущая CMS/репозиторий, счётчики аналитики, рекламные кабинеты (только на чтение), документация по API интеграций.
• Роли и права: кто согласует контент, кто принимает разработку, кто отвечает за безопасность и доступность.

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

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

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

1. Задайте единый формат описания требований. Используйте одинаковые поля для всех функций: что делает, кто пользуется, входы/выходы, ошибки, критерии приёмки, приоритет. Это упрощает оценку и тестирование.
   • Пример формулировки. "Форма заявки: пользователь вводит имя, телефон и комментарий; при ошибке показывается сообщение под полем; при успехе - экран подтверждения и событие в аналитике".
2. Соберите функциональность по модулям. Разбейте сайт на логические блоки: контент (страницы), лидогенерация (формы), поиск/фильтры, личный кабинет, админка, интеграции, аналитика.
   • Пример. "Каталог: фильтры по параметрам, сортировка, карточка, сравнение (если нужно)".
3. Расставьте приоритеты Must/Should/Could. Приоритет - это не "важно/неважно", а правило для объёма первой версии и для компромиссов при сроках/бюджете.
   • Пример. Must: "форма заявки", Should: "онлайн-чат", Could: "калькулятор стоимости".
4. Опишите данные и поля (таблица). Для форм, сущностей и интеграций фиксируйте поля, формат, обязательность и приоритет. Это снижает риск "всё сделали, но данные не те".

   Имя поля	Формат	Обязательность	Приоритет
   name	строка, 2-100 символов	обязательно	Must
   phone	телефон (E.164 или маска по РФ), валидация	обязательно	Must
   email	email, валидация	опционально	Should
   comment	текст до заданного лимита	опционально	Could
   consent	логическое значение (согласие)	обязательно	Must

5. Сформулируйте критерии приёмки для каждой ключевой фичи. Пишите проверяемо: условия, ожидаемый результат, что считается ошибкой, что логируется/отправляется во внешние системы.
   • Пример формулировки. "Если телефон не проходит валидацию, отправка не происходит, поле подсвечено, текст ошибки отображается, событие ошибки фиксируется в логах".
6. Приложите "тз на сайт образец" в виде шаблонов страниц. Для главной/категории/карточки/контактов/лендинга перечислите блоки, источники контента, состояния (пусто/ошибка/нет результатов).
   • Пример. "Шаблон карточки услуги: заголовок, преимущества, цена/тарифы, FAQ по услуге, форма заявки, блок доверия (кейсы/отзывы), контакты".

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

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

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

Проверяйте, что ТЗ не оставляет "дыр" в эксплуатации. Используйте чек-лист как минимум для Must-функций и критичных страниц.

• Производительность: описаны целевые показатели и метод проверки (что измеряем, где, на каких страницах).
• Надёжность: что происходит при недоступности интеграции (ретраи, очередь, сообщение пользователю).
• Безопасность: роли и права в админке; требования к паролям/сессиям, защита форм, ограничения по попыткам.
• Персональные данные: какие данные собираются, где хранятся, кто имеет доступ, где отображается согласие и политика.
• Логи и аудит: какие события пишутся, какие ошибки должны попадать в мониторинг, сроки хранения.
• Доступность: базовые требования к навигации с клавиатуры, альтернативным текстам, контрасту и фокус-состояниям.
• Совместимость: список поддерживаемых браузеров/устройств и поведение на малых экранах.
• SEO/индексация: правила для мета-данных, человекопонятных URL, редиректов и страниц 404/410.

Архитектура контента, карты страниц и шаблоны

Чаще всего ТЗ "ломается" не на разработке, а на контенте: неизвестно, кто пишет тексты, какие поля нужны, что будет в карточках и откуда это берётся.

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

Технические ограничения, интеграции, стек и критерии приёмки

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

Что обязательно зафиксировать

• Стек и версии: CMS/фреймворк, версия PHP/Node.js, версия БД, веб-сервер, окружение (dev/stage/prod).
• Интеграции: какие системы подключаем, тип (API/вебхуки/файлы), кто выдаёт ключи, лимиты, форматы, обработка ошибок.
• Контакт ответственного: ФИО/роль, канал связи, часы доступности, кто принимает решения при конфликте требований.
• Критерии приёмки (общие): как сдаётся работа, где смотреть, какие тесты обязательны, что считается блокером релиза.

Критерии приёмки (чек-лист для релиза)

• Все Must-функции реализованы и покрыты проверяемыми сценариями (описаны входы, шаги, ожидаемый результат).
• Формы: валидация, сообщения об ошибках, защита от спама, корректная отправка в нужные системы.
• Интеграции: тестовые ключи, обработка таймаутов/ошибок, логирование, повторные попытки где уместно.
• Контент: заполнены обязательные поля, нет заглушек, корректно работают шаблоны и состояния "пусто/ошибка".
• Редиректы и 404: правила настроены, критичные URL не ведут на ошибки.
• Доступы: переданы доступы и инструкции, роли в админке соответствуют требованиям.
• Сборка/деплой: описан процесс выкладки, откат, точки контроля.

Выбор подхода: когда какой вариант уместен

Подход	Когда выбирать	Риски	Что обязательно добавить в ТЗ
CMS (типовой сайт на готовой теме/конструкторе)	Нужен быстрый запуск, стандартные страницы и формы, минимум интеграций	Ограничения кастомизации, зависимость от плагинов	Список плагинов/модулей, ограничения темы, правила обновлений
Кастомная разработка (фреймворк)	Сложные роли, нестандартные процессы, высокая нагрузка, много интеграций	Дольше и дороже, нужен технадзор и дисциплина требований	API-контракты, NFR, логирование, SLA/мониторинг, план релизов
Headless (CMS + фронтенд отдельно)	Несколько витрин/каналов, контент переиспользуется, нужен гибкий фронтенд	Сложнее эксплуатация, больше точек отказа	Схема данных, кэширование, контентные модели, требования к API

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

Типовые вопросы возникающие при составлении ТЗ

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

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

Можно ли использовать тз на сайт образец и просто заменить названия?

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

Что обязательно включить, если нужно составить техническое задание на сайт под тендер?

Добавьте приоритеты Must/Should/Could, единый формат полей и общий чек-лист приёмки. Тогда разные подрядчики посчитают сопоставимый объём.

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

Когда много стейкхолдеров, интеграций, ролей, или есть риск переработок из‑за неясных требований. Отдельная аналитика снижает "разночтения" между бизнесом, дизайном и разработкой.

Как корректно обсуждать "техническое задание на создание сайта цена", если объём ещё плавает?

Фиксируйте цену на базовый объём Must и отдельно оценивайте Should/Could как опции. Дополнительно согласуйте процесс change request: как считаются изменения и кто их утверждает.

Кто должен быть ответственным за ТЗ и правки?

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