Техническое задание на сайт: что в нём должно быть обязательно

Разбор от команды разработки AmSales.

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

Зачем вообще нужно ТЗ, а не «созвон и погнали»

ТЗ решает три задачи: фиксирует объём (что входит в проект, а что нет), даёт основу для приёмки (по каким критериям работа считается сделанной) и защищает обе стороны, когда всплывает «а мы думали, это тоже входит». Без документа границы проекта плавают, и в итоге проигрывают все: подрядчик делает бесплатно, заказчик получает срыв сроков.

Отдельно проговорим: ТЗ — это не дизайн-макет и не прототип. Это описание того, что система должна делать. Макеты и прототипы — приложения к нему, а не замена.

Обязательные разделы ТЗ

1. Цели и метрики

Сайт делается не «чтобы был», а под задачу: собирать заявки, продавать онлайн, разгружать поддержку. Пропишите измеримую цель — например, приём заявок с формы в CRM и рост доли онлайн-заказов. Без этого невозможно принимать решения о приоритетах: любой спорный вопрос сверяется с целью.

2. Структура сайта и список страниц

Полная карта: все страницы и шаблоны (главная, каталог, карточка товара, статья, посадочная). Важно различать уникальные страницы и шаблоны: «карточка товара» — это один шаблон на тысячу товаров, а не тысяча страниц. Здесь же — что попадает в меню, футер, хлебные крошки.

3. Функциональные требования по каждому блоку

Самый важный и самый недооценённый раздел. По каждой функции описывается поведение, а не только внешний вид. Форма заявки — это не «поле имя, поле телефон, кнопка». Это: какие поля обязательны, какая валидация, куда уходят данные (почта, CRM, мессенджер), что видит пользователь после отправки, что происходит при ошибке, есть ли защита от спама. Чек-лист на каждую нетривиальную функцию:

• Что на входе — какие данные вводит пользователь и в каком формате.
• Что на выходе — куда уходит результат и в каком виде.
• Крайние случаи — пустые поля, ошибка сети, дубль отправки, недоступность внешней системы.
• Кто и что видит — сообщения пользователю, уведомления менеджеру.

4. Интеграции

Отдельным разделом: с чем сайт обменивается данными — CRM (Битрикс24, amoCRM), 1С, платёжные системы, службы доставки, аналитика, мессенджеры. По каждой интеграции: направление обмена (сайт → система или в обе стороны), какие данные, как часто, что делать при недоступности сервиса. Именно здесь чаще всего вылезают скрытые сроки и стоимость, поэтому не оставляйте формулировку «интегрировать с 1С» — она не значит ничего.

5. Нефункциональные требования

То, что не видно на макете, но определяет качество: скорость загрузки (целевые метрики Core Web Vitals), адаптивность (какие устройства и разрешения), поддерживаемые браузеры, SEO-требования (ЧПУ, метатеги, микроразметка, карта сайта), доступность, требования к безопасности и защите персональных данных. Пропустите этот раздел — и получите красивый сайт, который грузится пять секунд и не индексируется.

6. Контент и наполнение

Кто даёт тексты и фото, кто делает под них вёрстку, сколько товаров/статей заливается на старте и кто это делает. «Мы думали, вы наполните каталог» против «мы думали, вы дадите контент» — классический конфликт. Пропишите зону ответственности явно.

7. Технологии, хостинг, доступы

CMS или фреймворк, где размещается сайт, кому принадлежат домен и хостинг, как передаются доступы, кто ведёт сайт после запуска. Если платформа задана (например, 1С-Битрикс из-за интеграции с 1С) — это фиксируется здесь.

8. Приёмка, сроки и этапы

Разбейте проект на этапы с результатом каждого (прототип, дизайн, вёрстка, backend, интеграции, наполнение). По каждому — критерии приёмки: конкретные проверяемые условия, а не «нам нравится». Форма отправляет заявку в CRM за N секунд, сайт открывается на iPhone без горизонтального скролла — вот язык приёмки.

Ошибки, которые убивают проект

• «Сделать красиво и удобно». Оценочные формулировки без критериев — источник бесконечных правок. Всё, что нельзя проверить, переписывайте в проверяемое.
• Нет раздела «что НЕ входит». Явно исключите то, о чём легко подумать, что оно включено: наполнение каталога, тексты, мобильное приложение, техподдержка после сдачи.
• Функции описаны только картинкой. Макет показывает, как выглядит, но не как работает. Поведение — словами.
• Интеграции одной строкой. Самый недооценённый по сложности блок. Детализируйте.
• Нет ответственного за контент. Проект встаёт не на коде, а на том, что «тексты будут завтра» три недели подряд.

Из чего складывается цена ТЗ и работ по нему

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

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