Техническое задание на сайт: что в нём писать

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

Чем техническое задание отличается от брифа

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

Разница хорошо видна на одном пожелании. Допустим, сайт нужен компании, которая устанавливает кондиционеры. В брифе она пишет: «Хотим, чтобы с сайта записывались на установку». В ТЗ эта фраза превращается в требования:

• на странице каждой модели есть кнопка «Заказать установку»;
• в форме — имя, телефон, адрес и удобная дата; обязательны только телефон и согласие на обработку персональных данных;
• заявка попадает в CRM со статусом «Новая» и дублируется менеджеру в мессенджер;
• после отправки посетитель видит, когда ему перезвонят;
• в Яндекс Метрике срабатывает цель «Заявка на установку».

Бриф объясняет, зачем это нужно, а ТЗ — что именно сделать, чтобы разработчику не пришлось додумывать, а заказчик заранее знал, что получит.

Когда нужно ТЗ, а когда хватит брифа и прототипа

Подробное ТЗ нужно там, где много логики, которую не видно на картинке:

• Каталог. Какие у товара характеристики, по каким фильтровать, откуда берутся цены и остатки, что показывать, если товар закончился.
• Интеграции. CRM, онлайн-оплата, онлайн-запись через YCLIENTS, расчёт доставки: какие данные передаются, в какую сторону и что происходит, если сервис не ответил.
• Личный кабинет. Регистрация, вход и восстановление пароля, что видит клиент, а что — менеджер, какие уведомления и когда приходят.
• Несколько подрядчиков. Когда дизайн делает одна команда, программирование — другая, а обмен с учётной системой — третья, ТЗ становится общим языком и границей ответственности. Без него каждый уверен, что недостающее должен был сделать сосед.

Для лендинга, сайта-визитки или небольшого сайта услуг толстый документ обычно лишний. Цели и аудитория уже описаны в брифе, а страницы и блоки нагляднее показывает прототип — схема, где видно, что за чем идёт и куда ведёт каждая кнопка. К ним достаточно добавить короткий список технических требований: куда уходят заявки, какие цели нужны в Метрике, на кого оформлены домен и хостинг. У нас прототип делается вместе с текстами за 3–5 дней после разбора задачи, и к дизайну проект приходит с согласованной схемой страниц.

Что писать в техническом задании на сайт

Состав зависит от проекта, но основные разделы повторяются. Если какого-то раздела в проекте нет, его лучше вычеркнуть, чем заполнять общими словами.

Раздел	Что в нём описать
Цели и аудитория	Зачем сайт, кто на него приходит, какое действие главное
Структура и шаблоны	Список страниц и их типов: главная, услуга, карточка товара, статья
Функциональность	Сценарии: кто действует, что делает и что получает в итоге
Формы	Поля, обязательные и нет, проверки, куда уходит заявка, что видит посетитель после отправки
Интеграции	Сервисы, какие данные и в какую сторону передаются, что делать при сбое
Контент	Что уже есть, что нужно создать, кто готовит тексты и фото и к какому сроку
Адаптив и браузеры	Самая узкая ширина экрана, браузеры и устройства для проверки
Скорость	Целевые значения Core Web Vitals
SEO и аналитика	Адреса страниц, title и description, перенаправления, цели в Метрике
Доступы и хостинг	На кого оформлены домен, хостинг, админка и сервисы
Критерии приёмки	Как проверяется каждое требование

Раздел про контент недооценивают чаще других. Если в ТЗ не записано, кто пишет тексты и снимает фотографии, их не готовит никто — и дизайн рисуют под заглушки.

Как описать функциональность, формы и интеграции

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

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

1. Посетитель открывает каталог и указывает площадь комнаты.
2. Каталог показывает подходящие модели с ценой установки.
3. Посетитель нажимает «Заказать установку» и оставляет телефон.
4. Если CRM не ответила, заявка не теряется: она уходит менеджеру на почту.

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

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

Для интеграции указывают сервис, какие данные и как часто передаются, у кого ключи доступа и кто отвечает за настройку на стороне сервиса.

Какие требования к адаптиву, скорости и SEO записать

Этих требований не видно на прототипе, поэтому их чаще всего пропускают, а потом выясняется, что сайт проверяли на одном ноутбуке.

• Адаптив. С какой ширины экрана сайт работает без горизонтальной прокрутки — обычно с 320 пикселей — и что меняется на телефоне: меню, таблицы, порядок блоков.
• Браузеры. Например, актуальные версии Chrome, Safari, Firefox и Яндекс Браузера на компьютере, Safari на iPhone и Chrome на Android.
• Скорость. Измеримая цель — хорошие значения Core Web Vitals: LCP не дольше 2,5 с, INP не больше 200 мс, CLS не больше 0,1.
• Доступность. Контраст обычного текста — не ниже 4,5 : 1 по WCAG, подписи у полей, управление с клавиатуры.
• SEO. Адреса страниц, свои title и description, перенаправления со старых адресов, если сайт заменяет прежний, sitemap.xml и robots.txt.
• Аналитика. Счётчик Яндекс Метрики в аккаунте заказчика и список целей: каждая форма, клик по телефону, переход в мессенджер.
• Доступы и хостинг. На кого регистрируется домен, где будет размещён сайт, у кого права администратора. Надёжнее, когда всё оформлено на заказчика с первого дня.

Критерии приёмки: как проверить, что всё сделано

Требование без способа проверки — пожелание. «Сайт должен быстро загружаться» нельзя ни принять, ни оспорить, а «LCP главной страницы в мобильном тесте PageSpeed Insights — не больше 2,5 с» — можно.

Хорошие критерии приёмки:

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

На приёмке ТЗ превращается в чек-лист: идёте по пунктам и отмечаете выполненные. Что ещё проверить перед финальной оплатой, — в статье о приёмке сайта.

Кто пишет ТЗ и как его согласовать

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

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

Согласование обычно проходит так:

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

Частые ошибки в ТЗ на сайт

• Взять чужое ТЗ из интернета: в нём чужой бизнес и чужие функции.
• Описывать внешний вид вместо задачи: «синяя кнопка справа» вместо «главное действие — заявка на установку».
• Писать «удобный», «современный», «быстрый» без цифр и способа проверки.
• Описать только удачный сценарий и забыть про ошибки, пустые результаты и сбои.
• Не записать, откуда берутся данные: цены, остатки, расписание.
• Не назначить ответственного за контент.
• Добавлять функции «на будущее»: они раздувают срок и смету первой версии.
• Утвердить документ и больше не обновлять: через месяц он описывает не тот сайт, который делают.

Если проект сложный и непонятно, с чего начать, расскажите о задаче: разберём её и предложим структуру. Как объём из ТЗ превращается в цену, — в статье сколько стоит сайт, а кому доверить такой документ, поможет решить статья о выборе подрядчика для сайта.