Привет, Хабр! Это вторая статья про BPMN – инструмент, который я регулярно использую в работе.

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

В этой статье мы перейдём к практике: начнём проектировать процессы и обсудим три важных аспекта:

• выбор архитектуры процесса: монолитная или микросервисная;

• выбор вида BPMN-схемы: взаимодействие или хореография;

• выбор подхода для начальной декомпозиции процессов: случайные или детерминированные подпроцессы.

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

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

Третий аспект связан с декомпозицией процессов. Анализ статей по BPMN на профильных it-ресурсах, показал, что проектирование процессов часто начинается с рекомендации по использованию событий, шлюзов и задач. Вместо этого, мы сосредоточимся на рекомендациях стандарта BPMN по проектированию процессов, связанных с разработкой программного обеспечения. Эти рекомендации особенно актуальны для тимлидов и аналитиков, которые планируют применять BPMN для моделирования детальных процессов заказчика или команды.

Понимание этих аспектов намного важнее для проектирования и оптимизации процессов, чем идеальное знание элементов нотации.

1. Монолитная или микросервисная архитектура?

Отличие учебных схем от моделей реальных процессов

Вы аналитик и перед вами поставили задачу обследовать заказчика и описать как выполняются текущие процессы («as-is»), а затем вариант улучшения («to-be»). А, возможно, вы тимлид, которому нужно описать процессы команды или написать регламент и дополнить схемами в нотации BPMN.

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

Аналитики и тимлиды продолжают использовать «монолитные» схемы на практике: операции выполняются последовательно, а взаимодействие между участниками – синхронное. Хотя процессы кажутся простыми и понятными, но они не отражают реальное положение дел и мало полезны для анализа и оптимизации работы.

Рассмотрим для примера небольшую команду, которая состоит из тимлида, аналитика, разработчика и QA уровнем middle или выше. Часто процесс их работы описывают последовательно, как в «водопадной» методологии управления проектами: заказчик передаёт задачу тимлиду, тот её оценивает и отдает аналитику. Аналитик уточняет требования и передаёт разработчику, а тот передаёт готовый сервис на проверку QA.

Но команда – это сложная динамическая система. Её архитектура и принципы работы скорее напоминают микросервисы. Взаимодействия асинхронные и непоследовательные, как в Agile. У тимлида огромное количество дел, которыми он «жонглирует»: планирует и декомпозирует цели и задачи, доводит их суть до команды, организует работу команды, проводит собеседования, мотивирует и развивает сотрудников, оценивает метрики, делает отчеты для руководства и т. д. Аналитик переключается между множеством контекстов и задач, общается в десятке тредов (чатов), планирует и проводит множество встреч с заказчиками, смежными командами, разработчиком и QA, анализирует документацию, код и т. д.

Поэтому эффективное управление небольшой командой – очень сложная задача.

Конечно, встречаются ситуации, когда схема работы команды выстраивается последовательно и напоминает «водопад». Например, при дефиците задач, когда тимлид их ждёт, а аналитик-стажёр не может работать автономно и требует постоянного микроконтроля. Или когда есть жестко регламентированный процесс (например, оказания государственных услуг). Однако это частные случаи, которые хорошо укладываются в базовые примеры из учебных курсов по BPMN. В данной статье мы их рассматривать не будем.

Определяем контекст процесса

На первом этапе проектирования процессов команды или заказчика надо определить контекст, который включает три ключевых составляющих:

• скоуп (границы проектирования процессов);

• участников процессов;

• точки зрения, относительно которых будут описаны процессы.

Скоуп – это области или домены, в рамках которых надо спроектировать процессы. Скоуп может включать один четко определенный домен, описанный в техническом задании, с указанием подразделения заказчика и функций для автоматизации. А может охватывать несколько доменов, если вы проектируете процессы для команды и вам важно отдельно описать:

• взаимодействие команды с другими подразделениями;

• взаимодействие внутри команды.

После определения скоупа нужно выявить участников процессов. Согласно стандарту BPMN 2.0 участники процесса – это пулы. Процессы могут отображать взаимодействие участников или их внутренних подразделений.

Следующий шаг – определение точек зрения, относительно которых необходимо описать процессы. Если описывать процессы команды с точки зрения (ценности) заказчика, тимлида и аналитика, то получится три набора разных процессов. Заказчику важны метрики проекта, скорость реализации и удобство функционала. Тимлиду – загрузка и развитие команды, налаживание коммуникаций и соблюдение внешних договоренностей. Аналитику – выбрать метод реализации требований заказчика с приемлемым уровнем качества при минимальных затратах ресурсов.

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

Проектируем схемы взаимодействия участников

Следующий шаг – это проектирование схем взаимодействия участников (Collaboration) [1, стр. 24] для каждой из точек зрения. На схемах взаимодействия верхнего уровня пулы могут быть свернуты – отображаться как черный ящик без описания операций процесса (событий, шлюзов и активностей).

В BPMN пул изображается прямоугольником, нарисованным жирной линией. Название пула отделяется от его содержимого линией. Если пул свернут (содержимое скрыто), то линию можно не рисовать. Ниже показано несколько примеров таких схем.

Анализируем подачу и обработку заявки в онлайн-школу

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

Ниже приведен пример схемы, аналогичной первой, но с дорожками.

Схема кажется понятной и правильной, но несёт мало ценности. Прежде чем разобрать почему, давайте вспомним основные связи (коннекторы) в BPMN:

• поток управления (sequence flow) – отображает последовательность операций процесса;

• поток сообщений (message flow) – отображает обмен сообщениями, используется для синхронизации процессов.

Графическое отображение связей показано ниже.

Внутри пула (участника) стандарт разрешает использовать только первый вид связей «поток управления». Он позволяет передавать токены. Токены – это абстрактные объекты или фишки, с помощью которых можно описать поведение (симуляцию) БП. Стартовое событие генерирует токен, который перемещается по потоку операций. Операции (активности) и шлюзы могут поглощать токены или генерировать новые.

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

Между пулами разрешена только слабая связь – поток сообщений (Message Flow). Этот тип связи не передаёт токены. Участники (пулы) в отличие от дорожек слабо связаны друг с другом и могут работать независимо. Внутри процесса сообщения могут приостанавливать движение токенов и влиять на шлюзы. Генерация токена от сообщения возможна, если процесс начинается со стартового события, ожидающего сообщения от другого участника.

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

На схеме показаны два участника процесса. В нижней части пула указана множественность участников: множество посетителей взаимодействует с множеством онлайн‑школ. Множественность обозначается специальным маркером – тремя вертикальными линиями внизу пула.

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

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

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

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

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

В схеме с пулами мы учитываем, что у посетителя сайта свои цели и приоритеты, и конкретная (наша) онлайн-школа ему не интересна. Для его привлечения надо снизить стоимость курса, автоматизировать его актуализацию, доработать полноту. Даже если посетитель допустит ошибку при заполнении заявки в одну из школ, его процесс не остановится. Он получит уведомление от другой онлайн-школы и начнёт обучение там.

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

Проектируем процесс выполнения задачи

Заказчик, тимлид, аналитик, разработчик, QA, стримы и внешние команды – это разные пулы. Каждый придерживается своих ценностей и работает автономно. Ниже представлен пример значительно упрощенной схемы, отображающей работу участников над задачей.

В схеме с дорожками заказчик ставит задачу, тимлид её планирует и передаёт в аналитику. Такая схема понятна, но она будет работать для одной задачи. При поступлении нескольких задач, она теряет актуальность.

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

Ценности для заказчиков, смежных команд и руководства очевидны. Но какая ценность у тимлида? Если он возьмёт в работу все задачи, то возможны два сценария. В первом команда не успеет выполнить работу, что может привести к её расформированию. Во втором работа будет завершена, но за счёт переработок, ведущих к выгоранию сотрудников. Поэтому главная ценность тимлида – сохранить и развить команду, учитывая интересы всех участников процесса.

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

Также неверно думать, что если тимлид одобрил задачу, аналитик бросит всё и начнёт её выполнять. Ценности аналитика отличаются и не связаны напрямую с сохранением и развитием команды. Он заинтересован сделать качественную аналитику и развить профессиональные навыки (хард- и софт‑скилы).

На схеме видно, что аналитик взаимодействует со всеми участниками процесса. От пула аналитика связь идёт к каждому участнику работы над задачей. Топология такого взаимодействия – это «звезда», надёжность и производительность которой определяется центральным компонентом (аналитиком). В активной фазе работы над задачей аналитик прорабатывает технические решения по всем требованиям, налаживает коммуникации и согласовывает планы с заказчиком, внешними командами, разработчиками, профлидами и QA, выявляет и нивелирует риски, декомпозирует задачи, всё документирует и т. д. Скорость работы всей команды зависит от аналитика.

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

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

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

Итоги

Не пропускайте этап моделирования взаимодействия участников (пулов). Он так же важен, как и проектирование схемы контекста в нотации C4. Пропустить этот этап – всё равно что отказаться от схем контекста, контейнеров и компонентов и сразу перейти к схеме с кодом.

Не начинайте детальное проектирование с дорожек и операций, думая, что вы и так хорошо знаете свою команду (заказчика) и сможете быстро всё «нарисовать» и оптимизировать. Это почти всегда приводит к созданию и оптимизации несуществующих процессов.

Разработчикам, которые недавно стали тимлидами важно запомнить: даже небольшая команда – это сложная система. А значит модель её работы тоже должна отражать эту сложность.

Изучите официальные примеры BPMN [2, стр. 8], в которых показано, что для анализа, оптимизации и автоматизации небольшого процесса обработки обращений в поддержку требуется сложная схема, состоящая из пяти независимых участников (пулов). Схема с дорожками тоже присутствует, но с целью первичного уточнения скоупа процесса.

Используйте при моделировании процессов принципы эффективного проектирования сложных систем, например, придерживайтесь низкой связанности (coupling) и высокого сцепления (cohesive) [3].

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

2. Хореография или взаимодействие (сотрудничество)?

Оптимизируем схему взаимодействия участников

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

Согласно международному стандарту «BABOK» (Business Analysis Body of Knowledge) [4] и своду знаний по управлению бизнес-процессами «BPM CBOK» (Guide to the Business Process Management Common Body Of Knowledge) [5], моделирование процессов чаще всего выполняется в нотациях: Flowcharts, BPMN и UML (диаграммы активности). Но базовые элементы этих нотаций выглядят одинаково, поэтому схемы не будут выглядеть эффективнее.

Также стандарты рекомендуют использовать IDEF, SIPOC (Suppliers, Inputs, Process, Outputs and Customers) и VSM (Value stream mapping) [4]. Но они нам не подходят: IDEF предлагается использовать для определения скоупа/границ моделирования, а SIPOC и VSM – для анализа процессов.

Ещё один вариант, часто встречающийся на практике – проектировать схемы процессов в виде UML-диаграмм последовательности (sequence diagram). Причина – высокая популярность диаграмм у системных аналитиков и разработчиков для отображения взаимодействия объектов. Однако важно учитывать, что диаграммы последовательности изначально предназначались для моделирования небольших схем. Согласно замыслу создателей UML, диаграмма должна представлять таблицу [6], в столбцах которой указывают объекты, а в строках – стрелки, показывающие взаимодействие. Работать с ней удобно как на маркерной доске (или листе А4), так и в цифровом виде в приложениях моделирования. Нотация создавалась для удобства коммуникаций и мозговых штурмов, а не для описания низкоуровневых алгоритмов или процессов. Удивительно, как часто её используют для создания громоздких схем с множеством фреймов условий и циклов. Как можно быстро набрасывать вложенные фреймы при мозговом штурме на маркерной доске? Дополнительно PlantUML способствует усложнению диаграмм последовательности, уводя от их основного назначения [7]. По этим причинам мы не будем переносить наши схемы в UML‑диаграммы последовательности, хотя и будем иногда их упоминать.

Поскольку подходящих альтернатив нет, вернёмся к стандарту BPMN. BPMN предлагает два вида схем: схемы взаимодействия с пулами и дорожками (collaboration) и схемы хореографии (choreography) [1, стр. 315].

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

Изучаем нотацию хореографии

Паттерн «хореография» в BPMN и проектировании программного обеспечения имеет схожий смысл, если рассматривать каждого участника процесса как независимый микросервис. Существуют даже работы по генерации REST API хореографии микросервисов на основе BPMN-схем хореографии [8, 9].

Компактность при использовании схем хореографии достигается за счет сокращения количества связей и более рационального использования пространства схемы. Кроме того, стандарт говорит, что схемы хореографии легче редактировать [1, стр. 315]. Вы наверняка замечали, как сложно масштабировать схемы с множеством участников. Кроме того, BPMN-схемы с пулами и дорожками (или UML-диаграммы активности) часто выглядят неэффективно. Значительная часть таких диаграмм – это пустое пространство, которое возникает из-за того, что в один момент времени активна только одна дорожка. В результате больше половины схемы оказывается пустой.

Ниже приведен пример таких схем. Пустое пространство, не имеющее ценности, выделено красным.

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

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

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

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

В стандарте BPMN указано, что схема хореографии определяет последовательность взаимодействий [1, стр. 316]. Примечательно, что термин «диаграмма последовательности» больше соответствует именно хореографии, чем одноимённой диаграмме в UML.

Как и на схемах взаимодействия, на хореографии активности делятся на атомарные – задачи (task) и составные – подпроцессы (sub-process). На активностях допускается указывать маркер множественности.

Проектируем схемы хореографии

Если вспомнить пример из первой части статьи, где к тимлиду поступали задачи от руководства отдела, бизнес-заказчиков и смежных команд, то на схеме взаимодействия было четыре пула. В схеме хореографии логика отображается компактнее: вместо четырёх пулов – один прямоугольник (активность), отражающий взаимодействие. Участники указываются внутри активности: сверху – постановщики задач, снизу – тимлид.

Процесс планирования и выполнения задач будет выглядеть следующим образом.

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

Итоги

Если процесс моделирует множество интенсивно взаимодействующих участников, то схема хореографии будет оптимальнее, чем взаимодействия или UML-диаграмма активности. Она будет компактнее, проще для понимания и редактирования (масштабирования).

Если вас пугает основной недостаток такого решения – малая распространённость нотации, то не используйте только схемы хореографии. Дополняйте ими схемы взаимодействия. Стандарт BPMN предлагает комбинировать оба вида схем [1, стр. 363].

Обязательно ознакомьтесь со схемами, приведенными в стандарте BPMN [1, стр. 344] и официальных примерах [2, стр. 9, 10], наглядно демонстрирующими упрощение восприятия процесса с помощью хореографии.

Схемы хореографии можно найти в большинстве систем для проектирования процессов, таких как Enterprise Architect, Visual Paradigm, Drawio и других [10, 11, 12]. К сожалению, их часто исключают из книг и курсов даже разработчики стандарта [13, 14, 15, 16]. Кроме того, их нет в популярных приложениях для автоматизации процессов, таких как Bizagi, Camunda и Stormbpmn [17, 18, 19, 20].

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

Схема процесса

3. Случайные или детерминированные подпроцессы?

Проблема, при которой декомпозиция неэффективна

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

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

Нередко встречаются ситуации, когда руководителями подразделений делают ведущих специалистов, из-за того, как они прекрасно выполняли свои задачи. Но опыт руководства у них отсутствует. Они привыкли быть «звёздами» и не осознают (или не признают), что не понимают, как оптимально выстраивать процессы работы команды.

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

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

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

Прежде чем приступать к декомпозиции процессов заказчика, проверьте, не столкнетесь ли вы с этой проблемой. Если она есть, обсудите и скорректируйте цели моделирования с руководителем.

Выбираем типы активностей

Исключив риск связанный с мотивацией заказчика, приступаем к декомпозиции операций (активностей) внутри пулов тимлида, аналитика, разработчика и QA. В стандарте BPMN операции, выполняемые пользователями или программным обеспечением, называются активностями [1, стр. 151]. Они делятся на на атомарные – задачи (task) и составные – подпроцессы (sub-process).

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

Это подпроцесс типа «Ad-Hoc» («произвольный» или «от случая к случаю»). В соответствии со стандартом BPMN «Ad-Hoc» – это подпроцесс, в котором нельзя точно определить последовательность и порядок выполнения, входящих в него задач. Исполнитель должен сам решить, какие из них выполнить и сколько раз [1, стр. 180]. Подпроцесс «Ad-Hoc» обозначается маркером «~».

Стандарт BPMN приводит примеры областей и задач, для которых надо использовать «Ad-Hoc» подпроцессы: разработка приложений, заключение сложных сделок и продаж, написание книг [1, стр. 151].

Работа системного аналитика, разработчика, QA и тимлида часто напоминает небольшие исследования. Аналитик получает требования, проводит «созвоны» с заказчиком, изучает документацию, анализирует существующий код, организует мозговые штурмы. При этом невозможно заранее сказать, сколько итераций каждой из активностей потребуется, чтобы выполнить задачу.

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

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

Декомпозируем активности участников команды

Если использовать «Ad-Hoc» подпроцесс для декомпозиции работы тимлида, аналитика и разработчика, то процессы будут выглядеть похоже.

«Ad-Hoc», как и все подпроцессы в BPMN можно развернуть. Развернутый подпроцесс работы тимлида будет выглядеть следующим образом.

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

Процессы для аналитика и разработчика будут выглядеть аналогично, но включать другие активности.

Следующим шагом надо вынести активности из «Ad-Hoc» в более детерминированные подпроцессы, например событийные [1, стр. 175]. Они отображаются в виде прямоугольника, нарисованного пунктирной (точечной) линией. Событийные подпроцессы не являются частью основного потока операций и запускаются параллельно при срабатывании событий.

Например, тимлид много лет по единому шаблону планирует день в 8:00, а в 21:00 готовит отчёт по проделанной работе. Иногда звонит генеральный директор, и тогда тимлиду приходится срочно решать вопрос, прерывая текущие задачи. В этом случае процесс работы тимлида будет выглядеть следующим образом.

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

Это очень важный, но не окончательный шаг декомпозиции. Далее надо продолжить декомпозировать и детерминировать активности, которые потенциально будут оптимизированы и автоматизированы. Не бойтесь рисовать такие процессы, моделируя работу для своей команды. И не требуйте от аналитиков сразу предоставить точную пошаговую модель процесса после одного визита к заказчику. Как и в it-командах, в работе заказчиков часто встречаются подразделения, работа которых лучше всего описывается «Ad-Hoc» подпроцессами.

Итоги

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

Используйте рекомендуемый стандартом подпроцесс «Ad-Hoc», который даёт исполнителю свободу выбора – какие задачи и сколько раз выполнять.

При взаимодействии с заказчиком учитывайте, что у некоторых из них стиль работы построен на принципах «Ad-Hoc» («от случая к случаю»).

Постепенно выносите активности из «Ad-Hoc» подпроцессов в более детерминированные. Старайтесь подкреплять этот перенос достаточным объемом данных.

4. Подводим итог

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

• правильного выбора и построения архитектуры схемы;

• учёта контекста, интересов всех сторон и точек зрения на процесс;

• корректного выбора видов диаграмм для описания процессов;

• сохранения в модели гибкости реального процесса за счёт использования «Ad-Hoc» подпроцессов.

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

• не стремитесь к чрезмерному упрощению процессов и представлению их в виде, который видели в обучающих материалах по BPMN;

• изучите официальные примеры BPMN-схем [2, стр. 8], где показано, что именно схема с пулами позволяет выполнить анализ, оптимизацию и автоматизацию процесса, а схема с дорожками может потребоваться только для уточнения скоупа процесса;

• чётко фиксируйте границы моделирования, выделяйте участников как независимые пулы, а не дорожки, и учитывайте разные точки зрения: один и тот же процесс для заказчика, тимлида и аналитика может выглядеть по-разному;

• используйте хореографию, если на схеме процесса много участников и взаимодействий между ними: она эффективнее отображает обмен данными, компактнее, проще для понимания и редактирования;

• помните, что схемы хореографии менее распространены, поэтому не стоит использовать их без схем взаимодействия;

• не исключайте из соглашений по моделированию подпроцессы «Ad-Hoc», используйте их для описания сложной интеллектуальной деятельности: управления командой, аналитики, разработки, тестирования или проведения исследований;

• начинайте декомпозицию процессов с «Ad-Hoc» подпроцессов, постепенно переносите из них активности в более детерминированные виды подпроцессов.

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

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

Спасибо, до новых встреч!

Список источников

1. Business Process Model and Notation. History. URL: https://www.omg.org/spec/BPMN

2. BPMN 2.0 by Example. URL: https://www.omg.org/spec/BPMN

3. Принцип каскадного снижения связанности. URL: https://habr.com/ru/articles/894766/

4. A Guide to the Business Analysis Body of Knowledge (BABOK Guide). URL: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/

5. Guide to the Business Process Management Common Body Of Knowledge (BPM CBOK). URL: https://www.litres.ru/book/raznoe-4340152/svod-znaniy-po-upravleniu-biznes-processami-bpm-cbok-4-0-67034260/

6. Grady Booch «The Unified Modeling Language Usere Guide». URL: https://www.litres.ru/book/gradi-buch/vvedenie-v-uml-ot-sozdateley-yazyka-6135054/

7. Как рисовать Sequence без боли и страданий в PlantUML. URL: https://habr.com/ru/companies/X5Tech/articles/821687/

8. Adriatik Nikaj «Semi-automatic derivation of RESTful choreographies from business process choreographies». URL: https://www.researchgate.net/publication/322207923_Semi-automatic_derivation_of_RESTful_choreographies_from_business_process_choreographies

9. Francesco Donini «Coordinating REST interactions in service choreographies using blockchain». URL: https://www.sciencedirect.com/science/article/pii/S209672092400054X

10. Enterprise Architect User Guide v. 17.1. Choreography Diagrams. URL: https://sparxsystems.com/enterprise_architect_user_guide/17.1/modeling_languages/bpmn_2_0_choreography.html

11. Visual Paradigm «How to Create BPMN Diagram». URL: https://www.visual-paradigm.com/tutorials/how-to-create-bpmn-diagram/

12. Drawio «BPMN 2.0 shapes for detailed process flows and choreography models». URL: https://www.drawio.com/blog/bpmn-2-0

13. Брюс Сильвер «BPMN – Метод и стиль» 2025 год. URL: https://www.litres.ru/book/bruce-silver/bpmn-metod-i-stil-71857840/

14. Владимир Репин «Моделирование бизнес-процессов в нотации BPMN». URL: https://www.litres.ru/book/vladimir-repin-18519/modelirovanie-biznes-processov-v-notacii-bpmn-posobie-42388863/

15. Joshua Fuehrer, Wesley Almeida «LEARNING BPMN 2.0 A Practical Guide for Today’s Adult Learners: An Introduction of Engineering Practices for Software Delivery Teams». URL: https://www.amazon.com/gp/product/B0BPPQBZ6R

16. BPMN – что это такое? URL: https://stormbpmn.com/blog/bpmn/bpmn-polnoe-rukovodsko-na-primeryah

17. Bizagi Modeler. URL: https://www.bizagi.com/en/platform/modeler

18. Simulation in Bizagi. URL: https://help.bizagi.com/platform/en/index.html?simulation_in_bizagi_st.htm

19. Camunda. URL: https://camunda.com

20. Stormbpmn. URL: https://stormbpmn.com/

21. Flavio Corradini «Collaboration vs. choreography conformance in BPMN». URL: https://www.researchgate.net/publication/339199573_Collaboration_vs_choreography_conformance_in_BPMN