Блоги: заметки с тегом Decision Patterns

Decision Patterns, пост 2

Артем Ушанов — Sun, 18 Aug 2024 14:03:41 +0500

Посты про фреймворк Джона Фитча под названием Decision Patterns.

В первом посте мы выяснили, что «принять решение» — на самом деле довольно сложный процесс. Нужно уметь разделять проблему, потенциальные способы разрешения (solutions), и ситуацию выбора из этих способов с применением критериев — decision.

В этом посте разберем основы фреймворка и некоторые устойчивые паттерны.

Определения и фундаментальные концепты

Начнем с понимания основы — что же такое этот самый decision:

«Принимаемое решение» (decision) в фреймворке Фитча — это фундаментальный вопрос или проблема, требующие ответа/решения (solution).

Примеры «принимаемых решений»:

Выбери университет для поступления
Выберите технологию для тормозной системы автомобиля
Выберите юзкейсы, которые нужно реализовать в продукте
Выберите маркетинговые каналы для рекламной кампании.

С этой точки зрения «принимаемое решение» — это составная часть задачи. А сама задача состоит из набора таких «принимаемых решений», вопросов, на которые нужно последовательно ответить. «Принимаемые решения» организуются в Decision Breakdown Structure (DBS), я про нее писал в прошлом посте.

С точки зрения системной инженерии — это следование принципу separation of concerns, мы «распиливаем» домен задачи на отдельные функциональные блоки и разбираемся с ними по отдельности.

Перечислю основные сущности домена решаемой задачи, для верности:
«Принимаемое решение» — в форме вопроса «Выбери Х»; «способы решения» (solutions) — потенциальные варианты выбора в рамках принимаемого решения; критерии — требования для оценки способов решения в рамках принимаемого решения.

На примере университета:

Принимаемое решение: нужно выбрать универ для поступления.
Альтернативы: АГТУ, АГУ, МГУ, Бауманка, МФТИ.
Критерии: универ в Астрахани или в Москве; хорошая репутация; есть возможность пройти на бюджет; сильные программы по экономике и маркетингу.

На примере маркетинговых каналов:

Нужно выбрать маркетинговые каналы для рекламной кампании
Альтернативы: РСЯ; контекстная реклама; реклама в видео; размещение у блогеров.
Критерии: бюджета хватит на 60 дней размещения; обеспечит охват в 250 тысяч; можно разместить видео; можно менять креативы раз в две недели; можно оплатить с юрлица.

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

Как принимаемые решения объединяются в паттерны?

В рамках конкретной задачи определяется одно главное принимаемое решение, которое разделяется на несколько принимаемых решений более низкого уровня. Это и есть Decision Breakdown Structure (DBS) — структура/диаграмма разбиения принимаемого решения. Устойчивый набор принимаемых решений, организованный в такую диаграмму, называется «паттерном принимаемых решений» (Decision Pattern).

Далее будет пример такого паттерна — «Дизайн оргспособности» (ОС, Capability Concept). Он будет состоять из номера принимаемого решения, его названия, короткого вопроса и класса принимаемого решения.

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

Номер Название ПР Описание ПР Класс ПР 1. Концепт оргспособности Какова верхнеуровневая архитектура, дизайн или пример имплементации для этой ОС? Один ответ 1.1 Сценарии использования В каких ситуациях или сценариях мы будет использовать ОС? Несколько ответов 1.1.1 Ценностное предложение Какую уникальную ценность предложит новая ОС в этом сценарии? Один ответ 1.2 Ключевые методы Какие методы или комбинации методов обеспечат основу этой ОС? Один ответ 1.3 Архитектура процесса Какую архитектуру, фреймворк или флоу процесса мы используем для разворачивания ОС? Многочастный ответ 1.3.1 Дизайн процесса Как вот эта часть процесса будет работать? Один ответ 1.3.1.1 Инструменты Какой набор инструментов мы используем, чтобы обеспечить эту часть процесса? Один ответ 1.3.1.2 Рабочие продукты Какие РП будут созданы этим процессом? Как они будут доставлены в следующий процесс? Несколько ответов 1.4 Интерфейсы ОС С какими процессами или другими ОС целевая ОС будет взаимодействовать? Несколько ответов 1.4.1 Концепт интерфейса Как эти ОС будут взаимодействовать друг с другом? Как их интерфейсы будут работать? Один ответ 1.5 Оргдизайн Как нам организоваться, чтобы эффективно использовать эту ОС? Кем укомплектуем команду? Какую роль будет играть каждый член команды? Многочастный ответ 1.6 Платформа Какая потребуется инфраструктура (помещения, рабочие центры, оборудование) для обеспечения ОС? Многочастный ответ 1.7 Метрики Какие метрики потребуется отслеживать для новой ОС? Как мы их соберем? Несколько ответов 1.8 Развитие Как мы получим или разовьем эту ОС? Один ответ

Классов принимаемого решения три:

«Один ответ» — обычно используется для вопросов вида «Каков/какой/как...», определяет концепты или технологии, выбираем один вариант из какого-то количества альтернатив.
«Несколько ответов» — используется для портфолийных вопросов вида «Какие N из набора M мы выберем?», выбираем все подходящие варианты.
«Многочастный ответ» — используется для архитектурных выборов, где варианты обычно представлены архитектурными моделями из нескольких связанных элементов. Например: какую оргструктуру выбрать для компании — более плоскую или более иерархичную? Каждый вариант «плоская, иерархичная» — это схема из нескольких элементов.

В принимаемых решениях классов «Несколько ответов» и «Многочастный ответ» у каждой рассматриваемой альтернативы должны быть рассмотрены все принимаемые решения ниже уровнем.

Пример:

1.1 Сценарии использования В каких ситуациях или сценариях мы будет использовать ОС? Несколько ответов 1.1.1 Ценностное предложение Какую уникальную ценность предложит новая ОС в этом сценарии? Один ответ

Если в «Сценариях использования» мы выбрали три сценария из пяти, то «Ценностное предложение» нужно выбрать для каждого из этих трех сценариев.

Понятнее станет, если мы посмотрим на то же самое в виде схемы:

Синие треугольники — обозначение того, что выбрать вариант решения нужно для каждого подварианта

Так же в рамках паттерна составляются списки критериев по каждому вопросу/принимаемому решению.

Вот пример критериев для вопроса «1.1 Сценарии использования»:

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

Конструкция «система должна» не обязательна, критерии/требования вполне могут быть в формате «максимизировать/минимизировать показатель N».
Сколько надо: Фитч пишет, что обычно получается 7-12 критериев на принимаемое решение. Лучшие критерии — измеримые и проверенные временем на ряде проектов: паттерн может и должен эволюционировать после каждого использования.

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

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

Что нам дают паттерны принимаемых решений? Они нам дают возможность выработать шаблонный способ принимать сложные решения. Золото для консультантов и работников «знаниевых» профессий.

Примеры паттернов

У Фитча таких паттернов некоторое количество, приведу примеры из исходной статьи.

System/Product Design
Содержит порядка 100 вопросов/принимаемых решений, наиболее часто применялся самим Фитчем.

Enterprise Strategy
Содержит около 60 вопросов/принимаемых решений, является «материнским» паттерном, от которого потом пойдут плясать продуктовые паттерны, паттерны оргспособностей и прочие.

Service Design
Содержит 25 вопросов/принимаемых решений; принимаемое решение Service Delivery Platform может стать триггером для запуска паттерна System/Product Design

Curriculum/Courseware Design
Содержит около 40 вопросов/принимаемых решений, позволяет спроектировать учебный артефакт от уровня индивидуального онлайн-курса до уровня полного университетского курса.

Выводы

Конец второго поста и конец оригинальной статьи. Подведем итоги.

Фитч нашел способ формализовать и описать сложный домен «принимаемых решений» через понятийный аппарат системной инженерии. Это позволяет разложить принимаемое решение на набор элементов — решаемую проблему, критерии хорошего решения, доступные варианты решения, — и разобраться с ними по очереди. Получился фреймворк для принимаемых решений с основным рабочим артефактом Decision Breakdown Structure.
С помощью фреймворка и набора методов Фитч предлагает создавать паттерны решений — устойчивые наборы принимаемых решений и наборы критериев для конкретных доменов задач. Паттерны можно переиспользовать в разных проектах для решения похожих задач, что особенно ценно для консультантов: у них есть задача алгоритмизировать любые уникальные задачи, чтобы их можно было решать быстрее или силами менее опытных сотрудников.

Дальше буду разбирать статью Фитча «Decision Patterns. So what?» на ту же тему.

Decision Patterns, пост 1

Артем Ушанов — Wed, 19 Jun 2024 19:38:46 +0500

Артем Ушанов:

Посты про фреймворк Джона Фитча под названием Decision Patterns.

Люди и решения

Люди плохо умеют принимать решения в контексте сложных проблем и задач.

В постах про отчеты 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/

Номер	Название ПР	Описание ПР	Класс ПР
1.	Концепт оргспособности	Какова верхнеуровневая архитектура, дизайн или пример имплементации для этой ОС?	Один ответ
1.1	Сценарии использования	В каких ситуациях или сценариях мы будет использовать ОС?	Несколько ответов
1.1.1	Ценностное предложение	Какую уникальную ценность предложит новая ОС в этом сценарии?	Один ответ
1.2	Ключевые методы	Какие методы или комбинации методов обеспечат основу этой ОС?	Один ответ
1.3	Архитектура процесса	Какую архитектуру, фреймворк или флоу процесса мы используем для разворачивания ОС?	Многочастный ответ
1.3.1	Дизайн процесса	Как вот эта часть процесса будет работать?	Один ответ
1.3.1.1	Инструменты	Какой набор инструментов мы используем, чтобы обеспечить эту часть процесса?	Один ответ
1.3.1.2	Рабочие продукты	Какие РП будут созданы этим процессом? Как они будут доставлены в следующий процесс?	Несколько ответов
1.4	Интерфейсы ОС	С какими процессами или другими ОС целевая ОС будет взаимодействовать?	Несколько ответов
1.4.1	Концепт интерфейса	Как эти ОС будут взаимодействовать друг с другом? Как их интерфейсы будут работать?	Один ответ
1.5	Оргдизайн	Как нам организоваться, чтобы эффективно использовать эту ОС? Кем укомплектуем команду? Какую роль будет играть каждый член команды?	Многочастный ответ
1.6	Платформа	Какая потребуется инфраструктура (помещения, рабочие центры, оборудование) для обеспечения ОС?	Многочастный ответ
1.7	Метрики	Какие метрики потребуется отслеживать для новой ОС? Как мы их соберем?	Несколько ответов
1.8	Развитие	Как мы получим или разовьем эту ОС?	Один ответ

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