{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Блоги: заметки с тегом Системное мышление",
    "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": false,
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/blogengine.me\/blogs\/tags\/sistemnoe-myshlenie\/",
    "feed_url": "https:\/\/blogengine.me\/blogs\/tags\/sistemnoe-myshlenie\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/blogengine.me\/blogs\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "134886",
            "url": "https:\/\/artemushanov.ru\/?go=all\/obsudili-s-dinaroy-kamolovoy-processny-podhod-video\/",
            "title": "Обсудили с Динарой Камоловой процессный подход (видео)",
            "content_html": "<p>Пообщались с Динарой Камоловой — обсудили управление процессами и всякие связанные штуки.<\/p>\n<div class=\"e2-text-video\">\n<video src=\"https:\/\/artemushanov.ru\/video\/Podkast-2.mp4#t=0.001\" width=\"1600\" height=\"900\" controls alt=\"\" \/>\n\n<\/div>\n<p>Смотреть на других ресурсах: <a href=\"https:\/\/youtu.be\/8ebZdPhZIrs?si=0oET6Ja5x9S_Hukd\">на Ютубе<\/a>, <a href=\"https:\/\/vkvideo.ru\/video2131309_456239146?list=ln-4LFWN1tMQIzEgNyPvF\">на ВК<\/a>, <a href=\"https:\/\/rutube.ru\/video\/8c432ab8bbd4a18f86b2ab981cb7bd50\/\">на Рутубе<\/a>.<\/p>\n<p>Основные инсайты:<\/p>\n<ol start=\"1\">\n<li>Блок-схема — не единственный способ репрезентации процесса; еще есть табличный вариант (SIPOC) и структурированный текст<\/li>\n<li>Основная ценность стандартизованных процессов — снижение вариабельности при достижении того же результата<\/li>\n<li>Переход на процессное управление нужен для масштабирования и снижения издержек<\/li>\n<li>Три полезных вопроса при обнаружении отклонений: есть ли стандарт (для этой операции\/процесса)? Соблюдался ли стандарт? Адекватен ли стандарт?<\/li>\n<li>У процессов есть пререквизиты (обязательные условия для старта) и выходные метрики — эффективность, результативность, удовлетворенность<\/li>\n<li>В первую очередь нужно моделировать и разбирать те процессы, которые во-первых задействованы в цепочке создания ценности, во-вторых — затрагивают несколько бизнес-юнитов.<\/li>\n<\/ol>\n<p>Упоминаемые книги:<\/p>\n<ul>\n<li>«Выход из кризиса» — У. Деминг<\/li>\n<li>The Principles of Product Development Flow — Donald Reinertsen (<a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">серия моих постов<\/a>)<\/li>\n<li>«Как измерить все, что угодно» — Дуглас Хаббард<\/li>\n<li>«Система разработки продукции в Toyota» — Лайкер, Морган<\/li>\n<\/ul>\n<p>Ссылка на доску, на которой мы рисовали: <a href=\"https:\/\/app.holst.so\/share\/b\/76ca188e-4b23-4174-b888-205ae27b2eff\">https:\/\/app.holst.so\/share\/b\/76ca188e-4b23-4174-b888-205ae27b2eff<\/a><\/p>\n<p>Канал Динары про процессный подход: <a href=\"https:\/\/t.me\/DK_ProcessThinking\">https:\/\/t.me\/DK_ProcessThinking<\/a><\/p>\n",
            "date_published": "2025-02-26T14:01:09+05:00",
            "date_modified": "2025-02-26T14:55:59+05:00",
            "tags": [
                "post",
                "видео",
                "Процессы",
                "Системное мышление"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Wed, 26 Feb 2025 14:01:09 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "134886",
            "_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)"
}