Как принять сложное решение? Метод анализа иерархий

Я могу легко выбрать из двух вариантов: если на витрине два вида бу́реков — с мясом и с зеленью, я возьму второй; если с сыром или с зеленью — уже сложнее, скорее всего тоже возьму второй. Тут один простой критерий: с зеленью мне больше нравится на вкус.

Сложнее будет, если мне надо выбрать перекус: взять бурек? Или купить питьевой йогурт? Или поесть супа? Питьевой йогурт — полезно, но надо идти до супермаркета и стоять там в очереди. Бурек — вредно, но вкусно, и пекарня по пути. Супа хочется, и это полезно, но надо идти в кафе, заказывать, ждать, есть, просить счет, ждать, платить...

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

Любители поесть всегда решают такие кейсы с помощью метода анализа иерархий (МАИ).

Как мы офис выбирали  #

Впервые для плюс-минус рабочей задачи я использовал метод анализа иерархий примерно десять лет назад. Мы искали помещение под офис в Астрахани, я полез в интернеты, пообщался с риелторами и накидал лонглист из пары десятков позиций. Выбрать сходу было просто нереально — как только казалось, что вот это вот помещение самое то, как через пару строчек находилось примерно такое же, но на первом этаже вместо третьего; круто, тогда его надо брать? Нет, вот еще одно — на втором, зато в полтора раза дешевле. Но — оно максимально неудобно с точки зрения логистики.

В общем, поняв, что таким хаотичным перебором вопрос не решить, я накидал в экселе матрицу приоритетов.

Выделил критерии (этаж, транспортная доступность, площадь, цена, состояние помещения и т. п.), попарно сравнил. Сравнение было простое: если в паре «этаж — транспортная доступность» важнее казалось второе, то в этой паре этажу присваивался ноль баллов, а транспортной доступности — два балла; если равнозначно — по единице каждому. Таким образом, проведя все парные сравнения, я получил оценку в баллах по каждому критерию — образовалась иерархия критериев, от более важных к менее важным.
Критериев было много, с десяток, поэтому я выкинул треть с самыми низкими баллами из анализа.

Далее я внес в табличку все варианты помещений под аренду из моего списка. Все варианты нужно было оценить по каждому критерию. Самые удобные — которые можно выразить числами: цена, площадь, этаж. Менее удобные — которые сложно выразить какими-то опциями. Как оценить транспортную доступность? Оценивали в итоге по адаптированной шкале Ликерта — от «очень удобно добираться» до «совсем неудобно добираться».

Дальше мы просто считаем условные баллы по каждому варианту и по итогу берем победителя.

Что хорошего в таком подходе?
1) Он позволяет математически выразить проблему сложного выбора и решить ее тоже математически; это снижает зависимость от эмоций в процессе и дает понятный алгоритм на будущее
2) Он демократичен; можно попросить заполнить матрицу всех причастных (семью, коллег), после чего агрегировать результаты и вывести победителя; сомневающимся в результате можно объяснить логику и показать расчеты, т. е. все прозрачно и проверяемо
3) На уровне ответов на вопросы — метод реально простой. Любому человеку гораздо легче ответить на вопрос «что лучше — А или Б?» много раз подряд, чем пытаться из ряда альтернатив сразу по всем критериям.
4) Можно сохранить результат со всеми промежуточными шагами в эксельке и пересмотреть спустя годик; возвращаться к принятым решениям и анализировать их спустя время — хорошая практика.

Но экселька — это неудобно. Хотелось к этому всему прикрутить интерфейс, чтобы не по ячейкам до ряби в глазах прыгать, а просто тыкать в один из двух предложенных системой вариантов. А баллы пусть она там внутри считает.

1000minds и смена работы  #

Три года назад я нашел такую софтину — кажется, через википедию и случайно. Называется она 1000minds и сделали ее два профессора из Новой Зеландии.
Когда я решил сменить работу в конце 2020, я использовал 1000minds для оценки потенциальных вакансий, потому что опять-таки столкнулся со сложностью выбора.

1. Выбор критериев.
Я выделил следующие:

С вариантами оценки пришлось пофантазировать

2. Сравнение критериев
Система может примерно подсчитать, сколько сравнений нужно сделать, чтобы составить модель весов.

Ну а потом система начинает предлагать варианты:

Картинка не моя, с сайта продукта; можно увидеть, что система предлагает сравнить не два критерия по важности (что довольно абстрактно), а два предполагаемых варианта, у каждого из которых сразу два критерия с разными значениями. На картинке сравниваются два условных проекта с разной предполагаемой эффективностью и степенью соответствия стратегическим целям.

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

Авторы называют свой метод PAPRIKA, он запатентован и умеет подстраивать дальнейшие пары в зависимости от уже полученных ответов. Подстройка позволяет системе увидеть явные тренды и не задавать пары, результат сравнения в которых кажется очевидным.

Погоняв нас по таким сравнениям, система выстраивает модель весов.

Есть много разных вьюшек, в т.ч. такая — так выглядела бы модель в экселе:

Получив модель весов, можно начинать вносить кандидатов.

3. Оценка альтернатив
Каждый кандидат получает название и оценивается по всем критериям

После внесения всех кандидатов получаем такой вот дашборд:

Дальше просто: при появлении нового кандидата просто вносим его в систему, оцениваем критерии и смотрим, в какое место общего рейтинга он попадает.

На скриншоте выше финальный вид дашборда — в компанию наверху списка я и устроился в итоге.

1000minds довольно гибкий. Веса можно в любой момент пересчитать, не теряя данные — просто заново пройти trade-offs. Появился новый критерий? Ок, вносим его в систему и опять-таки заново проходим trade-offs.
Можно создавать модель весов коллективно. При создании проекта в системе указывается его тип — «опрос» мы делаем или «решение». Если мы сделали «опрос», то можно оформить критерии, опубликовать опросник, выдать ссылку респондентам и получить в итоге модель весов не одного человека, а коллектива. Если бы в примере с выбором офиса я использовал 1000minds, я бы так и поступил, чтобы учесть мнения всех коллег.

Кейсы  #

Что можно оценивать с помощью МАИ?

Простые кейсы — выбор автомобиля, техники или квартиры; почему-то я не использовал метод, когда искал квартиру в Белграде год назад, а стоило бы; еще почему-то сервисы подбора жилья не имеют такого встроенного инструмента, хотя бы упрощенного

Кейсы посложнее:

  • Подбор кандидатов на вакансию в компании. Тут придется пораскинуть мозгами — как формализовать критерии, как оценивать по этим критериям кандидатов; а загнать эти штуки потом в систему — дело техники
  • Приоритизация бэклога — по модели impact-effort или более сложной; альтернативами считаем фичи/юзер стори
  • Оценка потенциальных фичей с помощью пользователей; из JTBD, CJM или Value proposition canvas выделяем критерии, потом пробуем построить модель весов на группе пользователей;
  • Выбор модулей для продукта, особенно при анализе решений сторонних поставщиков;

Важно правильно поставить задачу и формализовать критерии. Можно почитать книгу «Как измерить все, что угодно», там описываются методы квантификации неквантифицируемого.

Ссылки  #

Отправить
Поделиться
Запинить