# Техническое задание на сайт: структура и пример

Источник: https://nadodumat.ru/articles/tekhnicheskoe-zadanie-na-sayt

Автор: команда «Надо думать». Дата: 2026-11-11.

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

## Зачем нужно ТЗ, если задачу уже обсудили

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

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

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

## Зафиксируйте цель и границы первой версии

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

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

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

Учебные границы первой версии сайта монтажной компании

- Входит: Три страницы услуг и общие разделы; Не входит: Каталог оборудования с остатками; Нужно от заказчика: Перечень услуг, регион и ограничения
- Входит: Форма запроса с передачей в CRM; Не входит: Личный кабинет и онлайн-оплата; Нужно от заказчика: Правила обработки, тестовый доступ и ответственный
- Входит: Редактирование цен и описаний; Не входит: Автоматическое составление сметы; Нужно от заказчика: Кто утверждает цены и обновляет материалы

- [Как выбрать формат и объём сайта](https://nadodumat.ru/articles/lending-ili-mnogostranichnyy-sayt)

## Опишите страницы и материалы, которые в них появятся

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

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

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

Пример реестра контента для одного типа страниц

- Материал: Описание трёх услуг; Кто готовит: Подрядчик после интервью; Как принимается: Заказчик подтверждает состав и ограничения
- Материал: Два примера выполненных работ; Кто готовит: Заказчик передаёт факты и фотографии; Как принимается: Проверены подписи, права и разрешённый объём сведений
- Материал: Контакты и условия обращения; Кто готовит: Ответственный сотрудник заказчика; Как принимается: Адреса, часы работы и маршрут заявки актуальны

## Пишите сценарии вместо общих пожеланий

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

У сценария есть не только успешный конец. Что увидит посетитель, если пропустил обязательное поле, потерял соединение или дважды нажал кнопку? Что произойдёт с уже введённым текстом? Такие вопросы дешевле решить до разработки. В руководстве W3C по формам отдельно рассматриваются подписи полей, инструкции, проверка ввода и уведомления — их стоит перевести в конкретные требования вашего проекта.

Не делайте каждое поле обязательным без причины. Спросите менеджера, без каких сведений он действительно не сможет начать разговор. Для сложной услуги подробности можно собрать на следующем шаге. Сокращённая форма и подробный опросник решают разные задачи; выбор должен опираться на маршрут клиента, а не на привычку подрядчика.

## Заполненный пример: три проверяемых требования

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

У требований есть номера: на них удобно ссылаться в оценке, замечаниях и акте проверки. Сначала описан результат для пользователя или сотрудника, затем способ его подтвердить. Так заказчику не приходится разбираться во внутреннем устройстве программы, чтобы понять, выполнена ли договорённость.

- Для ТЗ-01 заранее определить поля CRM и правило выбора услуги.
- Для ТЗ-02 согласовать, какое подтверждение считается надёжным приёмом и как исключаются дубли.
- Для ТЗ-03 указать роль сотрудника, места показа цены и способ публикации изменения.
- Сохранить результат каждого сценария: пройден, есть замечание или не проверен, с причиной и ответственным.

Учебный фрагмент ТЗ: требование, проверка, подтверждение

- Требование: ТЗ-01. Сохранять выбранную услугу в обращении; Сценарий приёмки: Открыть «Вентиляция для кафе», отправить тестовый запрос; Что подтверждает готовность: В карточке CRM указана эта услуга, а контакт совпадает с введённым
- Требование: ТЗ-02. Различать приём заявки и доставку в CRM; Сценарий приёмки: Проверить штатную отправку, повтор, отказ сохранения и временную недоступность CRM; Что подтверждает готовность: Одно обращение учитывается один раз. Не удалось сохранить — ошибка без ложного успеха, ввод сохранён. Сохранено, но CRM недоступна — приём подтверждён, доставка ожидается и контролируется
- Требование: ТЗ-03. Обновлять цену из одного поля управления; Сценарий приёмки: Сотрудник меняет учебное значение с 30 000 на 35 000 ₽; Что подтверждает готовность: После публикации 35 000 ₽ показаны и в списке услуг, и на странице; другие цены не изменены

## Уточните требования к качеству и ограничениям

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

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

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

- [Как связать состав ТЗ и смету разработки](https://nadodumat.ru/articles/skolko-stoit-zakazat-sayt)

## Доведите интеграции до получателя и понятного события

«Подключить CRM» — начало описания, а не критерий готовности. Укажите, какие данные передаются, в какую воронку, кто становится ответственным и что происходит при недоступности сервиса. Нужны ли уведомление, очередь повторной отправки, сохранение источника? Каждый такой механизм имеет цену и ограничения; его нельзя молча считать включённым.

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

Для аналитики составьте отдельный перечень действий. В Метрике целевое событие может обозначать разные сценарии, поэтому названия «заявка» недостаточно: нужно условие срабатывания. Например, событие отправляется после подтверждённого приёма, а клик по кнопке учитывается отдельно. Проверка доставки в CRM и проверка аналитики остаются двумя действиями: блокировка счётчика не должна ломать обращение.

- [Почему важно проверить путь от обращения до продажи](https://nadodumat.ru/articles/zayavki-est-prodazh-net)

## Договоритесь о согласовании и изменениях

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

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

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

## Завершите ТЗ планом приёмки и передачи

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

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

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

- [Что предусмотреть для обслуживания после запуска](https://nadodumat.ru/articles/stoimost-soderzhaniya-sayta)
- [Как организовать переход со старого сайта](https://nadodumat.ru/articles/redizayn-sayta-kogda-i-kak)

## Вопросы и ответы

### Кто должен писать техническое задание на сайт?

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

### Можно ли начать без готового ТЗ?

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

### Подойдёт ли шаблон технического задания из интернета?

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

### Нужно ли описывать дизайн до начала проектирования?

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

### Можно ли менять ТЗ после начала разработки?

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