BA toolkit - Part 2: Формула ефективного вибору - зважена матриця рішень
- Anastasiia Kraievska
- 26 трав.
- Читати 6 хв
Оновлено: 4 серп.
Чому одне рішення здається “правильним”, а інше - “якимось не таким”? Ми часто покладаємось на інтуїцію, досвід або авторитет думки. Але коли на кону серйозні бізнес-рішення, цього замало. У цій статті ми розглянемо інструмент, який допомагає ухвалювати обґрунтовані рішення навіть у складних і невизначених умовах - зважену матрицю рішень (weighted decision matrix). Я покажу, як її застосовувати для стратегічного вибору та пріоритезації вимог, і як вона здатна відокремити емоційну складову та поставити акцент на логіку та прозорість.
Зважена матриця рішень. Визначення
ВАВОК говорить, що зважена матриця рішень - це техніка, яка багатогранно оцінює можливі варіанти для того, щоб обрати рішення з найвищою цінністю в умовах невизначеності (BABOK, Chapter 10.16.1)
Давайте розглянемо як це працює на практиці.
Аналіз стратегічних рішень
Зважену матрицю доцільно застосовувати для аналізу потенційно прийнятних рішень. Розглядаючи наявні варіанти рішень з різних аспектів, ми виберемо одне, яке найкраще задовольняє визначеним критеріям.
Давайте пригадаємо приклад, який ми розглянули в першій частині статті. Ми хотіли побудувати систему звітності і виокремили два можливі варіанти для її реалізації:
Вбудований модуль зі збереженням елементів інтерфейсу основної системи.
Платформа візуальної аналітики (наприклад Tableau).
Для того, щоб детально проаналізувати обидва варіанти, відбираємо для початку критерії оцінювання.
Критерії оцінювання можуть відображати як функціональні, так і нефункціональні вимоги, включаючи вимоги до інтерфейсу, цілісності даних, очікування зацікавлених осіб, тощо.
Для кожного критерію визначається його важливість у вигляді так званої ваги (weight), скажімо, від 0 (неважливо) до 1 (найвищий рівень важливості) з кроком в одну соту.
Наступним кроком буде оцінити, на скільки критерій задовольняється для кожної опції. Нехай це буде оцінка від 0 до 5 з кроком в один, де 5 - критерій повністю задовольняється, а 0 - повністю не задовольняється.
Вибір критеріїв оцінювання та їх оцінка буде залежати від середовища, в якому продукт функціонуватиме, включаючи такі аспекти як людський фактор, процеси, існуюча архітектура та безперечно культура.
Фінальна вправа - порахувати суму оцінок, помножених на вагу.
Та опція, яка набере найвищу кількість балів, і буде переможцем. Тобто формальним шляхом ми визначимо, який варіант найкраще задовольняє потреби зацікавлених осіб.
Для прикладу я створила таблицю зі списком критеріїв оцінювання та їх оцінку для обох варіантів реалізації.
Таблиця 1 - Зважена матриця для аналізу стратегічних рішень
# | Критерії оцінювання | Вага | Вбудований модуль | Платформа візуальної аналітики |
1. | Цілісність даних | 1 | 5 | 5 |
2. | Складність реалізації | 0,7 | 1 | 4 |
3. | Масштабованість | 1 | 3 | 4 |
4. | Інтеграція з існуючими системами | 0,9 | 5 | 4 |
5. | Користувацький досвід (UX) | 0,8 | 5 | 3 |
6. | Безпека даних | 1 | 5 | 4 |
7. | Якість та глибина аналітики | 0,9 | 2 | 5 |
8. | Гнучкість налаштувань | 0,7 | 1 | 5 |
9. | Час впровадження | 0,8 | 2 | 4 |
10. | Надійність та відмовостійкість | 0,6 | 4 | 4 |
Результат | 28,7 | 35,4 |
Формуючи список критеріїв та надаючи кожному критерію вагу, ми значно зменшуємо емоційну складову при виборі рішення. Тобто ми можемо формалізувати вплив таких чинників як «мені здається, що це складно» чи «щось мені ця ідея не подобається», вимірявши конкретний вплив чинника на прийняття рішення.
Для нашого прикладу зі звітністю ми оберемо варіант інтеграції та побудови платформи візуальної аналітики.
Пріоритезація вимог
Цей метод формально наслідує thought process членів команди, РО чи ВА під часу «пересування» вимог у беклозі вверх чи вниз (Wiegers and Hokanson, Software requirements essentials, Chapter 5).
Для початку потрібно визначитися з критеріями оцінювання. Очевидним критерієм для пріоритезації вимог є цінність (business value). Неочевидним - автор вимоги. Хіба не стикались ви на своїх проєктах з тим, що певний функціонал йшов першим в розробку, тому що його «замовив» особливо важливий стейкхолдер? Це може бути як і регулятор, так і внутрішня зацікавлена особа. В обох випадках джерело вимоги буде впливати на першочерговість виконання.
Ще одним важливим критерієм пріоритезації вимог є частота використання функціоналу. Це, доречі, також гарний аргумент для переговорів з представниками бізнесу.
На одному з проєктів я мала досвід з тим, що функціонал був замовлений надзвичайно важливим стейкхолдером і я навіть зафіксувала функціональні вимоги для нього. Але в результаті ця функціональність була посунута далеко вниз беклогу, якраз посилаючись на те, що насправді очікувана частота використання фічі була низька.
Інші важливі критерії оцінювання пріоритезації вимог - це вартість реалізації, ризики, вчасність, тощо.
Критерії оцінювання та їхня вага у визначенні пріоритетності будуть відрізнятись для кожного проєкту та для кожного функціоналу. Знову ж таки, на вибір критеріїв та їх вагу будуть впливати внутрішні елементи культури компанії та проєкту.
Повернемось до прикладу зі звітністю на платформі візуальної аналітики та проведемо пріоритезацію її функціональності.
Для початку проведемо декомпозицію звіту на функціональні блоки, щоб зрозуміти, що нам потрібно пріоритезувати:
Керування доступом (права користувачів переглядати чи не переглядати певну інформацію).
Загальний огляд (overview) - агреговані дані для забезпечення можливості побачити загальну картинку, помітити тренди.
Детальний зріз даних (raw data).
Фільтри.
По аналогії з оцінкою варіантів рішень залишимо значення ваги критеріїв від 0 до 1 з кроком в одну соту, де 1 - найвищий вплив критерію, а 0 - найнижчий.
Тепер оцінимо кожний функціональний блок відносно критеріїв по шкалі від 0 до 5, де 5 - найвища цінність, а 1 - найнижча.
Таблиця 2 - Зважена матриця рішень для пріоритезації вимог
# | Критерії оцінювання | Вага | Керування доступом | Загальний огляд | Детальний зріз | Фільтри |
1. | Цінність для керівника | 1 | 5 | 5 | 3 | 4 |
2. | Автор | 0,7 | 1 | 5 | 3 | 4 |
3. | Частота використання | 1 | 5 | 5 | 4 | 3 |
4. | Терміновість реалізації | 0,9 | 2 | 4 | 1 | 2 |
Результат | 12,5 | 17,1 | 10 | 11,6 |
Розглянемо детальніше оцінювання критеріїв. Ми знаємо, що нашим звітом будуть користуватись керівники компанії, тому оцінка цінності блоку керування доступом та загальний огляд - 5. Детальний зріз даних та фільтрування не так важливо для керівників такого рівня.
В більшості випадків керівники компанії не задумуються про те, як обмежуються дані у звітності в залежності від їхнього доступу. Але це обмеження вимагається політикою компанії. Тому оцінка критерію «Автор» для блоку керування доступом - найнижча і становить 1. Тоді як агрегований звіт - пряма вимога керівництва, а отже "Автор" - 5.
Частота використання - оцінюємо як часто функціоналність буде використовуватись зацікавленими особами. Для прикладу, блок керування доступом має найвищу оцінку, оскільки кожне відкриття звіту першочергово буде звертатись до налаштувань прав на перегляд даних. А загальний огляд даних - це перше, що будуть бачити користувачі, коли відкриватимуть звіт.
Терміновість реалізації (time sensitivity) - деяка функціональність може і не впливати на досвід користувача і навіть не покращувати нічого у системі, але бути вимогою для успішного проходження внутрішнього чи зовнішнього аудиту. Для прикладу це може бути або специфічна класифікація, тобто призначення ідентифікатора на певну подію, яка вимагається регулятором. Або, наприклад, експорт даних в третю систему може бути потрібний для роботи іншої команди.
Для нашої звітності строгих вимог по часу немає. А загальний огляд даних має високу оцінку 4, тому що керівництво компанії планує покладатись на новий звіт у наступному звітному періоді.
Таким чином заповнюється вся таблиця. Результат вираховується як сума оцінок, помножених на вагу критерія.
Для нашого прикладу ми змогли емпірично пріоритезувати вимоги в наступному порядку:
Загальний огляд
Керування доступом
Фільтри
Детальний зріз.
В результаті, застосовуючи критерії оцінювання, а також зважену матрицю рішень, ми змогли проаналізувати варіанти рішень та зробити усвідомлений вибір. А також пріоритезувати список функціональності для першого запуску.
Залежності
Яка ж пріоритезація без залежностей? В деяких випадках залежності між блоками функціональності вибудовуються таким чином, що реалізація одного блоку стає передумовою для початку роботи над іншим. Адже ми не можемо почати будувати дах будинку, якщо немає фундаменту і стін. Або ми не можемо реалізовувати розрахунок картою в онлайн магазині, якщо у нас не підключена платіжна система.
Залежності варто намагатись виявляти якомога раніше та явно вказувати у трекінгових системах, таких як Jira/Confluence.
Залежності потрібно особливо уважно проговорювати та записувати під час планування роботи в рамках спринтів та продуктових інкрементів.
Також гарною практикою є залишати невеликий запас по часу, якщо ми плануємо працювати над функціональністю з передумовами. Тому що залежності - це завжди про ризики. А якщо щось може піти не так, то щось обоʼязково піде не так :)
Переваги зваженої матриці рішень
Оцінка варіантів рішень виконується багатогранно, формально та уніфіковано для всіх опцій.
Значно зменшується емоційна складова при аналізі рішень.
Техніка підходить для аналізу стратегій в умовах з багатьма вхідними даними і в умовах невизначеності. Передбачається попередній аналіз різних аспектів стратегій.
Техніка підходить для пріорітезації незалежних вимог, тобто таких, які можуть бути реалізовані одночасно.
Недоліки техніки
Може бути боляче визнати перемогу рішення, до якого немає емоційної привʼязки.
Підказка: емоційний компонент за потреби можна винести в окремий критерій та також оцінити його вплив на загальну оцінку.
Якщо ж все таки відчувається внутрішня незгода з формально визначеним рішенням, варто повернутись та розглянути ще раз критерії оцінювання. Можливо пропустили важливий чинник, чи забули про потреби якогось стейкхолдера, чи про вимоги аудиту?
Деякі ситуації можуть вимагати негайного прийняття рішення без можливості детально оцінити різні його аспекти.
Підказка: можна і не використовувати зважену матрицю формально, але варто мати на увазі складові цього методу. Особливо критерії оцінювання.
Зважена матриця ускладнюється, якщо потрібно пріоритезувати вимоги з залежностями. Якщо реалізація функціональності на момент пріоритезації неможлива, то тоді немає сенсу оцінювати інші критерії, оскільки з часом контекст зміниться і оцінки поміняються відповідно.
Підказка: залежності можна формально винести як окремий критерій оцінювання. Тоді функціонал, який є передумовою для чогось іншого, отримає високу оцінку критерія «залежність» і це відобразиться на загальній оцінці і відповідно на порядку реалізації.
Наразі, дякую всім, хто прочитав статтю. Пишіть у коментарях чи було корисно! Буду рада знайомству та спілкуванню.
About the Author
Anastasiia Kraievska, Product Owner, CBAP, PSPO I, PSM I and ISTQB certified with over 13 years of experience in IT, most recently specializing in non-financial risk management at Deutsche Bank. Connect with me via Linkedin.
Disclaimer: The opinions and views expressed in this article are my own and do not necessarily represent those of my organization.
Хочете більше дізнатись про стратегічний аналіз, критерії оцінки та критерії приймання? Приходьте на Комплексний онлайн тренінг з бізнес-аналізу (BABOK 3.0) Комплексний онлайн тренінг з бізнес-аналізу (BABOK 3.0)
Новини та статті по бізнес-аналізу
про застосування техніки для аналізу стратегічних рішень так само матрицю можна сміливо використовувати для ще більш стратегічного рівня – аналізу альтернативних рішень / конкурентів, по одній вісі перелік конкруентів, по другій вісі критерії, якщо треба, то можна також ввести вагу для критеріїв про застосування техніки для менеджменту беклогу є подібна техніка "з коробки" – сейфівська wsjf (Weighted Shortest Job First) (https://framework.scaledagile.com/wsjf), яку також за необхідності можна кастомізувати і збагачувати "потрібними під себе" критеріями, наприклад, часто збагачують так само критерієм "залежність"