Или ментальные «ловушки», которые мешают аналитикам использовать нотации.

От системного аналитика требуют знание нотации BPMN (Business Process Model and Notation). А действительно ли ей пользуются на практике? Если нет, то почему?

Этот вопрос подтолкнул меня провести опрос среди своих коллег — системных аналитиков. Большинство ребят считают, что нотации необходимы в работе, но на практике используют меньше половины. Почему возник такой парадокс?

Результаты опроса

На вопросы отвечали 45 системных аналитиков четырёх уровней.

86,7% из них считает, что BPMN-нотации необходимы системному аналитику.

Но при этом в работе их использует меньше половины.

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

Почему такое расхождение? Почему аналитики, которые считают нотации необходимыми, их не применяют?

Три самых популярных ответа:

• В схему никто, кроме рисующего не смотрит.

• Разное толкование обозначений. 

• Не знаю с чего начать.

Остальные ответы про 200 с лишним элементов, сложность нотаций, их декомпозицию, а ещё отсутствие опыта в «рисовании», можно отнести к этим трём пунктам.

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

№1. «Не знаю с чего начать» — показываем на практике

Давайте попробуем закрыть проблему «Не знаю с чего начать» и начнём с основных элементов.

BPMN позволяет аналитику, product owner (PO) и разработчику общаться на одном языке с помощью условных обозначений, который приняты в нотации. 

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

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

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

«Как же так?!» — разводит руками PO и не понимает как так вышло, что сделали не то, о чём он говорил.

Product owner

«В доке описан алгоритм работы» — говорит системный аналитик.

Системный аналитик

«Я реализовал задачу по документации».

Программист

Вернёмся назад в прошлое, на несколько дней раньше. В нашей истории аналитик описал требования в формате текста:

«Пользователь заходит на сайт. Сервис находит список депозитов. Если депозиты не найдены, то пользователь не видит виджет, иначе показываем виджет со списком. В списке могут быть не доступные для пользователя депозиты, так как в калькуляторе выбраны определенные условия»

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

Какое ветвление процесса не учли? Что в списке визуально будут отображены депозиты, которые не доступны пользователю при определенных условиях в калькуляторе, но по тексту программист этого не понял. Команда избежала бы конфликта, если бы аналитик зарисовал с помощью BPMN схему и согласовал его с PO и программистом.

Основные элементы BPMN

Вернёмся к нашим «дорожным знакам». Представьте, что BPMN — это язык, а элементы это слова. У «слов» есть обозначения и значения. Вот несколько основных элементов нотаций.

Pool — Пул. Определяет границы процесса и описывает один процесс на диаграмме. Пул также обозначает систему или роль.

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

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

Activity — Действия. Это работа, которую выполняет исполнитель на каком-то этапе бизнес-процесса. Обозначаются прямоугольниками, внутри которых помещается задача действия. Задача — это простое действие. Она может быть абстрактной, сервисной или пользовательской. Например, нажимает пользователь на кнопку «Отправить» — это пользовательское действие.

Gateway — Шлюз. Элемент показывает ветвление, слияние процесса. Шлюз — это узел, который «ветвит» процесс, поэтому изображается ромбом. Например, когда пользователь выбирает депозит и видит его, то может перейти на следующий процесс — совершить какие-то действия с депозитами. Если они не показываются, то это уже другой процесс.

Flow — Поток. Связывает элементы процесса: события, процессы, шлюзы. Обозначается стрелкой.

Data — Данные. Это могу быть объекты данных, базы данных. Например, сервис сформировал список депозитов и отправил их для отображения на сайте пользователю.

Элементов нотации гораздо больше, но для начала хватит базовых.

Как построить диаграмму за 5 шагов

Давайте построим диаграмму для нашей задачи по списку депозитов вместе с аналитиком.

1️⃣ Выделяем участников процесса (lanes).

Это может быть Пользователь, Сайт, Сервис.

2️⃣ Находим события начала (start) и окончания (end) процесса.

Это важный этап — запланировать начало и конец процесса, чтобы обозначить его рамки, иначе процесс будет бесконечным, а нам это не нужно. Start будет начинать пользователь, а end будет несколько у сайта, так как процесс имеет ветвления.

3️⃣ Укажем действия участников внутри lanes.

• Пользователь открывает страницу сайта.

• Сайт отправляет запрос на получение информации.

• Сервис собирает данные для ответа. Если есть депозиты, сайт показывает виджет. 

• Дальше проверяет все ли депозиты доступны. Если не все, то подсвечивает их визуально для пользователя.

Если участников несколько, то сначала описываем действия одного участника, потом другого.

4️⃣ Нарисуем потоки данных (flow) и укажем сами данные (data).

В нашей схеме будет поток управления и данные со списком депозитов.

5️⃣ Обозначим на схеме шлюзы (gateway). 

Будет 2 ветвления:

• Есть ли депозиты?

• Есть ли среди депозитов недоступные?

Получили вот такую диаграмму.

А что же было не так с текстовым описание процесса от аналитика? Теперь, когда у нас есть диаграмма, видно, что в тексте не учли ветвление «Есть ли активные депозиты?» На схеме это наглядно видно, что по тексту может быть неочевидно.

Инструменты. Для рисования я использовала инструмент storm.Bpmn2.ru, потому что он мне удобен (скачать файл можно по ссылке). В нём есть основные элементы, проверка диаграммы, возможность скачать *.jpg, *.bpmn. Но, по результатам моего опроса, он не самый популярный.

Большинство аналитиков применяют draw.io, Visio и Camunda Modeller.

Есть еще и другие, которые могут быть удобнее лично вам, но они оказались не такими популярными, например, drawio, Bpmn.io, Camunda Modeler или Chor-js (demo).

№ 2. «В схему никто, кроме рисующего не смотрит»

Этот ответ подтолкнул меня запустить опрос в своей команды и понять, а правда ли в схему никто не смотрит. На опрос ответило 14 человек с разными ролями.

Большинство — 78,6% — всё же заглядывают в схему в документах аналитиков.

Получилось, что в схемы команда смотрит. Может быть проблема в разном толковании этих схем?

№ 3. «Разное толкование схем»

Для проверки этой проблемы я провела опрос внутри команды. Всё те же 14 человек попросила выбрать понятную им схему в BPMN и UML Sequence.

Примечание. Как нарисовать UML Sequence описано в статье «Plantuml в работе системного аналитика. Пиши uml диаграммы текстом, чтобы сэкономить время»

Как выглядела схема в опросе (в двух вариантах).

Здесь мнения разделились.

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

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

По моему опыту, проблема не в толковании, а в недоинформированности об элементах схем и в сложности самих схем.

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

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

Как презентовать BPMN команде?

Чтобы не возникало проблем с толкованием (а скорее, чтобы аналитику успокоить самого себя), стоит уделить описанию элементов и их взаимодействия немного времени, тогда нотации сразу становятся наглядными. Конечно для этого нужно время и отдельное мероприятие. По моему опыту, лучший вариант презентации схемы — на груминге/PBR команды. Если просто отправить документ в личку и ждать, что программист его прочитает и поймет, то можно не дождаться.

Примечание. Есть ещё вариант, чтобы разработчик посмотрел схему, нужно сделать так, чтобы она ему стала нужна для разработки кода. Например, о таком варианте рассказывал Дмитрий Жезлов на митапе Backend Stories (Java) в докладе «Zeebe для Банка в 2021 году».

А что в итоге?

Я верю, что после прочтения статьи у вас не возникнут три основные проблемы:

• В схему никто, кроме рисующего не смотрит.

• Разное толкование обозначений. 

• Не знаю с чего начать.

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

Единственная трудность возникает в:

• Глубоком изучении BPMN, её элементов и абстракций. Я потратила довольно много времени на изучение, но наглядность схем бизнес-процессов сейчас оправдали эти «вложения».

• Презентации. Но это уже вопрос другого порядка, скорее организаторский или из области психологии.

Решать, конечно, вам — использовать или нет BPMN диаграммы в работе, но теперь вы прочитали про практический опыт в одной из команд Альфа-Банка. Надеюсь, было полезно.

Сейчас нам в Альфа-Банк нужен системный аналитик в УКД и системный аналитик в отдел риск-технологий. Если хотите, чтобы в команде смотрели и понимали ваши схемы, приходите:)

Статьи, которые могут быть интересны:

• Удачный шаблон документации на API, который будут читать

• Plantuml в работе системного аналитика. Пиши uml диаграммы текстом, чтобы сэкономить время

• Мой краткий чек-лист по скилам системного аналитика

• Альф, переведи мне на телефон миллион рублей