Как составить техническое задание на сайт: структура и шаблон

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

Зачем оно на самом деле

Три вещи, которые ТЗ делает и которые больше не делает ничто.

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

Переносит правки на дешёвый этап. Изменить структуру в документе — минуты. В макете — часы. В свёрстанном сайте — дни. ТЗ вытаскивает сложные решения в начало проекта, когда они ещё дёшевы.

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

Структура документа

1. О проекте и бизнес-задаче

Чем занимается компания, кто клиент, какую задачу решает сайт. Не «сделать современный сайт», а «получать заявки на монтаж вентиляции от юрлиц» или «снизить нагрузку на менеджеров за счёт онлайн-записи».

Этот раздел читают все участники, и он определяет десятки мелких решений дальше.

2. Целевая аудитория и сценарии

Кто приходит на сайт, откуда и с каким вопросом. Минимум два-три сценария: «закупщик ищет позицию по артикулу», «частный клиент сравнивает цены с телефона».

Сценарии важнее портретов аудитории: из них напрямую следует структура страниц.

3. Структура сайта

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

4. Функциональные требования

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

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

Список внешних систем с указанием: есть ли API и документация, кто предоставляет доступы, в какую сторону идёт обмен, как часто. Это самый рискованный раздел — здесь чаще всего срываются сроки.

6. Контент

Кто пишет тексты, кто предоставляет фотографии, к какому сроку. Пункт выглядит скучным, а на практике именно он чаще всего останавливает проекты.

7. Технические требования

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

8. Что не входит

Самый недооценённый раздел. Явно перечислите то, чего в проекте не будет: наполнение каталога, продвижение, съёмка, мобильное приложение. Одна страница текста здесь снимает половину будущих споров.

Типовые ошибки

«Сделать красиво и удобно». Это не требование, а пожелание. Проверить его выполнение невозможно, значит спорить об этом можно бесконечно.

Описание решения вместо задачи. «Нужен слайдер на главной» — это решение, причём часто неудачное. Задача звучит иначе: «показать три направления работы». Дайте подрядчику задачу — способ он подберёт лучше.

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

Требования без приоритетов. Если всё обязательно, при нехватке бюджета резать придётся вслепую. Разделите функции на «без этого не запускаемся» и «желательно» — это же основа поэтапного запуска, одного из работающих способов сэкономить на разработке.

Отсутствие критериев приёмки. Как вы поймёте, что работа сделана? Для скорости это конкретные метрики, для форм — проверенные сценарии, для адаптивности — список устройств.

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

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

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

Что делать, если ТЗ нет

Ситуация нормальная: большинство заказчиков приходят с задачей, а не с документом. Порядок такой:

1. Брифинг — подрядчик задаёт вопросы и собирает фактуру.
2. Прототип структуры — быстрее и нагляднее текста, многие противоречия видны сразу.
3. ТЗ на основе прототипа — уже с конкретикой по функциям и интеграциям.
4. Смета по разделам ТЗ.

Если подрядчик готов назвать точную цену, не пройдя эти шаги, — либо в цену заложен тройной запас, либо в середине проекта начнётся разговор о доплате. Этот и другие тревожные признаки собраны в чек-листе как выбрать веб-студию.

Итог

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

Если у вас есть задача, но нет документа — пришлите описание в свободной форме. Вернёмся с вопросами, которые обычно и превращаются в нормальное ТЗ.