228. Как описывать процессы, чтобы их понимали

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

⚡️ Вопрос звучал так: "В какой нотации вы разрабатываете бизнес-процессы?"

Нотаций желаете... Их есть у меня. Я в целом могу спокойно пояснить за BPMN 2.0, UML, C4, майнд карты, простые блок-схемы, любимые многими таблицы и прочие способы разложить процесс по полочкам.

🤘 Но есть нюанс... Я не верю в одну "правильную" нотацию на все случаи жизни.

Иногда процесс удобнее описать обычной таблицей, потому что люди привыкли потреблять информацию в таком виде.

Иногда хватает блок-схемы уровня школьных уроков информатики.

Иногда действительно нужен BPMN. Ибо в условиях и ролях черт ногу сломит.

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

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

Где он начинается. Кто что делает. Какие данные нужны. Где принимается решение. Что делает человек. Что делает система. Что происходит при нормальном сценарии. Что происходит, когда всё пошло... Не по плану...

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

И формально то всё будет красиво. А по факту — процесс похоронили во имя нотации. Прикол будет ещё, если на этапе сдачи-приемки окажется что на самом деле все должно работать иначе, просто кто-то не разобрался в последовательности кубиков.

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

❗️ Форма должна подбираться под задачу.

Если нужно быстро согласовать логику — подойдёт текстовый сценарий или простая блок-схема.

Если нужно описать статусы, роли, поля, условия, уведомления и роботов — часто лучше работает таблица.

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

Если обсуждаем интеграции и границы систем — полезнее смотреть в сторону C4 и архитектурных схем.

Короче, микроскоп — хороший инструмент. Но если им забивать гвозди...,

Возможно этот пост — начало новой рубрики. Не буду забегать вперед - следите за каналом.

С уважением к здравому смыслу. Ваш Максим С днем России!

#систематизируйэто

@M3ybeev