Главное за минуту
- Начинайте ТЗ с цели и пользовательского сценария, а не с перечня страниц.
- Для каждой формы фиксируйте поля, обязательность, UTM и правило создания сущности в CRM.
- Критерии приёмки должны позволять проверить задачу без догадок и доступа к коду.
- Макеты важны, но не заменяют описание ошибок, ограничений и бизнес-логики.
01
ТЗ начинается с маршрута пользователя
Когда маркетолог просит «сделать новую страницу», разработчик видит набор неизвестных: откуда придёт трафик, какое действие считается целевым, куда попадут данные и кто их обработает. Поэтому сначала опишите маршрут: рекламное объявление → посадочная страница → форма → лид или сделка в CRM → ответ менеджера.
В практике ICONICA типовая проблема выглядит так: страница согласована по макету, но после запуска нельзя отличить заявки из кампаний, часть полей не передаётся, а менеджер получает письмо без источника. Эти условия нужно зафиксировать до оценки.
02
Карточка сценария
Один сценарий связывает цель, интерфейс, данные и проверку результата в единую задачу.
03
Из каких частей собрать техническое задание на сайт
Не пытайтесь описать всё одним документом «на 40 страниц». Соберите ТЗ из блоков, которые можно согласовать с владельцем процесса, маркетингом и подрядчиком. Для сложной разработки к нему добавляют прототип, карту интеграций и спецификацию API.
Цель
Какой показатель или процесс должна изменить доработка.
Сценарии
Что делает посетитель, менеджер и администратор сайта.
Данные
Поля, форматы, источники, согласия и правила передачи.
Приёмка
Набор действий и ожидаемых результатов для проверки.
Если сайт работает на 1С-Битрикс, отдельно укажите: где редактируется контент, нужны ли новые свойства инфоблока, права доступа и что происходит при пустом значении. Документацию по инфоблокам удобно сверять в официальном API 1С-Битрикс.
04
Что написать о формах, CRM и аналитике
Форма — это не только поля на странице. В ТЗ нужно описать данные до отправки, после отправки и действия при ошибке.
| Параметр | Что зафиксировать | Как проверить |
|---|---|---|
| Поля | Название, тип, обязательность, маска телефона | Неверный email не отправляется |
| CRM | Сущность, ответственный, источник, защита от дублей | Создан лид с нужными значениями |
| UTM | Список меток и поле хранения | Метка из URL видна в карточке |
| Согласие | Текст, ссылка на политику, обязательность | Без согласия отправка недоступна |
05
Шаблон постановки задачи подрядчику
Скопируйте структуру ниже в задачу. Значения в квадратных скобках замените на свои: это минимальный уровень детализации, с которого можно запросить оценку.
Готовое сообщение
Цель: [увеличить заявки / сократить ручную обработку / запустить кампанию].
Сценарий: посетитель приходит по [каналу], открывает [страницу], заполняет [форму], видит [сообщение].
Поля и данные: [перечень полей], обязательные — [список]. Передавать в [CRM, сущность], включая [UTM, страницу, время, согласие].
Ограничения: [адаптив, браузеры, права редактора, антиспам, сроки].
Приёмка: на тестовой ссылке отправить форму с UTM; в CRM появляется [сущность] с [полями]; дубль обрабатывается по [правилу]; редактор меняет [контент] без разработчика.
06
Как принять работу до публикации
Проверяйте не только внешний вид. Повторите маршрут пользователя на тестовой копии сайта, а затем проверьте результат на стороне CRM и аналитики.
- 1
Откройте ссылку с UTM. Убедитесь, что метки не исчезают при переходах и отправке формы.
- 2
Заполните форму корректно. Проверьте обязательные поля, маски, согласие и текст успешной отправки.
- 3
Создайте ошибку. Отправьте пустую форму и неверный email: сообщения должны быть понятными.
- 4
Проверьте CRM. Сверьте сущность, значения полей, ответственного и отсутствие лишних дублей.
- 5
Проверьте редактора. Измените предусмотренный текст в админке и убедитесь, что вёрстка не ломается.
07
Ошибки, которые делают ТЗ дорогим
Самые затратные уточнения появляются после старта, когда разные участники по-разному понимают слово «готово».
Не пишите «как на другом сайте»
Ссылка может быть ориентиром, но не спецификацией. Укажите, какой элемент нужен, что он делает, на каких устройствах работает и какие данные меняет.
08
Когда ТЗ лучше делать вместе с подрядчиком
Привлекайте аналитика до разработки, если меняется несколько систем, нужна личная зона, нестандартный каталог или непонятна логика продаж. Посмотрите подход к проектированию в кейсах портфолио ICONICA: исходные ограничения и критерии результата важнее декоративного описания экранов.
Цель сформулирована; сценарии описаны; поля и статусы CRM сопоставлены; UTM определены; редакторские права названы; тесты приёмки согласованы; тестовая среда предусмотрена.
FAQ
Частые вопросы
Можно ли написать ТЗ без дизайна?
Да. Сначала опишите сценарии и требования, затем добавьте прототип или макеты. Визуал не должен заменять бизнес-логику.
Какой объём ТЗ нужен для небольшой правки?
Достаточно цели, места изменения, сценария, ограничений и двух-трёх критериев приёмки.
Кто согласует ТЗ со стороны клиента?
Владелец процесса подтверждает логику, маркетинг — коммуникацию и аналитику, продажи — данные CRM, технический специалист — ограничения.
Нужно ли описывать мобильную версию отдельно?
Да, если поведение отличается: порядок блоков, состав полей, меню, фиксированные кнопки или условия показа.
