{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Блоги: заметки с тегом Decision Patterns",
    "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": false,
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/blogengine.ru\/blogs\/tags\/decision-patterns\/",
    "feed_url": "https:\/\/blogengine.ru\/blogs\/tags\/decision-patterns\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/blogengine.ru\/blogs\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "130171",
            "url": "https:\/\/artemushanov.ru\/?go=all\/decision-patterns-post-2\/",
            "title": "Decision Patterns, пост 2",
            "content_html": "<p class=\"foot\">Посты про фреймворк Джона Фитча под названием Decision Patterns.<\/p>\n<p>В <a href=\"https:\/\/artemushanov.ru\/?go=all\/decision-patterns-post-1\/\">первом посте<\/a> мы выяснили, что «принять решение» — на самом деле довольно сложный процесс. Нужно уметь разделять проблему, потенциальные способы разрешения (<i>solutions<\/i>), и ситуацию выбора из этих способов с применением критериев — <i>decision<\/i>.<\/p>\n<p>В этом посте разберем основы фреймворка и некоторые устойчивые паттерны.<\/p>\n<h3>Определения и фундаментальные концепты<\/h3>\n<p>Начнем с понимания основы — что же такое этот самый decision:<\/p>\n<p class=\"loud\">«Принимаемое решение» (decision) в фреймворке Фитча — это фундаментальный вопрос или проблема, требующие ответа\/решения (solution).<\/p>\n<p>Примеры «принимаемых решений»:<\/p>\n<ul>\n<li>Выбери университет для поступления<\/li>\n<li>Выберите технологию для тормозной системы автомобиля<\/li>\n<li>Выберите юзкейсы, которые нужно реализовать в продукте<\/li>\n<li>Выберите маркетинговые каналы для рекламной кампании.<\/li>\n<\/ul>\n<p>С этой точки зрения «принимаемое решение» — это составная часть задачи. А сама задача состоит из набора таких «принимаемых решений», вопросов, на которые нужно последовательно ответить. «Принимаемые решения» организуются в Decision Breakdown Structure (DBS), я про нее писал в прошлом посте.<\/p>\n<p>С точки зрения системной инженерии — это следование принципу separation of concerns, мы «распиливаем» домен задачи на отдельные функциональные блоки и разбираемся с ними по отдельности.<\/p>\n<p>Перечислю основные сущности домена решаемой задачи, для верности:<br \/>\n«Принимаемое решение» — в форме вопроса «Выбери Х»; «способы решения» (<i>solutions<\/i>) — потенциальные варианты выбора в рамках принимаемого решения; критерии — требования для оценки способов решения в рамках принимаемого решения.<\/p>\n<p>На примере университета:<\/p>\n<ol start=\"1\">\n<li>Принимаемое решение: нужно выбрать универ для поступления.<\/li>\n<li>Альтернативы: АГТУ, АГУ, МГУ, Бауманка, МФТИ.<\/li>\n<li>Критерии: универ в Астрахани или в Москве; хорошая репутация; есть возможность пройти на бюджет; сильные программы по экономике и маркетингу.<\/li>\n<\/ol>\n<p>На примере маркетинговых каналов:<\/p>\n<ol start=\"1\">\n<li>Нужно выбрать маркетинговые каналы для рекламной кампании<\/li>\n<li>Альтернативы: РСЯ; контекстная реклама; реклама в видео; размещение у блогеров.<\/li>\n<li>Критерии: бюджета хватит на 60 дней размещения; обеспечит охват в 250 тысяч; можно разместить видео; можно менять креативы раз в две недели; можно оплатить с юрлица.<\/li>\n<\/ol>\n<p>Порядок принятия решения такой: <tt>определяем задачу → определяем критерии → ищем и подбираем альтернативы<\/tt>. Люди склонны к <a href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%A1%D0%BA%D0%BB%D0%BE%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8E_%D1%81%D0%B2%D0%BE%D0%B5%D0%B9_%D1%82%D0%BE%D1%87%D0%BA%D0%B8_%D0%B7%D1%80%D0%B5%D0%BD%D0%B8%D1%8F\">ошибке подтверждения<\/a>, поэтому существует вероятность несознательной подгонки критериев под уже выбранную альтернативу. Такая подгонка — интуитивный подход, а ему никакие фреймворки не нужны: выбирай сердцем и не мучай мозг. Поэтому по науке сначала — критерии, потом — альтернативы.<\/p>\n<h3>Как принимаемые решения объединяются в паттерны?<\/h3>\n<p>В рамках конкретной задачи определяется одно главное принимаемое решение, которое разделяется на несколько принимаемых решений более низкого уровня. Это и есть <i>Decision Breakdown Structure<\/i> (DBS) — структура\/диаграмма разбиения принимаемого решения. Устойчивый набор принимаемых решений, организованный в такую диаграмму, называется «паттерном принимаемых решений» (Decision Pattern).<\/p>\n<p>Далее будет пример такого паттерна — «Дизайн оргспособности» (ОС, Capability Concept). Он будет состоять из номера принимаемого решения, его названия, короткого вопроса и класса принимаемого решения.<\/p>\n<p class=\"foot\">Capability\/оргспособность — это способность вашей системы (софта, организации) что-то делать. Например, для системы управления умным домом оргспособностью может быть «обеспечение безопасности дома». В рамках нее у системы может быть несколько функций: видеонаблюдение, датчики движения, умные замки и т. д. Но сама оргспособность — это общая способность системы обеспечивать безопасность.<\/p>\n<p><tt><\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td><b>Номер<\/b><\/td>\n<td><b>Название ПР<\/b><\/td>\n<td><b>Описание ПР<\/b><\/td>\n<td><b>Класс ПР<\/b><\/td>\n<\/tr>\n<tr>\n<td>1.<\/td>\n<td>Концепт оргспособности<\/td>\n<td>Какова верхнеуровневая архитектура, дизайн или пример имплементации для этой ОС?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<tr>\n<td>1.1<\/td>\n<td>Сценарии использования<\/td>\n<td>В каких ситуациях или сценариях мы будет использовать ОС?<\/td>\n<td>Несколько ответов<\/td>\n<\/tr>\n<tr>\n<td>1.1.1<\/td>\n<td>Ценностное предложение<\/td>\n<td>Какую уникальную ценность предложит новая ОС в этом сценарии?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<tr>\n<td>1.2<\/td>\n<td>Ключевые методы<\/td>\n<td>Какие методы или комбинации методов обеспечат основу этой ОС?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<tr>\n<td>1.3<\/td>\n<td>Архитектура процесса<\/td>\n<td>Какую архитектуру, фреймворк или флоу процесса мы используем для разворачивания ОС?<\/td>\n<td>Многочастный ответ<\/td>\n<\/tr>\n<tr>\n<td>1.3.1<\/td>\n<td>Дизайн процесса<\/td>\n<td>Как вот эта часть процесса будет работать?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<tr>\n<td>1.3.1.1<\/td>\n<td>Инструменты<\/td>\n<td>Какой набор инструментов мы используем, чтобы обеспечить эту часть процесса?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<tr>\n<td>1.3.1.2<\/td>\n<td>Рабочие продукты<\/td>\n<td>Какие РП будут созданы этим процессом? Как они будут доставлены в следующий процесс?<\/td>\n<td>Несколько ответов<\/td>\n<\/tr>\n<tr>\n<td>1.4<\/td>\n<td>Интерфейсы ОС<\/td>\n<td>С какими процессами или другими ОС целевая ОС будет взаимодействовать?<\/td>\n<td>Несколько ответов<\/td>\n<\/tr>\n<tr>\n<td>1.4.1<\/td>\n<td>Концепт интерфейса<\/td>\n<td>Как эти ОС будут взаимодействовать друг с другом? Как их интерфейсы будут работать?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<tr>\n<td>1.5<\/td>\n<td>Оргдизайн<\/td>\n<td>Как нам организоваться, чтобы эффективно использовать эту ОС? Кем укомплектуем команду? Какую роль будет играть каждый член команды?<\/td>\n<td>Многочастный ответ<\/td>\n<\/tr>\n<tr>\n<td>1.6<\/td>\n<td>Платформа<\/td>\n<td>Какая потребуется инфраструктура (помещения, рабочие центры, оборудование) для обеспечения ОС?<\/td>\n<td>Многочастный ответ<\/td>\n<\/tr>\n<tr>\n<td>1.7<\/td>\n<td>Метрики<\/td>\n<td>Какие метрики потребуется отслеживать для новой ОС? Как мы их соберем?<\/td>\n<td>Несколько ответов<\/td>\n<\/tr>\n<tr>\n<td>1.8<\/td>\n<td>Развитие<\/td>\n<td>Как мы получим или разовьем эту ОС?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<\/table>\n<p><\/tt><\/p>\n<p>Классов принимаемого решения три:<\/p>\n<ul>\n<li>«Один ответ» — обычно используется для вопросов вида «Каков\/какой\/как...», определяет концепты или технологии, выбираем один вариант из какого-то количества альтернатив.<\/li>\n<li>«Несколько ответов» — используется для портфолийных вопросов вида «Какие N из набора M мы выберем?», выбираем все подходящие варианты.<\/li>\n<li>«Многочастный ответ» — используется для архитектурных выборов, где варианты обычно представлены архитектурными моделями из нескольких связанных элементов. Например: какую оргструктуру выбрать для компании — более плоскую или более иерархичную? Каждый вариант «плоская, иерархичная» — это схема из нескольких элементов.<\/li>\n<\/ul>\n<p>В принимаемых решениях классов «Несколько ответов» и «Многочастный ответ» у каждой рассматриваемой альтернативы должны быть рассмотрены все принимаемые решения ниже уровнем.<\/p>\n<p>Пример:<br \/>\n<tt><\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>1.1<\/td>\n<td>Сценарии использования<\/td>\n<td>В каких ситуациях или сценариях мы будет использовать ОС?<\/td>\n<td>Несколько ответов<\/td>\n<\/tr>\n<tr>\n<td>1.1.1<\/td>\n<td>Ценностное предложение<\/td>\n<td>Какую уникальную ценность предложит новая ОС в этом сценарии?<\/td>\n<td>Один ответ<\/td>\n<\/tr>\n<\/table>\n<p><\/tt><br \/>\nЕсли в «Сценариях использования» мы выбрали три сценария из пяти, то «Ценностное предложение» нужно выбрать для каждого из этих трех сценариев.<\/p>\n<p>Понятнее станет, если мы посмотрим на то же самое в виде схемы:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-post-2.png\" width=\"1408\" height=\"1044\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Синие треугольники — обозначение того, что выбрать вариант решения нужно для каждого подварианта<\/div>\n<\/div>\n<p>Так же в рамках паттерна составляются списки критериев по каждому вопросу\/принимаемому решению.<\/p>\n<p>Вот пример критериев для вопроса «1.1 Сценарии использования»:<br \/>\n<tt><\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: left\"><b>Критерий<\/b><\/td>\n<td style=\"text-align: left\"><b>Описание<\/b><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Комплаенс<\/td>\n<td style=\"text-align: left\">ОС должны поддерживать сценарии использования, которые соответствуют спецификациям заказчика, нормативным требованиям и соответствующим стандартам.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Кол-во пользователей<\/td>\n<td style=\"text-align: left\">ОС должны поддерживать юзкейсы с большим количеством пользователей<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Срочность<\/td>\n<td style=\"text-align: left\">ОС должна поддерживать юзкейсы, решающие срочные потребности пользователей<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Дифференциация<\/td>\n<td style=\"text-align: left\">ОС должны поддерживать юзкейсы, в которых ценностное предложение выгодно отличается от конкурентов<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Долгосрочные потребности<\/td>\n<td style=\"text-align: left\">ОС должны поддерживать юзкейсы, закрывающие стабильные долгосрочные потребности<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Время вывода на рынок<\/td>\n<td style=\"text-align: left\">ОС должны поддержать юзкейсы, которые мы готовы предоставить в короткие сроки<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Низкая себестоимость<\/td>\n<td style=\"text-align: left\">ОС должны поддерживать юзкейсы, которые мы можем предоставить с низкими издержками<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left\">Соответствие стратегии<\/td>\n<td style=\"text-align: left\">ОС должны поддержать юзкейсы, которые соответствуют нашей стратегии и создают новые возможности<\/td>\n<\/tr>\n<\/table>\n<p><\/tt><\/p>\n<p>Конструкция «система должна» не обязательна, критерии\/требования вполне могут быть в формате «максимизировать\/минимизировать показатель N».<br \/>\nСколько надо: Фитч пишет, что обычно получается 7-12 критериев на принимаемое решение. Лучшие критерии — измеримые и проверенные временем на ряде проектов: паттерн может и должен эволюционировать после каждого использования.<\/p>\n<p>Как пользоваться паттерном? Как чеклистом и основой для плана: в паттерне должны быть все важные вопросы в отношении принимаемого решения. Нужно составить порядок ответа на все вопросы из таблички, начиная с самых критичных; составить список критериев для них; начать разбираться с потенциальными способами решения. Времени это займет порядочно, за день не управиться, но и вопрос создания новой оргспособности — довольно важный.<\/p>\n<p>В работе по паттерну есть цикл, я его затрагивал в первом посте: после каждого принятого решения из DBS нужно вернуться к критериям и пересмотреть их, т. к. выбранный вариант решения может породить некоторое количество новых требований и ограничений. Именно поэтому важно в первую очередь принять самые критичные решения, которые позже будет сложно и дорого откатить — они обеспечат нам набор новых требований.<br \/>\nКак следствие, в фреймворке Фитча нет конфликта принимаемых решений — может быть только конфликт варианта решения с критериями или требованиями.<\/p>\n<p>Что нам дают паттерны принимаемых решений? Они нам дают возможность выработать <b>шаблонный способ принимать сложные решения<\/b>. Золото для консультантов и работников «знаниевых» профессий.<\/p>\n<h3>Примеры паттернов<\/h3>\n<p>У Фитча таких паттернов некоторое количество, приведу примеры из исходной статьи.<\/p>\n<p><b>System\/Product Design<\/b><br \/>\nСодержит порядка 100 вопросов\/принимаемых решений, наиболее часто применялся самим Фитчем.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-post-2-1.png\" width=\"1056\" height=\"1010\" alt=\"\" \/>\n<\/div>\n<p><b>Enterprise Strategy<\/b><br \/>\nСодержит около 60 вопросов\/принимаемых решений, является «материнским» паттерном, от которого потом пойдут плясать продуктовые паттерны, паттерны оргспособностей и прочие.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-63.png\" width=\"2274\" height=\"1202\" alt=\"\" \/>\n<\/div>\n<p><b>Service Design<\/b><br \/>\nСодержит 25 вопросов\/принимаемых решений; принимаемое решение <i>Service Delivery Platform<\/i> может стать триггером для запуска паттерна <i>System\/Product Design<\/i><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-post-2-2.png\" width=\"1904\" height=\"984\" alt=\"\" \/>\n<\/div>\n<p><b>Curriculum\/Courseware Design<\/b><br \/>\nСодержит около 40 вопросов\/принимаемых решений, позволяет спроектировать учебный артефакт от уровня индивидуального онлайн-курса до уровня полного университетского курса.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-64.png\" width=\"2190\" height=\"1222\" alt=\"\" \/>\n<\/div>\n<h3>Выводы<\/h3>\n<p>Конец второго поста и конец оригинальной статьи. Подведем итоги.<\/p>\n<ol start=\"1\">\n<li>Фитч нашел способ формализовать и описать сложный домен «принимаемых решений» через понятийный аппарат системной инженерии. Это позволяет разложить принимаемое решение на набор элементов — решаемую проблему, критерии хорошего решения, доступные варианты решения, — и разобраться с ними по очереди. Получился фреймворк для принимаемых решений с основным рабочим артефактом Decision Breakdown Structure.<\/li>\n<li>С помощью фреймворка и набора методов Фитч предлагает создавать <i>паттерны решений<\/i> — устойчивые наборы принимаемых решений и наборы критериев для конкретных доменов задач. Паттерны можно переиспользовать в разных проектах для решения похожих задач, что особенно ценно для консультантов: у них есть задача алгоритмизировать любые уникальные задачи, чтобы их можно было решать быстрее или силами менее опытных сотрудников.<\/li>\n<\/ol>\n<p>Дальше буду разбирать статью Фитча «Decision Patterns. So what?» на ту же тему.<\/p>\n",
            "date_published": "2024-08-18T14:03:41+05:00",
            "date_modified": "2024-09-06T15:59:50+05:00",
            "tags": [
                "Decision Patterns",
                "post",
                "методика"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Sun, 18 Aug 2024 14:03:41 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "130171",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "128878",
            "url": "https:\/\/artemushanov.ru\/?go=all\/decision-patterns-post-1\/",
            "title": "Decision Patterns, пост 1",
            "content_html": "<p class=\"foot\">Посты про фреймворк Джона Фитча под названием Decision Patterns.<\/p>\n<h3>Люди и решения<\/h3>\n<p>Люди плохо умеют принимать решения в контексте сложных проблем и задач.<\/p>\n<p>В постах про отчеты CHAOS Report я наткнулся на важную мысль:<\/p>\n<p class=\"loud\">Быстро принять неоптимальное решение лучше, чем долго искать оптимальное решение<\/p>\n<p>«Неоптимальное» — это не «плохое», а скорее «достаточно хорошее», неидеальное, но работающее. Трактовка автоматически тянет за собой вопрос «а как мы определим <i>оптимальность<\/i> решения?» — то есть, каковы критерии выбора? За короткий абзац стало понятно, что минимальный фреймворк для принятия решений содержит в себе три элемента: проблема, вариант решения, критерии оценки решения.<\/p>\n<p>Я часто наблюдал или принимал участие в проектах и рабочих группах, где решения вырабатывались интуитивно (очень быстро и неоптимально) или наоборот — очень долго и безрезультатно.<\/p>\n<p>Интуитивный способ — ок, до тех пор пока вы относитесь к решениям как к неподтвержденным гипотезам, которые можно быстро и дешево проверить. А если проверка провалится — пересмотреть свой выбор (см. <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-oktyabre-2023\/#:~:text=%D0%9F%D0%BE%D1%81%D1%82%20%D0%9F%D0%B8%D0%BE%D0%BD%20%D0%9C%D0%B5%D0%B4%D0%B2%D0%B5%D0%B4%D0%B5%D0%B2%D0%BE%D0%B9%20%C2%AB%D0%AD%D0%BD%D0%B5%D1%80%D0%B3%D0%B8%D1%8F%2C%20%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F%20%D0%B8%C2%A0%D0%BA%D1%80%D0%B8%D0%BD%D0%B6%D0%BC%D0%B5%D1%82%D1%80%C2%BB\">пост Пион про энергию<\/a>). То есть, интуитивный способ — это рабочий метод в рамках фреймворка «быстро проверяем много простых гипотез». Обычно никто не думает про критерии и берет решение с верха стопки в ассоциативном ряду — плохо.<\/p>\n<p>«Очень долго и безрезультатно» обычно бывает, когда плохо сформулирована проблема или плохо понятны критерии выбора. Тогда вопрос может месяцами ходить между стейкхолдерами и отделами, переливаться из митинга в митинг и обрастать мхом. Способ решения «садимся в комнату и не выходим оттуда, пока не примем решение» без понимания проблемы и\/или модели критериев скорее всего приведет к компромиссу, зато круто выглядит в моменте — волчара с мощными лапами взял всех за шкирку и заставил решить вопрос. Минусы понятны: решение скорее всего будет быстрым-интуитивным и не учтет произошедшие в мире изменения за время, пока вопрос обрастал мхом.<\/p>\n<blockquote>\n<p>На правах демонстрации чувственного опыта. Если компания: в течение года переходит с вью на реакт, а потом обратно; принимает решение быстренько срубить бабла на консьюмерах, переделав б2б-продукт в б2с при полном неумении в б2с-маркетинг; полгода разрабатывает софтверный продукт, а потом перед выводом на рынок задается вопросом «а что это мы сделали и кому будем продавать?» — то в такой компании:<\/p>\n<\/blockquote>\n<blockquote>\n<p><i>(а)<\/i> все отлично, так у всех, жизнь сложная<\/p>\n<\/blockquote>\n<blockquote>\n<p><i>(б)<\/i> не очень ок с качеством решений.<\/p>\n<\/blockquote>\n<blockquote>\n<p>Напишите выбранный вариант в комментах, приложите копию паспорта. А то вдруг вы бот.<\/p>\n<\/blockquote>\n<p>Короче, люди плохо умеют принимать решения по сложным проблемам\/задачам. Поэтому нужно научиться раскладывать сложные проблемы на простые составляющие и решать по частям, а для этого нужен какой-то метод. Мне стало интересно, что про это пишут в мире, поэтому я решил поразбираться в домене Decision Making.<\/p>\n<p>Я уже немного писал на эту тему. В til за январь у меня был раздел <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-yanvare-2024\/#:~:text=%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8%20%D0%BF%D1%80%D0%B8%D0%BD%D1%8F%D1%82%D0%B8%D1%8F%20%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B9\">про фреймворки принятия решений<\/a> из рассылки Ленни Рачицкого, там можно примерно понять роли и фазы процесса.<br \/>\nЕще был отдельный <a href=\"https:\/\/artemushanov.ru\/?go=all\/kak-prinyat-slozhnoe-reshenie-metod-analiza-ierarhiy\/\">пост про метод анализа иерархий<\/a> — там я рассказываю <strike>про еду<\/strike> про софт, помогающий принимать сложные решения с помощью матмоделей. Все по науке и отлично работает на многокритериальных проблемах, но в освоении может быть сложно.<\/p>\n<h3>Зачем это читать (строим базу)<\/h3>\n<p>Пишу эти посты в стремлении навести какую-то базу в размышлениях о домене Decision Making: как вообще правильно думать об этом?<\/p>\n<p>Приведу абзац из <a href=\"https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2018\/\">моего поста про CHAOS Report 2018<\/a>:<\/p>\n<blockquote>\n<p>Основной тезис раздела звучит так:<\/p>\n<blockquote>\n<p>The value of the interval is greater than the quality of the decision.<\/p>\n<\/blockquote>\n<\/blockquote>\n<blockquote>\n<p>Я это понимаю так: если мы принимаем решения быстро и умеем не менее быстро понять, что какое-то решение было плохое, то мы можем перебрать больше решений за единицу времени. «Быстро понять, что какое-то решение было плохое» — это второй важный навык внутри первого, потому что нет смысла перебирать много решений, если мы не понимаем, какое из них — хорошее, а какое — нет.<\/p>\n<\/blockquote>\n<blockquote>\n<p>Группа Стендиш предлагает прикольную эмпирическую метрику: проект порождает одно решение на тысячу долларов проектных трудозатрат. Если в проекте на одно решение приходится не одна, а две тысячи трудозатрат — значит, решения принимаются дольше, чем это возможно.<\/p>\n<\/blockquote>\n<blockquote>\n<p>«Решением» здесь может быть любой выбор из какого-то количества альтернатив, способный повлиять на дальнейший ход проекта, его «выхлоп» или метод работы.<\/p>\n<\/blockquote>\n<p>А вот цитаты из другого моего поста, <a href=\"https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2020\/\">про отчет 2020 года<\/a>:<\/p>\n<blockquote>\n<p>Good Decision Latency — это когда решения принимаются быстро, а Poor — когда долго (...). Разница поразительная: быстрые решения в десять раз уменьшают вероятность зафейлить проект и почти в четыре раза увеличивают вероятность успешно завершить проект.<\/p>\n<\/blockquote>\n<blockquote>\n<p>...Разница в накладных расходах на принятие решений у команд с High-скиллом и Poor-скиллом примерно десятикратная.<\/p>\n<\/blockquote>\n<p>Принимать решения и делать это правильно — выгодно.<\/p>\n<p>В связи с вышеизложенным, у меня родилось несколько аксиом:<\/p>\n<ol start=\"1\">\n<li>Решение всегда решает проблему\/задачу<\/li>\n<li>Возможных решений у проблемы\/задачи всегда больше одного<\/li>\n<li>Лучше принимать хорошие решения, а не плохие<\/li>\n<li>Лучше принимать решения быстро, а не долго<\/li>\n<\/ol>\n<p>И несколько важных следствий из аксиом:<\/p>\n<ol start=\"1\">\n<li>Нужно понять решаемую проблему или задачу, прежде чем искать способы решения<\/li>\n<li>Если после формулирования проблемы сразу понятно, как ее решать — нужно не бросаться решать, а подумать еще; ассоциации первого порядка не всегда лучший выбор<\/li>\n<li>Нужно уметь отличать хорошие решения от плохих; для этого нужно хорошо понимать проблему\/задачу — см следствие 1<\/li>\n<li>Нужно уметь понять, что такое «долго»; это следует из контекста проблемы\/задачи — см. следствие 1.<\/li>\n<\/ol>\n<p>Джон Фитч, чей фреймворк вынесен в заголовок поста, как раз предлагает метамодель и шаблоны для понимания домена Decision Making. Этот пост — про первую статью Джона, опубликованную в <a href=\"https:\/\/issuu.com\/ppisyen\/docs\/ppi_syen_107_december_final\">SyEN edition 107, December 2021<\/a>.<\/p>\n<p>Важно отметить: в статьях Джона используются слова <i>decision<\/i> и <i>solution<\/i>, которые оба на русский переводятся как «решение». При этом под <i>decision<\/i> понимается <i>ситуация выбора из какого-то количества вариантов<\/i> — то есть, необходимость принять решение; под <i>solution<\/i> понимается <i>конкретный способ решения выбранной проблемы или задачи<\/i>, пошаговый алгоритм. Можно сказать, что decision (принятие решения) — это выбрать лучший вариант из какого-то набора solutions (конкретных вариантов решения).<\/p>\n<h3>Методы рационального мышления<\/h3>\n<p>Фреймворк Джона корнями растет из простого четырехчастного фреймворка <i>K-T Rational Process<\/i>, с которым Джон ознакомился на тренинге в 1986 году:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-1.png\" width=\"1062\" height=\"564\" alt=\"\" \/>\n<\/div>\n<p><i>Situation Appraisal (Оценка ситуации)<\/i> — это повторяющийся процесс, в ходе которого мы изучаем ситуацию, чтобы выявить проблемы\/задачи и спланировать, как мы будем их решать.<\/p>\n<p><i>Анализ проблем (Problem Analysis)<\/i> — столкнувшись с проблемой непонятного происхождения, мы должны определить корневую причину ее возникновения, прежде чем приниматься за решение. Если проблемы (т. е. какого-то нежелательного или вредного явления) нет, то этап можно пропустить. Проблемы может не быть, когда инженерный проект запускается для новых достижений — запустить ракету в космос, изобрести новый источник энергии и т. п.<\/p>\n<p><i>Анализ решений (Decision Analysis)<\/i> — мыслительный паттерн для проектирования будущего: выработки решений под требования стейкхолдеров; методов оценки или сравнения этих решений; выбора курса действий для достижения оптимальной эффективности. Отвечает на вопросы «какое (решение взять)?» или «как (решить проблему)?».<\/p>\n<p><i>Анализ потенциальных проблем (Potential Problem Analysis)<\/i> — мыслительный паттерн для обнаружения потенциальных проблем, могущих возникнуть вследствие выбора какого-то решения из предыдущего этапа. Помогает предусмотреть и митигировать риски.<\/p>\n<p>«Всего четыре Паттерна для моделирования целого мыслительного цикла человека разумного — это было не просто смело», решил Джон. И начал изо всех сил применять его, обвешивая и модифицируя под свои задачи на протяжении многих лет.<\/p>\n<h3>Джон изобретает решение-центричную СИ<\/h3>\n<p>Спустя годы Джон пришел к собственной модели — «решение-центричной системной инженерии» (Decision-centric Systems Engineering). Выглядит она посложнее, чем предыдущий фреймворк:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-2.png\" width=\"1082\" height=\"593\" alt=\"\" \/>\n<\/div>\n<p>«Решение-центричность» означает, что важнейшим элементом системы становится <b>decision<\/b> — ситуация, в которой нужно сделать выбор из списка доступных вариантов, ориентируясь на важные для этого выбора критерии.<\/p>\n<p>Слева направо:<br \/>\nDecision Breakdown Structure (DBS) — схема декомпозиции проблемы или задачи на набор понятных вопросов, объединенных в группы; это основа системы:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-3.png\" width=\"312\" height=\"216\" alt=\"\" \/>\n<\/div>\n<p>Requirements — требования к будущей системе; обуславливают критерии для выбора решений.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-4.png\" width=\"290\" height=\"265\" alt=\"\" \/>\n<\/div>\n<p>Decision Analysis — схема принятия решения по каждому вопросу из DBS. В смысловом центре схемы — желтый блок, это <i>Decision<\/i>, или вопрос, на который нужно ответить. Его берем из DBS.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-post-1.png\" width=\"920\" height=\"842\" alt=\"\" \/>\n<\/div>\n<p>Слева от него — <i>критерии<\/i>, которые важно принять во внимание по конкретному вопросу. Они формируются из требований. Цветные блоки справа от желтого блока — список <i>альтернатив<\/i>, потенциальных способов ответить на вопрос. Каждый такой способ оценивается по <i>эффективности\/производительности<\/i> (Performance) и <i>архитектурной пригодности<\/i> — для понимания этого рисуются простенькие Architecture models. Модели должны быть с уровнем детализации, достаточным для прикладывания их к критериям и сравнения между собой: Джон несколько раз пишет в статье «no modeling for modeling’s sake».<br \/>\nИногда, когда того требует ситуация, для оценки применяются физические или матмодели.<br \/>\nИз каждого способа решения растет вправо набор <i>следствий<\/i> — действий или эффектов, которые случатся, если выбрать этот вариант. Есть петля обратной связи от следствий обратно к требованиям: решения принимаются по очереди, и уже принятые нужно учесть в дальнейших выборах — в формате новых требований.<\/p>\n<p>Планы работ и родмепы — это положенная на таймлайн последовательность действий по реализации принятых в качестве решений альтернатив и по митигации рисков:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-6.png\" width=\"332\" height=\"514\" alt=\"\" \/>\n<\/div>\n<p><b>Пример применения на понятном инженерном проекте:<\/b><br \/>\nДопустим, мы хотим приготовить яичницу. На двоих, с жидковатыми желтками, с помидорами, желательно пожарить на сливочном масле — так вкуснее, сверху посыпать тертым сыром. Помидоры лучше начать жарить раньше, чтобы они успели прожариться до нужной степени. С завтраком не торопимся, время терпит.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-9.png\" width=\"640\" height=\"480\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Образ результата<\/div>\n<\/div>\n<ol start=\"1\">\n<li>Делаем DBS — формулируем вопросы:<\/li>\n<\/ol>\n<p>Команда:<\/p>\n<ul>\n<li>Кто будет жарить?<\/li>\n<li>Кто будет готовить ингредиенты?<\/li>\n<li>Кто побежит в магаз за помидорами, если их не обнаружится в холодильнике?<\/li>\n<\/ul>\n<p>Архитектура яичницы:<\/p>\n<ul>\n<li>Сколько яиц взять?<\/li>\n<li>На каком масле жарить?<\/li>\n<li>Какую сковороду использовать?<\/li>\n<\/ul>\n<p>Методы:<\/p>\n<ul>\n<li>Как обеспечить нужную степень прожарки?<\/li>\n<li>Каков порядок закладки ингредиентов?<\/li>\n<li>Как подготовить сыр?<\/li>\n<\/ul>\n<p>...и так далее.<\/p>\n<ol start=\"2\">\n<li>Оформляем все детали к альтернативам из группы «Архитектура яичницы»:<\/li>\n<\/ol>\n<ul>\n<li>Сколько яиц взять: два (минимум для двух человек); четыре (оптимум); шесть (если сильно голодные)<\/li>\n<li>На каком масле жарить: на сливочном; на подсолнечном; без масла<\/li>\n<li>Какую сковороду использовать: стандартную; большую<\/li>\n<\/ul>\n<ol start=\"3\">\n<li>Детализируем пару альтернатив по сковороде:<\/li>\n<\/ol>\n<ul>\n<li>«Использовать стандартную сковороду»: легко реализовать — сковорода лежит в шкафчике рядом; вмещает яичницу на 2-4 яиц, но не на 6; легко мыть, целиком помещается в мойку; оценим перфоманс как «высокий»<\/li>\n<li>«Использовать большую сковороду»: реализация сложнее: нужно идти за ней на лоджию, будет тяжело мыть — не помещается в мойку; ворочать ей на плите тоже сложно: занимает больше места, тяжелая; вмещает яичницу на 4-8 яиц, ради двух нет смысла с ней связываться; оценим перфоманс как «средний с минусом»<\/li>\n<\/ul>\n<p>Где-то тут мы поняли, что у нас оформилось решение по количеству яиц: хотим четыре. А значит, у нас формируется новое требование (на основе принятого решения): «сковорода должна вмещать яичницу на 4 яйца». Выходит, нам легче взять стандартную сковороду, у нее выше оценка перфоманса.<\/p>\n<p>Дальше примерно понятно: определяем «следствия», строим план, реализуем, а потом с аппетитом этот инженерный проект съедаем, урча маянезиком.<\/p>\n<p>Снова про еду получилось, надо что-то с этим делать.<\/p>\n<h3>Методология управления решениями<\/h3>\n<p>Если элементы из схемы выше упаковать в более крупные группы, то получается методология управления решениями (Decision Management methodology):<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/decision-patterns-chast-1-7.png\" width=\"1061\" height=\"533\" alt=\"\" \/>\n<\/div>\n<p>Эту методологию Джон преподает на тренингах и воркшопах. Вот список областей, где она, со слов Джона, применяется:<\/p>\n<ul>\n<li>New product development<\/li>\n<li>Technical proposals<\/li>\n<li>Technology insertion projects<\/li>\n<li>Portfolio management<\/li>\n<li>Strategic capability design initiatives, e. g. transformational or continuous improvement<\/li>\n<li>Common\/reference architecture development (platform & product line engineering)<\/li>\n<li>Innovation framework<\/li>\n<li>Feasibility analyses<\/li>\n<li>Research and Development (R&D) and Science and Technology (S&T) project management<\/li>\n<li>New business\/technology incubation<\/li>\n<li>Capability, product, technology and platform roadmapping<\/li>\n<li>Business ecosystem modeling and design (looking for opportunities)<\/li>\n<li>Life coaching<\/li>\n<\/ul>\n<p>Процессы в методологии:<\/p>\n<p>Plan Decisions — процесс определения списка «выборов» (decisions), которые надо сделать для решения выбранной проблемы; итоговый артефакт процесса — Decision Breakdown Structure из большой схемы, где каждый «выбор» — это вопрос. Далее с помощью DBS строится Trade Study Plan — на русском это что-то вроде «плана исследования компромиссов\/альтернативных решений». План содержит порядок, в котором следует принимать решения из DBS, основываясь на приоритетах и логике, а также все меры по поиску и формированию необходимой для этих решений информации. То есть, DBS — это «что» надо сделать, а TSP — «как» это сделать.<\/p>\n<p>Plan Decisions можно использовать не только для «прямой инженерии» (от проблемы к решению), но и для «обратной», или реверс-инжиниринга. Зная, какие альтернативы были выбраны в существующем продукте\/сервисе, можно пойти в обратную сторону: попробовать определить, какие решения в компании принимали, когда их выбирали, и какими требованиями руководствовались.<\/p>\n<blockquote>\n<p>Звучит шизофренично, но вот вам кейс из жизни: крупный маркетплейс с огромным штатом разработчиков и аналитиков, обвешанный бигдатой со всех сторон, нанял консультантов. Для того, чтобы консультанты зареверсинжинирили интерфейс мобильного приложения и определили, какие фичи помогают пользователю, а какие — мешают. На всякий случай напомню, что каждая из этих фич была кем-то придумана, описана, засунута в бэклог, обоснована экономически, а потом реализована, протестирована и торжественно релизнута. Ну или не торжественно, а буднично, если там CI\/CD.<\/p>\n<\/blockquote>\n<p>Практика реверс-инжиниринга принятых решений (Джон зовет ее <i>Decision Blitz<\/i>) позволяет вовлечь стейкхолдеров в проект и обнаружить важные штуки:<\/p>\n<ul>\n<li>несогласие стейкхолдеров по поводу принятых решений (они видели его по-разному), а следовательно — и по поводу требований, которые следовали из этих решений;<\/li>\n<li>подсветить ранее принятые решения (decisions), которые могли бы дать больше ценности стейкхолдерам\/проекту, если откатить их и заново рассмотреть.<\/li>\n<\/ul>\n<p>Реверс-инжиниринг начинается с документов: списков требований и спецификаций. Поиск вопросов\/решений ведется с помощью вопроса «Если Икс (требование, критерий, и т. п.) — это ответ, то на какой вопрос? Какое решение принималось?».<br \/>\nДжон утверждает, что несколько дней реверс-инжиниринга обычно приводят к DBS из пятидесяти элементов. Получившуюся модель нужно обсудить со стейкхолдерами, определить точки несогласия для проработки — или получить от всех «ОК» и обновить требования и границы системы.<\/p>\n<p>На схеме методологии есть большой процесс <i>Manage Decisions across Domains<\/i> — он управляет системой знаний на предприятии и осуществляет валидацию, хранение и переиспользование решений на разных проектах. Один из его подпроцессов, <i>Manage Decision Patterns<\/i>, отвечает за процессы извлечения новой информации из проектов и ее использования для улучшения существующих паттернов.<\/p>\n<p>Пожарив и съев яичницу из примера выше, мы можем сделать выводы и проапдейтить наш паттерн и в следующий раз жарить яичницу более грамотно.<\/p>\n<p>На этом я первый пост закончу — мы примерно на середине первой статьи.<\/p>\n<h3>Резюме<\/h3>\n<ol start=\"1\">\n<li>Для успеха в проекте и личной жизни нужно уметь быстро принимать хорошие решения;<\/li>\n<li>Чтобы быстро принимать хорошие решения — нужно правильно подходить к этому: изучить проблему\/вопрос, декомпозировать на список вопросов, сформировать требования, превратить требования в критерии, к каждому вопросу подобрать несколько вариантов решения\/ответа, сравнить их между собой на предмет соответствия критериям, оценить риски и следствия, повторить пока не наступит просветление;<\/li>\n<li>Яичница с жидковатыми желтками лучше хорошо прожаренной.<\/li>\n<\/ol>\n<p>Блог Джона Фитча: <a href=\"https:\/\/decisiondriven.wordpress.com\/\">https:\/\/decisiondriven.wordpress.com\/<\/a><\/p>\n",
            "date_published": "2024-06-19T19:38:46+05:00",
            "date_modified": "2024-07-10T05:33:43+05:00",
            "tags": [
                "Decision Patterns",
                "post",
                "методика",
                "Системное мышление"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Wed, 19 Jun 2024 19:38:46 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "128878",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        }
    ],
    "_e2_version": 4079,
    "_e2_ua_string": "Aegea 11.0 (v4079e)"
}