Как написать ТЗ: короткий шаблон задачи разработчику

01

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

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

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

В практике ICONICA такие задачи часто начинают с одного вопроса: что именно должно стать иначе после релиза? Ответ «форма должна работать» не подходит: она может отправлять письмо, но не создавать лид или терять UTM-метки. Ответ «после отправки на странице /akciya/ создается лид в CRM, а менеджер видит телефон, страницу и источник рекламы» уже можно оценивать, реализовывать и принимать.

Не пытайтесь заранее выбрать PHP-модуль, API-метод или структуру компонента 1С-Битрикс. Это зона исполнителя. Заказчик отвечает за сценарий, исходные данные и критерий результата. Если технический способ критичен — например, нельзя менять текущую CRM-интеграцию, — укажите это как ограничение, а не как предположение о реализации.

03

Пять частей короткого ТЗ для доработки сайта

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

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

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

04

Мини-кейс: форма акции без понятного источника заявок

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

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

Отдельно проверьте, кто принимает решение о дублях и источнике правды. Разработчик может реализовать правило, но не должен угадывать бизнес-логику продаж. Полезно сделать тестовую отправку с уникальным номером и UTM, затем найти ее в CRM и сверить все значения. В портфолио ICONICA можно ориентироваться на реальные примеры процессов и интерфейсов, а не на вымышленные скриншоты: портфолио проектов.

05

Готовый шаблон: заполните его перед передачей в работу

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

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

Ссылки на макеты, тексты, политику обработки данных и доступы не нужно вставлять в саму формулировку, если они выданы отдельно. Но укажите их статус: приложены, предоставит заказчик до старта или нужны от подрядчика. Это влияет на срок и помогает не принять частичную работу за готовое решение.

06

Как проверить задачу до оценки и после релиза

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

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

Записывайте результаты приемки в тикете: дата, URL, тестовые данные и итог. Это позволяет отличить дефект разработки от ограничения CRM, блокировки почты или неверно введенной заявки. Такой журнал особенно полезен, когда поддержку сайта и CRM ведут разные подрядчики.

1. 1

   Соберите исходные ссылки. Укажите страницу, макет, тексты, политику и действующую форму, если она есть.

2. 2

   Пройдите текущий сценарий. Отправьте тест и зафиксируйте, куда попали данные и чего в результате не хватает.

3. 3

   Утвердите карту полей. Назначьте обязательность, формат, CRM-получатель и правила для дублей.

4. 4

   Согласуйте границы. Отдельно назовите страницы и интеграции, которые не должны измениться.

5. 5

   Проведите приемку. Проверьте интерфейс, CRM, UTM и повторную отправку по согласованному сценарию.

07

Четыре ошибки, из-за которых задача возвращается на уточнение

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

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

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

08

Когда короткого шаблона недостаточно

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

Сигнал к детализации — разные ответы участников на вопрос «что будет, если». Что будет, если CRM недоступна? Если клиент отправил форму дважды? Если UTM отсутствуют? Если менеджер не имеет права видеть сделку? Эти исключения не всегда требуется реализовывать сразу, но решение по ним нужно зафиксировать до старта.

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

09

Что отправить разработчику сегодня

Начните не с технического решения, а с одной страницы: цель, ссылка на место изменения, сценарий пользователя, список данных и критерии приемки. Для формы на сайте этого достаточно, чтобы исполнитель понял объем, увидел вопросы до оценки и не подменил бизнес-результат формальной установкой кнопки.

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

Подключайте подрядчика на этапе разбора, если изменение затрагивает текущую CRM-интеграцию, обработчики 1С-Битрикс, персональные данные или несколько систем. Техническая проверка до старта обычно дешевле, чем исправление уже запущенной доработки. Хорошая задача оставляет разработчику свободу выбрать реализацию, но не оставляет свободы гадать, какой результат нужен бизнесу.