Структура ТЗ на доработку Битрикс24: 12 обязательных блоков

Зачем нужна жёсткая структура ТЗ

Техническое задание работает сразу на двух уровнях: инструкция для исполнителя и юридическая рамка для заказчика. Без чёткой структуры всплывает классика — настройщик сделал «как понял», заказчик ждал «как хотел».

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

Перед составлением документа рекомендуем провести интервью с ключевыми пользователями — так требования собираются полнее и нюансы не теряются на этапе написания.

Блок 1. Цель и контекст проекта

Первый блок отвечает на простой вопрос: зачем вообще затевается доработка? Здесь фиксируется:

• текущая ситуация — что работает не так или чего не хватает;
• бизнес-цель изменений: ускорить обработку заявок, убрать ручной ввод, выстроить контроль согласований и т. д.;
• связь с другими системами — 1С, сайт, телефония, мессенджеры.

Без этого блока исполнитель работает вслепую и рискует сделать формально правильное, но бизнесу бесполезное.

Блок 2. Глоссарий и договорённость о терминах

Заказчик говорит «заявка», а имеет в виду то, что в Битрикс24 называется «лид» или «сделка». Путаница в терминах — прямой путь к переделкам.

Минимальный набор понятий, который стоит зафиксировать:

Термин заказчика	Сущность Битрикс24
Заявка / обращение	Лид
Сделка / проект	Сделка
Клиент / контрагент	Контакт / Компания
Задача по сделке	Дело / Задача
Автоматическое действие	Робот / Бизнес-процесс

Такой глоссарий снимает двусмысленность и при согласовании ТЗ, и при приёмке работ.

Блок 3. Воронки и стадии

Центральный блок для проектов с CRM. Здесь описывается:

• перечень воронок (лиды, сделки, Смарт-процессы);
• стадии каждой воронки в нужном порядке;
• условия перехода между стадиями — вручную менеджером или автоматически;
• финальные стадии: успешные и провальные.

В типовом проекте воронка содержит от 5 до 15 стадий. Для каждой имеет смысл прописать, что должно произойти при входе на неё и что — при выходе.

flowchart LR
    A[Новый лид] --> B[Квалификация]
    B --> C[Коммерческое предложение]
    C --> D[Согласование]
    D --> E{Решение}
    E -->|Успех| F[Выигран]
    E -->|Отказ| G[Проигран]
    D -->|Доработка| C

Блок 4. Карточки сущностей и поля

Для каждой сущности — лида, сделки, контакта, компании — фиксируется список полей:

• стандартные поля Битрикс24, которые нужно использовать;
• пользовательские поля с указанием типа: строка, список, дата, привязка к справочнику;
• обязательность заполнения на конкретных стадиях;
• видимость для разных ролей.

В типовом проекте суммарно по всем воронкам настраивается до 50 полей. Если одно поле используется в нескольких воронках — оно считается как одно.

Блок 5. Роли, права и видимость данных

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

• доступ к сделкам: свои / отдела / все;
• доступ к контактам и компаниям;
• возможность экспорта данных;
• видимость аналитики.

Настройка прав напрямую связана с логикой распределения лидов между менеджерами — удобнее описать это в одном блоке или дать перекрёстную ссылку внутри ТЗ.

Блок 6. Автоматизация: роботы и бизнес-процессы

Здесь перечисляется каждое автоматическое действие с указанием:

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

Роботов и бизнес-процессы нужно разграничить. Роботы настраиваются через интерфейс без программирования. Бизнес-процессы — это более сложные цепочки с ветвлением и многоуровневыми согласованиями. Например, согласование договоров в Битрикс24 реализуется именно через бизнес-процесс с несколькими ветками и возможностью отклонения на любом этапе.

Блок 7. Интеграции с внешними системами

Для каждой интеграции фиксируется:

• система: 1С, сайт, телефония, мессенджеры, маркетплейсы;
• направление обмена: из Битрикс24 в систему, из системы в Битрикс24 или двусторонний;
• передаваемые объекты и поля;
• условия и частота синхронизации;
• ответственная сторона за настройку «на той стороне».

При интеграции с 1С, например, нужно заранее договориться, кто пишет ТЗ для разработчика 1С. У нас в проектах это, как правило, задача аналитика со стороны интегратора Битрикс24, а реализация на стороне 1С — силами заказчика.

Блок 8. Генерация документов

Если нужно автоматически формировать договоры, счета, акты или коммерческие предложения, в ТЗ прописывается:

• перечень документов;
• шаблон каждого с указанием подставляемых полей из карточки;
• условие запуска: стадия, кнопка или бизнес-процесс;
• формат вывода: PDF или DOCX.

Этот блок чаще всего «обнаруживается» уже на этапе настройки как забытый. Результат — расширение объёма работ и неприятный разговор с заказчиком.

Блок 9. Уведомления и коммуникации

Фиксируется, кто, кому и в каком случае получает уведомление:

• внутренние уведомления в Битрикс24: колокольчик, чат;
• e-mail-уведомления сотрудникам и клиентам;
• сообщения в мессенджерах — WhatsApp, Telegram — через подключённые каналы.

Для каждого уведомления нужен текст или шаблон с переменными полями.

Блок 10. Аналитика и отчёты

Описываются нужные отчёты и дашборды:

• стандартная аналитика CRM: воронка, динамика сделок, эффективность менеджеров;
• пользовательские отчёты через универсальные списки или BI-коннектор;
• права на просмотр по ролям.

Когда данные из разных источников нужно собрать в единый дашборд — это требует отдельного описания логики сборки.

Блок 11. Обучение и сопровождение

ТЗ должно содержать раздел о том, что входит в передачу результата:

• формат обучения: онлайн, запись экрана;
• продолжительность и аудитория: все сотрудники, руководители или только администраторы;
• период поддержки после внедрения и условия обращений.

В типовом проекте предусмотрено двухчасовое групповое обучение с записью экрана. Для более сложных внедрений — четыре часа с разбивкой по ролям.

Блок 12. Ограничения и «не входит в объём»

По нашей практике, именно этот блок чаще всего спасает от конфликтов при сдаче. Здесь явно перечисляется:

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

Чёткое разграничение «входит / не входит» — главный инструмент против переделок и неудобных разговоров при сдаче проекта.

---

Как собрать данные для ТЗ

Стандартный процесс подготовки ТЗ состоит из двух этапов:

1. Интервью с представителями заказчика — сбор требований, описание текущих процессов, согласование логики работы.
2. Составление документа — формализация требований в виде таблиц, схем и текстовых описаний.

В типовых проектах на оба этапа суммарно уходит от 10 до 15 часов работы бизнес-аналитика. Проекты с комплексной автоматизацией — согласования, интеграции, нестандартные сущности — выходят за этот диапазон. Если хотите понять, сколько часов закладывать на весь проект, ориентируйтесь на данные из реальных планов работ.

Формат итогового документа — таблицы, текст, схемы — аналитик выбирает исходя из того, что нагляднее описывает конкретный процесс.