Як думка про ризик впливає на вас? Викликає обережність чи відкриває захоплюючі можливості? Давайте поговоримо про ризики і розглянемо яку роль бізнес-аналітик (BA) може відігравати у керуванні ризиками.
Прийняття ризику як можливості дозволяє створювати та вдосконалювати високоякісні рішення, що в кінцевому підсумку забезпечує відчутну цінність для бізнесу. Цьому процесу сприяє всебічне розуміння природи ризику, потенційних джерел, впливу, оцінок і стратегій управління. Вищезазначене застосовується як до проектних, так і до продуктових ризиків.
Важливо визнати, що жодна кришталева куля не може передбачити майбутнє. Тому ретельне розуміння тонкощів проекту та ретельний аналіз потенційних подій, як позитивних, так і негативних, є обов’язковими. Відсутність розуміння або недопуск до важливої інформації може призвести до ризику. Проте слід пам'ятати, що ризик не завжди є негативним; його вплив може бути позитивним, виступаючи як можливість.
Зазвичай менеджери проекту відповідальні за ідентифікацію та управління ризиками проекту, але в команді, що працює за принципами Agile, це завжди є спільною відповідальністю, і досвідчений бізнес-аналітик повинен володіти навичками управління ризиками, особливо продуктовими ризиками. БА має ефективно доносити ці ризики та можливі стратегії по роботі з ними до членів команди. Надійний план управління ризиками допомагає зацікавленим сторонам зрозуміти, як ризики будуть:
Ідентифікуватись,
Оцінюватись та аналізуватись,
Документуватись,
Контролюватися та управлятись,
Відображатись в звітах.
Давайте розглянемо можливу структуру опису характеристик ризику, у вигляді таблиці:
Стовпець таблиці | Пояснення |
Дата додавання | Дата, коли ризик був доданий до реєстру |
Звітувач | Особа, яка визначає ризик |
Джерело | Документація, певна ініціатива, епік тощо |
Вимір | Певний фактор, який може вплинути на час, обсяг або якість продукту. Наприклад: • Фінанси (контракт) - перевищення бюджету, суперечливість у контракті. • Обсяг - протиріччя вимог • Розклад - затримка в узгодженні • Якість - помилки в роботі • EngX - проблема масштабування технології • CSAT - власник продукту не задоволений • Команда (робота, найм) - низька продуктивність, довгий час на адаптацію для нового працівника. • Процес - відсутність відгуків від користувачів до запуску. |
Ефект | Можливий ефект з детальним описом. Наприклад, якщо функція та історія користувача не відповідають DoR, то ... |
Стратегія обробки | Уникнути, зменшити, передати або прийняти |
Вплив | Може бути визначений кількісно гроші або час, якщо це можливо виміряти, або просто 1 - як незначний, 2 – під контролем, 3 - великі втрати. Не приділяйте багато тут задля точної оцінку. Проведення приблизного оцінювання завжди краще, ніж нічого. |
Ймовірність | Вірогідність у відсотках, що ризик може спрацювати |
Індекс ризику | Вплив, помножений на ймовірність; найвищий індекс ризику найвищий пріоритет ризику з точки зору інших |
Власник ризику | Особа, відповідальна за вирішення ризику |
Крайній термін | Дата, до якої команда / відповідальна особа зобов'язується вирішити ризик |
Статус | Поточний статус ризику на дату |
Нотатки | Я б радила мати цю колонку, особливо коли потрібно щось додати до статусу |
Термін спостереження за ризиком після вирішення | Це дуже цікава інформація, взята з мого досвіду. Як BA та Власник продукту, я керувала таблицею з усіма вищезазначеними параметрами. Потім, під час сертифікації аудиту безпеки, мені рекомендували аналізувати ризики протягом певного визначеного часу після їх зменшення або вирішення, що може мати сенс у деяких ситуаціях, наприклад, коли це стосується безпеки. |
Це досить велика таблиця. Вашому проекту можливо не потрібні всі стовпчики, або ви можете розділити її на дві чи більше таблиць. Наприклад, якщо ви аналізували та оцінювали ризики, ви можете зберегти кожну стратегію обробки в окремій таблиці.
Як BA, ви відповідаєте за аналіз складних Епіків (Epic), в реалізації яких може бути задіяно більше однієї команди. Аналіз ризиків і їх обробка можуть виглядати наступним чином: ви можете керувати статусом важливих завдань та використовувати цей документ для перевірки стану для вас та керівництва. Це можна виглядати наступним чином:
Якщо перша таблиця "як може структурувати роботу, щодо реагування на ризики" більше стосується опису характеристик ризику та є більш базовою, то друга таблиця стосується детального опису обраного найбільш значущого джерела ризику саме для вашого проекту та його детального аналізу.
Як показує досвід, потенційні ризики в рамках одного Епіку для проекту з різними командами це:
Підписаня вимог
Готовність технічного дизайну
Готовність прототипів
Готовність HTML
Наявність оцінки необхідного часу на виконання.
Крім того, епіки не завжди потрібно тестувати на всіх цих ризикових точках. Як аналітик, я аналізував, чи це доцільно, позначав «Y» або «N», які потім підсвічувалися червоним кольором. Ви можете просто використовувати прочерк там, де не потрібно цих перевірок. Наприклад, для епіку F23 достатньо мати готовий технічний дизайн і оцінку епіку.
Вас можуть збентежити колонки i9, i10. Дозвольте пояснити: в цьому випадку вони позначають діяльність з автоматизованого тестування, щоб ми могли швидко відзначати за кольором ті місця, де потрібна більша увага, або вони можуть бути перед епіком, де це необхідно. Також ми використовуємо зелений колір, щоб сигналізувати про те, що все в порядку і ми можемо продовжувати, і ми використовуємо жовтий, щоб показати роботу, яка в процесі. Ми також використовуємо числа у верхній частині таблиці, щоб побачити, скільки розробників або інших спеціалістів працює в команді над епіком, і ми ставимо '1' там, де потрібна додаткова потужність (з будь-якої причини).
Проте ви можете запитати: Чому ми додали присутність розробників на дату до цього аналізу? Саме через те, що їхня доступність та ефективне розподіл також є джерелом ризику, тому ми можемо добре планувати етапи роботи всередині епіку, але можемо зазнати невдачі, якщо не враховуємо присутність і розподіл розробників, інтерфейсу користувача або інших важливих спеціалістів. За допомогою такої таблиці можна легко передбачити вузькі місця-блокери. Як ви можете бачити, в роботі над епіком залучені різні команди, і ще одна важлива характеристика - релізи. Це дозволяє нам бачити, в якому релізі кожна команда працює над завданнями всередині епіку / функції і більш ефективно пріоритизувати завдання.
Ця таблиця досить деталізована і враховує не лише окремі функції (features) в межах епіку, але й кількість розробників на певну дату та релізи. Крім того, є інші позначки кольором і числами, які допомагають швидко зрозуміти, де ми знаходимося. Сподіваюся, цей приклад буде корисним у вашій роботі з управління ризиками і заохотить вас розробити власний, який задовольнить ваші конкретні потреби.
На завершення, вам не потрібно боятися або уникати обговорення питань, пов'язаних з ризиком, думаючи, що це лише відповідальність керівництва. Замість цього розглядайте ризики як можливість доставити високоякісні рішення та виконати терміни завдяки офіційному аналізу та управлінню ризиками.
Дякую за вашу увагу, і будь ласка, не соромтеся поділитися своїми думками у коментарях нижче. Я сподіваюся, що моя стаття корисна, і ви використаєте контекст для застосування його до проектних заходів у ролі BA та PO також.
Comments