Полнота технического задания на доработку Битрикс24 напрямую определяет точность оценки, сроки и итог настройки. Ниже - 12 блоков, которые должны быть в любом ТЗ, независимо от масштаба проекта.
Техническое задание работает сразу на двух уровнях: инструкция для исполнителя и юридическая рамка для заказчика. Без чёткой структуры всплывает классика - настройщик сделал «как понял», заказчик ждал «как хотел».
По нашему опыту, большинство разногласий при сдаче работ возникают не из-за плохой настройки. Причина проще: требования изначально нигде не зафиксированы. Структурированное ТЗ этот риск убирает.
Перед составлением документа рекомендуем провести интервью с ключевыми пользователями - так требования собираются полнее и нюансы не теряются на этапе написания.
Первый блок отвечает на простой вопрос: зачем вообще затевается доработка? Здесь фиксируется:
Без этого блока исполнитель работает вслепую и рискует сделать формально правильное, но бизнесу бесполезное.
Заказчик говорит «заявка», а имеет в виду то, что в Битрикс24 называется «лид» или «сделка». Путаница в терминах - прямой путь к переделкам.
Минимальный набор понятий, который стоит зафиксировать:
| Термин заказчика | Сущность Битрикс24 |
|---|---|
| Заявка / обращение | Лид |
| Сделка / проект | Сделка |
| Клиент / контрагент | Контакт / Компания |
| Задача по сделке | Дело / Задача |
| Автоматическое действие | Робот / Бизнес-процесс |
Такой глоссарий снимает двусмысленность и при согласовании ТЗ, и при приёмке работ.
Центральный блок для проектов с CRM. Здесь описывается:
В типовом проекте воронка содержит от 5 до 15 стадий. Для каждой имеет смысл прописать, что должно произойти при входе на неё и что - при выходе.
flowchart LR
A[Новый лид] --> B[Квалификация]
B --> C[Коммерческое предложение]
C --> D[Согласование]
D --> E{Решение}
E -->|Успех| F[Выигран]
E -->|Отказ| G[Проигран]
D -->|Доработка| C
Для каждой сущности - лида, сделки, контакта, компании - фиксируется список полей:
В типовом проекте суммарно по всем воронкам настраивается до 50 полей. Если одно поле используется в нескольких воронках - оно считается как одно.
Этот блок определяет, кто и что видит в системе. Типовые роли: менеджер, руководитель отдела, администратор. Для каждой роли указывается:
Настройка прав напрямую связана с логикой распределения лидов между менеджерами - удобнее описать это в одном блоке или дать перекрёстную ссылку внутри ТЗ.
Здесь перечисляется каждое автоматическое действие с указанием:
Роботов и бизнес-процессы нужно разграничить. Роботы настраиваются через интерфейс без программирования. Бизнес-процессы - это более сложные цепочки с ветвлением и многоуровневыми согласованиями. Например, согласование договоров в Битрикс24 реализуется именно через бизнес-процесс с несколькими ветками и возможностью отклонения на любом этапе.
Для каждой интеграции фиксируется:
При интеграции с 1С, например, нужно заранее договориться, кто пишет ТЗ для разработчика 1С. У нас в проектах это, как правило, задача аналитика со стороны интегратора Битрикс24, а реализация на стороне 1С - силами заказчика.
Если нужно автоматически формировать договоры, счета, акты или коммерческие предложения, в ТЗ прописывается:
Этот блок чаще всего «обнаруживается» уже на этапе настройки как забытый. Результат - расширение объёма работ и неприятный разговор с заказчиком.
Фиксируется, кто, кому и в каком случае получает уведомление:
Для каждого уведомления нужен текст или шаблон с переменными полями.
Описываются нужные отчёты и дашборды:
Когда данные из разных источников нужно собрать в единый дашборд - это требует отдельного описания логики сборки.
ТЗ должно содержать раздел о том, что входит в передачу результата:
В типовом проекте предусмотрено двухчасовое групповое обучение с записью экрана. Для более сложных внедрений - четыре часа с разбивкой по ролям.
По нашей практике, именно этот блок чаще всего спасает от конфликтов при сдаче. Здесь явно перечисляется:
Чёткое разграничение «входит / не входит» - главный инструмент против переделок и неудобных разговоров при сдаче проекта.
Стандартный процесс подготовки ТЗ состоит из двух этапов:
В типовых проектах на оба этапа суммарно уходит от 10 до 15 часов работы бизнес-аналитика. Проекты с комплексной автоматизацией - согласования, интеграции, нестандартные сущности - выходят за этот диапазон. Если хотите понять, сколько часов закладывать на весь проект, ориентируйтесь на данные из реальных планов работ.
Формат итогового документа - таблицы, текст, схемы - аналитик выбирает исходя из того, что нагляднее описывает конкретный процесс.
Оставьте заявку - мы свяжемся с вами и проконсультируем.
Эксперт АС Проект свяжется в течение 60 минут.