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

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

Что такое техническое задание на сайт и почему без него нельзя

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

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

Зачем нужно техническое задание

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

Что происходит без ТЗ:

• Студия делает «стандартный корпоративный сайт» — заказчик ожидал калькулятор, личный кабинет и интеграцию с 1С.
• Нет критериев приёмки — «нравится/не нравится» становится основанием для бесконечных правок.
• Бюджет разрастается: каждая «дополнительная хотелка» стоит денег, которые не были заложены.
• Сроки срываются: непонятный объём работ нельзя оценить точно.

Хорошее ТЗ защищает обе стороны: заказчик получает именно то, что заказал, студия не делает бесплатные правки «потому что так я имел в виду».

Структура технического задания на сайт

Стандартное ТЗ на разработку корпоративного сайта состоит из следующих разделов:

1. Цели и задачи. Зачем сайт? Генерация заявок, информирование, продажи онлайн, работа с партнёрами? Цель определяет всё остальное.
2. Целевая аудитория. Кто пользователь сайта: директор компании, HR-специалист, конечный потребитель? Разная ЦА — разные сценарии поведения и разные приоритеты контента.
3. Структура сайта (sitemap). Полный список страниц с иерархией. Главная → разделы → подразделы. Согласованная структура — основа навигации и SEO.
4. Функциональные требования. Что должен уметь сайт: форма заявки, личный кабинет, фильтры каталога, онлайн-оплата, калькулятор, интеграция с CRM. Каждая функция описывается отдельно.
5. Технические требования. CMS (WordPress, Bitrix, кастом), хостинг, PHP/MySQL версии, SSL, скорость загрузки (Core Web Vitals), поддержка браузеров и устройств, техническое обслуживание после запускав.
6. Дизайн и UX. Референсы, фирменный стиль (если есть), требования к адаптивности, стилистические ограничения.
7. Контент. Кто готовит тексты и изображения: заказчик или студия. Сроки предоставления. Требования к SEO-текстам.
8. SEO-требования. Структура URL, метатеги, микроразметка, sitemap.xml, robots.txt.
9. Интеграции. Яндекс.Метрика, GA4, CRM (amoCRM, Bitrix24), чат-боты, системы оплаты, 1С.
10. Сроки и этапы. Чёткий таймлайн с датами сдачи каждого этапа.
11. Критерии приёмки. По каким объективным критериям работа считается выполненной.

Шаблон ТЗ: минимальный чеклист для малого бизнеса

Для небольшого корпоративного сайта (5–10 страниц) достаточно документа на 5–10 страниц. Вот минимальный чеклист:

• ☐ Цель сайта (одно предложение)
• ☐ Список страниц (sitemap)
• ☐ Для каждой страницы: название, назначение, основной блок контента
• ☐ Формы и функции: что нужно кроме текста и картинок
• ☐ Референсы: 3–5 сайтов, которые нравятся визуально
• ☐ CMS: что используется или предпочтительно
• ☐ Кто готовит тексты: заказчик или подрядчик
• ☐ Срок запуска
• ☐ Бюджет

Этот минимум уже позволяет студии дать точную оценку. Без него — только примерная вилка, которая потом «неожиданно» вырастает.

Пример хорошего описания задачи в ТЗ:

Плохо: «Сделайте красивый современный сайт с возможностью добавления товаров»

Хорошо: «Интернет-магазин на WordPress + WooCommerce. Каталог: 2 категории, около 50 товаров. Фильтры: по цене, бренду. Оплата: Яндекс.Касса (карты + СБП). Доставка: СДЭК + самовывоз. Интеграция: выгрузка заказов в 1С через API. Дизайн: в фирменных цветах (hex-коды в приложении). Мобильная версия: обязательна. Срок: до 15 августа».

Разница очевидна: второй вариант позволяет дать точную смету. Первый — гарантирует разногласия при сдаче работы.

Кто должен писать ТЗ: заказчик или студия

Оба варианта рабочие, у каждого свои плюсы и минусы.

ТЗ пишет студия (рекомендуется). Студия знает, что важно зафиксировать и какие детали влияют на стоимость. Заказчик отвечает на вопросы, студия структурирует. Стоимость — обычно 20 000–50 000 ₽ за документ, засчитывается в стоимость разработки.

ТЗ пишет заказчик. Подходит, если у заказчика есть опыт и понимание процесса. Студия проверяет и дополняет. Риск: заказчик может пропустить технические детали, которые потом станут источником споров.

Совместная работа. Студия проводит брифинг (1–2 часа), затем составляет ТЗ. Заказчик согласовывает. Оптимальный вариант для большинства проектов.

В АйТи-Стандарт ТЗ всегда пишет менеджер проекта после брифинга. Документ подписывается обеими сторонами до начала работ — это защита и клиента, и студии.

Как описать функционал в ТЗ: примеры для распространённых задач

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

Форма обратной связи:

• Поля: имя (обязательное), телефон (обязательное, маска +7), email (необязательное), сообщение (текстовая область)
• Валидация: проверка формата телефона, защита от спама через Яндекс SmartCaptcha
• После отправки: анимация «Спасибо», уведомление на email info@company.ru, запись в amoCRM как лид

Каталог товаров/услуг:

• Список категорий с иконками, количество уровней вложенности (максимум 2)
• Карточка: изображение, название, краткое описание, цена (или «по запросу»), кнопка действия
• Фильтры: по категории, по цене (диапазон), по тегам
• Сортировка: по цене (↑↓), по популярности, по дате добавления

Личный кабинет:

• Регистрация: email + пароль или через Яндекс ID
• Разделы: история заявок, профиль (редактирование данных), документы (скачать счета/акты)
• Доступ к разделам: только авторизованные пользователи

Такой уровень детализации позволяет студии дать точную оценку и избежать ситуации «а мы думали, что уведомления в CRM — это бесплатно».

ТЗ и SEO: что нужно зафиксировать на старте

SEO-требования, заложенные в ТЗ, экономят значительно больше, чем SEO-доработки после запуска. После запуска изменение структуры URL обнуляет накопленный ссылочный вес.

Что должно быть в SEO-разделе ТЗ:

• Структура URL. Формат: /услуги/разработка-сайтов/ или /uslugi/razrabotka-saytov/. Ни один URL не должен меняться после запуска без редиректа.
• Шаблоны метатегов. Как формируется title и description для разных типов страниц: главная, категория, карточка. Без шаблона разработчик поставит дефолтное название сайта.
• Микроразметка. Какие Schema.org типы нужны: Organization, LocalBusiness, Article, FAQPage, Service. Требуется описать в ТЗ — иначе не будет реализовано.
• Карта сайта (sitemap.xml). Автоматическая генерация через плагин или вручную. Какие страницы включать, какие исключать (страницы спасибо, профиль пользователя).
• Скорость загрузки. Минимальные требования: LCP менее 2,5 сек, CLS = 0, FID менее 100 мс. Это технические критерии приёмки.

Что происходит, если ТЗ составлено плохо

По данным исследований в области управления проектами, около 70% переработок в IT-проектах связаны с недостаточно проработанными требованиями на старте. В веб-разработке это выражается конкретно: заказчик говорит «это не то, что я имел в виду», студия выставляет счёт за доп. работы, сроки срываются, отношения испорчены.

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

Частые ошибки в техническом задании

• «Сделайте как у Apple/Яндекса». Референс без описания конкретных элементов — не ТЗ. Что именно взять от Apple? Минимализм? Анимации? Структуру меню?
• Нет описания бизнес-логики. «Корзина и оплата» — не достаточно. Нужно: какие платёжные системы, как работает возврат, что происходит после оплаты.
• Контент «предоставим позже». Без контента нельзя сделать ни финальный дизайн, ни правильную вёрстку. Это главная причина задержки запуска сайтов.
• Размытые критерии приёмки. «Должно выглядеть профессионально» — субъективно. «Время загрузки главной страницы менее 3 секунд на 4G» — объективно и проверяемо.
• Нет описания интеграций. «Подключить CRM» — это полдня работы или две недели? Зависит от CRM и требований к интеграции. Без описания студия заложит минимум, заказчик ожидает максимум.

Опыт 170+ проектов показывает: главная причина срыва сроков — не техника, а коммуникация. ТЗ, которое фиксирует решения в письменном виде, снижает число спорных ситуаций в 3–4 раза. Каждый час, потраченный на составление ТЗ, экономит 3–5 часов переделок в процессе разработки.

Хотите помочь с составлением ТЗ для вашего проекта? Обратитесь к нам — первичный бриф и структуру ТЗ составим бесплатно за 1 рабочий день.

Согласование ТЗ: как избежать конфликтов с подрядчиком

ТЗ — документ, а не разговор. Самая дорогая ошибка в веб-разработке — это «мы же договорились устно». Правила работы с ТЗ, которые экономят нервы и деньги:

• Подписать ТЗ с двух сторон перед началом разработки. Подпись — юридическое подтверждение, что обе стороны понимают объём одинаково. Без подписи ТЗ — просто текст, который каждый трактует по-своему.
• Зафиксировать дату заморозки ТЗ. После начала вёрстки изменения в ТЗ — это доп. работы с отдельной оплатой. Это нормально и честно — но должно быть прописано заранее.
• Версионирование документа. Каждая версия ТЗ — отдельный файл с датой: ТЗ_v1.0_01.04.2026.pdf, ТЗ_v1.2_15.04.2026.pdf. Так всегда понятно, какая редакция действует.
• Итерационные согласования. Не ждите финального ТЗ, чтобы согласовать всё сразу. Согласовывайте по блокам: сначала структура, потом функционал, потом требования к контенту. Ошибки в структуре дешевле исправлять в начале.
• Список открытых вопросов. В ТЗ должна быть таблица «открытых вопросов» — того, что ещё не решено: какое фото на главную, какой текст кнопки CTA, нужна ли интеграция с CRM. Пока вопрос не закрыт — разработка этой части не начинается.

АйТи-Стандарт использует собственный шаблон ТЗ, который прошёл более 200 проектов. Все изменения после подписания фиксируются в Change Log с оценкой трудозатрат. Это защищает и студию, и заказчика от недопонимания.

Хорошее ТЗ vs плохое: конкретные примеры

Разница между хорошим и плохим ТЗ — не в объёме, а в конкретности. Сравним три типичных случая:

Хорошее ТЗ отвечает на вопрос разработчика, не создавая новых вопросов. Если при чтении ТЗ возникает вопрос «а как именно?» — ТЗ неполное. Нужна помощь с составлением ТЗ? Мы предоставляем шаблон и помогаем его заполнить на первом брифинге.

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

Обязательно ли техническое задание для небольшого сайта?

Для сайта из 3–5 страниц без сложных функций можно обойтись подробным брифом и перечнем страниц. Но даже для лендинга полезно зафиксировать: что должно быть на каждом экране, какая форма, куда идут заявки. Это займёт 1–2 часа, но сэкономит неделю разногласий.

Сколько стоит составить техническое задание?

Профессиональное ТЗ на корпоративный сайт стоит 20 000–50 000 ₽. Для интернет-магазина с нестандартной логикой — 50 000–100 000 ₽. В большинстве студий стоимость ТЗ засчитывается в стоимость разработки при подписании договора на проект.

Можно ли начать разработку без ТЗ?

Студии, которые берутся за работу без ТЗ, либо очень опытны (делают всё интуитивно, потом согласовывают), либо готовятся к будущим разногласиям. Второе встречается чаще. Уважающая себя студия не начнёт дорогостоящую разработку без согласованного документа.

Что такое прототип и чем он отличается от ТЗ?

ТЗ — текстовый документ, описывающий требования. Прототип — визуальная схема страниц (wireframes в Figma): где что находится, как выглядит навигация, что происходит при нажатии кнопки. Прототип делается на основе ТЗ и предшествует дизайну. Хорошее ТЗ + прототип = минимум правок на этапе разработки.

Кто несёт ответственность, если сайт не соответствует ТЗ?

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

Нужно ли ТЗ для редизайна существующего сайта?

Обязательно, и здесь ТЗ ещё важнее, чем при разработке с нуля. Нужно зафиксировать: какие страницы остаются, какие переделываются, что сохраняется в структуре URL (для SEO), какой контент обновляется. Без этого редизайн превращается в «угадай что я хотел».

Хотите начать проект с правильного ТЗ? Запросите брифинг у АйТи-Стандарт — составим ТЗ за 3 рабочих дня и согласуем до начала разработки.