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

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

Зачем нужно ТЗ и что оно экономит

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

ТЗ решает три задачи:

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

Бриф, ТЗ и прототип: в чём разница

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

Для небольшого сайта бриф и прототип иногда заменяют полноценное ТЗ. Для проекта с интеграциями, ролями пользователей и сложной логикой без ТЗ не обойтись.

Структура ТЗ на сайт: разделы, которые можно взять за основу

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

• Цели и аудитория. Зачем сайт бизнесу (заявки, продажи, найм, доверие инвесторов), кто его посетители и какое целевое действие должны совершить.
• Структура и страницы. Карта сайта с перечнем шаблонов: главная, услуги, карточка услуги, кейсы, блог, контакты. Для каждого шаблона — список блоков.
• Функции. Формы, калькуляторы, фильтры каталога, поиск, личный кабинет, мультиязычность. Каждая функция описана через поведение: что делает пользователь и что получает.
• Роли и админка. Кто и что правит на сайте: редактор публикует статьи, менеджер меняет цены, администратор управляет пользователями. Что должно быть доступно без программиста.
• Интеграции. CRM (куда уходят заявки, какие поля, как распределяются), онлайн-оплата, 1С (выгрузка товаров, остатков, заказов), рассылки, телефония. Для каждой — направление обмена данными и частота.
• Контент и кто его готовит. Тексты, фото, видео, переводы: что предоставляет заказчик, что делает студия, в какие сроки и в каком виде.
• Требования к дизайну. Фирменный стиль, брендбук, референсы с пояснением, что именно в них нравится, ограничения по цветам и шрифтам.
• Адаптивность. Ширины экранов, на которых проверяется сайт, и поддерживаемые браузеры.
• Скорость и SEO. Целевые показатели загрузки, управление мета-тегами title и description, карта сайта, ЧПУ, микроразметка, hreflang для языковых версий. При переносе со старого сайта — карта 301-редиректов и сохранение адресов, которые приносят трафик.
• Аналитика и цели. Яндекс Метрика и другие счётчики, список целей (отправка формы, клик по телефону, оплата), передача источника заявки в CRM.
• Доступность. Контрастность текста, работа с клавиатуры, подписи к изображениям и полям форм.
• Хостинг и безопасность. Где размещается сайт, кто отвечает за сервер, SSL-сертификат, резервное копирование, защита форм от спама, доступы и их передача заказчику.
• Персональные данные. Какие формы собирают данные, политика обработки персональных данных, согласие на обработку по 152-ФЗ. На момент публикации согласие оформляют отдельно от других документов, поэтому в ТЗ стоит заложить отдельный чекбокс и ссылку на текст согласия. Сами тексты готовит юрист заказчика.
• Приёмка и критерии готовности. Как проверяется каждая функция, на каких устройствах, какие показатели скорости считаются достаточными, сколько итераций правок входит в работу.
• Поддержка. Гарантийный период, что входит в гарантию, как оформляются доработки после запуска, кто обновляет систему управления и плагины.

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

Кто пишет ТЗ: заказчик, студия или вместе

Есть три рабочих варианта.

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

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

Нужен ли ГОСТ для технического задания

Для автоматизированных систем существует ГОСТ 34.602-2020, который с 1 января 2022 года заменил ГОСТ 34.602-89. Он задаёт подробную структуру ТЗ и часто требуется в госзаказе и крупных внутренних системах. Для коммерческого сайта следовать ему целиком обычно избыточно: документ разрастается, а нужные решения тонут в формальных разделах. Разумный подход — взять из ГОСТа идею полноты и порядок, а писать коротко и по делу.

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

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

Как подойти к ТЗ: наше правило

Объём документа должен соответствовать сложности проекта:

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

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