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