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

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

Зачем нужно ТЗ, если это «просто сайт»

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

Техническое задание — это не формальность для подрядчика, а страховка для заказчика: без него любая правка «за рамками» превращается в спор о том, что вообще входило в проект.

ТЗ и бриф — в чём разница

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

Из каких разделов состоит рабочее ТЗ

Структура, которая подходит для большинства проектов — от визитки до корпоративного сайта:

Цели и задачи сайта — что должен делать сайт: собирать заявки, продавать, информировать, поддерживать имидж;
Целевая аудитория — кто приходит на сайт и с каким запросом;
Структура сайта (карта разделов) — список всех страниц с кратким описанием содержания каждой;
Функциональные требования — форма заявки, калькулятор, личный кабинет, каталог, фильтры, интеграции с CRM;
Требования к дизайну — референсы, фирменный стиль, обязательные и нежелательные элементы;
Технические требования — платформа (CMS или индивидуальная разработка), хостинг, требования к скорости и адаптивности;
SEO-требования — структура URL, метатеги, микроразметка, требования к семантическому ядру;
Контент — кто предоставляет тексты и изображения: заказчик или подрядчик;
Сроки и этапы — с датами сдачи по каждому этапу, а не только финальной;
Критерии приёмки — по каким признакам работа считается выполненной.

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

Самая практичная часть технического задания — таблица со списком страниц. Она снимает большинство споров о «что входило в проект», потому что фиксирует объём буквально по страницам:

Страница	Назначение	Ключевые блоки
Главная	Первое знакомство, оффер	Заголовок, услуги, преимущества, форма заявки
Услуги / каталог	Презентация продукта	Список позиций, цены, описания
О компании	Доверие	История, команда, лицензии
Контакты	Связь	Адрес, телефон, карта, форма

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

Функциональные требования: детализация решает

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

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

SEO-требования в ТЗ — не опция, а обязательный раздел

Если сайт должен приносить трафик из поиска, SEO-требования нужно закладывать в ТЗ с самого начала, а не добавлять постфактум. Минимальный набор пунктов:

Человекопонятные ЧПУ-адреса страниц без технических параметров;
Уникальные title, description и H1 для каждой страницы — не шаблонные;
Разметка Schema.org под тип бизнеса (организация, товар, FAQ, хлебные крошки);
Требования к скорости загрузки и корректной мобильной версии;
Список страниц, которые нужно закрыть от индексации (личный кабинет, служебные страницы).

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

Кто составляет ТЗ: заказчик или подрядчик

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

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

Расплывчатые формулировки вроде «сделать красиво и современно» без референсов;
Отсутствие сроков по промежуточным этапам — только финальная дата;
Нет ответственного за предоставление контента и его дедлайна;
Функционал описан списком без деталей — «нужен калькулятор» без логики расчёта;
SEO-требования добавляются после сдачи сайта, когда структура URL уже зафиксирована в коде.

Пример короткого ТЗ на лендинг

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

Цель: сбор заявок на услугу «монтаж систем вентиляции» с рекламного трафика Яндекс.Директ. Структура: один экран-оффер, блок преимуществ, этапы работы, портфолио объектов, отзывы, форма заявки (поля: имя, телефон, комментарий, отправка на почту и в Telegram-бот). Дизайн: по референсам заказчика, фирменные цвета — синий и белый. Технические требования: адаптивная вёрстка, скорость загрузки мобильной версии до 2,5 секунд. Срок: 3 недели, приёмка — по чек-листу функционала и корректному отображению на трёх типах устройств.

Даже такой сжатый формат снимает большинство рисков недопонимания — потому что каждый пункт можно однозначно проверить после сдачи проекта.

Что делать, если требования меняются в процессе разработки

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

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

Чек-лист: готово ли ваше ТЗ к передаче в работу

Указаны цели сайта и то, как будет измеряться результат;
Есть полная карта разделов с описанием содержания каждой страницы;
Функциональные блоки описаны с деталями, а не общими фразами;
Указаны сроки по этапам, а не только финальная дата сдачи;
Определён ответственный за контент и дедлайн его передачи;
Прописаны SEO-требования: ЧПУ, метатеги, микроразметка;
Есть критерии приёмки — по каким признакам работа считается завершённой.

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

Вывод

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

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