Привіт, мене звати Марія Терлецька, я тренер і консультант у компанії E5, а також провідний бізнес-аналітик у компанії EPAM Systems. Мій досвід роботи в IT складає 17 років, з них понад 10 років я працюю на посаді BA. Останнім часом я стала помічати, що все більше команд прагнуть використовувати мову UML, до того ж помилково сприймаючи її як аналог BPMN.
Моє спостереження стало приводом для створення цього матеріалу. У ньому ми будемо розбиратися, що ж таке UML та в чому полягає відмінність від BPMN. Також поговоримо про ситуації, коли команді знадобляться UML-діаграми, а в яких випадках краще обійтися без них.
Скажу одразу, якщо ви прийшли за однозначною відповіддю на запитання, використовувати UML чи ні, тут ви її не знайдете. Це пояснюється тим, що не існує універсального рішення для всіх. Так само як і не існує чітких правил – ні в бізнес-аналізі, ні в моделюванні. У реальних умовах є канони, та є те, що працює: допомагає зробити всі процеси швидшими та ефективнішими.
Ця інформація стане у пригоді тим командам, які планують використовувати UML, не можуть обрати між нею та BPMN або все ще намагаються визначитися, чи доцільно в їхньому випадку працювати з діаграмами взагалі.
UML vs BPMN
BPMN (Business Process Model and Notation) – це метод відображання блок-схем, який дозволяє створювати прості для розуміння діаграми. Вже в самій його назві зашита інформація, що йдеться про бізнес-процеси. Відповідно, цю нотацію використовують, коли потрібно показати, як функціонує бізнес. Тут на першому місці завжди люди: комунікація між підрозділами, між структурами бізнесу. Ще одна відмінна риса – орієнтація саме на процес.
На противагу BPMN існує UML (Unified Modeling Language) – мова графічного опису для моделювання у сфері розробки програмного забезпечення та бізнес-процесів. Зверніть увагу: UML – це мова програмування, в якій використовується виключно графічне представлення. Її головна відмінність від BPMN полягає в тому, що Unified Modeling Language насамперед візуалізує не процеси, а систему. Вона спеціалізується на моделюванні програмного забезпечення та орієнтується на комунікації між компонентами системи.
Основні будівельні блоки UML: діаграми
UML використовується у розробці програмного забезпечення та відрізняється блоковою структурою. Ця мова складається з декількох фрагментів, і один з них – діаграми трьох типів:
- структурні діаграми;
- поведінкові діаграми;
- діаграми взаємодії.
Кожен з цих типів охоплює декілька діаграм. Базовий набір – поведінкові діаграми, з якими ми працюємо мало не щодня:
- діаграми активностей;
- діаграми сценаріїв використання;
- діаграми станів.
Раніше, коли бізнес-аналіз ще тільки починав розвиватися, BA широко використовували й інші різновиди діаграм.
Структурні:
- діаграми класів;
- діаграми об’єктів;
- діаграми компонентів;
- діаграми впровадження.
Пізніше всі вони перейшли до зони відповідальності технічних працівників, адже в них здебільшого містяться дані про технологічний стек та безпосередньо написання коду розробниками. Бізнес-аналітики все ще мають перевіряти ці діаграми, але за їх складання вже не відповідають.
Діаграми взаємодії:
- часова діаграма;
- діаграма послідовності;
- діаграма комунікації.
Можу сказати з власного досвіду, що наразі активно використовується лише діаграма послідовності. Інші мені не доводилося зустрічати в жодному з проєктів, над якими я працювала – я їх бачила хіба що в підручниках.
Таким чином, з усіх перелічених діаграм малювати потрібно вміти три поведінкові діаграми. Ще чотири – діаграми класів, компонентів, впровадження та часову діаграму – варто навчитися читати та розуміти. Це необхідно бізнес-аналітику для виконання його прямого обов’язку – забезпечення відповідності технологічних рішень інтересам бізнесу. Наскільки цей процес успішний.
Доцільність малювання діаграм
Щоб зрозуміти, чи потрібно використовувати діаграми у своїй діяльності, варто відповісти на кілька запитань:
- Навіщо ви хочете намалювати діаграму? Використання артефактів у вигляді діаграм має бути чітко обґрунтоване.
- Чи буде у вас час підтримувати такий підхід до робочого процесу й надалі? Адже створення діаграми навіть для великої команди – це тиждень роботи, основний же час займає її постійне оновлення.
- Для кого ви малюєте діаграму? Ви можете робити це для себе або третіх осіб. Якщо йдеться про представників бізнесу, потрібно впевнитися, що вони зможуть її прочитати, адже не всім зрозумілий навіть BPMN, а тут – технічна документація. З командою розробників та сама ситуація: UML – це не їх спеціалізація, тому не всі можуть навіть правильно читати такі діаграми. І ми повертаємось до попереднього питання: чи знайдете ви час на навчання команди?
Якщо відповідь хоча б на одне з цих запитань «Ні», не варто й починати. Якщо вам потрібно швидко показати якусь послідовність дій, візьміть звичайну алгоритмічну нотацію: If, Then, Else, хоча цей підхід і не настільки комплексний та глибокий. Однак бувають проєкти, де нотації необхідні. На це може бути три причини:
- Цього вимагає хтось зі стейкхолдерів, адже добре знається на нотаціях та йому зручно з ними працювати. Їх використання пришвидшує для нього аналіз та робить зрозумілим напрямок руху команди.
- Над проєктом працюють декілька вендорів, які розуміються на нотаціях. В цьому випадку їх використання значно полегшить комунікації між технічними спеціалістами.
- Це вимога архітектора, який не приймає жодну нову функціональність без підкріплення моделі даних або моделі взаємозв’язків.
То чи варто використовувати UML? І якщо «так», то як її впровадити максимально успішно? Ось декілька рекомендацій стосовно цього.
- Говоріть з представниками бізнесу. Уточнити, чи сприймають вони UML або BPMN нотації – це нормально.
В моїй практиці був кейс, коли клієнт сказав: «Якщо у вас досить часу і є бажання, можете намалювати діаграми, але до Definition of Done (визначення готовності) я цю вимогу не додаю». Добре! Частково діаграми на проєкті малювалися, частково – ні.
Якщо ж клієнт запитає у вас, що таке UML та BPMN, забудьте про ці діаграми. Це означає, що ви маєте справу з класичним бізнесом, який розуміє мову грошей, дедлайнів і ризиків. Діаграми можуть бути присутні лише схематично. - Говоріть з командою. Їй може бути комфортно говорити мовою UML.
На одному з проєктів розробники мені сказали: «Не пиши багато тексту, намалюй дві діаграми, ми розберемося». Це було дійсно круто: ми зекономили купу часу та ресурсів. Єдиний мінус полягав у тому, що було некомфортно планувати. Тому можу сказати з власного досвіду: краще шукати золоту середину. - Думайте, зважуйте всі переваги та недоліки нотації. Починайте використовувати UML тільки тоді, коли впевнені в правильності рішення на 100%. Якщо ви почнете малювати діаграми й кинете справу на півдорозі, буде некомфортно всій команді, і насамперед бізнес-аналітику. Адже спеціалісти будуть очікувати на діаграми, а коли вони перестануть з’являтися, виникнуть питання саме до вас.
- Спробуйте знайти інший шлях до візуалізації. Не завжди використання UML-діаграм є доцільним. В деяких випадках розумніше намалювати скриншоти в iFrame: створити мінімальні приклади вигляду системи та показати стрілочками напрямок руху кожного спеціаліста. Це буде швидше, наочніше та допоможе досягти поставленої задачі набагато якісніше.
- Не малюйте лише тому, що можете. Варто пам’ятати, що одного разу ви можете перестати встигати. Якщо ваш рівень як бізнес-аналітика вже досить просунутий, ви повинні знати нотації, та це все ж не означає, що їх потрібно використовувати завжди. Вашим принципом має стати твердження: малюю не тому, що можу, а тому, що потрібно.
Підіб’ємо підсумки
Обираючи підхід до моделювання бізнес-процесів, завжди варто дивитися на такі речі:
- Хто ваш споживач та чи сприймає він UML/BPMN?
- Скільки часу буде займати підтримання актуальності діаграм, які ви плануєте намалювати?
- Чи принесе це хоча б невелику користь вам, команді та вашому клієнту?
Якщо відповідь на всі три запитання «Так», і є об’єктивна потреба, можна сміливо використовувати UML-діаграми. Якщо ж хоча б на одне запитання ви не надали стверджувальної відповіді, подумайте: можливо, є сенс обрати інший спосіб візуалізації.
Якщо вам необхідна практика побудови основних діаграм, що найчастіше використовуються у командах розробки ІТ-рішень — запрошуємо на курс UML: Unified Modeling Language.
Детальніше про UML та BPMN дивіться у вебінарі:
Стаття взята з блогу компанії E-5