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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

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

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

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

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

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

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

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