BA toolkit - Part 2: Формула эффективного выбора – взвешенная матрица решений
- Anastasiia Kraievska
- 26 мая
- 6 мин. чтения
Почему одно решение кажется "правильным", а другое - "каким-то не таким"? Мы часто полагаемся на интуицию, опыт или авторитетное мнение. Но когда на кону серьезные бизнес-решения, этого мало. В этой статье мы рассмотрим инструмент, помогающий принимать обоснованные решения даже в сложных и неопределенных условиях – взвешенную матрицу решений (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)
Новости и статьи по бизнес-анализу:
Comments