Как составить ТЗ на сайт, чтобы получить именно то, что нужно? Хорошее ТЗ — это не многотомный документ, а чёткий список того, что сайт должен делать. Главное: опишите цель сайта, целевую аудиторию, структуру страниц, функционал и дизайн-референсы. Без ТЗ разработчик будет гадать — и почти наверняка угадает мимо. Средний срок подготовки ТЗ силами заказчика — 3–7 дней при системном подходе. В этой статье — пошаговый чек-лист, который превратит хаос в структуру.
Зачем вообще нужно техническое задание
Техническое задание (ТЗ) — это документ, который фиксирует договорённости между заказчиком и разработчиком до начала работы. Без ТЗ разработка превращается в бесконечный цикл «сделай так… нет, не так… а можно ещё вот это?».
По статистике студий, проекты с ТЗ сдаются в 2,5 раза быстрее и требуют на 60% меньше правок после сдачи. Причина проста: когда все параметры зафиксированы на бумаге, нет места фантазиям и недопониманию.
ТЗ выполняет три функции:
- Юридическая защита — при конфликте вы ссылаетесь на пункт ТЗ, а не на устную договорённость
- Точная оценка — разработчик видит объём работ и называет реальную цену, а не «от 50 000»
- Контроль результата — при приёмке вы сверяете сайт с ТЗ пункт за пунктом
Что должно быть в ТЗ: обязательные разделы
ТЗ не обязательно делать на 40 страниц. Для типового сайта достаточно 5–10 страниц структурированного документа. Вот минимальный набор разделов:
1. Цели и задачи сайта
Опишите, какую бизнес-задачу решает сайт. Не «нужен сайт», а конкретно: «получать 30 заявок в месяц с органического поиска», «продавать онлайн-курсы через корзину», «презентовать портфолио для B2B-клиентов». Чем конкретнее цель — тем точнее разработчик подберёт инструменты.
2. Целевая аудитория
Кто будет пользоваться сайтом? Опишите 2–3 портрета: возраст, профессия, боли, сценарий использования. Например: «руководитель отдела закупок, 35–50 лет, ищет поставщика через Google на мобильном телефоне».
3. Структура и навигация
Перечислите все страницы сайта с их названиями и иерархией. Пример:
- Главная
- Услуги (с подстраницами)
- Портфолио
- О компании
- Контакты
- Блог / Статьи
Для интернет-магазина добавьте: каталог → категории → карточка товара, корзина, оформление заказа, личный кабинет.
4. Функциональные требования
Самый важный раздел. Опишите, что должен уметь сайт. Разбейте на блоки:
- Формы — какие формы нужны (обратная связь, заявка, подписка), какие поля, куда отправлять заявки
- Интеграции — CRM, платёжные системы, почтовые сервисы, Telegram-боты
- Личный кабинет — нужен ли, какой функционал
- Поиск и фильтры — поиск по сайту, фильтрация товаров по параметрам
- Мультиязычность — нужны ли версии на других языках
- Админ-панель — что заказчик должен уметь менять сам (тексты, фото, цены)
5. Дизайн и визуальный стиль
Приложите референсы: 3–5 ссылок на сайты, которые нравятся визуально. Укажите, что именно нравится: цветовая гамма, типографика, расположение блоков, анимации. Если есть брендбук — приложите его.
Укажите требования к адаптивности: сайт должен корректно отображаться на мобильных устройствах, планшетах и десктопах (это стандарт, но лучше прописать явно).
6. Технические требования
Здесь — всё, что касается «внутренностей» сайта:
- CMS (WordPress, 1С-Битрикс, самописная)
- Хостинг и домен — есть ли уже, или нужна помощь с выбором
- SSL-сертификат — обязателен для всех сайтов в 2026 году
- Требования к скорости загрузки
- SEO-требования — базовая оптимизация или глубокая проработка
Как составить ТЗ, чтобы разработчик не завысил цену
Распространённая ошибка заказчика — дать слишком подробное ТЗ с техническими деталями, в которых сам заказчик не разбирается. Разработчик видит это и думает: «О, тут уже решили за меня — значит, правки будут бесконечные, заложу +30% к смете».
Правильный подход: в ТЗ описывайте ЧТО должен делать сайт, а не КАК. Как — решает разработчик. Например:
- ❌ «Форма должна отправлять данные через AJAX-запрос с CSRF-токеном»
- ✅ «Форма должна отправлять заявку на почту и не обновлять страницу при отправке»
Ещё один способ не переплатить — разделите функционал на «обязательный» и «желательный». Обязательный попадает в смету, желательный — опционально, если впишется в бюджет. Это даёт разработчику гибкость и снижает итоговую цену на 15–25%.
Чек-лист: 15 пунктов, которые спасут ваш проект
Перед отправкой ТЗ разработчику пройдитесь по этому списку. Каждый пункт «нет» — потенциальный источник правок и дополнительных расходов:
- ☐ Цель сайта сформулирована в одном предложении
- ☐ Целевая аудитория описана (2–3 портрета)
- ☐ Все страницы перечислены с названиями
- ☐ Для каждой страницы указан её контент (текст, фото, видео)
- ☐ Все формы описаны (какие поля, куда отправлять)
- ☐ Интеграции перечислены (CRM, оплата, рассылки)
- ☐ Дизайн-референсы приложены (минимум 3 ссылки)
- ☐ Требования к мобильной версии указаны
- ☐ Брендбук или гайдлайн приложен (если есть)
- ☐ CMS и хостинг выбраны или заданы вопросы разработчику
- ☐ Прописана SEO-стратегия (базовая или глубокая)
- ☐ Функционал разделён на «обязательный» и «желательный»
- ☐ Сроки сдачи обозначены (хотя бы желаемые)
- ☐ Критерии приёмки записаны
- ☐ Контакты ответственного лица указаны
Типичные ошибки в ТЗ и как их избежать
Ошибка 1. «Сделайте как у конкурента, но лучше». Разработчик не читает мысли. Приложите конкретные ссылки и опишите, что именно нужно повторить, а что улучшить.
Ошибка 2. ТЗ на две страницы текста сплошным полотном. Никто не будет это читать. Структурируйте: заголовки, списки, таблицы. Разработчик скажет спасибо и назовёт точную цену.
Ошибка 3. «Дизайн на ваше усмотрение». Это гарантированный путь к трём итерациям переделок. Даже если нет чёткого видения, покажите 3–5 сайтов, которые нравятся, и 2–3, которые не нравятся.
Ошибка 4. Забыть про контент. Разработчик сделает сайт, но кто наполнит его текстами и фото? Если контента нет — заложите его подготовку в ТЗ отдельной строкой. Копирайтинг и фотосъёмка — это не «само собой разумеется».
Ошибка 5. Не обсудить поддержку после сдачи. Сайт — не картина, он требует обновлений. Пропишите в ТЗ, что входит в постпроектную поддержку: обновление CMS, исправление багов, консультации. Уточните формат: разовые работы или абонентское обслуживание.
Где взять шаблон ТЗ
Не нужно изобретать велосипед. Есть готовые шаблоны, которые можно адаптировать под свой проект:
- Google Docs / Notion — создайте документ по разделам из этой статьи и заполняйте постепенно
- Брифы веб-студий — многие студии (в том числе наша на странице портфолио и услуг) предлагают заполнить бриф перед стартом проекта
- WordPress-плагины — для сложных проектов можно использовать плагины сбора требований, интегрированные в админку
На практике 80% проектов успешно стартуют с документом на 5–7 страниц, составленным по разделам из этой статьи. Главное — начать, а не откладывать «на потом».
Сколько стоит подготовка ТЗ
Три сценария:
- Самостоятельно — бесплатно, 3–7 дней работы. Подходит, если вы готовы разобраться в структуре
- С помощью разработчика — 5 000–15 000 ₽ за анализ и составление ТЗ. Многие студии включают эту услугу в стоимость проекта или предлагают как отдельную консультацию
- Бизнес-аналитик — 30 000–80 000 ₽. Детальная проработка для сложных проектов (интернет-магазины, порталы, маркетплейсы)
Важный момент: если разработчик предлагает сделать сайт «без ТЗ, по ходу разберёмся» — это красный флаг. Опытные студии не берутся за проект без зафиксированных требований, потому что знают: без ТЗ правки будут бесконечными.
Вывод
Техническое задание — не бюрократия, а страховка ваших денег и времени. Хорошее ТЗ экономит до 40% бюджета проекта за счёт отсутствия переделок. Потратьте 3–5 дней на подготовку требований до обращения к разработчику — и вы получите именно тот сайт, который нужен вашему бизнесу, без сюрпризов по срокам и бюджету.
Начните с простого: откройте Google Doc, скопируйте разделы из этой статьи и заполните их. Через пару дней у вас будет документ, с которым не стыдно идти в любую веб-студию.
Можно ли обойтись без ТЗ при заказе сайта?
Технически — да, но это рискованно. Без ТЗ вы получаете сайт «как получится», а любые правки после сдачи оплачиваются отдельно. По статистике, проекты без ТЗ требуют в 2–3 раза больше доработок по сравнению с проектами, где требования зафиксированы.
Кто должен писать ТЗ — заказчик или разработчик?
Основу ТЗ составляет заказчик — он знает свой бизнес и цели. Разработчик может помочь структурировать требования и задать правильные вопросы, но содержательное наполнение — задача заказчика. Оптимальный вариант: заказчик заполняет бриф, а разработчик на его основе готовит формализованное ТЗ.
Какой объём ТЗ считается нормальным?
Для лендинга — 3–5 страниц, для корпоративного сайта — 5–10 страниц, для интернет-магазина — 10–20 страниц. Главное — не объём, а полнота охвата: все разделы из чек-листа должны быть освещены.
Что делать, если в процессе разработки захотелось добавить новый функционал?
Это нормальная практика — она называется «дополнительное соглашение». Новые требования оформляются отдельным документом, оцениваются по времени и бюджету, и добавляются к основному договору. Главное правило: не менять ТЗ «на лету» без письменной фиксации.
Влияет ли качество ТЗ на стоимость разработки?
Напрямую. Чем детальнее ТЗ, тем точнее оценка. Разработчик видит реальный объём работ и не закладывает «запас на неизвестность». Экономия на этапе ТЗ почти всегда оборачивается перерасходом на этапе разработки.
Можно ли использовать один шаблон ТЗ для разных типов сайтов?
Базовую структуру — да. Но каждый тип сайта имеет специфику: для лендинга важен сценарий конверсии, для интернет-магазина — логистика и интеграции, для портала — ролевая модель пользователей. Адаптируйте шаблон под конкретный проект.
