«Пришлите ТЗ» — фраза, которая ставит в тупик половину заказчиков. Люди представляют многостраничный документ с терминами и откладывают проект на недели. На деле техническое задание — это просто понятный ответ на вопрос «что должно быть на сайте и как понять, что он готов». Разберём, из каких пунктов состоит рабочее ТЗ, дадим шаблон — и честно скажем, когда тяжёлое ТЗ не нужно вовсе.
Зачем нужно ТЗ и чем оно отличается от брифа
ТЗ решает одну задачу — убрать разночтения. Без него «современный сайт» для вас и для разработчика — две разные картинки, и на сдаче начинается «мы так не договаривались». ТЗ фиксирует договорённость письменно, чтобы и вы, и исполнитель проверяли результат по одному документу.
Важно не путать ТЗ с брифом. Бриф — про смысл: зачем сайт, для кого, что продаём, какой результат нужен. ТЗ — про конкретику: какие страницы, какие функции, какие формы и интеграции. Обычно заказчик заполняет бриф, а исполнитель на его основе формирует ТЗ или прототип. Как собрать бриф без тяжёлой бюрократии, мы разбирали в статье как составить бриф на сайт.
Шаблон ТЗ на сайт: разделы по пунктам
Ниже — структура ТЗ, которую поймёт любой разработчик. Это не жёсткий стандарт, а рабочий каркас: часть пунктов для вашего проекта может не понадобиться.
| Раздел | Что писать |
|---|---|
| О проекте и цели | Чем занимается бизнес, зачем сайт, какой результат считается успехом |
| Аудитория | Кто клиент, какие у него вопросы и возражения |
| Структура страниц | Перечень страниц и что на каждой — без дизайна, просто список блоков |
| Функции | Формы, калькулятор, каталог, личный кабинет, поиск — что из этого нужно |
| Формы и заявки | Какие поля, куда падают заявки (админ-панель, Telegram, MAX, почта, CRM) |
| Интеграции | CRM, 1С, оплата, запись, аналитика — что подключается |
| Контент | Кто даёт тексты и фото, что пишет исполнитель |
| Технические требования | Адаптив, скорость, домен, хостинг, безопасность данных |
| Что НЕ входит | Явно перечислить, чего в проекте не будет — снимает половину споров |
Отдельно выделю последний пункт. Раздел «что НЕ входит» бережёт нервы сильнее всех остальных: именно невысказанные ожидания («а я думал, вы и тексты напишете, и фото снимете») превращаются в конфликт на сдаче. Лучше честно договориться на берегу.
Как заполнять каждый раздел: примеры формулировок
ТЗ должно быть на человеческом языке, а не на техническом жаргоне. Хорошая формулировка описывает результат, который можно проверить. Сравните:
- Плохо: «нужна форма». Хорошо: «форма с полями имя и телефон, заявка приходит в Telegram и в админ-панель, клиент видит сообщение Спасибо, перезвоним в течение 15 минут».
- Плохо: «каталог товаров». Хорошо: «каталог на ~120 позиций, фильтр по типу и цене, карточка товара с фото и кнопкой Запросить расчёт, без онлайн-оплаты».
- Плохо: «сайт должен быстро работать». Хорошо: «PageSpeed 90+ на мобильном, изображения в современных форматах».
- Плохо: «подключить CRM». Хорошо: «заявки с сайта автоматически создают сделку в amoCRM с заполненными имя, телефон и источник».
Принцип один: формулировка хороша, если по ней можно однозначно сказать «сделано» или «не сделано». Всё остальное — повод для спора. Частые промахи на этом этапе мы собрали в статье ошибки при заказе сайта.
Когда тяжёлое ТЗ не нужно
Честно: для лендинга или небольшого сайта многостраничное формальное ТЗ чаще вредит. Пока вы его пишете и согласуете, проект стоит; а описать словами, как должна выглядеть страница, почти невозможно — текст всё равно читается у всех по-разному.
Лучшее ТЗ для простого сайта — это не документ, а прототип, который можно открыть и кликнуть. На нём сразу видно то, о чём в тексте спорили бы неделю.
Поэтому для простых проектов мы заменяем тяжёлое ТЗ связкой «бриф плюс кликабельный прототип». Прототип главной мы делаем бесплатно, до оплаты, за 3 рабочих дня — на нём видно структуру, блоки и путь к заявке. Это нагляднее любого описания и фиксирует объём не хуже формального документа. Как в целом идёт работа над сайтом, разобрано в статье этапы создания сайта.
Частые ошибки в ТЗ
- Писать ТЗ на техническом жаргоне, который понятен только автору. Разработчик всё равно будет переспрашивать.
- Описывать дизайн словами. «Красиво и современно» ничего не значит — это задача прототипа и макета, а не текста.
- Забыть раздел «что НЕ входит». Именно невысказанные ожидания рождают конфликты на сдаче.
- Раздувать ТЗ ради объёма. Длинный документ не значит хороший — важна проверяемость пунктов.
- Не фиксировать правки по ходу. Крупные изменения — это новый объём работ, а не мелочь внутри прежней цены.
Что в итоге дать разработчику
- Короткий бриф: что за бизнес, зачем сайт, кто клиент.
- Перечень страниц и что на каждой — хотя бы списком.
- Нужные функции: формы, каталог, запись, оплата, кабинет.
- Куда должны падать заявки и с какими системами связать сайт.
- Кто даёт контент — тексты и фото.
- Явный список того, чего в проекте быть не должно.
С чего начать
Не садитесь писать многостраничное ТЗ с нуля — скорее всего, вы потратите неделю и всё равно упустите половину. Начните с простого: перечислите страницы, нужные функции и то, куда должны приходить заявки. Этого достаточно, чтобы разработчик понял объём.
Напишите нам пару абзацев про ваш бизнес и задачу — остальное вытащим вопросами и соберём в понятное ТЗ или сразу в прототип. Кликабельный прототип главной сделаем бесплатно за 3 рабочих дня, работаем по этапам, оплата 50 на 50. Так вы увидите будущий сайт раньше, чем дописали бы классическое ТЗ, а споры «не так договаривались» снимаются на старте.