Бізнес-аналітики мають особливі здібності, які підсилюють їхню цінність для будь-якої команди чи організації.
BA — це не просто «писар», який занотовує все, що кажуть різні стейкхолдери. Ефективний BA копає глибше, шукаючи те, що лишається неозвученим:
- Якщо ви чуєте припущення — чи воно досі валідне? Хто це стверджує? А що, якщо ні?
- Якщо ви чуєте ідею рішення — це справжнє обмеження (constraint) чи просто одна з ідей?
- Кому насправді потрібна можливість (capability), яку щойно описав користувач?
- Чи є інші способи, якими користувач може захотіти виконати конкретне завдання?
- Яких обмежень, стандартів, регуляторних вимог і політик має дотримуватися рішення?
- Як рішення має обробляти різні помилкові ситуації (error conditions)?
- Коли хтось каже «зручний для користувача», що саме мається на увазі? Як ми можемо це оцінити? Те саме стосується багатьох інших атрибутів якості (quality attributes).
Ні, BA — не писар, а дослідник, який спрямовує команду розробки до розв’язання правильної проблеми — шляхом побудови правильної функціональності, коректно і в потрібний момент. BA не дає стейкхолдерам блукати навмання, навіть якщо в них найкращі наміри.
Оскільки організації починають використовувати ШІ для генерації вимог до продукту, кмітливий BA додає критичну «перевірку реальністю». Генеративні інструменти ШІ добре відомі тим, що створюють галюцинації — помилковий або вигаданий контент, поданий так само авторитетно, як і точна інформація. BA має валідувати все, що створює ШІ, а не просто припускати, що воно правильне. Не варто очікувати, що ШІ замінить якісне критичне мислення.
Суперсила №3: перемикатися між рівнями абстракції
Дехто мислить «великою картиною» (високий рівень абстракції). Інші надають перевагу деталям (низький рівень абстракції). Але небагато людей уміють однаково добре мислити на обох рівнях і легко переходити між ними залежно від ситуації. Бізнес-аналітики особливо сильні саме в цьому.
Вибір доречного рівня абстракції стає критичним під час сесій elicitation (виявлення/збору вимог). Стейкхолдери часто з самого початку занурюються в «високодеталізовані» нюанси. Однак фасилітатору зазвичай ефективніше почати з загального бачення й відкласти деталізацію на потім.
Фасилітатор має вміти помічати момент, коли група «пірнає в кролячу нору» — передчасно відволікається на деталі й майже не просувається вперед. Тоді він/вона може повернути обговорення до фокусу на правильному рівні для цілей цього дня. Сьогодні ми ідентифікуємо use cases чи деталізуємо поведінку в межах одного use case? Сьогодні ми визначаємо об’єкти даних чи розбираємо їхні атрибути по одному? Усі ці дискусії важливі — але у свій час.
Уявімо, що команда генерує багато дрібних деталей на кшталт: «А, до речі, userId не може містити спеціальних символів». Розібратися, куди подіти такі фрагменти, — це як збирати пазл на тисячу елементів, піднімаючи по одному й щоразу думати: «Куди це вставити?» Такий підхід «знизу догори» не надто ефективний.
BA здатен(на) помічати, коли кілька фрагментів інформації або вимог логічно групуються. Наприклад, пов’язані user stories можна зібрати в один use case з кількома альтернативними потоками (alternative flows). Уміння легко «ковзати» вгору й вниз шкалою абстракції — ще один спосіб, у який талановитий BA допомагає ефективно працювати і з людьми, і з інформацією.
Крім того, BA має вміти одночасно діяти в трьох часових контекстах:
- Минуле: чому були ухвалені певні рішення?
- Теперішнє: що команда має будувати зараз?
- Майбутнє: як продукт має еволюціонувати в коротко-, середньо- та довгостроковій перспективі?
З таким «часовим баченням» BA може дивитися за горизонт в обох напрямках і правильно розміщувати сьогоднішню роботу в потрібному контексті.
Суперсила №4: ефективно представляти знання
Я подумки перекладаю фразу «писати вимоги» як «репрезентувати знання про вимоги». BA обирає найдоречніші способи подання знань залежно від ситуації та аудиторії. Менеджерам інколи достатньо маркованого списку або діаграми, тоді як розробникам потрібна більша деталізація. Один-єдиний спосіб репрезентації навряд чи задовольнить потреби всіх стейкхолдерів.
Колись я переглядав специфікацію вимог для наступного продукту консалтингового клієнта — складного електронного пристрою з кількома програмними й апаратними компонентами. У специфікації була довга таблиця зі станами пристрою та описом того, що відбувається, коли в кожному стані виконуються певні дії. Але, читаючи цю таблицю, було важко скласти цілісне уявлення про те, як працює пристрій загалом.
Тож я вирішив побудувати діаграму переходів між станами (state-transition diagram), щоб показати різні стани пристрою та дозволені переходи між ними. У процесі я виявив дві пропущені вимоги й одну помилкову вимогу в тій таблиці. Наявність різних технік у моєму інструментарії дозволяє обирати найкращу — щоб подати інформацію саме так, як потрібно для конкретної мети.
BA вміє обрати, як найкраще зафіксувати інформацію для подальшого використання та комунікації. Іноді потрібен текст, щоб передати всі деталі: розробники мають розуміти, що будувати; тестувальники — що перевіряти; клієнти — чого очікувати. Ієрархічно структурований текст і таблиці зазвичай зручніші в роботі, ніж довгі наративні абзаци або марковані списки.
В інших ситуаціях діаграма може або замінити, або (частіше) доповнити текст. Я вважаю моделювання (modeling) невід’ємною практикою бізнес-аналізу. Досвідчений BA знає, коли потрібна детальна специфікація вимог, коли достатньо кількох user stories на стікерах, а коли варто «намалювати картинку».
Суперсила №5: фасилітувати співпрацю
Основа ефективної співпраці — комунікація. У своїй суті бізнес-аналіз — це про комунікацію. Бізнес-аналітик виступає «містком» між різнорідною спільнотою користувачів, яких часто представляють product champions, і командою розробки:
BA має ідентифікувати численних стейкхолдерів, яким є що сказати про вимоги або які в інший спосіб зазнають впливу від ініціативи. Не всі стейкхолдери мають однакову «вагу», тож BA потрібно розуміти, хто з них має найбільший вплив на численні рішення, які доведеться ухвалювати.
Бізнес-аналітики мають розуміти цілі, занепокоєння, обмеження, упередження, страхи та тиск у кожній спільноті стейкхолдерів. BA знають, що клієнт не завжди має рацію, але клієнт завжди має підставу. Потрібно розуміти й поважати внесок клієнта. Водночас варто прямо вказувати, коли очікування клієнта нереалістичні або він просто помиляється. Це може бути дискомфортно, але така відвертість допомагає BA спрямувати команду до правильних рішень.
Колись я був(ла) провідним BA у команді, що запускала проєкт після того, як дві попередні команди зазнали невдачі. Головний стейкхолдер був злий і під сильним тиском. «У мене більше немає часу обговорювати вимоги!» — сказав він мені. — «Зробіть мені систему!» Я переконав(ла) його, що ми застосуємо нові техніки (зокрема use cases) і задокументуємо все, що дізнаємося. Він неохоче погодився співпрацювати. Проєкт виявився великим успіхом, і стейкхолдер був у захваті.
Ми всі пропускаємо те, що чуємо від інших, через власні «фільтри». Як висловився мій колега Антон, BA потрібна «здатність слухати без упередження, передчасного судження або інтелектуальної прив’язаності». BA має виходити за межі власної системи координат, щоб почути реальні проблеми, опиратися спокусі нав’язувати власні вподобання та спрямовувати учасників до визначення задовільних рішень.
Стейкхолдери часто висувають суперечливі потреби та пріоритети. Якщо ці суперечності не розв’язати, з ними доведеться розбиратися команді розробки. BA має встановити процес ухвалення рішень, який дозволить вирішувати такі конфлікти до того, як вони почнуть заважати співпраці. Бізнес-аналітики здатні фасилітувати складні розмови й переговори між стейкхолдерами, щоб досягати оптимальних для бізнесу результатів.
Коротко кажучи, роль BA включає в себе те, щоб «посадити всіх на одну сторінку» — і втримати їх там.
Ти — Super BA?
Якщо ти досвідчений бізнес-аналітик, ти вже накопичив(ла) цінний набір знань, умінь і інструментів. Ймовірно, частина цих «суперсил» у тебе вже є. Втім, завжди можуть знайтися можливості підсилити свої компетенції та стати ще ефективнішим(ою). Спробуй зробити інвентаризацію навичок (skills inventory), щоб зрозуміти, де додаткове навчання й практика дадуть найбільший ефект. А тоді «випусти в дію» ці п’ять сил у наступному проєкті — щоб допомогти організації побудувати правильне рішення для розв’язання реальної проблеми й отримати максимум бізнес-цінності.