Процес моделювання предметної області. Гайд для бізнес-аналітиків

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт, мене звати Ілля, працюю продакт-менеджером в Star.

На цю статтю мене наштовхнула думка, що тема пресейлів стає все більш і більш актуальною, адже український ІТ-аутсорс дещо втратив клієнтів останнім часом і багато компаній налягли на залучення нових. Рано чи пізно, вони почнуть вистрілювати, що створить певне навантаження на пресейл-команди, в тому числі та на бізнес-аналітиків.

Я сподіваюсь, що ця техніка допоможе всім, хто задіяний у пресейлах, а особливо тим, хто не привʼязаний до конкретної індустрії, потребує швидкого занурення у новий для себе чи компанії домен.

Предметна область (домен)

Що ж таке предметна область і навіщо її моделювати? Трохи теорії.

Предметна область, або домен, у загальному сенсі можна визначити як «сфера знань, впливу або активності...», а специфічно для розробки програмного забезпечення «..., навколо якої будується логіка програмного забезпечення». Детальніше тут.

Модель — це спрощений спосіб представлення реальності. У цій статті йтиме мова про концептуальну модель, тобто представлення сукупності обʼєктів, навколо чи за допомогою яких ми будемо будувати нашу майбутню систему.

Коли ми створюємо концептуальну модель, ми аналізуємо домен в цілому, тому не так важливо розділяти поточний і майбутній стани системи.

Створення доменної моделі може бути корисним:

• для поглиблення вашого власного розуміння, адже сам процес створення стимулює дослідження;
• як інструмент для виявлення вимог, особливо скритих, очевидних для замовника;
• як інструмент передачі знань;
• як інструмент для спілкування з архітектором.

Аналітик в пресейлі

На поточному місці роботи раз на кілька місяців доводиться брати участь у пресейлах.
В залежності від запиту, з яким прийшов замовник, команда пресейлу може мати технічних спеціалістів (як мінімум архітектор), проджект-менеджера (зазвичай у якості пресейл ліда), UX-спеціаліста та спеціаліста, що покриває частину бізнес-аналізу (бізнес-аналітика або продакт-менеджера).

З точки зору бізнес-аналітика, специфіка пресейлу полягає у тому, що потрібно у досить короткий термін сформувати вимоги, які потім має оцінити технічна команда. Також досить часто потрібно доєднатись до пресейлу, домен якого аналітику досконало (чи взагалі) не відомий.

Звідси постає декілька критичних питань:

• як за короткий час, та ще й не знаючи домену, побудувати якісні вимоги?
• як показати замовнику, що ми говоримо з ним однією мовою?
• як ставити релевантні запитання?

Додамо до цього обмеження часу, що заданий рамками пресейл-проєкту, ще й основний проєкт задіяного аналітика та необхідність хоч іноді відпочивати.

Для себе я відповів на це питання, зупинившись на моделюванні предметної області (domain model), як інструменті, що дозволяє в досить стислі терміни з мінімальною інформацією на вході зрозуміти про що йдеться.

Перед тим, як почати

Дотримуюсь підходу, що будь-який інструмент чи техніку є шанс ефективно застосувати, якщо мати на увазі наступні основні елементи: вхідна інформація, цілі, зацікавлені особи, інструменти.

Цілі

Спочатку наведу приклади типових цілей моделювання:

1. Розібратись самому в новому бізнес домені і на основі цього виконати наступні пункти.
2. Сформувати перелік питань для інтервʼю замовника.
3. Сформувати перелік сценаріїв використання.
4. Пояснити суть предметної області технічним спеціалістам.
5. Передати знання іншому бізнес-аналітику або цілій команді.

Зацікавлені особи

Вхідна інформація

Інструменти

Для себе серед нотацій (UML Class Diagrams, Crow’s foot ERD, ERM) саме для концептуальних моделей я зупинився на нотації Crow’s foot. По софту останнім часом все більше використовую Miro іноді diagrams.net, рідше — PlantUML.

В принципі, для власних потреб, можна швиденько накидати просто стікерів чи квадратиків і не паритись з нотацією (створити такий собі mind map). Але такий підхід погано масштабується. Тож якщо плануєте вашу майбутню модель комусь показувати, щось за допомогою неї пояснювати — варто оформити її як слід.

Процес моделювання

• Занотувати своє розуміння того, про що проєкт, що має робити застосунок, яку проблему вирішувати.
• Перерахувати основних користувачів або персон.
• Продумати ключові сценарії використання чи взяти ті, про які згадав замовник.
• Визначити процеси, які на вашу думку необхідні для забезпечення діяльності компанії замовника.

Це по суті і буде контекст, який вже можна використовувати для нарощування обсягу інформації: пошуку у Google чи запитів до ChatGPT, чи, в ідеалі, питань до замовника та SME (експерта предметної області).

Цей процес займає від декількох годин до днів і напряму залежить від якості та кількості вхідної інформації. З власного досвіду, після того, як набив руку, максимальний час складає до 8 годин протягом декількох днів. Для чогось зовсім нового (а-ля rocket science) звісно часу потрібно значно більше, зросте кількість ітерацій та уточнень.

Для прикладу візьмемо задачу з реального проєкту, але значно спрощену:

«Побудувати систему для морського вантажного терміналу, що буде відповідати за розвантаження контейнерів із судна та розміщення їх у контейнерному депо.»

Сутності

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

Ідентифікувати основні обʼєкти можна, розглядаючи процеси та сценарії використання, які ми записали раніше — це щось, над чим виконується операція (фізичні об’єкти, документи й т.д..), і хтось, хто виконує ці операції.

Основні сутності нашого домену

Атрибути

Далі потрібно записати атрибути — характеристики сутностей, що ми обрали. Відрізнити атрибут від сутності (обʼєкту) дуже просто: атрибути самі ніякої роботи не виконують, вони тільки можуть щось описати. Також в атрибутів є значення, наприклад:

Обʼєкт — атрибут — значення

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

Деякі важливі атрибути наших сутностей

Звʼязки

Тепер можна переходити до звʼязків. Знову таки, абстрагуючись від нотації, зв’язок — це те, яким чином сутності асоціюються одна з одною. Зв’язок можна схарактеризувати:

• дією, що поєднує дві сутності,
• співвідношенням сутностей одна до одної (Cardinality).
Звʼязок в основному встановлюють, керуючись загальною логікою, та іноді його можуть продиктувати атрибути: У наведеному прикладі:
• один оператор маніпулює декількома кранами,
• декілька кранів розташовані на одному причалі,
• щонайменше одна зона розміщення контейнерів розташована на одному причалі,
• один кран може розвантажити декілька контейнерів,
• багато або жодного контейнера може бути перевезено на кораблі,
• один корабель може бути пришвартовано в одному доці.
Жирним виділено приклад атрибута, який є посиланням на іншу сутність.Кардинальність не відіграє великої ролі при моделюванні концепту. Щоб засвоїти предметну область на рівні, достатньому для проведення пресейлу, це не завжди потрібно, скоріше бажано.

Оформлення

Після того, як ми все зʼєднали і описали настає час «причісувати» нашу модель. Деякі утиліти справляються з цим краще, деякі, наприклад PlantUML, візуально менш апетитні. В загальному, щоб вашу модель було легше сприймати, раджу звернути увагу на наступне:
• будьте консистентними (наприклад, якщо вказуєте кардинальність, робіть це всюди, використовуйте однаковий шрифт та формат фігур);
• на скільки це можливо, уникайте перехрещень зв’язків та не робіть їх надто довгими;
• в ідеалі, підписи звʼязків мають читатись зліва направо та згори вниз.
Я вживаю «бажано» і «в ідеалі», тому що через велику кількість сутностей це може бути досить складно, потрібно буде робити компроміси між розміром діаграми і «читабельністю». Сам процес моделювання у мене, сукупно, займає десь в районі 8 годин. Але протяжність може бути від декількох днів до тижня, знов таки, в залежності від складності домену, доступності SME або клієнта. Тож на весь процес створення я б закладав до чотирьох днів чистого часу і до двох тижнів по календарю для прям великих і комплексних RFP у практично невідомій сфері.

Наступні кроки

Немає, принаймні у мене, конкретних метрик, щоб визначити, коли пора завершувати процес. Поки що я не придумав кращого ніж «має бути достатньо». В залежності від масштабу (галузь знань в цілому, бізнес замовника, конкретний продукт) кількість сутностей і деталізація будуть різними. Тож і «достатньо» в кожному випадку буде інакшим, наприклад:
• у вас закінчився час на виконання задачі,
• ви не можете сформулювати нових висновків з існуючої моделі,
• можете пояснити, про що ваша модель непідготовленій людині, і її питання не ставлять у вас у глухий кут.
Іноді зупинитись важко через власний інтерес до предметної області. Але пресейли зазвичай досить обмежені у часі і задачі стоять дуже конкретні, тому я не бачу в цьому ризиків. У найгіршому випадку — ви ще краще розберетесь. Отже, після того, як ваша концептуальна модель зазнає декількох ітерацій, її можна використати для:
• формулювання якісних питань до замовника,
• комунікації меж відповідальності або scope проєкту,
• виявлення сценаріїв використання та вимог,
• у випадку успіху пресейлу потрібен ще й інструмент для передачі знань іншому аналітику та і всій команді розробки.

Логічна модель

Для того, щоб якісно деталізувати вимоги вже після успішного завершення пресейлу, потрібно опуститись на рівень нижче і створити логічну модель. Процес її створення аналогічний до концептуальної: можна використовувати ті самі інструменти, але вже критичну роль відіграють якісно і детально прописані звʼязки та атрибути сутностей. На цьому етапі у нас, як правило, буде краще розуміння вимог, цілей та обсягу проєкту, що дозволить виокремити з усього домену саме ті сутності, з якими буде працювати наша майбутня система.

Замість висновку

У цьому контексті знання техніки допомагає нам поглибити знання домену, тож у вічному холіварному питанні про «важлівіше техніка чи домен?» я схиляюсь до технік. Буду радий змістовним коментарям та питанням. Сподіваюсь, було корисно 🙂