Сьогодні пропонуємо вам нову статтю, у якій йдеться не тільки про кілька основних практик роботи бізнес-аналітики, але й про світогляд людини, яка виконує цю роботу. Матеріал взятий з спільноти EPAM і автором є Kamya Jangbahadur (EPAM, Lead Business Analyst), а адаптований переклад здійснила Софія Зеленська
Роль БА передбачає роботу з вимогами, управління відносинами зі стейкхолдерами, співпрацю та координування не тільки з внутрішніми, а й із зовнішніми стейкхолдерами в межах команди проєкту, а також роботу над самим проєктом на всіх етапах SDLC. Тому, свідомо чи несвідомо, ми постійно вирішуємо складні та заплутані ситуації.
Ви не одні на цьому шляху, і всі ми в певний момент у своїй ролі стикалися або можемо зіткнутися з такими ситуаціями.
З часом ми вчимося справлятися з цими ситуаціями, і на допомогу завжди приходять перевірені способи.
Обговорімо детально типові виклики, що трапляються в роботі бізнес-аналітика, та певні шляхи їх подолання.
- Робота зі складними стейкхолдерами – Не всі проєкти або зацікавлені сторони однакові, і цілком можливо, що БА матиме справу зі стейкхолдерами, які не беруть участі або є не дуже активними, відповідальними чи схильними до співпраці.
- У таких ситуаціях важливо набратися терпіння і спробувати організувати ван-ту-ван зустріч з клієнтом.
- Також важливо зрозуміти, чи не зайнятий клієнт іншими справами, а отже, чи може він приділити необхідний час та увагу. У таких випадках завоювати його довіру допоможе глибоке розуміння продукту, а також надання цінних ідей та пропозицій. Ця понаднормова робота допомагає полегшити його робоче навантаження, і тоді клієнт може надати вам повноваження приймати рішення за його відсутності, звичайно, з наміром завжди тримати його в курсі подій.
- У випадку, якщо вищезазначене не допомагає, і делівері починає зазнавати впливу, потрібно залучати Scrum-Master/Delivery Manager, щоб ця проблема могла бути вирішена через відповідні канали комунікації або ж через канал матриці ескалації клієнта (customer escalation matrix).
- Вимоги, які постійно змінюються – У світі гнучкого управління проєктами зміни вимог у зв’язку з еволюцією потреб замовника/ринку є звичайною справою. Проте іноді це стає складним завданням, коли це відбувається дуже часто і зриває виконання проєкту. Це виводить із себе команду, яка повинна аналізувати, оцінювати та працювати над новим обсягом робіт, іноді з дуже жорсткими термінами.
- У таких ситуаціях важливо розуміти, чому ця зміна була запроваджена, її нагальність та чи є спосіб скоротити існуючу роботу при розгляді нового обсягу, щоб уникнути вигорання команди та овертайму.
- Важливо встановити процес управління змінами та дотримуватися його для уникнення демотивації команди, а також для безперервного та комфортного делівері і релізу.
- У рідкісних випадках важливо досягти компромісу через неминучі ситуації, такі як регуляторні/юридичні вимоги, зобов’язання щодо критично важливого продукту та цінність змін для критично важливих та великих клієнтів.
- Пропущені або нечіткі вимоги – Від БА очікують, що він добре знає вимоги і розуміє їх настільки, що може уникнути двозначності. Однак іноді бізнес-аналітик, будучи новачком у цій галузі або не маючи достатніх знань про продукт, може створювати суперечливі або нечіткі специфікації.
- У такій ситуації важливо, щоб БА звертався за експертною оцінкою, схваленням від стейкхолдерів, зворотним зв’язком до лідів/архітекторів, які краще розуміють продукт.
- БА повинен докладати постійних зусиль для отримання хорошого розуміння продукту і повинен бути впевненим, що специфікації вимог є чіткими. Він має бути переконаним, що специфікації містять достатньо деталей для розробки системи, а надана інформація може задовольнити бізнес-очікування.
- Неможливість отримати затвердження вимог – існує ймовірність того, що БА не зможе отримати підпис на вимогах, що іноді є блокуванням для команди, яка починає реалізацію. Це може статися у випадках, коли стейкхолдер зайнятий або не повністю усвідомлює/переконаний у специфікації вимог, а отже, йому важко підтвердити, що робота готова до впровадження.
- У таких ситуаціях БА може провести покрокове обговорення зі стейкхолдером.
- Зафіксувати зустрічі для отримання згоди та розмістити їх у файлі з вимогами.
- Додати коментар до тікета, в якому зазначається, що вимоги завершені та готові до розгляду та підписання. Якщо не залишиться більше відкритих питань, ми плануємо розпочати реалізацію до <x> дати/терміну. Таким чином, власність та підзвітність для ПО може бути зміщена та виділена.
- Нереалістичні очікування від ролі БА – У багатьох компаніях роль БА все ще залишається невизначеною. Багато людей плутають цю роль з відповідальністю тільки за співпрацю, або іноді тільки за документацію, або тільки за управління ресурсами. Іноді на стороні замовника є бізнес-аналітики, і відповідно роль БА на стороні постачальника може бути звужена до ролі посередника з меншою потребою у створенні вимог або участі у впровадженні рішень. Існує також тонка межа між обов’язками Product Owner, Scrum-master та Business Analyst.
- Щоб чітко розуміти очікування від БA, перш за все, важливо попередньо окреслити сферу відповідальності та обов’язки БA на проєкті й отримати згоду від клієнта.
- Щоб уникнути зайвих очікувань, важливо, щоб сам БA не ставав джерелом нереалістичних очікувань.
- Вирішення конфліктів у команді та зі стейкхолдерами – Оскільки БА має справу як із зовнішніми, так і з внутрішніми стейкхолдерами, він може часто опинятися в конфліктних ситуаціях, незалежно від того, чи це стосується роботи з декількома стейкхолдерами, де можуть виникнути конфлікти в процесі обговорення, досягнення консенсусу, ЧИ під час роботи з внутрішньою командою розробників та тестувальників, наприклад, щодо обсягу інформації, доступної в історії користувача, або прийняття пропущеної вимоги чи розбіжностей щодо термінів.
- Кожна ситуація може вимагати переговорів або компромісу, однак ми завжди повинні представити належне обґрунтування. Наприклад, у конфліктних ситуаціях з БА, де декілька стейкхолдерів мають різний спосіб мислення, важливо провести належну перевірку та вивчити всі “за” і “проти” кожної ситуації, залучити експертів та впливових людей, які можуть допомогти вирішити ситуацію з позитивним результатом.
- Щоб контролювати та вирішувати конфлікти з командою, яка пов’язана з вимогами, іноді легше змиритися з тим, що просто стався промах. Часто можна помітити, що user stories в agile не можуть бути деталізованими, тому важливо налагодити процес, щоб всіляко допомагати команді отримати максимальну ясність щодо вимог, залучаючи їх до постановки питань або створюючи контрольний список для перевірки при розробці/тестуванні подібних вимог.
- Робота з клієнтом в іншому часовому поясі – Як БА, ви можете працювати з клієнтами в різних часових поясах, і важливо регулярно підтримувати з ними зв’язок, особливо в agile, де більше уваги приділяється співпраці та комунікації. Розбіжність часових поясів може вплинути на частоту спілкування, а також може призвести до затримки в часі відповіді, тим самим впливаючи на результат.
- У цій ситуації завжди корисним є письмове спілкування.
- При з’ясуванні вимог, деякі способи, такі як опитувальник з відкритими питаннями або створення візуальних матеріалів та обмін ними із замовником, можуть допомогти йому надати відповіді навіть без необхідності безпосередньої взаємодії.
- Спроби збігатися з часовим поясом замовника, працюючи в ті ж години, має велике значення не тільки для побудови довіри та здорових відносин, але й для усунення прогалин у спілкуванні.
- Команда постійно звертається з питаннями/обговореннями – Будучи БA, ми часто стикаємося із ситуацією, коли члени команди не наважуються обговорювати свої питання перед клієнтом, тому вони звертаються до БA кілька разів, щоб отримати ясність щодо вимог.
- Незважаючи на те, що іноді це може викликати розчарування, з власного досвіду можу сказати, що важливо заохочувати команду задавати питання в присутності клієнта.
- Дякуйте команді, коли вони задають питання під час сесій уточнення беклогу, і допомагайте їм, якщо вони застрягли, пояснюючи те ж саме замовнику.
- Проводьте зворотній обмін знаннями або DEV/QA сесії по уточненню беклогу з членами команди, які працюють над тікетом, щоб переконатися, що вони мають повне розуміння. Це дозволить уникнути побічних ефектів і допоможе досягти цілей спринту з якісними результатами.
- Доменні та технічні навички – Це дискусійне питання, чи є доменні та технічні навички обов’язковими для того, щоб БА досягнув успіху в проєкті. Це також залежить від потреб проєкту з точки зору очікуваного рівня навичок бізнес-аналітика.
Для проєктів, де більше фронт-енду, функціональної роботи, необов’язково мати знання кодування, БД чи бекенду, однак є певні проєкти, де клієнт схильний залучати БА, які можуть робити запити до БД, мають достатнє розуміння домену, особливо для проєктів, пов’язаних із дотриманням вимог законодавства. У деяких проєктах є потреба у створенні API, і базове розуміння цього завжди корисно для розуміння потреб бізнесу.
- У таких випадках, БA повинен розуміти очікування клієнта та потреби проєкту. Ви можете прийняти або відхилити виклик в залежності від того, наскільки далеко ви готові зайти в набутті необхідних навичок і виправдати такі очікування.
- Для проєктів, де знання предметної області або технічні навички не є обмеженням, БА завжди може набути їх під час роботи, а також за допомогою інших джерел, таких як самонавчання, дослідження та аналіз клієнтів і конкурентів, взаємодія з профільними фахівцями тощо.
На завершення скажу, що ми всі можемо погодитися, що роль БA — це величезна відповідальність, що пов’язана з певним набором викликів, однак з досвідом, зрілістю та позитивним ставленням ці виклики можна перетворити на можливості вчитися, розвиватися та надавати цінність клієнту, а також пройти довгий шлях у побудові довготривалих відносин з клієнтом та командою😊.
Автор: Kamya Jangbahadur – EPAM, Lead Business Analyst
Переклад: Sofiia Zelenska