Я, Yuliia Asliaieva, практикуючий Бізнес Аналітик з багаторічним досвідом роботи в банківській та страховій галузях, який спеціалізується на фінансових технологіях (фінтех проекти), сертифікована як CСВА IIBA. В цій статті хочу поділитись своїм досвідом подолання ряду проблем при виявленні вимог.
Виявлення вимог - це ключовий етап будь-якого проекту, який визначає успіх розробки. Однак, цей процес може бути пов'язаний з різними викликами, які можуть значно ускладнити роботу Бізнес Аналітика. Давайте розглянемо найпоширеніші перешкоди та методи їх подолання.
1. Відсутність доступу до кінцевого користувача
Часто трапляється, що розробляються вимоги до програмного забезпечення або процесу без можливості безпосереднього спілкування з кінцевим користувачем, на якого впливають запропоновані зміни.
Рішення:
Включення представника замовника: в команду проекту додають представника замовника, який має безпосередній доступ до кінцевих користувачів. Він стає мостом між розробниками та користувачами, забезпечуючи зворотній зв'язок та правильне розуміння потреб.
2. Різні точки зору стейкхолдерів
Кожен стейкхолдер має свою унікальну точку зору, яка формується під впливом особистого досвіду, культурного походження, цінностей та переконань. Це може призводити до розбіжностей у розумінні потреб та шляхів їх вирішення.
Рішення:
Емпатія: тільки здорова доза емпатії допоможе Бізнес Аналітику зрозуміти різні точки зору стейкхолдерів та допомогти зацікавленим сторонам порозумітись один з одним. Спробуйте поставити себе на місце кожного стейкхолдера, розгляньте його мотивацію та цінності.
Колабораційні ігри, що сприяють командній роботі та взаєморозумінню, можуть допомогти стейкхолдерам знайти спільну мову та визначити пріоритетні потреби.
Опрацюйте декілька варіантів можливих рішень, для кожної опції/варіанту позначайте обмеження передбачені дизайном чи втіленням, припущення, ризики. Далі розглядайте із стейкхолдерами ці декілька варіантів, дискутуйте разом із стейкхолдерами, досягайте консенсусу, обирайте.
Приклади колабораційних ігор, які я на практиці застосовувала під час комунікацій із стейкхолдерами:
Колабораційна гра “Різнокольорові капелюхи”
Тривалість від 45 хв до 90 хв, кількість учасників від 6 до 20.
Кожен капелюх представляє інший спосіб погляду на задачу/проблему. Рандомно призначте кожному стейкхолдеру різні капелюхи, якщо учасників більше шести, то кольори капелюхів можуть повторюватись. Або кожен стейкхолдер може по-черзі “приміряти” різні кольори капелюхів і висловлювати свою думку.
Синій капелюх вдягає фасилітатор, як правило Бізнес Аналітик, який направляє інших учасників.
Люди із зеленим капелюхом розмірковують про проблему творчо та генерують різноманітні ідеї вирішення.
Люди з білим капелюхом зосереджуються на фактах: Яка інформація відома про проблему? Яка інформація відсутня? Чим можливо доповнити відсутність інформацію? Що варто взяти до уваги? Що відомо із минулих схожих ситуацій?
Люди в червоному капелюсі це про емоції та інтуїцію. Висловлюють почуття щодо проблеми незалежно від фактів, способів її вирішення, при цьому не виправдовуючи жоден спосіб.
Люди в жовтому капелюсі намагаються мислити оптимістично та концентруються на світлому боці оптимізму щодо проблеми і способів її вирішення. В процесі обговорення з людьми в інших капелюхах з’явиться багато питань до людей в жовтому капелюсі, щоб сконцентруватись на позитивних перевагах.
Чорний капелюх логічно оцінює всі ідеї та шукає причини бути обережним. Цей капелюх працює як протилежний до жовтого капелюха та висловлює застереження.
Як результат такого обговорення в ролях, проблема розкривається з усіх боків, а рівень залученості стейкхолдерів зростає.
колабораційна гра “Плюси та Мінуси”
Тривалість від 30 хв до 45 хв, кількість учасників від 3 до 6.
Застосовую, коли маємо із стейкхолдерами кілька ідей і потрібно вирішити яку обрати.
Перераховуємо переваги та недоліки кожної з ідей та спільно порівнюємо результати.
Переваги такого способу в тому, що можна виявити різні уяви про переваги та недоліки того чи іншого рішення і одразу попрацювати над спільним розумінням ситуації. Також це дуже гарна відправна точка, щоб обговорити кінцеву ціль необхідного рішення.
колабораційна гра “Стікери та крапки”
Тривалість від 5 хв до 15 хв, кількість учасників до 50.
Застосовую, коли необхідно розставити пріоритети для згенерованих ідей. Візуалізую перелік ідей, роздаю/призначаю учасникам певну кількість стікерів ( або крапок) і прошу розташувати їх поряд з ідеєю/ідеями, які вони вважають важливішими. Кожен учасник має право витратити стікери ( чи крапки) на одну ідею чи розподілити їх між кількома варіантами. По результату голосування всіх, разом підраховуємо рейтинг та отримуємо перелік найбільш пріоритетних ідей.
3. Довге очікування фідбеку від стейкхолдерів
Часто буває, що отримати зворотній зв'язок від стейкхолдерів на документ з вимогами - це справжнє випробування терпіння для Бізнес Аналітика. Якщо компанія велика і ініціатива проекту має багато стейкхолдерів, то проста перевірка документу легко може зайняти 2-3 календарних тижні. Зазвичай це пояснюється зайнятістю стейкхолдерів, бо вони можуть мати кілька запитів на тиждень від різних проектів, але Бізнес Аналітику від того швидко не просунутись.
Рішення:
Спробуйте швидко отримати відгук під час онлайн зустрічі. Заплануйте онлайн-зустріч з усіма стейкхолдерами та забронюйте час в їх календарях. Під час онлайн зустрічі почніть з розмови про ініціативу (тут варто увімкнути камеру). Далі дайте завдання прочитати документ і виділіть на це певну кількість часу ( під час читання камеру можна вимкнути). Витратьте час, що залишився, на дискусію, обговорення та визначення наступних кроків. Секрет результативності цього варіанту полягає в тому, що всі зайняті стейкхолдери передбачають зустріч задля роботи з документом у своєму щільному розкладі. До прикладу, я віддаю перевагу гібридному підходу, коли всі погоджуються прочитати документ перед зустріччю, а зустріч планується для дискусії та прийняття рішень. Це дозволяє проводити більш цілеспрямоване обговорення та швидко приймати рішення.
Використання онлайн-платформ для коментування документів та анкетування дозволяє спростити процес збору зворотного зв'язку та зробити його більш ефективним.
4. Стейкхолдери, що одразу переходять до системних рішень
Часто стейкхолдери схильні на ходу пропонувати конкретні системні рішення, не вдаючись в деталі бізнес-проблеми. В той же час, Бізнес Аналітику на цей момент може бути ще недостатньо верхньорівневих бізнес вимог, потрібно більше знати проблематику, контекст.
Рішення:
Спочатку застосовуйте активно наступні запитання: "Яка мета запропонованого рішення? Яку проблему ви намагаєтеся вирішити? Що важливого це дає?" Продовжуйте доки не дійдете до суті. Далі побудуйте ієрархію вимог: від бізнес вимог до функціональних. Пам’ятайте, що у кожної функціональної вимоги має бути зв’язок із бізнес вимогою.
5. Як не пропустити залучення важливих стейкхолдерів
Наприклад, обговорили всі вимоги з департаментом маркетингу та забули про комплаєнс та департамент фінансової безпеки. Це може призвести до неповного обсягу вимог і неготовності продукту до виходу на ринок.
Рішення:
Спілкуючись із першою групою стейкхолдерів пошторміть, хто ще має бути врахований.
6. Стейкхолдери, що пропускають зустрічі або не активно приймають в ній участь, а далі зволікають з рішеннями
Можуть існувати стейкхолдери, які не розуміють, що просто з’явитися на зустріч недостатньо і не усвідомлюють, що їхня відсутність участі або зволікання з прийняттям рішення, насправді є затримкою процесу збору вимог.
Рішення:
Обговорюйте спільно із стейкхолдерами критичний шлях вашого проекту і пояснюйте залежності, щоб всі стейкхолдери розуміли вплив затримок. Якщо це доречно, запропонуйте їм допомогти подумати над їх рішенням разом, для цього можна запланувати додаткові сесії спільного вивчення документації чи сесії брейншторму ідей рішень, підтримуйте їхнє дослідження або сприяйте розмові з іншими стейкхолдерами, щоб допомогти рухатися вперед. Невелика підтримка може мати велике значення.
Враховуйте заздалегідь доступність стейкхолдерів до участі в сесіях збору вимог. Обмеження в часі для проекту, географічна локація стейкхолдерів та роль певного стейкхолдера в проекті мають бути враховані. Будьте готові адаптувати розклад воркшопів збору вимог під прогрес проекту, коли раптом з’явиться необхідність в додаткових сесіях обговорення певних вимог.
візуалізуйте документацію та тези до обговорення, щоб залучити до активної співпраці всіх та посилити збереження інформації в пам’яті.
Що обрати для візуалізації, як представити дані?
Далі я хочу навести приклади візуалізацій для зустрічей із стейкхолдерами:
Таблиця можливостей поточного процесу та майбутнього покращеного процесу
Застосовується під час спільних обговорень із стейкхолдерами поточних можливостей та можливостей, що стануть доступними після впровадження змін/ рішень для виявлених проблем:
Діаграма Ісікави, відома як діаграма “риб’яча кістка”
Використовується для зображення причин певної проблеми.
Як правило, проблема, розташовується біля голови риби, яка може бути спрямована як вправо, так і вліво.
Далі генерується разом із стейкхолдерами від трьох до восьми причин або категорій як оптимальна кількість причин, що пов’язані з проблемою.
Для кожної визначеної причини задається питання, чому ця причина виникає, і позначаються всі виявлені підвипадки, щоб отримати уявлення про проблему та зрозуміти її основні причини.
7. Велика кількість стейкхолдерів (зацікавлених сторін)
Важко керувати проектом, коли стейкхолдери перехоплюють управління вимогами один в іншого, і чітко не узгоджено, хто з них за яку ціль (що позначена в вимогах) відповідальний. Саме тоді вимоги стають розмитими, а просування проекту може навіть заблокуватись.
Рішення:
Користуйтесь матрицею RACI, щоб визначити ролі стейкхолдерів у проекті:
1. Визначте всі ключові активності проекту.
2. Перелічіть всіх зацікавлених сторін (стейкхолдерів).
3. Заповніть матрицю, присвоюючи кожному стейкхолдеру певну роль для кожної активності:
· A (Accountable): Хто несе відповідальність за виконання завдання та досягнення результату;
· R (Responsible): Хто безпосередньо виконує завдання;
· C (Consulted): Хто повинен бути проінформований про виконання завдання і може давати рекомендації;
· I (Informed): Хто повинен бути в курсі результату завдання.
4. Обговоріть матрицю з усіма стейкхолдерами. Це допоможе забезпечити розуміння їхніх ролей та уникнути непорозумінь.
5. Регулярно оновлюйте матрицю RACI в міру зміни проекту та його вимог.
Абревіатура RACI позначає чотири основні ролі:
Приклад RACI матриці:
Матриця RACI допомагає чітко розподілити відповідальність між стейкхолдерами, уникаючи конфліктів та розмитих вимог. Застосування матриці RACI забезпечує чіткість і прозорість у розподілі ролей, що сприяє ефективному виконанню проекту.
Подолання перерахованих викликів під час збору вимог завжди вимагає від Бізнес Аналітика уваги до деталей, проактивного підходу до комунікацій та здатності ефективно управляти змінами та долати невизначеність.
Сподіваюсь, що наведені мною приклади зорієнтують на шляху збору вимог та сприятимуть успішній валідації вимог, що в результаті допоможе досягти бізнес цілей та задовільнити потреби стейкхолдерів.
Насправді, інколи мені здається, що збір вимог схожий на сплав по річці. Щоб випливти, Бізнес Аналітик має знати правильні техніки рафтингу та бути готовим зустрітись з хвилями та порогами. Та якщо все планувати, передбачати ризики й вчасно реагувати на них, то подорож човном по бурхливій річці з вимогами буде набагато безпечнішою і ви досягнете наступної фази проекту.
Comments