Процес моделювання предметної області. Гайд для бізнес-аналітиків
Привіт, мене звати Ілля, працюю продакт-менеджером в Star.
На цю статтю мене наштовхнула думка, що тема пресейлів стає все більш і більш актуальною, адже український ІТ-аутсорс дещо втратив клієнтів останнім часом і багато компаній налягли на залучення нових. Рано чи пізно, вони почнуть вистрілювати, що створить певне навантаження на пресейл-команди, в тому числі та на бізнес-аналітиків.
Я сподіваюсь, що ця техніка допоможе всім, хто задіяний у пресейлах, а особливо тим, хто не привʼязаний до конкретної індустрії, потребує швидкого занурення у новий для себе чи компанії домен.
Предметна область (домен)
Що ж таке предметна область і навіщо її моделювати? Трохи теорії.
Предметна область, або домен, у загальному сенсі можна визначити як «сфера знань, впливу або активності...», а специфічно для розробки програмного забезпечення «..., навколо якої будується логіка програмного забезпечення». Детальніше тут.
Модель — це спрощений спосіб представлення реальності. У цій статті йтиме мова про концептуальну модель, тобто представлення сукупності обʼєктів, навколо чи за допомогою яких ми будемо будувати нашу майбутню систему.
Коли ми створюємо концептуальну модель, ми аналізуємо домен в цілому, тому не так важливо розділяти поточний і майбутній стани системи.
Створення доменної моделі може бути корисним:
- для поглиблення вашого власного розуміння, адже сам процес створення стимулює дослідження;
- як інструмент для виявлення вимог, особливо скритих, очевидних для замовника;
- як інструмент передачі знань;
- як інструмент для спілкування з архітектором.
Аналітик в пресейлі
На поточному місці роботи раз на кілька місяців доводиться брати участь у пресейлах.
В залежності від запиту, з яким прийшов замовник, команда пресейлу може мати технічних спеціалістів (як мінімум архітектор), проджект-менеджера (зазвичай у якості пресейл ліда), UX-спеціаліста та спеціаліста, що покриває частину бізнес-аналізу (бізнес-аналітика або продакт-менеджера).
З точки зору бізнес-аналітика, специфіка пресейлу полягає у тому, що потрібно у досить короткий термін сформувати вимоги, які потім має оцінити технічна команда. Також досить часто потрібно доєднатись до пресейлу, домен якого аналітику досконало (чи взагалі) не відомий.
Звідси постає декілька критичних питань:
- як за короткий час, та ще й не знаючи домену, побудувати якісні вимоги?
- як показати замовнику, що ми говоримо з ним однією мовою?
- як ставити релевантні запитання?
Додамо до цього обмеження часу, що заданий рамками пресейл-проєкту, ще й основний проєкт задіяного аналітика та необхідність хоч іноді відпочивати.
Для себе я відповів на це питання, зупинившись на моделюванні предметної області (domain model), як інструменті, що дозволяє в досить стислі терміни з мінімальною інформацією на вході зрозуміти про що йдеться.
Перед тим, як почати
Дотримуюсь підходу, що будь-який інструмент чи техніку є шанс ефективно застосувати, якщо мати на увазі наступні основні елементи: вхідна інформація, цілі, зацікавлені особи, інструменти.
Цілі
Спочатку наведу приклади типових цілей моделювання:
- Розібратись самому в новому бізнес домені і на основі цього виконати наступні пункти.
- Сформувати перелік питань для інтервʼю замовника.
- Сформувати перелік сценаріїв використання.
- Пояснити суть предметної області технічним спеціалістам.
- Передати знання іншому бізнес-аналітику або цілій команді.
Зацікавлені особи
Відповідно до цілей з прикладу, найголовнішою зацікавленою особою тут у першу чергу є сам аналітик, далі — його наступник з команди розробки, архітектор, дизайнер тощо. Потенційно — всі, хто так чи інакше буде брати участь у пресейлі та у розробці.Вхідна інформація
На вхід може бути отримано все що завгодно, від незначного брифінгу сейлза до велетенського RFP з переліком функціональностей, яку надіслав потенційний клієнт. Rule of thumb для мене такий — чим менше вхідної інформації, тим більше зростає важливість надати їй форму та розібратись.Інструменти
Під інструментами я маю на увазі програмне забезпечення (софт) для моделювання та нотації. Але тут все просто — чим краще володієте тим, що доступно або прийнято у вашій компанії — те і використовуєте. Іноді нотації та софт диктуються проєктом, але це рідко буває саме на пресейлах. Сам підхід, який я хочу сьогодні розглянути не залежить від інструментів.Для себе серед нотацій (UML Class Diagrams, Crow’s foot ERD, ERM) саме для концептуальних моделей я зупинився на нотації Crow’s foot. По софту останнім часом все більше використовую Miro іноді diagrams.net, рідше — PlantUML.
В принципі, для власних потреб, можна швиденько накидати просто стікерів чи квадратиків і не паритись з нотацією (створити такий собі mind map). Але такий підхід погано масштабується. Тож якщо плануєте вашу майбутню модель комусь показувати, щось за допомогою неї пояснювати — варто оформити її як слід.
Процес моделювання
Отже, визначившись із вищеперерахованим і зібравши з доступних джерел інформацію, можна переходити до моделювання. В залежності від складності домену, що в першу чергу задається вашим його початковим рівнем розуміння, процес може трохи відрізнятись, але в середньому можна прийняти наступний порядок дій:- Занотувати своє розуміння того, про що проєкт, що має робити застосунок, яку проблему вирішувати.
- Перерахувати основних користувачів або персон.
- Продумати ключові сценарії використання чи взяти ті, про які згадав замовник.
- Визначити процеси, які на вашу думку необхідні для забезпечення діяльності компанії замовника.
Це по суті і буде контекст, який вже можна використовувати для нарощування обсягу інформації: пошуку у Google чи запитів до ChatGPT, чи, в ідеалі, питань до замовника та SME (експерта предметної області).
Цей процес займає від декількох годин до днів і напряму залежить від якості та кількості вхідної інформації. З власного досвіду, після того, як набив руку, максимальний час складає до 8 годин протягом декількох днів. Для чогось зовсім нового (а-ля rocket science) звісно часу потрібно значно більше, зросте кількість ітерацій та уточнень.
Для прикладу візьмемо задачу з реального проєкту, але значно спрощену:
«Побудувати систему для морського вантажного терміналу, що буде відповідати за розвантаження контейнерів із судна та розміщення їх у контейнерному депо.»
Сутності
Не залежно від нотації, яку ми оберемо, наступним кроком моделювання буде запис всіх можливих сутностей (обʼєктів) у нашому домені. Для концептуальної моделі здебільшого це будуть фізичні обʼєкти, які нам потім знадобляться (або ні) у нашій майбутній інформаційній системі.
Ідентифікувати основні обʼєкти можна, розглядаючи процеси та сценарії використання, які ми записали раніше — це щось, над чим виконується операція (фізичні об’єкти, документи й т.д..), і хтось, хто виконує ці операції.
Основні сутності нашого домену
Атрибути
Далі потрібно записати атрибути — характеристики сутностей, що ми обрали. Відрізнити атрибут від сутності (обʼєкту) дуже просто: атрибути самі ніякої роботи не виконують, вони тільки можуть щось описати. Також в атрибутів є значення, наприклад:
Обʼєкт — атрибут — значення
Варто зазначити, що на рівні концепту самі атрибути та їх значення не відіграють вирішальної ролі, в цілому ними можна знехтувати. Проте, якщо ми хочемо скласти краще уявлення про домен, хоча б основні атрибути потрібно записати.
Деякі важливі атрибути наших сутностей
Звʼязки
Тепер можна переходити до звʼязків. Знову таки, абстрагуючись від нотації, зв’язок — це те, яким чином сутності асоціюються одна з одною. Зв’язок можна схарактеризувати:
- дією, що поєднує дві сутності,
- співвідношенням сутностей одна до одної (Cardinality). Звʼязок в основному встановлюють, керуючись загальною логікою, та іноді його можуть продиктувати атрибути:
- один оператор маніпулює декількома кранами,
- декілька кранів розташовані на одному причалі,
- щонайменше одна зона розміщення контейнерів розташована на одному причалі,
- один кран може розвантажити декілька контейнерів,
- багато або жодного контейнера може бути перевезено на кораблі,
- один корабель може бути пришвартовано в одному доці.
- будьте консистентними (наприклад, якщо вказуєте кардинальність, робіть це всюди, використовуйте однаковий шрифт та формат фігур);
- на скільки це можливо, уникайте перехрещень зв’язків та не робіть їх надто довгими;
- в ідеалі, підписи звʼязків мають читатись зліва направо та згори вниз.
- у вас закінчився час на виконання задачі,
- ви не можете сформулювати нових висновків з існуючої моделі,
- можете пояснити, про що ваша модель непідготовленій людині, і її питання не ставлять у вас у глухий кут.
- формулювання якісних питань до замовника,
- комунікації меж відповідальності або scope проєкту,
- виявлення сценаріїв використання та вимог,
- у випадку успіху пресейлу потрібен ще й інструмент для передачі знань іншому аналітику та і всій команді розробки.

16 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів