Как выбирать решения на основе критериев?

Как выбирать решения на основе критериев? - 1

Речь пойдет об инструменте, который поможет выбрать вариант решения, даже если вы выбираете куда поехать в отпуск. Мой опыт сложился в крупных корпоративных проектах, где я проработала бизнес-аналитиком более 15 лет, поэтому все мои примеры именно от туда.

Что обычно прячется за кулисами задач по проектированию изменений в системах или процессах? Для развития темы это важно, хотя у кого-то такое напоминание может вызвать легкий нервный тик.

  • Много участников. Список заинтересованных сторон может содержать десятки имен. Направления интересов у всех очень разные. Бывает, что «заинтересованная сторона» совсем не заинтересована в изменениях, а вам тем не менее нужно получить решение или согласие.

  • Информация распределена. Источники информации очень разные: спецификации, ТЗ, регламенты, распоряжения, предыдущие версии систем, сотрудники… Встретить неактуальный документ и нигде не встретить того, кто его составил, — это не редкость.

  • Ошибки в решениях обходятся дорого. Если для изменений требуется большой каскад согласований и поэтапное внедрение, то исправить промах сложно.

Казалось бы уже известно много фреймворков для определения приоритетов или выбора наилучшего решения. Всего можно выделить три группы техник приоритизации: группировка, ранжированиескоринг, переговоры. Вот они на картинке ниже.

Сводная картинка основных групп техник приоритизации

Сводная картинка основных групп техник приоритизации

Давайте рассмотрим такой кейс, где все это плохо работает. Представьте, что вы в команде разработки ERP-платформы и нужно переходить с легаси-версии на новую, с новым тех-стеком. При этом:

  • Карточки объектов имеют не менее сотни атрибутов из разных областей: финансовые, учетные, технические, эксплуатационные и пр.

  • Каждая группа бизнес-данных имеет своего владельца и ни один из владельцев уже не помнит, откуда его поля взялись.

  • Нужно как-то договориться, какие поля обязательно нужно забрать в новую версию, а какие безнадежно устарели и останутся в прошлой.

«Legacy» само по себе в переводе означает «наследие», но это из тех наследий, которые мало кто хочет унаследовать. Разбор устаревших полей — это как выкинуть хлам из гаража: пока лежит — никому не нужен, а как только берёшь пакет для мусора — это уже «папины инструменты», которые точно будут скоро нужны. И в таком контексте:

  • Группировка перестает работать, потому что все поля получают приоритет «высокий». Воспринимаемая ценность каждого поля становится очень высокой на фоне перспектив принять решение об его удалении.

  • Типовое ранжирование не подходит. Там в любом варианте смотрится отношение бизнес-ценности к затратам, а у нас тут в числителе «папины инструменты», а в знаменателе — затраты на перенос одного поля не сильно одно от другого отличаются.

  • Переговоры из-за объема эмоций, мнений и непроверенной информации могут занять годы и не привести к результату.

Какую альтернативу выбрать? Среди 50 техник BABOK 3.0 упоминается Анализ решений (Decision Analysis). Строго говоря, за этим термином прячется несколько инструментов, например: дерево решений, таблицы решений, анализ затрат и выгод (Cost-Benefit Analysis) и не только. В этой статье речь о матрице решений с весами, которая еще может называться матрица управленческих решений или матрица Пью.

Смысл применения этого инструмента в том, чтобы от эмоционального принятия решений перейти к конкретным измеримым критериям. Какой из вариантов получит наиболее высокий итоговый балл, тот и получит наивысший приоритет или окажется самым подходящим решением среди прочих. Построить такую матрицу можно за 4 шага.

Шаг 1. Записать варианты к сравнению. Сформулируйте, между какими вариантами нужно сделать выбор. Чтобы снизить влияние собственного мнения, перечислите все альтернативы, даже те, что кажутся очевидными. На этом шаге не сравниваем и не оцениваем, просто фиксируем список.

Можно использовать любые удобные таблицы (Excel, Google, Яндек), вики-систему (Confluence, Obsidian) или доску со стикерами вроде Miro, а можно и просто начертить на листе бумаги, если у вас не более пяти вариантов к выбору. При выборе инструмента обратите внимание на пару моментов:

  • Если над данными работает несколько человек, важно, чтобы у всех был доступ на чтение или запись.

  • Если список больше, чем из пяти опций, то важно иметь удобную сортировку и группировку, ведь итоговые оценки нужно будет проанализировать и сравнить.

Для кейса с выбором полей в объекте ERP первые пять строк матрицы и заголовок могут выглядеть как на рисунке ниже: название и пара характеристик, которые могут быть нужны для информации. Если опций много, то лучше их пронумеровать, чтобы у каждой получилось что-то вроде идентификатора.

Для кейса с выбором полей в объекте первые пять строк матрицы могут выглядеть так.

Для кейса с выбором полей в объекте первые пять строк матрицы могут выглядеть так

Для кейса с выбором полей в объекте первые пять строк матрицы могут выглядеть так

Шаг 2. Выбрать критерии для оценки. Критерии — это то, по чему можно сравнивать варианты, они формулируются как измеримые параметры, а не как «нравится / не нравится». Достаточно 3–5 критериев, которые действительно влияют на решение, иначе можно уйти в затяжной анализ данных и потерять преимущество быстрого принятия решений, а особой статистической значимости дополнительных критериев не получить.

В случае кейса с устаревшими полями карточки объекта можно:

  • использовать исследования пользовательского опыта: провести опрос, , чтобы понять как пользователи работают с данными, какие выборки чаще всего делают и какие данные важны в их работе. Если позволяют сроки можно провести контекстные интервью;

  • на основании регламентов оценить насколько поле участвует в формальных процессах;

  • провести анализ интерфейсов и документации систем, выполняющих похожую работу в терминах JTBD и оценить вероятность использования поля;

  • оценить фактическое наполнение данными — наличие хотябы в одной записи данных, сохраненных не позже 2х лет назад от текущей даты (по данным выгрузки из БД).

Пример выбора критериев и правила подсчета итогового балла

Пример выбора критериев и правила подсчета итогового балла

Преимущество матрицы решений в том, что критерии могут быть разными в зависимости от специфики вашей задачи и данных, которые вам доступны для анализа. Скажем, кроме перечисленных выше для выбора полей можно посмотреть участвует ли атрибут в интеграциях, важен ли для регулятора, как используется в отчетности и учесть как одно поле зависит от другого.

Шаг 3. Назначить веса для критериев. Критерии не равны, один может быть важнее другого и вес это показывает. Чем больше вес, тем сильнее критерий влияет на итоговый балл, который считается как взвешенная сумма: сумма произведений оценок по всем критериям на их веса.

При выборе весов оценивайте скрытые критерии важности и уровень доверия к информации для оценки. На примере выше веса расставлены так, что доверия больше пользовательскому опыту и регламентам. Можно подобрать веса с учетом контекста задачи, главное, чтобы в сумме они составляли 100%.

Матрица для кейса с выбором полей в объекте готова к выставлению оценок

Матрица для кейса с выбором полей в объекте готова к выставлению оценок

Шаг 4. Проставить оценки по критериям. Каждый вариант получает балл по каждому критерию. Оценивается, насколько вариант соответствует критерию. Сложность здесь — отвлечься от мнений и оценивать именно соответствие по принципу: «точно соответствует», «скорее да», «скорее нет», «не соответствует». Шкалу оценок часто советуют от 1 до 5: где 5 — лучшее соответствие, 1 — худшее, но если вы хотите учесть очень тонкие различия, то можно взять и больший интервал, важно, чтобы он был однородным для всех критериев.

Теперь вы готовы считать итоговый балл для каждого варианта и сравнивать. На картинке пример группировки полей карточки объекта по итоговому баллу, как это может выглядеть для кейса с ERP.

Пример группировки полей карточки объекта по итоговому баллу

Пример группировки полей карточки объекта по итоговому баллу

Подводные камни. По сути такая матрица — это способ договориться об аргументах, которые можно принять за основу для итогового решения. Вот только можно увлечься цифрами и забыть важный момент, я так и сделала, когда впервые применяла этот подход. Наверное, потому что я — математик :)

Сам по себе алгоритм не заменяет ни экспертного суждения, ни ответственности конкретных людей за принятие решений. Уделите время согласованию критериев и источников информации и убедитесь, что все участники готовы доверять этому, а не только вы сами.

Не обязательно выбирать критерии в одиночку. Прежде, чем согласовывать с теми, кто будет принимать решение, можно посоветоваться с вашей командой, тимлидом или представителями от бизнеса, в конце концов приоритеты требований или выбор решения для них тоже важны.

Итак. Матрица решений вполне может вас выручить и помочь прийти к аргументированному обсуждению, если известные вам техники приоритизации почему-то не работают для вашей задачи и вы уверены, что

  • можно выбрать критерии, по которым есть данные,

  • оценка таких критериев не сложнее обычной приоритизации,

  • правила и критерии могут быть согласованы теми, кто принимает итоговое решение.

Не обязательно ждать легаси-платформу с сотней полей. Матрица решений справится с любым сложным выбором. Главное, не забудьте согласовать критерии. Хотя бы с собой, если вы единственный, отвечающий за решение.

Автор: BA_Mentor

Источник

Оставить комментарий