Как составить ТЗ для разработчика: цель, поля, сценарии и приемка

01

ТЗ начинается с результата, который нужен бизнесу

Когда маркетолог пишет «нужно сделать форму», разработчик видит только способ реализации. Неясно, зачем нужна форма, какие обращения она должна отсеивать, кто получает заявку и что считается успешным запуском. В результате команда может аккуратно сверстать блок, но не передать источник лида в CRM, не настроить уведомление или оставить посетителю непонятное сообщение об ошибке.

Перед тем как составить техническое задание, сформулируйте цель в связке «изменение — ожидаемый эффект — способ проверки». Например: «Добавить форму расчета на странице услуги, чтобы менеджеры получали квалифицированные обращения в Битрикс24; после отправки создается лид с телефоном, услугой и UTM-метками». Такая формулировка не подменяет результат дизайном и дает разработчику границы задачи.

Отделите обязательный минимум от пожеланий. В минимум входят страница, форма, поля, получатель, логика отправки и аналитика. Пожелания — анимация, дополнительные подсказки, вариации текста — не должны блокировать запуск. Если задача затрагивает существующий сайт на 1С-Битрикс, приложите URL, доступ к тестовой среде и укажите, что нельзя сломать: действующие формы, SEO-адреса, корзину, интеграцию с CRM.

Не используйте в цели слова «удобно», «современно» и «быстро» без расшифровки. Их нельзя принять. Вместо «форма должна быстро работать» укажите: «после нажатия кнопка блокируется, посетитель видит результат не позднее чем через 3 секунды, повторный клик не создает второй лид».

03

Опишите путь пользователя и данных, а не только экран

Сценарий в ТЗ отвечает на вопрос «что происходит после действия». Его полезно писать от лица посетителя, затем отдельно проверить путь менеджера. Посетитель открывает страницу с рекламной UTM-меткой, заполняет форму, видит подтверждение. Сайт валидирует данные, создает сущность в CRM, передает метки и фиксирует цель аналитики. Менеджер открывает карточку и понимает, какая услуга интересует клиента и откуда пришло обращение.

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

Сценарии должны включать не только идеальный путь. Пользователь может не заполнить телефон, CRM может временно не ответить, а запрос может быть отправлен повторно. В каждом случае укажите видимое пользователю сообщение, действия системы и ответственного за разбор сбоя. Для интеграций с Битрикс24 полезно сверить допустимые методы и поля в справке Битрикс24 до постановки задачи.

04

Зафиксируйте поля как контракт между сайтом и CRM

Список полей в макете недостаточен. Одно и то же «Имя» может храниться в CRM как стандартное поле, пользовательское свойство или вовсе не передаваться. Поэтому для каждого значения в ТЗ нужны четыре характеристики: подпись для посетителя, техническое имя или понятное назначение, правило заполнения и место назначения. Если поле не передается, это тоже стоит отметить.

Особое внимание уделите скрытым данным. UTM-метки, URL страницы, referer, идентификатор формы и время отправки не видны посетителю, но помогают маркетингу связать лид с рекламой и разобраться в спорной ситуации. Укажите правило, когда метка сохраняется: при первом заходе, при последнем заходе или только из текущего URL. Иначе отчетность разных каналов начнет расходиться.

Согласуйте справочники заранее. Если в форме выбирают услугу, а в CRM есть список направлений, перечислите допустимые значения. Формулировка «передавать выбранную услугу» не защищает от ситуации, когда на сайте «SEO-аудит», а в CRM — «Поисковая оптимизация», и автоматизация не срабатывает.

05

Добавьте ограничения и границы ответственности

ТЗ становится управляемым, когда в нем указано, что входит в работу, а что нет. Например, «разработчик подключает форму к существующему порталу Битрикс24, но не создает новые воронки, роботы и права доступа». Это не бюрократия: границы позволяют получить сопоставимую оценку и избежать ожидания функциональности, которая не была заказана.

Отдельно перечислите доступы и материалы со стороны заказчика: административный доступ к сайту, тестовый аккаунт CRM, доступ к аналитике, тексты согласий на обработку данных, макет или ссылка на прототип. Если доступа нет, укажите, кто и к какой дате его выдает. Нельзя считать интеграцию готовой, пока исполнитель не смог проверить ее в реальном контуре.

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

ТЗ не обязано описывать код. Оно обязано исключить разные трактовки результата, данных, сроков и ответственности.

06

Превратите требования в короткий маршрут приемки

Приемка не должна начинаться с вопроса «ну что, все работает?». Подготовьте тестовые данные еще до передачи задачи: номер телефона, набор UTM-меток, вариант с незаполненным обязательным полем и вариант повторной отправки. Тогда маркетолог проверит не только внешний вид, но и то, что заявка сохранила рекламный источник.

Проводите тест на той среде, где реально работает посетитель. Проверка только в админке сайта не покажет проблемы с кешированием, JavaScript, мобильной версией или блокировщиками. После переноса на боевой сайт повторите минимальный сценарий и сохраните ссылку на тестовую заявку в задаче.

Критерий приемки должен быть бинарным: выполнен или нет. «Поля заполнены корректно» замените на перечень конкретных полей и значений. «Нет дублей» — на проверку: один клик по кнопке создает ровно одну сущность. Так согласование не превращается в обмен субъективными впечатлениями.

1. 1

   Откройте страницу с метками. Используйте URL с utm_source=test, utm_medium=cpc и utm_campaign=tz-check.

2. 2

   Проверьте валидацию. Отправьте пустую форму и неверный телефон; сообщения должны быть понятны, а лид не создан.

3. 3

   Отправьте корректные данные. Зафиксируйте время, страницу и введенные значения для сверки в CRM.

4. 4

   Сверьте карточку CRM. Проверьте телефон, услугу, комментарий, UTM, URL, ответственного и отсутствие дубля.

5. 5

   Проверьте аналитику. Убедитесь, что цель отправки сработала один раз и не записалась при ошибке.

07

Типовые ошибки, из-за которых ТЗ не защищает результат

Первая ошибка — описывать решение раньше проблемы. Фраза «сделать попап и отправлять на почту» закрепляет случайный способ, хотя бизнесу может быть нужен лид в CRM, привязанный к кампании. Вторая — не назначать владельца решения. Разработчик завершает код, но никто не отвечает за выдачу CRM-доступа, текст согласия или проверку рекламы.

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

Если задача затрагивает нестандартный компонент или обработчик на 1С-Битрикс, попросите указать способ сопровождения: где находятся изменения, как они переживут обновление и кто получит инструкцию. Это особенно важно для сайта, который поддерживает несколько подрядчиков.

08

Когда достаточно шаблона, а когда нужен разбор с подрядчиком

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

Совместный разбор нужен, если задача пересекает несколько систем: сайт, CRM, платежи, 1С, личный кабинет, рекламу и BI-отчеты. Здесь ошибка в одном поле может не проявиться на странице, но испортить маршрутизацию лида или данные в отчете. До оценки работ полезно построить схему обмена, определить владельцев доступов и согласовать источник истины для каждого значения.

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

09

ТЗ готово, когда его можно проверить без автора

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

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

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