Техническое задание на разработку сайта: структура, пример и шаблон

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

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

Что такое ТЗ на сайт и чем оно отличается от брифа и договора

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

Документ	На какой вопрос отвечает	Кто заполняет	Когда
Бриф	Что за бизнес, какая задача, какие примеры нравятся	Заказчик	До оценки
Техническое задание	Какие страницы, функции, требования и как принимаем	Исполнитель вместе с заказчиком	После брифа, до дизайна
Прототип	Как расположены блоки на ключевых страницах	Исполнитель	Вместе с ТЗ или сразу после
Договор	Сроки, цена, этапы оплаты, права, ответственность	Юристы сторон	ТЗ становится приложением к договору

Удобная практика: ТЗ подписывают как приложение к договору. Тогда спор «это входило в работу или нет» решается по тексту, а не по памяти.

Кто пишет техническое задание

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

Кто пишет	Плюс	Риск
Заказчик сам	Точно описан бизнес и клиенты	Пропущены технические требования, формулировки размыты
Исполнитель сам	Грамотная техническая часть	ТЗ подогнано под то, что исполнителю удобно сделать
Вместе	Бизнес и техника в одном документе	Нужны 2–3 встречи и время заказчика
Отдельный аналитик	Независимый взгляд, можно отдать ТЗ разным студиям	Дополнительный этап и бюджет

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

Структура ТЗ на разработку сайта: 10 разделов

В ТЗ на сайт достаточно десяти разделов. Если по какому-то разделу требований нет, его не удаляют, а пишут «требований нет». Так делает и ГОСТ 34.602-2020 для больших автоматизированных систем: пустой раздел сохраняется с такой пометкой. Сайту малого бизнеса ГОСТ не обязателен, но эта привычка полезна: видно, что вопрос обсудили, а не забыли.

1. Общие сведения. Название компании, адрес будущего сайта, кто со стороны заказчика принимает решения, кто ведёт проект у исполнителя.
2. Цели и показатели. Зачем сайт: заявки, звонки, продажи, запись. Как поймём, что он работает: например, цель «отправка формы» в Яндекс Метрике и заявки в почте или CRM.
3. Аудитория и сценарии. Кто приходит и что делает. Например: «частный заказчик выбирает тип бани, считает примерную стоимость и оставляет заявку».
4. Структура и страницы. Карта сайта и состав каждой страницы сверху вниз.
5. Функции и формы. Калькуляторы, каталог, фильтры, оплата, личный кабинет. Для каждой формы: поля, обязательные поля, куда уходит заявка, что видит человек после отправки.
6. Дизайн и контент. Фирменный стиль, примеры, кто пишет тексты и готовит фото, сколько страниц наполняет исполнитель.
7. Интеграции. CRM, телефония, мессенджеры, оплата, 1С, карты. Что именно и в какую сторону передаётся.
8. Технические требования. Скорость, адаптивность, браузеры, хостинг, безопасность, база для поиска, резервные копии.
9. Приёмка. Как и на чём проверяем, сколько дней на замечания, что считается ошибкой.
10. Сроки и изменения. Этапы, кто что передаёт и когда, как вносим изменения в ТЗ по ходу работ.

Как формулировать требования, чтобы их поняли одинаково

Требование должно быть проверяемым: прочитав его, любой человек скажет «выполнено» или «не выполнено». В ГОСТ 34.602-2020 перечислены характеристики хорошего требования: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность. Для сайта это значит простую вещь: одно требование в одном пункте, без слов «удобный», «современный», «быстрый» без цифр.

Размыто	Проверяемо
Удобная форма заявки	Форма из трёх полей: имя, телефон, комментарий. Обязателен только телефон. После отправки человек видит сообщение и срок ответа
Сайт должен быстро грузиться	LCP не больше 2,5 с, INP не больше 200 мс, CLS не больше 0,1 на мобильных по данным PageSpeed Insights
Заявки приходят менеджеру	Каждая заявка приходит на почту отдела продаж и в рабочий чат в течение минуты, с адресом страницы, с которой её отправили
Современный дизайн	Дизайн в фирменных цветах, три примера сайтов, которые нравятся, и что именно в них нравится
Сайт адаптирован под телефоны	Все страницы без горизонтальной прокрутки на ширине от 360 px, кнопки и телефон нажимаются пальцем
Админка для контента	Сотрудник без навыков разработки меняет цены, фото и тексты услуг и добавляет новость

Пример ТЗ на разработку сайта: строительная компания с калькулятором

Пример условный, сокращённый до главного. Он показывает, как выглядят заполненные разделы, а не готовый документ для вашего проекта.

Раздел	Что записано
Цели и показатели	Заявки на строительство бань. Показатели: цели Метрики «расчёт в калькуляторе» и «отправка заявки», доля заявок с указанным проектом
Сценарий	Человек выбирает проект, меняет размер и материал, видит примерную стоимость, отправляет заявку с расчётом
Страницы	Главная, каталог проектов, карточка проекта, калькулятор, портфолио, цены, о компании, контакты, политика обработки данных
Карточка проекта	Фото, планировка, размеры, что входит в комплектацию, цена от, кнопка «рассчитать этот проект»
Калькулятор	Поля: проект, размер, материал стен, кровля, фундамент. Цены задаёт сотрудник в админке. Итог с пометкой, что расчёт предварительный
Интеграции	Заявка с расчётом уходит в CRM и в рабочий чат, в заявке страница входа и метки рекламы
Технические требования	Core Web Vitals в зелёной зоне на мобильных, HTTPS, sitemap.xml и robots.txt, перенаправления со старых адресов
Приёмка	Проверка на тестовом адресе по списку сценариев, 5 рабочих дней на замечания, после исправления перенос на рабочий домен

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

Что добавить в ТЗ для вашего типа сайта

Базовые разделы общие для всех сайтов, но у каждого типа есть свои пункты, которые чаще всего забывают. Переключайте вкладки.

Технические требования, которые чаще всего забывают

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

• Скорость. У Google есть три метрики Core Web Vitals: LCP (загрузка главного содержимого) до 2,5 секунды, INP (отклик на нажатие) до 200 миллисекунд, CLS (сдвиги вёрстки) до 0,1. Их считают по 75-му процентилю посещений, отдельно для мобильных и компьютеров.
• База для поиска. Отдельные title и description у страниц, понятные адреса, sitemap.xml, robots.txt, 301-перенаправления со старых адресов, если сайт переделывается.
• Персональные данные. Если на сайте есть форма с именем и телефоном, вы собираете персональные данные. Часть 2 статьи 18.1 закона 152-ФЗ требует опубликовать на сайте документ о политике обработки данных. Пропишите в ТЗ страницу политики и отметку согласия у форм, текст пусть проверит юрист.
• Доступы. Домен, хостинг, Метрика и аккаунты сервисов оформлены на компанию заказчика. Исполнитель работает через выданные ему доступы.
• Права на код и дизайн. По статье 1296 ГК РФ исключительное право на программу, созданную по заказу, принадлежит заказчику, если договор не говорит иное. Проверьте, что договор этого не меняет.
• Резервные копии и тестовый адрес. Где хранится копия сайта и как изменения проверяют до выхода на рабочий сайт.

Приёмка: как ТЗ превращается в список проверок

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

• Проходите сценарии, а не страницы: «найти проект, рассчитать, отправить заявку, проверить, что она пришла в CRM».
• Проверяйте на телефоне и на компьютере, в двух-трёх браузерах.
• Записывайте замечания списком с номером пункта ТЗ. Замечание без пункта ТЗ это новая задача, а не ошибка.
• Изменения по ходу работ записывайте дополнением к ТЗ с датой и подписью. Так поступают и в ГОСТ 34.602-2020: изменения оформляют дополнением, которое становится частью ТЗ.

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

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

Шаблон ТЗ на разработку сайта

Скопируйте структуру и заполните ответы своими словами. Вопросы в скобках подсказывают, что написать.

1. Общие сведения (компания, адрес сайта, кто принимает решения, контакты).
2. Цели и показатели (что должен делать посетитель, как это измерим).
3. Аудитория и сценарии (кто приходит, что ищет, какой путь до заявки).
4. Карта сайта (список страниц и их вложенность).
5. Состав страниц (блоки сверху вниз для каждой ключевой страницы).
6. Функции и формы (поля, проверки, куда уходит заявка, что видит человек после отправки).
7. Дизайн (фирменный стиль, примеры, что нравится и что нет).
8. Контент (кто пишет тексты, кто готовит фото, сколько страниц наполняет исполнитель).
9. Интеграции (какие сервисы, какие данные, в какую сторону).
10. Технические требования (скорость, адаптивность, браузеры, хостинг, база для поиска, персональные данные, резервные копии, доступы).
11. Приёмка (сценарии проверки, срок на замечания, тестовый адрес).
12. Сроки, этапы и порядок изменений (кто что передаёт, как оформляем изменения).

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

Перед отправкой ТЗ исполнителю пройдите короткую проверку.

Что делать после ТЗ

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

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