CRM-платформа с low-code/no-code-настройкой: пользователь сам собирает объектную модель раздела, настраивает бизнес-процессы и маршруты согласования под свой бизнес. Дизайнер бизнес-процессов — инструмент, через который пользователь описывает автоматизации в системе: что должно происходить при определённых событиях, как данные должны двигаться между разделами, какие уведомления и действия должны срабатывать без участия человека.
TL;DR
Дизайнер бизнес-процессов — ключевой модуль продукта. Это визуальный конструктор автоматизаций: пользователь собирает процесс из элементов (триггеры, действия с данными, шлюзы, уведомления) на холсте. Дизайнер раздела даёт возможность настраивать структуру данных, бизнес-процессы — описывать, как эти данные ведут себя в работе.
Над дизайнером бизнес-процессов работал в роли продакт-менеджера и продуктового дизайнера, с end-to-end ответственностью на всех этапах. Команда — семь человек: я, ещё один продуктовый дизайнер, которого менторил по ходу проекта, два фронтенд-разработчика, два бэкенд-разработчика и тестировщик.
На мне был весь цикл: проработка структуры конструктора, проектирование интерфейса для каждого типа элемента, проработка движка исполнения с точки зрения интерфейса, защита решений перед бизнесом, декомпозиция на пользовательские истории, груминги с командой, поддержка разработки до релиза.
В рамках проекта собрал визуальный конструктор процессов с триггерами разного типа, CRUD-операциями над записями, шлюзами для ветвления логики, формулами для работы с параметрами и встроенными уведомлениями. Дополнительно — две связанные с конструктором таблицы: библиотека процессов и журнал запущенных процессов с отображением статусов исполнения по каждому элементу.
Ниже — обзор того, как устроен инструмент и какие продуктовые решения в его основе.
Уведомления как элемент бизнес-процессов
Внедрение уведомлений в существующий движок автоматизаций — отдельным элементом, который можно ставить в процессы наравне с действиями и шлюзами.
Ситуация
Уведомления — одна из базовых функций системы: пользователь должен узнавать о событиях, которые его касаются. Назначили активность, изменился статус по записи, в которой он указан, и т. д. Формулировка на старте была общая, без подробностей о том, как именно это должно работать.
Задача
Закрыть сценарий, при котором пользователь получает уведомления о значимых для него событиях в системе, и сделать настройку этих уведомлений достаточно гибкой — чтобы покрыть и типовые случаи, и нестандартные.
Действия
Изначальное решение — сделать отдельный элемент «Уведомление» в дизайнере бизнес-процессов. Элемент ставится в процесс наравне с другими, получатели задаются через параметры, тело — через формулу. Любые условия срабатывания, любые получатели, любой текст.
В ходе обсуждения возникла альтернативная идея: дизайнер бизнес-процессов задумывался как движок для сложных автоматизаций, и использовать его, чтобы отправить уведомление, может быть избыточно. Подумали в сторону механизма подписки на изменения записи. Если пользователь упомянут в одной из колонок записи, он автоматически подписывается на её изменения, в настройках раздела можно чекбоксами выбрать конкретные колонки, по изменению которых нужно получать уведомления.
Проработал альтернативу как полноценное дизайн-решение и вынес оба варианта на обсуждение. По итогам коллективно решили идти по изначальному пути — элемент в дизайнере бизнес-процессов. Второй вариант остался в бэклоге.
Результат
В продукте появились уведомления — встроенные в движок бизнес-процессов как отдельный элемент. Гибкость, которую дал этот подход: любые условия срабатывания через шлюзы, любые получатели через параметры, любое тело уведомления через формулу. Отдельной системы для уведомлений делать не пришлось.
Итог
Дизайнер бизнес-процессов был для меня проектом с другой парадигмой проектирования по сравнению с остальными модулями продукта. Если в дизайнере раздела пользователь работает со структурированной формой настроек, а в маршрутах — с линейной схемой согласования, то здесь — с холстом и независимыми элементами, между которыми течёт логика исполнения. Пользователь не заполняет настройки сверху вниз, а собирает граф: ставит элементы, соединяет их потоками, настраивает условия ветвления, передаёт данные через параметры между элементами.
Продукт не вышел в коммерческую эксплуатацию. Дизайнер бизнес-процессов — инструмент, который оценивается через то, что в нём собирают, и сделать такую оценку в полной мере без реальных клиентов невозможно. На этапе проектирования я опирался на известные сценарии — проверял, что автоматизации собираются через интерфейс. Дальше нужны данные использования: какие элементы востребованы, насколько сложные процессы собирают клиенты, обращения в поддержку.
Проект дал мне опыт проектирования визуального конструктора, в котором логика собирается на нескольких уровнях: каждым отдельным элементом, способами их соединения и общим движком исполнения.