Как поставить задачу интегратору Битрикс24: что написать в ТЗ на доработку

Начните с одного случая, который мешает работе

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

Техническое задание, или ТЗ, на доработку Битрикс24 не обязано быть объёмным документом. Для одной задачи полезнее несколько связанных примеров, чем длинный перечень пожеланий без приоритетов. Опишите проблему словами сотрудника, а выбор технического способа оставьте исполнителю после проверки действующего портала.

Отделите доработку от изменения рабочего правила. Если сотрудники не договорились, кто готовит документы и в какой момент заказ считается подтверждённым, настройка автоматизации не разрешит этот спор. Сначала руководитель процесса принимает решение, затем интегратор отражает его в системе.

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

Покажите текущее поведение на обезличенных примерах

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

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

Уточните, с какого момента возникла проблема. Возможно, недавно добавили обязательное поле, сменили воронку или подключили приложение. Это не доказывает причину, но помогает направить проверку. Формулировка «после обновления всё сломалось» должна сопровождаться конкретным изменившимся действием.

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

Если причины нескольких сбоев пока неизвестны, начните с проверки действующей CRM, а после неё выделите отдельные доработки.

Опишите будущий процесс без преждевременного выбора кода

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

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

Не требуйте программную доработку до проверки стандартных возможностей. Интегратор может предложить настройку полей, прав или существующей автоматизации. Если требуется отдельное приложение, попросите объяснить причину и последствия для сопровождения. Заказчику важен устойчивый результат, а не максимальный объём кода.

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

Согласуйте поля, связи и доступы к результату

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

Битрикс24 позволяет связывать компании, контакты и сделки; настройка таких связей и доступ к изменению зависят от прав. Поэтому проверяйте доработку под ролью обычного сотрудника, который будет ей пользоваться. Успех под учётной записью администратора не доказывает работоспособность для менеджера.

Укажите, кто может менять исходные данные и кому разрешено видеть результат. Руководителю отдела может требоваться общий список, а сотруднику — только назначенные ему задачи. Не расширяйте доступ ко всей базе ради одной функции, пока исполнитель не объяснил необходимый объём полномочий.

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

Обсудите повтор, отмену и временную ошибку

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

Для повторного действия определите, нужно ли создать новый результат или сохранить прежний. Например, повторный переход на стадию не должен безусловно создавать ещё одну одинаковую задачу. Но при новом заказе того же клиента отдельная задача может быть необходима. Различие должно опираться на событие и объект, а не только на совпадение имени клиента.

Если решение использует программный интерфейс Битрикс24, исполнителю необходимо учитывать его ограничения. Документация REST API описывает лимиты, которые зависят от условий использования. Заказчику не нужно рассчитывать техническую очередь: в ТЗ достаточно потребовать обработку временного отказа, понятное обнаружение ошибки и согласованный порядок повторной попытки.

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

Переведите требования в сценарии приёмки

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

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

Используйте компактную таблицу.

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

Получите оценку с допущениями и составом передачи

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

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

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

Любое изменение требований после оценки записывайте вместе с влиянием на срок и стоимость. Устная просьба «добавить ещё одно поле» может оказаться простой, а может затронуть обмен и отчёт. Пусть исполнитель оценит последствия до выполнения, а владелец задачи подтвердит нужность изменения.

Что передать интегратору перед первым обсуждением

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

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

Готовое ТЗ позволяет ответить на три вопроса: какую проблему устраняем, где заканчивается задача и как докажем результат. Если описание пока не даёт этих ответов, начните с совместного разбора. ШТАБ ИТ поможет сформулировать доработку Битрикс24 по рабочим примерам и отделить необходимые изменения от необязательных пожеланий.