Рішення вже прийняті. То навіщо тоді BA

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

Мене звати Володимир Клевцов. Я керую командою бізнес-аналітиків і вже понад 7 років працюю над впровадженням великих корпоративних систем у різних доменах. За цей час я дедалі частіше помічав, що найбільший вплив бізнес-аналітика виникає не під час написання вимог, а значно раніше — у момент, коли бізнес-запит лише починає перетворюватися на майбутнє рішення.

Ця стаття буде корисною бізнес-аналітикам, Product Owner’ам, проєктним менеджерам і всім, хто бере участь у формуванні вимог та ухваленні рішень. У ній я хочу поділитися власним поглядом на те, де насправді знаходиться головна точка впливу BA і чому ця частина роботи часто залишається непомітною.

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

Інтро

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

Стейкхолдер приходить із формулюванням: «нам потрібен новий звіт», «давайте автоматизуємо процес», «треба реалізувати новий функціонал або навіть впровадити цілу систему».

Формально — це вимоги стейкхолдерів.

Насправді — це вже запропонований спосіб реалізації бізнес-потреби.

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

Роль BA за таких умов виглядає доволі просто:

зібрати вимоги → описати → передати в розробку.

Постає неприємне запитання:

• навіщо взагалі потрібен аналітик, якщо рішення вже ухвалені?

Але саме тут і починається справжня робота аналітика.

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

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

Іноді — через запитання.
Іноді — через формулювання проблеми.
Іноді — через те, які альтернативи взагалі потрапляють до обговорення.

Якщо подивитися на роботу BA під таким кутом, стає очевидно:

• його головна цінність — не в документації;
• його головна цінність — в управлінні процесом пошуку та вибору рішення.

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

1. Ілюзія: «рішення ухвалюють стейкхолдери»

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

Стейкхолдер рідко приходить із чимось на кшталт:
«Ми проаналізували п’ять альтернатив і обрали оптимальну».

Набагато частіше це звучить так:

• «нам потрібен новий звіт»;
• «давайте автоматизуємо цей процес»;
• «треба реалізувати ось такий функціонал».

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

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

І саме тут відбувається важливий зсув:

• рішення не існує в готовому вигляді;
• воно формується в процесі обговорення.

А отже, той, хто керує цим процесом, впливає на підсумкове рішення.

2. Де BA реально впливає на рішення

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

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

У підсумку мету бізнес-запиту формулюють приблизно так:
«Звіт необхідний для використання співробітниками відділу продажів».

Формально — мета є.
Насправді — вона нічого не пояснює і ні на що не впливає.

І саме в цьому місці бізнес-аналітик отримує одну зі своїх ключових точок впливу.

Якщо подивитися глибше, цілі присутні на кожному рівні декомпозиції вимог:

• мета бізнес-запиту;
• цілі вимог на рівні стейкхолдерів;
• цілі вимог до обраного способу вирішення задачі.

А отже, і точки впливу бізнес-аналітика розподілені між усіма цими рівнями.

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

3. Де вплив найбільший

Для себе я уявляю це як перевернуту піраміду впливу:

Що вищий рівень — то сильніший вплив на підсумкове рішення.

Що нижчий — то більше ми фіксуємо те, що вже було визначено раніше.

На кожному рівні аналітик може:

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

На перший погляд різниця здається незначною.

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

4. Вплив BA на кожному рівні

4.1. Бізнес-запит і його мета

Це вершина піраміди та точка найбільшого впливу.
Саме на цьому рівні визначається:

• яку бізнес-потребу необхідно задовольнити;
• навіщо це потрібно бізнесу;
• який результат буде вважатися успішним.

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

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

4.2. Вимоги на рівні стейкхолдерів та їхні цілі

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

Наприклад:

• поле у формі — щоб запобігти помилці;
• фільтр — щоб пришвидшити пошук;
• сповіщення — щоб скоротити затримку.

Саме на цьому рівні вплив BA проявляється через просте, але критично важливе запитання:

Навіщо існує ця вимога?

Якщо це запитання не поставити:

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

4.3. Вимоги щодо реалізації обраного способу та їхні цілі

Це нижній рівень піраміди.
Тут уже йдеться про те, як саме буде реалізовано вимоги:

• які поля, кнопки та сценарії потрібні;
• які існують обмеження;
• як поводитиметься система.

Цілі існують і на цьому рівні, але вони є похідними від попередніх рівнів і значно менше впливають на підсумкове рішення.
На цьому етапі BA частіше:

• уточнює;
• структурує;
• документує.

А не змінює напрямок рішення.

Ключова думка розділу

Мета існує на кожному рівні.
І на кожному з них BA допомагає її уточнити — а через це впливає на рішення.
Але що вище по цій «піраміді» працює бізнес-аналітик, то сильніший його вплив на кінцевий результат.

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

5. Механізми впливу

Завдяки чому BA впливає на рішення?

Я б виділив чотири основні механізми.

5.1. Через запитання

Рішення рідко змінюються тому, що BA пропонує власну думку.
Набагато частіше вони змінюються тому, що BA ставить запитання, яких раніше ніхто не ставив.

Наприклад:

• Яку проблему ми вирішуємо?
• Чому це важливо?
• Що вважатиметься успішним результатом?
• Чому обрано саме цей варіант?
• Які альтернативи розглядалися?

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

5.2. Через формулювання проблеми

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

Наприклад:

«Нам потрібен новий звіт»
і
«Нам потрібно скоротити фінансові втрати»

Формально йдеться про одну й ту саму ситуацію.
Але простір рішень буде зовсім іншим.

Коли BA допомагає уточнити та переформулювати проблему, він впливає на те, які варіанти взагалі з’являться під час обговорення.

5.3. Через набір альтернатив, що розглядаються

Будь-яке рішення існує лише серед інших можливих рішень.
Якщо альтернатив немає — вибору теж немає.

Тому вплив BA проявляється не лише в пошуку відповіді, а й у формуванні набору варіантів, серед яких цю відповідь буде обрано.

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

5.4. Через обмеження простору рішень

На мою думку, це один із найбільш недооцінених механізмів впливу бізнес-аналітика.

Простір рішень може бути обмежений не лише стейкхолдерами, а й об’єктивними чинниками:

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

На практиці цьому етапу часто приділяють недостатньо уваги або проходять його формально.

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

Однак саме на цьому етапі вплив BA полягає у своєчасному визначенні реальних меж простору рішень.

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

Наприклад, якщо платформа підтримує функціональність X, але принципово не підтримує функціональність Y, то обговорення варіантів реалізації Y втрачає сенс ще до початку проєктування.

Висновок розділу

Цікаво, що жоден із цих механізмів не потребує формальної влади.

BA не призначає бюджет.

Не затверджує стратегію.

Не ухвалює остаточних рішень.

Але саме через запитання, формулювання, альтернативи та розуміння обмежень BA впливає на процес, у якому ці рішення з’являються, обговорюються й ухвалюються.

6. Як це виглядає на практиці

Запит → аналіз наслідків → мета → аналіз формулювання мети → виявлення першопричин → рішення.

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

Отже.

Стейкхолдер звернувся із запитом:
«Потрібен звіт, який показуватиме перелік помилково внесених даних у системі».

Як такий простий запит, що на перший погляд здається зрозумілим і логічним «рішенням», перетворюється на аналітичне завдання та дає можливість вплинути на результат?

Маючи інженерну освіту, я звик розв’язувати задачі, рухаючись від наслідків до причин .

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

Крок 1. Визначити наслідки відсутності рішення

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

Крок 2. Проаналізувати виявлені наслідки

Усі ці наслідки об’єднані одним результатом — фінансовими втратами через некоректні розрахунки та нераціональне використання часу працівників.

Крок 3. Визначити мету

Стає очевидно, що мету можна сформулювати так:
«Зниження фінансових втрат, спричинених некоректними даними в системі».
Готово, мету визначено.
Але це лише початок наступного рівня аналізу.

Крок 4. Проаналізувати формулювання мети

Звернімо увагу на цікаву деталь у формулюванні — «некоректні дані в системі».
Розвиваю думку далі й намагаюсь відповісти на запитання:

«Як некоректні дані потрапляють у систему?»

Можливі варіанти відповіді, хоча їх, звичайно, може бути більше:

• під час ручного введення даних користувачем;
• під час передавання даних із зовнішніх систем через API-інтеграції;
• під час автоматичного розпізнавання тексту.

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

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

Тому наступний крок — не проєктування звіту, а аналіз джерел виникнення помилок.

Крок 5. Аналіз першопричин і пошук способів досягнення мети

Різні джерела — різні рішення щодо способів реалізації.
Якщо це ручне введення, проблема виникає на рівні взаємодії користувача із системою.
Можливі рішення:

• валідація у полях введення;
• обмеження форматів;
• підказки та контроль введення.

Якщо дані надходять через API, проблема може бути в інтеграції або контракті даних.
Можливі рішення:

• валідація на етапі приймання даних;
• контроль схеми;
• обробка некоректних payload.

Якщо використовується розпізнавання тексту, проблема може бути в якості алгоритму розпізнавання.
Можливі рішення:

• удосконалення моделей або патернів;
• додаткове навчання моделі;
• додавання ручної верифікації у критичних точках.

Висновок розділу

Початковий бізнес-запит у формулюванні «потрібен звіт» не допомагає досягти бізнес-мети.
Сам бізнес-запит не є інструментом її досягнення.
Запитуваний звіт лише покаже, що мети не досягнуто, та підсвітить відхилення від неї.
Отже, реальне досягнення мети завжди лежить на рівні першопричини, а не на рівні звітності.

Вплив BA — це не випадковість і не талант.
Це послідовність розумових кроків, яку можна застосовувати усвідомлено.

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

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

Але саме між першим бізнес-запитом і фінальним способом його реалізації відбувається найважливіша — і водночас найменш помітна — частина роботи бізнес-аналітика.

Саме тут:

• з’являються запитання;
• уточнюються цілі;
• аналізуються наслідки;
• виявляються першопричини;
• формуються та оцінюються альтернативи.

І саме тут поступово змінюється напрям пошуку способу досягнення мети.

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

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

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

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