Ольга Даценко в середині серпня 2024 року написала дуже хорошу статтю на ДОУ про гнучкість бізнес-аналітика. Залюбки ділимося нею з Вами!
ІТ-аутсорсинг є (і ще довго буде) темою суперечок серед української ІТ-спільноти. Зокрема йдеться про корпоративну культуру компаній та оцінку наполегливості працедавців щодо проходження сертифікацій.
Однак ми маємо прийняти реальність сьогодення. По-перше, такий вид послуг довго складав основу українського IT-сектору і все ще залишається значущою частиною. По-друге, великі гравці різних галузей — Banking, Insurance, Manufacturing, Healthcare тощо — завжди обиратимуть великі аутсорси для їхніх проєктів не тільки через досвід та репутацію, а й через можливість отримання супутніх послуг, таких як сертифікація продукту, оцінка відповідності регуляціям, стратегічні дослідження, ШІ консалтинг тощо.
З точки зору бізнес-аналітика, такі звичаї та закони ринку — цінна можливість для участі у проєктах різних масштабів та галузей: від Healthcare-стартапів до Insurance ентерпрайзів.
Пропрацювавши значну частину своєї кар’єри з ентерпрайз-клієнтами, я вважаю, що найціннішим є можливість взяти участь у масштабному проєкті для іменитого клієнта, адже в такому разі потрібно грати не тільки за правилами працедавця, а й відповідно до очікувань клієнта. Часто таке вузьке поле для маневру звужується ще більше за рахунок обмежень (limitations and constraints), продиктованих доменом (сферою діяльності) компанії-клієнта. У таких умовах аналітик, окрім своєї рутинної роботи, також має зважати на численні додаткові фактори.
Agile: необхідність чи даність
Із самого початку свого існування Agile-підхід дозволив бізнесам швидко рости завдяки можливості безперервного постачання програмного забезпечення (ПЗ). Тоді ж бізнеси отримали шанс тестувати свої припущення і, за можливості, залишатися гнучкими, перш ніж вони втратять великі суми і багато років на запуск продукту, який не відповідає ринковій ситуації, в і гіршому випадку, не задовольняє потреби користувачів.
З часу створення підходу Agile багатьом уже вдалось переконатись, що його використання та трактування для кожного проєкту є унікальним. Така «неоднозначність» — перевага цього підходу і може сприйматися як безперечна універсальність. Крім того, клієнти цінують Agile за можливість отримувати продукт поступово, що дозволяє оперативно вносити необхідні корективи в процесі розробки.
Власне з цього короткого опису здається, що Agile нарешті вирішив одвічний конфлікт між розробниками та клієнтами, тобто команда розробки може підлаштувати процес під свої потреби, а клієнт отримує свій продукт безперервно з можливістю його тестування на ринку і модифікування за потреби.
Однак, з точки зору бізнес-аналізу, Agile не можна назвати універсальною пігулкою від усіх хвороб, допоки у світі існують регуляції, політики та обмеження. Враховуючи потребу клієнтів мати базове ПЗ якомога швидше та збільшувати кількість функцій, на проєктах в аутсорсингу Agile підхід використовується найчастіше. Однак, він не завжди дозволяє аналітику ретельно досліджувати ситуацію і підготувати якісний беклог, як рекомендовано в Agile best practices.
Все ж рішення ухвалюються з урахуванням того, що аутсорсинг — це ринок клієнта, тому будуючи співпрацю, аутсорсингові компанії ставлять потреби та бажання клієнта на перше місце. Бізнес-аналітики, як частина аутсорсингової команди, повинні відповідати очікуванням, покладеним на компанію-виконавця, а відповідно і тим стандартам, які були обрані для проєкту. Незважаючи на домен клієнта та природу поставлених перед командою задач, аналітик має будувати свій підхід відповідно до затвердженого підходу, навіть якщо проєкт є одним із тих, що будуть розглянуті нижче, але ведеться як Agile.
Waterfall від народження, Agile за покликом: які проєкти мають послідовну природу з перспективи бізнес-аналізу
Основні категорії проєктів, які в ідеальному світі мають визначатися як каскадні, це — проєкти з конкретно визначеними вимогами, послідовними процесами, короткою тривалістю та низькою складністю. Проте ми не будемо зосереджуватися на них, оскільки вони доволі рідко зустрічаються у великих аутсорсингових компаніях.
Варто заглибитись у інші типи проєктів, які мають розглядатись як послідовні (але зазвичай цього не відбувається). Важливо дослідити ці проєкти та основні виклики, що постають перед бізнес-аналітиком в контексті роботи в Agile-команді. Доволі часто найпримітивніші методи або підходи можуть бути найбільш дієвими у складних для аналітика ситуаціях, тому далі будуть представлені приклади технік для маневрування в описаних умовах.
1. Проєкти для регульованих галузей (Regulated Industries)
Проєкти в галузях з високим рівнем регулювання, таких як Healthcare (особливо служби екстреної допомоги), Government, Military, Finance тощо, де необхідно дотримуватися суворих стандартів та протоколів.
Виклики для бізнес-аналітика
Від моменту узгодження скоупу Minimum Viable product (MVP) або пілотної версії та протягом усього часу розробки наступних версій аналітик має бути уважним до дотримання нормативних вимог. Теза очевидна, проте під час підготовки систем аналітик співпрацює з Product Manager/Product Owner або Subject Matter Expert (SME), які можуть сприймати гнучкість, дану Agile, занадто буквально.
Аналітик повинен вправно балансувати: бути відкритим до змін відповідно до умов ринку клієнта (або реальним зворотним зв’язком від кінцевих користувачів), але водночас унеможливити зміну вимог та пріоритетів «на ходу». Часті запити замовника на внесення змін можуть спричинити заглиблення в деталі, ускладнюючи роботу аналітика, а саме: ретельну перевірку їхньої відповідності встановленим обмеженням.
Аналітики, що працюють на проєктах молодих компаній у регульованих галузях, стикаються з особливими труднощами, коли одночасно потрібно дотримуватися обмежень та випробовувати ринок через ранній запуск продукту.
Враховуючи зазначене, для проєктів у регульованих галузях ефективним підходом є запровадження чіткого та прозорого процесу управління змінами (Change Management Process). Часом різні члени команди або стейкхолдери зі сторони клієнта можуть помилково розуміти цей процес як обмеження або заборону змін. Проте такий інструмент допоможе встановити прозорі очікування для обох сторін щодо обов’язкових кроків, які мають бути виконані для якісного впровадження змін.
Техніка: управління змінами (Change Management)
Під час визначення підходу до бізнес-аналізу на проєкті необхідно виділити час та створити детальний покроковий процес управління змінами, враховуючи потреби як внутрішньої команди, так і команди замовника, а саме:
- врахувати технічний рівень стейкхолдерів та знайти правильний спосіб документування процесу.
- обрати нотації діаграм, які найкраще підходять для представників замовника, адже візуальна презентація несе більше цінності ніж простий текст. Хоча деякі стейкхолдери з технічними знаннями надають перевагу діаграмуванню у MS Visio, Draw.io або Lucidchart, інструменти на зразок Miro та Whimsical значно вдосконалюють роботу з UML та BPM-діаграмами. Вони забезпечують широкий спектр кольорових шаблонів, які сприяють ефективній візуалізації та покращенню комунікації між технічними та нетехнічними командами. Незважаючи на те, що згадані нотації є безперечним базисом, сучасні платформи з інструментами для візуалізації роблять їх більш зрозумілими.
- Визначити необхідні кроки та ті, які можуть бути пропущені у випадку високо пріоритетного запиту. Якщо продуктом вже користуються реальні користувачі, підхід до термінових запитів з production stage має бути визначений окремо.
- Продумати список атрибутів або характеристик запиту (checklist), який дозволить оцінити терміновість очікуваних змін.
На основі практичного досвіду важливість управління змінами визначається як одне з першочергових завдань для команди бізнес-аналізу. Запит декількох змін з боку замовника навряд чи суттєво вплине на проєкт або діяльність бізнес-аналітика. Але за деякий час, коли команда й аналітик дозволять ці термінові зміни «на льоту», це може сприйматись як загальна практика.
Клієнту (наприклад, Product Owner) не потрібно буде проводити дослідження зі сторони бізнесу, затверджувати вимоги, розглядати декілька альтернативних підходів і брати на себе зобов’язання перед початком розробки, якщо зміни можна внести майже в будь-який час (адже всі зміни в такому випадку можна розглядати як однаково термінові і високо пріоритетні). Бізнес-аналітик повинен запропонувати процес управління змінами і затвердити його із замовником, щоб всі сторони погодили його для обов’язкового дотримання. Основу успішного проєкту, а отже і продукту, будує чесна співпраця між командою розробки і замовником. Цей процес лежить безпосередньо у зоні відповідальності бізнес-аналітика.
Зокрема доцільно розглянути можливість створення системи маркування для змін до затверджених вимог. Залежно від того, яке ПЗ для управління проєктами (Jira, AHA!, Azure DevOps) використовується, це може бути label, tag, custom field або абревіатура в назві тікета. Пізніше такі атрибути можна використати для автоматизованої статистики, яка надасть розуміння кількісної частки змінених вимог, що буде якісною візуалізацією і можливістю покращення підходу.
Якщо у замовника або команди є сумніви щодо впровадження Change Management, можливо, проблема в хибному уявленні про цей процес, як було згадано вище. Для злагодження гострих кутів можна змінити назву підходу на Enhancement Management, Modification Management, Transformation Management (якщо проєкт не передбачає трансформації в будь-якому іншому сенсі) тощо.
2. Проєкти для галузей зі стабільним середовищем (Stable Environment)
Проєкти, де середовище розробки, технології та зовнішні фактори стабільні і не піддаються частим змінам. Здебільшого ця категорія стосується тих самих галузей, що і попередня.
Виклики для бізнес-аналітика
Клієнти зі стабільних галузей часто зосереджуються на впровадженні сучасних та інноваційних функцій задля покращення свого ПЗ і згодом бізнесу. Проте важко очікувати на кардинальні зміни в Construction або Manufacturing (звісно, якщо мовиться про стандартне ПЗ для логістики, проєктного менеджменту тощо). У такому випадку бізнес-аналітик повинен зосередитись на реальних потребах кінцевих користувачів. Зазвичай, запит стосується автоматизації процесів, покращення роботи офісного персоналу тощо.
Інколи клієнти хочуть додати у своє рішення кожну функцію, яку мають їхні конкуренти, з метою монополізації ринку, замість того, щоб перед розробкою переосмислити досвід користувачів на своїй наявнійчи майбутній платформі. Часто буває, що реальний фідбек від користувачів або не збирається зовсім, або дуже обмежений і не детальний. У цьому разі дієвою технікою стане шлях користувача (User journey).
До теми: Customer journey з погляду бізнес-аналітика. Як зацікавити клієнта
Звичайно, щоб створити якісний шлях користувача, бізнес-аналітик має провести серію інтерв’ю, семінарів та сесій спостережень (observations) з кінцевими користувачами або їхніми представниками (зазвичай Product Owner). Однак така техніка може застосовуватись ізольовано.
Якщо мовиться про трансформацію наявного ПЗ, аналітик може створити User journeys під час ознайомлення з системою, базуючись на власному досвіді. Але не рекомендується будувати уявлення про ПЗ лише на таких артефактах. Це може сформулювати припущення щодо потенційних «pain points and opportunities» (див. далі), які обов’язково мають бути підтверджені фідбеками реальних користувачів або їхніх представників, статистикою тощо.
Техніка: шляхи користувача (User Journeys)
На перший погляд техніка потребує забагато ресурсів та часу. Проте, якщо ви працюєте над проєктом у стабільному середовищі, встановлення користувацького досвіду(user experience), як головного пріоритету, однозначно має сенс:
- дослідити, скільки кроків потрібно користувачеві для досягнення своєї мети на вашій платформі, з’ясуйте, чи достатня візуалізація;
- спробувати абстрагуватися та зрозуміти, чи потрібні додаткові підказки чи поради (hints, tips, manuals) для знаходження потрібного елементу;
- звернути увагу, де користувачі спочатку намагаються знайти потрібну функцію. Можливо, система не дотримується загальноприйнятих підходів;
- перевірити, чи всі іконки інтуїтивно зрозумілі;
- звернути увагу на елемент «pain points and opportunities» у User journey. Можливо якщо функція не відповідає очікуванням користувача для конкретного завдання, її можна перенести, щоб вона слугувала інструментом для іншого завдання.
Якщо аналітику з досвідом важко розібратись з деякими частинами системи, навіть після того дослідження схожого ПЗ, то скоріш за все, користувач відчуває себе також розгублено. Якщо у аналітиків немає прямого доступу до кінцевих користувачів, спілкування з ними можна замінити зустрічами зі стейкхолдерами зі сторони клієнта, де можна запитати про його/її власний досвід із цією функцією.
Також можливе проведення observation session зі стейкхолдером, якщо попросити його показати вам як він/вона досягає визначеної цілі у системі. Звертайте увагу на рухи курсора стейкхолдера, помилкові кліки (misscliks) та послідовність використання функцій. Це дасть змогу будувати теорії для подальшої роботи та аналізу.
Зверніть увагу: User Flows. Як ця техніка допомагає в роботі над проєктами
3. Проєкти з передбачуваним результатом (Predictable Outcomes)
Проєкти, де результат конкретний і затверджений, а команда має досвід роботи з подібними проєктами. Задачі із заміни legacy (наявне застаріле ПЗ) відносяться до цієї категорії.
Виклики для бізнес-аналітика
У проєктах з трансформації legacy, хоча і результат чітко визначений, все ж слід залишити деякий простір для удосконалень, змін і непередбачуваних задач. Це не означає повну зміну бачення продукту, але, залежно від документації legacy, технологій та загальної доступної бази знань про систему, компанію та сам бізнес-домен, можна опинитися в складній ситуації з плануванням зусиль бізнес-аналітиків.
Очевидно, щоб замінити legacy, потрібно спочатку зрозуміти роботу цієї системи. Можливо, під час вивчення основного джерела знань (самої legacy) та документації до неї виявиться, що поведінка не відповідає опису, а документація неповна або зовсім відсутня. Іноді така ситуація може стати явною вже після старту проєкту (навіть імплементації), або ж масштаб невідповідностей виявиться значно більшим, ніж очікувалось.
Це робочий процес, і існує багато способів, як з ним впоратися, але враховуючи, що аналітик повинен постійно і безперервно заповнювати беклог для своєї команди, він/вона може опинитися в складній ситуації: неможливо повністю проаналізувати поточний стан (current state), але потрібно надати обсяг роботи (scope) для команди розробки. Тут критично важливими можуть стати регулярні та часті зустрічі зі стейкхолдерами, особливо з Subject Matter Experts (SME) та Product Owners.
Техніка: чіткий розклад зустрічей (Meeting timetable)
Потрібно узгодити регулярні зустрічі, які охоплять усі ваші потреби у підготовці вимог:
- не змішувати теми між сесіями;
- якщо документація наявного ПЗ недостатня, встановити декілька сесій на тиждень для покриття недостатніх знань за допомогою стейкхолдерів. Попередньо створіти RACI matrix, розподілити питання відповідно до людей, які можуть на них відповісти (варто запрошувати їх окремо, щоб не витрачати їхній час);
- план зустрічі (agenda) має бути підготовлений заздалегідь;
- якщо немає можливості безпосередньо спілкуватися з кінцевими користувачами, варто забронювати одну сесію на тиждень, щоб обговорювати тільки pain points, очікування або відгуки кінцевих користувачів з Product Owner;
- ще одну зустріч можна зарезервувати тільки для затвердження вимог (requirements acceptance);
- додаткова зустріч потрібна для обговорення UI-дизайну.
- має сенс сесія, присвячена потенційним покращенням, які слід внести до наявності функцій. Хоча на проєктах рідко буває недостатньо скоупу, трапляється, що команда розробки потребує додаткових задач. У цьому разі обговорені й задокументовані в Parting lot потенційні покращення слугуватимуть як запасний беклог.
Якщо планувати зустрічі та розподілити їх на весь робочий тиждень, постійно підтримувати зв’язок зі стейкхолдерами буде просто. Хоча не рекомендується змішувати теми між зустрічами, можна витрачати 5-10 хвилин на кожній з них для термінових питань, незалежно від природи проблеми. Потрібно знайти такі часові проміжки, які не будуть постійно змінюватися, щоб обидві сторони відчували однакову відповідальність за підняті питання.
Корисним буде вести agenda як документ із версійністю, який доступний всім членам команди бізнес-аналізу і стейкхолдерам. По-перше, на деякі питання стейкхолдери можуть відповісти офлайн і ця відповідь буде доступна всім аналітиками. По-друге, agenda стане своєрідним логуванням знань, тобто додатковим універсальним ресурсом, до якого можна звернутися.
4. Проєкти з інтенсивною документацією (Documentation-Intensive)
Проєкти, що вимагають обширної документації на кожному етапі, забезпечуючи повний опис перед переходом до наступного етапу. Проєкти, пов’язані з цим пунктом, залежать або від замовника, або від політики аутсорсингової компанії.
Іноді клієнти приходять із негативним попереднім досвідом через брак документації або її низьку якість і хочуть більшого. Водночас якщо у компанії-виконавця високі стандарти документування, менеджмент може наполягати на додаткових артефактах. Однак це не означає, що аналітики не повинні висловлювати свою думку, якщо бачать, що підхід до документування, який буде використаний або вже використовується, недостатній для охоплення всіх деталей.
Буде цікаво: Як писати вимоги природною мовою. Три підходи
Виклики для бізнес-аналітика
Може бути складно одночасно створювати вимоги для команди розробників (зазвичай тікети в Jira) та вести додаткові документи чи посібники для клієнта. Ідеально, якщо підхід до документації буде погоджено з клієнтом на самому початку проєкту, але іноді буває, що початковий підхід не працює. Це не причина ставити під сумнів професіоналізм бізнес-аналітика, оскільки клієнт може зрозуміти, що раніше визначений тип документації не охоплює всі їхні потреби або незрозумілий для всіх стейкхолдерів. Найпростіший і найбільш очевидний інструмент, який може використовуватись для надання чітких вимог для команди, а також для створення мануалів для клієнта, — Acceptance Criteria у форматі checklist.
Техніка: Acceptance Criteria у форматі checklist
Хоча багато команд обирають Acceptance Criteria (AC) у форматі Gherkin, він може не підходити, якщо проєкт вимагає додаткової документації. Якщо аналітики відчувають, що навантаження на них занадто велике, можна визначити AC у формі checklist, який чітко описує поведінку користувача step-by-step, а також очікувану відповідь або реакцію системи.
У цьому разі, по-перше, команда розробки не зіткнеться з неоднозначними вимогами і не матиме надто багато простору для інтерпретацій, а, по-друге, такий формат буде зрозумілий клієнту, оскільки стане фактично покроковим посібником.
Якщо проєкт є «технічним» або система не передбачає тісної взаємодії з користувачем, можна спробувати використовувати такі техніки: псевдокод, описи сценаріїв (Scenario descriptions) або бізнес-правила (business rules). Також, використовуючи ПЗ для управління проєктами, зокрема Jira, варто створити додаткове джерело вимог, яке буде служити чистовиком. Потрібно визначити відповідну структуру і формат документа та розмістити актуальну версію вимог. Після завершення проєкту клієнт буде радий, що йому не доведеться копатися у величезному масиві задач у Jira.
Якщо клієнт наполягає на якомусь виді документації (наприклад, бізнес-правила), модна домовитись з командою про їхнє використання в якості Acceptance Criteria. Потрібно обговорити з командою, чи достатньо деталей в наявному форматі, якщо ні — комунікувати запропоновані покращення із замовником та затвердити їх. Так аналітик не зіткнеться з подвійною роботою.
Висновки
Із розглянутими викликами бізнес-аналітик може зустрітись на будь-якому проєкті. Так само, описані техніки можуть бути використані не лише для зазначених типів проєктів. Це лише частина підходів, які я вважаю дієвими з власного досвіду та які значно полегшують життя аналітику в описаних умовах.