Люди и решения
Люди плохо умеют принимать решения в контексте сложных проблем и задач.
В постах про отчеты CHAOS Report я наткнулся на важную мысль:
Быстро принять неоптимальное решение лучше, чем долго искать оптимальное решение
«Неоптимальное» — это не «плохое», а скорее «достаточно хорошее», неидеальное, но работающее. Трактовка автоматически тянет за собой вопрос «а как мы определим оптимальность решения?» — то есть, каковы критерии выбора? За короткий абзац стало понятно, что минимальный фреймворк для принятия решений содержит в себе три элемента: проблема, вариант решения, критерии оценки решения.
Я часто наблюдал или принимал участие в проектах и рабочих группах, где решения вырабатывались интуитивно (очень быстро и неоптимально) или наоборот — очень долго и безрезультатно.
Интуитивный способ — ок, до тех пор пока вы относитесь к решениям как к неподтвержденным гипотезам, которые можно быстро и дешево проверить. А если проверка провалится — пересмотреть свой выбор (см. пост Пион про энергию). То есть, интуитивный способ — это рабочий метод в рамках фреймворка «быстро проверяем много простых гипотез». Обычно никто не думает про критерии и берет решение с верха стопки в ассоциативном ряду — плохо.
«Очень долго и безрезультатно» обычно бывает, когда плохо сформулирована проблема или плохо понятны критерии выбора. Тогда вопрос может месяцами ходить между стейкхолдерами и отделами, переливаться из митинга в митинг и обрастать мхом. Способ решения «садимся в комнату и не выходим оттуда, пока не примем решение» без понимания проблемы и/или модели критериев скорее всего приведет к компромиссу, зато круто выглядит в моменте — волчара с мощными лапами взял всех за шкирку и заставил решить вопрос. Минусы понятны: решение скорее всего будет быстрым-интуитивным и не учтет произошедшие в мире изменения за время, пока вопрос обрастал мхом.
На правах демонстрации чувственного опыта. Если компания: в течение года переходит с вью на реакт, а потом обратно; принимает решение быстренько срубить бабла на консьюмерах, переделав б2б-продукт в б2с при полном неумении в б2с-маркетинг; полгода разрабатывает софтверный продукт, а потом перед выводом на рынок задается вопросом «а что это мы сделали и кому будем продавать?» — то в такой компании:
(а) все отлично, так у всех, жизнь сложная
(б) не очень ок с качеством решений.
Напишите выбранный вариант в комментах, приложите копию паспорта. А то вдруг вы бот.
Короче, люди плохо умеют принимать решения по сложным проблемам/задачам. Поэтому нужно научиться раскладывать сложные проблемы на простые составляющие и решать по частям, а для этого нужен какой-то метод. Мне стало интересно, что про это пишут в мире, поэтому я решил поразбираться в домене Decision Making.
Я уже немного писал на эту тему. В til за январь у меня был раздел про фреймворки принятия решений из рассылки Ленни Рачицкого, там можно примерно понять роли и фазы процесса.
Еще был отдельный пост про метод анализа иерархий — там я рассказываю про еду про софт, помогающий принимать сложные решения с помощью матмоделей. Все по науке и отлично работает на многокритериальных проблемах, но в освоении может быть сложно.
Зачем это читать (строим базу)
Пишу эти посты в стремлении навести какую-то базу в размышлениях о домене Decision Making: как вообще правильно думать об этом?
Приведу абзац из моего поста про CHAOS Report 2018:
Основной тезис раздела звучит так:
The value of the interval is greater than the quality of the decision.
Я это понимаю так: если мы принимаем решения быстро и умеем не менее быстро понять, что какое-то решение было плохое, то мы можем перебрать больше решений за единицу времени. «Быстро понять, что какое-то решение было плохое» — это второй важный навык внутри первого, потому что нет смысла перебирать много решений, если мы не понимаем, какое из них — хорошее, а какое — нет.
Группа Стендиш предлагает прикольную эмпирическую метрику: проект порождает одно решение на тысячу долларов проектных трудозатрат. Если в проекте на одно решение приходится не одна, а две тысячи трудозатрат — значит, решения принимаются дольше, чем это возможно.
«Решением» здесь может быть любой выбор из какого-то количества альтернатив, способный повлиять на дальнейший ход проекта, его «выхлоп» или метод работы.
А вот цитаты из другого моего поста, про отчет 2020 года:
Good Decision Latency — это когда решения принимаются быстро, а Poor — когда долго (...). Разница поразительная: быстрые решения в десять раз уменьшают вероятность зафейлить проект и почти в четыре раза увеличивают вероятность успешно завершить проект.
...Разница в накладных расходах на принятие решений у команд с High-скиллом и Poor-скиллом примерно десятикратная.
Принимать решения и делать это правильно — выгодно.
В связи с вышеизложенным, у меня родилось несколько аксиом:
- Решение всегда решает проблему/задачу
- Возможных решений у проблемы/задачи всегда больше одного
- Лучше принимать хорошие решения, а не плохие
- Лучше принимать решения быстро, а не долго
И несколько важных следствий из аксиом:
- Нужно понять решаемую проблему или задачу, прежде чем искать способы решения
- Если после формулирования проблемы сразу понятно, как ее решать — нужно не бросаться решать, а подумать еще; ассоциации первого порядка не всегда лучший выбор
- Нужно уметь отличать хорошие решения от плохих; для этого нужно хорошо понимать проблему/задачу — см следствие 1
- Нужно уметь понять, что такое «долго»; это следует из контекста проблемы/задачи — см. следствие 1.
Джон Фитч, чей фреймворк вынесен в заголовок поста, как раз предлагает метамодель и шаблоны для понимания домена Decision Making. Этот пост — про первую статью Джона, опубликованную в SyEN edition 107, December 2021.
Важно отметить: в статьях Джона используются слова decision и solution, которые оба на русский переводятся как «решение». При этом под decision понимается ситуация выбора из какого-то количества вариантов — то есть, необходимость принять решение; под solution понимается конкретный способ решения выбранной проблемы или задачи, пошаговый алгоритм. Можно сказать, что decision (принятие решения) — это выбрать лучший вариант из какого-то набора solutions (конкретных вариантов решения).
Методы рационального мышления
Фреймворк Джона корнями растет из простого четырехчастного фреймворка K-T Rational Process, с которым Джон ознакомился на тренинге в 1986 году:
Situation Appraisal (Оценка ситуации) — это повторяющийся процесс, в ходе которого мы изучаем ситуацию, чтобы выявить проблемы/задачи и спланировать, как мы будем их решать.
Анализ проблем (Problem Analysis) — столкнувшись с проблемой непонятного происхождения, мы должны определить корневую причину ее возникновения, прежде чем приниматься за решение. Если проблемы (т. е. какого-то нежелательного или вредного явления) нет, то этап можно пропустить. Проблемы может не быть, когда инженерный проект запускается для новых достижений — запустить ракету в космос, изобрести новый источник энергии и т. п.
Анализ решений (Decision Analysis) — мыслительный паттерн для проектирования будущего: выработки решений под требования стейкхолдеров; методов оценки или сравнения этих решений; выбора курса действий для достижения оптимальной эффективности. Отвечает на вопросы «какое (решение взять)?» или «как (решить проблему)?».
Анализ потенциальных проблем (Potential Problem Analysis) — мыслительный паттерн для обнаружения потенциальных проблем, могущих возникнуть вследствие выбора какого-то решения из предыдущего этапа. Помогает предусмотреть и митигировать риски.
«Всего четыре Паттерна для моделирования целого мыслительного цикла человека разумного — это было не просто смело», решил Джон. И начал изо всех сил применять его, обвешивая и модифицируя под свои задачи на протяжении многих лет.
Джон изобретает решение-центричную СИ
Спустя годы Джон пришел к собственной модели — «решение-центричной системной инженерии» (Decision-centric Systems Engineering). Выглядит она посложнее, чем предыдущий фреймворк:
«Решение-центричность» означает, что важнейшим элементом системы становится decision — ситуация, в которой нужно сделать выбор из списка доступных вариантов, ориентируясь на важные для этого выбора критерии.
Слева направо:
Decision Breakdown Structure (DBS) — схема декомпозиции проблемы или задачи на набор понятных вопросов, объединенных в группы; это основа системы:
Requirements — требования к будущей системе; обуславливают критерии для выбора решений.
Decision Analysis — схема принятия решения по каждому вопросу из DBS. В смысловом центре схемы — желтый блок, это Decision, или вопрос, на который нужно ответить. Его берем из DBS.
Слева от него — критерии, которые важно принять во внимание по конкретному вопросу. Они формируются из требований. Цветные блоки справа от желтого блока — список альтернатив, потенциальных способов ответить на вопрос. Каждый такой способ оценивается по эффективности/производительности (Performance) и архитектурной пригодности — для понимания этого рисуются простенькие Architecture models. Модели должны быть с уровнем детализации, достаточным для прикладывания их к критериям и сравнения между собой: Джон несколько раз пишет в статье «no modeling for modeling’s sake».
Иногда, когда того требует ситуация, для оценки применяются физические или матмодели.
Из каждого способа решения растет вправо набор следствий — действий или эффектов, которые случатся, если выбрать этот вариант. Есть петля обратной связи от следствий обратно к требованиям: решения принимаются по очереди, и уже принятые нужно учесть в дальнейших выборах — в формате новых требований.
Планы работ и родмепы — это положенная на таймлайн последовательность действий по реализации принятых в качестве решений альтернатив и по митигации рисков:
Пример применения на понятном инженерном проекте:
Допустим, мы хотим приготовить яичницу. На двоих, с жидковатыми желтками, с помидорами, желательно пожарить на сливочном масле — так вкуснее, сверху посыпать тертым сыром. Помидоры лучше начать жарить раньше, чтобы они успели прожариться до нужной степени. С завтраком не торопимся, время терпит.
- Делаем DBS — формулируем вопросы:
Команда:
- Кто будет жарить?
- Кто будет готовить ингредиенты?
- Кто побежит в магаз за помидорами, если их не обнаружится в холодильнике?
Архитектура яичницы:
- Сколько яиц взять?
- На каком масле жарить?
- Какую сковороду использовать?
Методы:
- Как обеспечить нужную степень прожарки?
- Каков порядок закладки ингредиентов?
- Как подготовить сыр?
...и так далее.
- Оформляем все детали к альтернативам из группы «Архитектура яичницы»:
- Сколько яиц взять: два (минимум для двух человек); четыре (оптимум); шесть (если сильно голодные)
- На каком масле жарить: на сливочном; на подсолнечном; без масла
- Какую сковороду использовать: стандартную; большую
- Детализируем пару альтернатив по сковороде:
- «Использовать стандартную сковороду»: легко реализовать — сковорода лежит в шкафчике рядом; вмещает яичницу на 2-4 яиц, но не на 6; легко мыть, целиком помещается в мойку; оценим перфоманс как «высокий»
- «Использовать большую сковороду»: реализация сложнее: нужно идти за ней на лоджию, будет тяжело мыть — не помещается в мойку; ворочать ей на плите тоже сложно: занимает больше места, тяжелая; вмещает яичницу на 4-8 яиц, ради двух нет смысла с ней связываться; оценим перфоманс как «средний с минусом»
Где-то тут мы поняли, что у нас оформилось решение по количеству яиц: хотим четыре. А значит, у нас формируется новое требование (на основе принятого решения): «сковорода должна вмещать яичницу на 4 яйца». Выходит, нам легче взять стандартную сковороду, у нее выше оценка перфоманса.
Дальше примерно понятно: определяем «следствия», строим план, реализуем, а потом с аппетитом этот инженерный проект съедаем, урча маянезиком.
Снова про еду получилось, надо что-то с этим делать.
Методология управления решениями
Если элементы из схемы выше упаковать в более крупные группы, то получается методология управления решениями (Decision Management methodology):
Эту методологию Джон преподает на тренингах и воркшопах. Вот список областей, где она, со слов Джона, применяется:
- New product development
- Technical proposals
- Technology insertion projects
- Portfolio management
- Strategic capability design initiatives, e. g. transformational or continuous improvement
- Common/reference architecture development (platform & product line engineering)
- Innovation framework
- Feasibility analyses
- Research and Development (R&D) and Science and Technology (S&T) project management
- New business/technology incubation
- Capability, product, technology and platform roadmapping
- Business ecosystem modeling and design (looking for opportunities)
- Life coaching
Процессы в методологии:
Plan Decisions — процесс определения списка «выборов» (decisions), которые надо сделать для решения выбранной проблемы; итоговый артефакт процесса — Decision Breakdown Structure из большой схемы, где каждый «выбор» — это вопрос. Далее с помощью DBS строится Trade Study Plan — на русском это что-то вроде «плана исследования компромиссов/альтернативных решений». План содержит порядок, в котором следует принимать решения из DBS, основываясь на приоритетах и логике, а также все меры по поиску и формированию необходимой для этих решений информации. То есть, DBS — это «что» надо сделать, а TSP — «как» это сделать.
Plan Decisions можно использовать не только для «прямой инженерии» (от проблемы к решению), но и для «обратной», или реверс-инжиниринга. Зная, какие альтернативы были выбраны в существующем продукте/сервисе, можно пойти в обратную сторону: попробовать определить, какие решения в компании принимали, когда их выбирали, и какими требованиями руководствовались.
Звучит шизофренично, но вот вам кейс из жизни: крупный маркетплейс с огромным штатом разработчиков и аналитиков, обвешанный бигдатой со всех сторон, нанял консультантов. Для того, чтобы консультанты зареверсинжинирили интерфейс мобильного приложения и определили, какие фичи помогают пользователю, а какие — мешают. На всякий случай напомню, что каждая из этих фич была кем-то придумана, описана, засунута в бэклог, обоснована экономически, а потом реализована, протестирована и торжественно релизнута. Ну или не торжественно, а буднично, если там CI/CD.
Практика реверс-инжиниринга принятых решений (Джон зовет ее Decision Blitz) позволяет вовлечь стейкхолдеров в проект и обнаружить важные штуки:
- несогласие стейкхолдеров по поводу принятых решений (они видели его по-разному), а следовательно — и по поводу требований, которые следовали из этих решений;
- подсветить ранее принятые решения (decisions), которые могли бы дать больше ценности стейкхолдерам/проекту, если откатить их и заново рассмотреть.
Реверс-инжиниринг начинается с документов: списков требований и спецификаций. Поиск вопросов/решений ведется с помощью вопроса «Если Икс (требование, критерий, и т. п.) — это ответ, то на какой вопрос? Какое решение принималось?».
Джон утверждает, что несколько дней реверс-инжиниринга обычно приводят к DBS из пятидесяти элементов. Получившуюся модель нужно обсудить со стейкхолдерами, определить точки несогласия для проработки — или получить от всех «ОК» и обновить требования и границы системы.
На схеме методологии есть большой процесс Manage Decisions across Domains — он управляет системой знаний на предприятии и осуществляет валидацию, хранение и переиспользование решений на разных проектах. Один из его подпроцессов, Manage Decision Patterns, отвечает за процессы извлечения новой информации из проектов и ее использования для улучшения существующих паттернов.
Пожарив и съев яичницу из примера выше, мы можем сделать выводы и проапдейтить наш паттерн и в следующий раз жарить яичницу более грамотно.
На этом я первый пост закончу — мы примерно на середине первой статьи.
Резюме
- Для успеха в проекте и личной жизни нужно уметь быстро принимать хорошие решения;
- Чтобы быстро принимать хорошие решения — нужно правильно подходить к этому: изучить проблему/вопрос, декомпозировать на список вопросов, сформировать требования, превратить требования в критерии, к каждому вопросу подобрать несколько вариантов решения/ответа, сравнить их между собой на предмет соответствия критериям, оценить риски и следствия, повторить пока не наступит просветление;
- Яичница с жидковатыми желтками лучше хорошо прожаренной.
Блог Джона Фитча: https://decisiondriven.wordpress.com/
