Как моделирование бизнес процессов помогло нам согласовать прототип мобильного приложения

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

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

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

При согласовании получившихся прототипов мы столкнулись с тем, что текстовое описание работы будущей системы не отвечало потребностям заказчика. Нам было озвучено, что «Без подробных схем того, как предлагаемое решение будет автоматизировать наши бизнес-процессы, мы не можем считать этап проектирования законченным». Иными словами, заказчик хотел провалидировать не только то, что в прототипах полностью отражены бизнес-требования, но и то, что данное решение полностью соответствует заявленным целям проекта, а именно – автоматизации некоторых бизнес-процессов компании.

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

• На данном проекте мы делали не только мобильное приложение, но также административную панель и бэкенд часть. То есть на нашей стороне полностью находилась логика взаимодействия между разными элементами системы, которую надо было отразить в схемах.
• Источником данных для проекта выступала достаточно разрозненная айти-инфраструктура, и для согласования прототипов было важно иметь четкое понимание, откуда берутся те или иные данные, которые отображаются в интерфейсе приложения.
• Было необходимо создать единую картину всех бизнес-процессов, которые покрываются данным решением, так как большинство стейкхолдеров отвечали только за один или несколько из них.

С пониманием того, что запрос в сущности своей более чем аргументированный, мы перешли к поиску подходящего решения.

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

Существует множество различных схем, диаграмм и языков моделирования (нотаций). Для нас было важно:

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

Выбор нотации

Несмотря на опыт моделирования с использованием UML, была выбрана нотация BPMN в силу нескольких причин:

• Наличие артефактов от заказчика с использованием BPMN.
• Общая ориентированность BPMN на бизнес-пользователей.
• Проект был построен вокруг автоматизации бизнес-процессов, моделирование которых и является целевым применением нотации BPMN.

Поиск идеальной схемы

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

• Показывать, как будет работать бизнес-процесс = традиционное описаний действий пользователей из BPMN. Например, «Менеджер заполняет карточку клиента в CRM».
• Учитывать разные роли пользователей в системе. То есть отражать действия как со стороны основной массы сотрудников в мобильном приложении, так и со стороны отделов, которые будут пользоваться административной панелью. Стало ясно, что на схеме должны быть отдельные блоки для разных групп пользователей. В этот раз мы впервые задумались об использовании SwimLane диаграммы.
• Отображать информационные потоки и отвечать на два вопроса: «Откуда берутся данные, необходимые для обеспечения данного процесса?» и «Куда отправляются/записываются данные в его результате?» Следовательно, в схеме необходимо показать операции, совершаемые на серверной стороне приложения.
• Показывать, что именно делает пользователь в интерфейсе мобильного приложения/административной панели. Данное требование скорее противоречит BPMN, но было принято компромиссное решение детализировать это в описании процессов.

Итого, мы решили использовать Swimlane диаграмму, где в качестве «плавательных дорожек» выступали бы не только разные группы пользователей, но также серверная часть приложения. Для более полного покрытия логических связей с прототипами/будущим интерфейсом решено указывать более подробную логику работы с интерфейсом в описании процессов.

Инструменты

В целом для моделирования и построения различных схем и графиков мы используем Miro. Однако в случае с данной задачей мы столкнулись со следующими проблемами:

• Организация работы. Miro скорее ориентировано на работу в одной доске, в то время как для наших целей больше подходил подход «1 схема – 1 файл». Помимо этого, даже если представить, что мы выделим отдельную доску под каждую схему, в Miro нет возможности удобно организовать доски внутри проекта – вложенность ограничена одним уровнем.
• Не самый удобный экспорт в PDF. В пару кликов диаграмму можно экспортировать только в CSV.
• Очень базовый шаблон для построения необходимой нам схемы. Недавнее обновление на эту тему мы, к сожалению, не застали.

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

А так схема выше выглядит, если у вас есть дизайнер.

Сказать, что мы провели детальный анализ инструментов на рынке, нельзя, но можем смело посоветовать Lucidchart для людей с базовыми запросами относительно построения Flowchart’ов с использованием BPMN.

С точки зрения процесса работы можно выделить следующие этапы:

• Составление списка процессов для моделирования. Здесь важно учитывать, что крупные процессы (с множественными ответвлениями) следует декомпозировать на более мелкие составляющие, чтобы сохранить читаемость будущей схемы. Например, при моделировании банковского перевода стоит составить отдельные схемы для перевода по номеру карты, через систему быстрых платежей и т.д.
• Согласование формата моделирования с заказчиком. Данный этап призван исключить ситуацию, когда вы несколько недель составляли схемы, которые в итоге никому непонятны. При подготовке пробных схем важно не брать самые простые процессы, так как они не смогут покрыть все нюансы/аспекты. В нашем случае было необходимо взять процесс, где бы участвовали пользователи с разными ролями и происходило взаимодействие между ними.
• Подготовка схем на основании согласованного формата. Для ускорения данного этапа полезно создать шаблон схемы, чтобы не составлять каждую с нуля. Изначально мы пробовали снимать копию с «похожей» схемы, но поняли, что тратим много времени на редактирование и удаление элементов и все же проще работать с чистым шаблоном.
• Сбор обратной связи на готовые схемы. Здесь нам пригодился простой и удобный экспорт Lucidchart в pdf.
• Внесение правок (в том числе в прототипы) и согласование финальной версии схем. Внесение правок удалось ограничить двумя-тремя итерациями благодаря хорошо налаженной коммуникации с заказчиком.

Мы были довольны результатом проделанной работы, и схемы стали одними из артефактов, которые не только помогли нам согласовать дизайн и приступить к разработке, но и

• Помогли быстро погрузиться в проект временному PMу
• Ускорили погружение в проект iOS и Android разработчиков
• Привели в восторг бэкенд разработчика
• Значительно сократили сроки разработки административной панели: весь процесс взаимодействия был «как на ладони»
• Оптимизировали процесс написания тест-кейсов для всех разделов МП и административной панели.

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

• Отсутствует единый продакт оунер на стороне заказчика
• Проект нацелен на автоматизацию бизнес-процессов
• Серверная логика преимущественно находится на нашей стороне
• Существует несколько интерфейсов и/или несколько ролей пользователей

Автор: Тимофей Мостивенко

Иллюстрации: Светлана Бельденкова