Зачем нужна жёсткая структура ТЗ
Техническое задание выполняет две функции одновременно: служит инструкцией для исполнителя и юридической рамкой для заказчика. Без чёткой структуры возникают классические проблемы — настройщик делает «как понял», а заказчик ожидал «как хотел».
По нашему опыту работы с проектами разного масштаба, большинство разногласий при сдаче работ связаны не с качеством настройки, а с тем, что требования изначально не были зафиксированы в документе. Структурированное ТЗ закрывает этот риск.
Перед составлением ТЗ рекомендуется провести интервью с ключевыми пользователями — это позволяет собрать требования полно и не упустить нюансы на этапе написания документа.
Блок 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. Ограничения и «не входит в объём»
Один из самых важных блоков с точки зрения управления ожиданиями. Здесь явно перечисляется:
- что не делается в рамках данного ТЗ (программирование, интеграции следующего этапа, доработка сторонних систем);
- работы, которые выполняются только в рамках штатного функционала выбранного тарифа;
- задачи, отложенные на следующую итерацию внедрения.
По нашей практике, чёткое разграничение «входит / не входит» — главный инструмент против переделок и конфликтов при сдаче проекта.
Как собрать данные для ТЗ
Стандартный процесс подготовки ТЗ включает два этапа:
- Интервью с представителями заказчика — сбор требований, описание текущих процессов, согласование логики работы.
- Составление документа — формализация требований в виде таблиц, схем и текстовых описаний.
В типовых проектах на оба этапа суммарно уходит от 10 до 15 часов работы бизнес-аналитика. Для проектов с комплексной автоматизацией (согласования, интеграции, нестандартные сущности) объём может быть больше. Если вы хотите понять, сколько часов заложить на весь проект, ориентируйтесь на данные из реальных планов работ.
Формат итогового документа — таблицы, текст, схемы — определяется аналитиком исходя из того, что нагляднее описывает конкретный процесс.