Скажи щось айтішною: бізнес-аналітик

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

Хто такий бізнес-аналітик

— Коли питають, що робить бізнес-аналітик, то логічно відповісти, що він аналізує бізнес. Але насправді не все так просто. На одному з мітапів я почула таке запитання — коли бізнес-аналітик стане непотрібною професією? Ніхто не розуміє, що вони роблять: кодів не пишуть, продуктових рішень не приймають. І була відповідь, що бізнес-аналітик певною мірою унікальна людина, тому що у нього два мозку. Перший розуміє бізнес, а другий — розробників, і я повністю поділяю цю думку, — ділиться Валерія.

— Бізнес-аналітик — це сполучна ланка між бізнесом та людьми, які пишуть код. Уявімо, прийшов бізнес і сказав, що йому потрібний інтернет-магазин. Виникає питання, що мається на увазі під інтернет-магазином? Перше, що спадає на думку, — це якийсь сайт. Бізнес-аналітик повинен поставити безліч уточнювальних питань: який це сайт, які вкладки, який товар буде представлений, чи буде на сайті оплата і через які системи? А може це взагалі просто вітрина без можливості робити покупки, де людина може просто ознайомитися з асортиментом? Чи можна залишати коментарі до замовлення? Постає дуже багато запитань, що чіпляються один за одного, але представник бізнесу часто не думає про це. А розробники чи дизайнери повинні знати, що їм малювати та розробляти. Тому просто прийти і сказати, що потрібно намалювати інтернет-магазин, не можна. Таким чином, бізнес-аналітик проходить усі етапи від просто ідеї з боку продукту та бізнесу та доводить до того моменту, коли це буде працювати.

Популярні терміни бізнес-аналітика

• «Сторя» (user story) — це користувацька історія, до якої входить опис функцій продукту, бажано простою і зрозумілою мовою. Вона має мати певний формат і відповідати загальноприйнятому набору критеріїв. Приклад одного з критеріїв — це уникнення двозначності. Одна й та сама «сторя» має сприйматися і бути зрозумілою різним людям однаково. User story складається з двох частин: основної частини та aceptance критеріїв (критеріїв приймання). Основна частина — це структурний опис побажань користувача. До aceptance критеріїв входять умови, яким повинен відповідати продукт, щоб його прийняв користувач. Ми думаємо не тільки про те, що користувач може зробити, а й навіщо йому це треба. Бізнес-аналітик стежить за тим, щоб розробка (розроблювана фіча) була потрібна і бізнесу, і користувачеві. Одне із завдань бізнес-аналітика — контролювати те, що йде в розробку. Воно має відповідати бізнес-цілям і потребам користувача, не виходити за межі скоупу (обсягу робіт, які потрібно виконати для досягнення цілей проєкту) і вирішувати проблему. Якщо до тебе приходить замовник і каже — хочу, щоб у мене по сайту літав літачок з лівого в правий кут, потрібно дізнатися, навіщо, яку бізнес-мету це несе, яку потребу користувача закриває. Можна сказати, що бізнес-аналітик — це сувора людина, яка постійно ставить багато запитань.
• BA approach (бізнес-аналітичний підхід). Важливо, щоб бізнес-аналітик правильно вибирав інструменти відповідно до завдань проєкту. Для цього існує BA approach — він необхідний, щоб визначитися, яким чином на проєкті вести документацію, як підтримувати комунікацію, за яким темплейтом (привіт, англіцизм) оформлювати юзер «сторю» та документацію, як їх систематизувати та зберігати. Це інструкція до того, як працювати. Особливо це важливо для джуніорів, які щойно прийшли на проєкт і не знають (та й не повинні), в якій ситуації як діяти. Головне — вміти правильно користуватись тим, що підготували старші колеги.
• Стейкхолдер-менеджмент. Стейкхолдери (зацікавлені особи) — це люди, чиї рішення та дії впливають на продукт. Дуже важливо знати, звідки до бізнес-аналітика надходять вимоги. Бізнес-аналітик постійно спілкується з бізнесом, тому необхідно розуміти, яка людина за що відповідає та якими повноваженнями наділена. Дуже часто трапляється так, що спонсор проєкту не має часу занурюватися в деталі. Але є працівники, в яких вплив на проєкт малий, а зацікавленість велика, сюди ж входять кінцеві користувачі продукту. Тут важливо розуміти, хто за що відповідальний, з якого питання до кого йти, з ким і як часто комунікувати. Частий кейс, коли прийшов стейкхолдер 1 і говорить, що кнопка має бути червоною, а стейкхолдер 2 — що синьою. Які твої дії як бізнес-аналітика? Відкриваємо документацію і дивимось, за що відповідає стейкхолдер 1, за що — стейкхолдер 2, і хто з них має повноваження ухвалювати це рішення.
• Ризик-менеджмент. Цей термін знайомий не тільки аналітикам, а й продуктовим та делівері-менеджерам. Усі мають свій перелік ризиків, які можуть здійснитися. Ризики можуть бути негативні і позитивні. За традицією, всі зазвичай фокусуються на негативних ризиках. Для бізнес-аналітика один із найпопулярніших і найбільш обговорюваних — ризик тихого стейкхолдера, коли ти пишеш листи «в нікуди». Тобі потрібно щось уточнити, у тебе горять терміни, простоює команда розробників, ти не можеш передати «сторю» у розробку без фінального ОК або уточнити деталі, а відповіді немає. Тому подумати про це слід заздалегідь і розробити план дій в разі складної ситуації. До речі, цей ризик тісно пов'язаний із стейкхолдер-менеджментом.
• Elicitation and gathering requirements (вимоги до виявлення та збору інформації). Бізнес-аналітику важливо не вигадувати своїх вимог до системи, а вміти грамотно дізнаватися у бізнесу, що ж треба йому. І далеко не завжди на просте і зрозуміле питання можна почути таку ж просту і зрозумілу відповідь. Щоб знайти істину, застосовують різні техніки: інтерв'ю, брейншторми, опитування та інші способи. Дуже важливо правильно поставити запитання. Як ти запитуєш, таку відповідь і почуєш. А найкраща відповідь для бізнес-аналітика — чітка, повна і недвозначна. Тобі потрібно виявити всі вимоги максимально повно для того, щоб з ними працювати далі і передавати в розробку.
• Traceability management (управління відстежуваністю). Цей інструмент призначений для того, щоб не виходити за межі та не допустити якихось прогалин усередині. Якісно опрацьовані цілі на початку роботи — запорука успіху проєкту. Далі важливо створити послідовність від початкової бізнес-вимоги до кінцевої юзер «сторі». Оскільки дорога довга, то часто з'являються вимоги, яких не було спочатку, або, навпаки, щось губиться. І настає момент, що вже незрозуміло, навіщо ти це робиш. Ми співвідносимо бізнес-потреби з потребами користувача. Потім вигадуємо рішення, дробимо його на фічі, фічі на «сторі». Це все можна уявити у вигляді traceability-матриці — таблиці, де видно, як від джерела проблеми ми доходимо до конкретної «сторі». Цей інструмент класно застосовувати, щоб у процесі не забути, що, навіщо і для кого ми робимо. В кінці, коли ти розумієш, що у тебе умовно 30 user stories і багато з них не покривають жодну з бізнес-цілей, від них потрібно відмовитися, щоб не робити зайву роботу і не зіткнутися з розчаруванням замовника.
• Беклог. Бізнес-аналітик — один із тих, хто відповідає за беклог продукту. Це місце, куди складаються всі завдання, які потрібно виконати. Далі бізнес-аналітик з командою та власником продукту їх естимує (оцінює) та пріоритизує (дуже багато технік пріоритизації можна знайти тут). Дати правильний пріоритет завданню напрочуд важливо, адже не варто забувати про принцип Парето, коли 80% результату припадає на 20% зусиль. Ці 80% дозволяють продукту працювати та приносити певну цінність. Часто стається так, що ті завдання, які мали низький пріоритет, виходять зі скоупу через непотрібність чи недостатню цінність.
• Бізнес-процеси. Бізнес-аналітики можуть малювати, як подорожують дані, але більше розуміються на бізнес-процесах — послідовності дій, результатом якої є створення продукту. Тут допомагає BPMN-діаграма (існує багато різних нотацій, але це одна з основних). Основне завдання розібратися із процесом AS IS (як зараз усе працює). Після візуалізації часто стає зрозуміло, де у процесі «болить». Другий етап — створення діаграми TO BE (яким має бути процес, щоб не «боліло»). Саме на її підставі йде робота з розробки та реалізації нової фічі або покращення вже реалізованої.

Детальніше із BPMN нотацією можна ознайомитися тут.

Якими якостями має володіти бізнес-аналітик

— Soft skills — це must have для бізнес-аналітика. Як не крути, основою є спілкування — порозумітися з бізнесом і розробниками. Створення артефактів не менш важливе. Але це іде як результат комунікаційної частини роботи. Тому важливо приділяти увагу таким скілам як problem solving та conflict management, і командній роботі. Сьогодні можна мати дуже круті hard skills, але якщо ти не вмієш спілкуватися, то нічого не вийде.

Важливими є й технічні знання, хоча б на рівні розуміння. Пам'ятайте про спілкування із колегами-розробниками.

Без знання англійської теж нікуди. Усю літературу рекомендую читати англійською. Якщо складно відразу читати англійською, то можна прочитати матеріал спочатку рідною мовою, а потім його ж — англійською.

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

Обговорити статтю запрошуємо в Discord-каналі.