Техническое задание на сайт: что в него включить

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

Зачем нужно ТЗ и чем оно отличается от брифа

Бриф собирает пожелания и информацию о бизнесе. ТЗ превращает их в проверяемые требования. Разница видна по формулировкам: «сайт должен быть современным и удобным» — это бриф. «Страница услуги содержит описание, форму заявки с тремя полями, блок вопросов и ответов и отображается корректно на экранах от 360 пикселей по ширине» — это ТЗ.

Документ нужен, чтобы:

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

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

Раздел первый: цели, аудитория и сценарии

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

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

Решите вместе, нужен ли вам одностраничный сайт или несколько разделов. Эта дилемма разобрана в статье лендинг или корпоративный сайт.

Раздел второй: структура и содержание страниц

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

Пример краткого описания для страницы услуги:

Страница услуги
- Заголовок H1 с названием услуги
- Краткое описание (2-3 предложения), что получает клиент
- Блок "Для кого" и "Что входит"
- Этапы работы
- Вопросы и ответы
- Форма заявки: имя, телефон, комментарий
- Ссылки на связанные услуги и статьи

Обязательно уточните:

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

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

Раздел третий: функции, формы и интеграции

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

Формы. Какие поля обязательны, как проверяются данные, что видит пользователь после отправки, куда приходит заявка (почта, мессенджер, CRM, 1С). Какая защита от спама: скрытое поле, проверка на стороне сервера, ограничение частоты отправки.

Каталог и поиск, если они нужны: поля карточки товара, фильтры, сортировки.

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

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

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

Админ-панель: какие разделы сайта можно редактировать без разработчика, какие роли пользователей существуют и что им доступно.

Чем конкретнее этот раздел, тем меньше расхождений при приёмке.

Раздел четвёртый: нефункциональные требования

Эти требования часто забывают, а потом спорят. Укажите:

• Скорость. Ориентиры по показателям загрузки, например по метрикам Core Web Vitals, и инструмент, которым вы будете их проверять.
• Адаптивность. Диапазон экранов, браузеры и их версии, которые должны поддерживаться.
• Безопасность. Обязательное HTTPS, защита форм, хранение паролей в виде хэшей, защитные заголовки, журналирование действий в админ-панели, порядок обновлений.
• Доступность. Контраст, возможность работы с клавиатуры, подписи к изображениям.
• Совместимость с поиском. Файлы robots.txt и sitemap.xml, канонические адреса, корректные коды ответа, микроразметка.
• Размещение. Хостинг, окружения (тестовое и боевое), порядок развёртывания и обновления.
• Нагрузка. Ожидаемое число посетителей в условных единицах, например «до нескольких сотен посетителей в день на старте», если это известно.

Такие пункты полезно привязывать к способу проверки: как именно вы убедитесь, что требование выполнено.

Раздел пятый: порядок работ, приёмка и передача

Это раздел, который превращает ТЗ из описания в рабочий инструмент.

1. Этапы. Дизайн, вёрстка, программирование, наполнение, тестирование, запуск. Для каждого свои результаты и срок.
2. Что требуется от заказчика. Материалы, доступы, согласования, с указанием сроков ответа.
3. Правки. Сколько раундов правок включено и как оформляются дополнительные.
4. Приёмка. Критерии: проход по сценариям из ТЗ, проверка на указанных устройствах, замечания фиксируются в списке и исправляются в оговорённые сроки.
5. Передача. Исходный код, доступы, документация по администрированию, регистрация домена и хостинга на заказчика.
6. Гарантия и сопровождение. Что подрядчик исправляет бесплатно в течение определённого периода и на каких условиях идёт дальнейшая поддержка.

Договорную часть и вопросы передачи прав обсуждайте с юристом, а ТЗ используйте как приложение к договору.

Типичные ошибки при составлении ТЗ

• Абстрактные прилагательные вместо измеримых требований.
• Отсутствие описания исключений: что при пустом поиске, при ошибке оплаты, при недоступности внешней системы.
• Смешение того, что нужно (задача), с тем, как это делать (технология), без причин.
• Копирование чужого ТЗ без адаптации.
• Нет владельца документа на стороне заказчика, который отвечает за согласование.
• Отсутствие приоритетов: что обязательно к запуску, а что можно сделать позже.

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

Пример короткого ТЗ на практике

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

1. Цели и показатели
2. Аудитория и сценарии
3. Карта сайта и состав страниц
4. Функции: формы, каталог, оплата, личный кабинет
5. Интеграции и обмен данными
6. Нефункциональные требования
7. Админ-панель и роли
8. Этапы, сроки, обязанности сторон
9. Порядок приёмки и передачи
10. Приложения: макеты, список материалов, глоссарий

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

Как согласовывать и обновлять ТЗ

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

Частые вопросы

Может ли ТЗ составить сам заказчик?

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

Насколько подробным должно быть ТЗ?

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

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

Это нормальная ситуация. Изменения фиксируются письменно с оценкой влияния на срок и стоимость и только после согласования вносятся в ТЗ. Тогда документ остаётся актуальным.

Нужен ли отдельный документ на дизайн?

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

Если вам нужно составить такое задание или оценить уже готовое, посмотрите страницу про создание сайтов или напишите мне в Telegram.