259. Когда одной схемы процесса уже мало
Продолжаю периодически вытаскивать из закромов разные способы рисовать процессы и системы.
Сегодня про UML.
Само название немного пугает. Unified Modeling Language звучит, будто сейчас придётся открывать учебник на 600 страниц и ловить флешбеки из университетской жизни.
На практике всё проще. Не пугайтесь.
⚡️ UML это не одна схема, а целый набор способов посмотреть на систему с разных сторон.
Причём именно на систему, а не только на отдельный бизнес-процесс.
Блок-схемой удобно показать, как человек проходит от одного действия к другому. BPMN помогает нормально разложить сложный процесс с условиями, событиями и разными участниками.
И в какой-то момент этого вам станет маловато.
Например, у нас есть менеджер собственной персоной, Битрикс, 1С, юрист и какой-нибудь внешний сервис. Все они участвуют в одном процессе, что-то друг другу передают, чего-то друг от друга ждут, на какие-то действия как-то реагируют.
Сам процесс быть может и понятен. А вот что конкретно происходит между его участниками уже не очень.
❗️ Тут UML как раз начинает быть полезен.
Одна из его диаграмм называется диаграммой последовательностей. В ней участники стоят рядом, а время идёт сверху вниз. Между ними рисуются обычные стрелочки взаимодействий.
🤘 Менеджер что-то сделал в CRM. CRM отправила данные в другой сервис. Сервис вернул результат. После этого система создала задачу сотруднику.
И вместе с этим довольно сложная логика начинает уютно помещаться на одном листе.
😈 Мне в таких схемах нравится ещё одна штука.
Они хорошо показывают ожидания.
Вот здесь как раз писал про согласования. Если договор независимо должны проверить руководитель, юрист и бухгалтер, нет особого смысла сначала ждать руководителя, потом отправлять юристу, а после него бухгалтеру.
На диаграмме последовательностей такая странность видна буквально глазами.
Три независимых действия почему-то выстраиваются в цепочку и сразу возникает классический вопрос автоваза.
〰А зачем?
Если зависимости между ними нет, скорее всего, их можно выполнять параллельно.
⚡️ Собственно, наверное, поэтому UML мне нравится не как язык для аналитиков или разработчиков. Это ещё один инструмент, который помогает разобраться, как должна быть устроена система.
Особенно когда в процессе начинают одновременно участвовать люди, кони и другие сервисы.
В такие моменты уже недостаточно понимать, что происходит сначала, а что потом. Нужно видеть связи между участниками системы.
И чаще всего несколько стрелочек UML объясняют эти связи сильно быстрее, чем три страницы технического задания.
Вот и думайте.
@M3ubeev
В этом посте были ссылки, но мы их удалили по правилам Сетки
