Мышление второго порядка, или Как принимать лучшие решения | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
 
Стаття відображається оригінальною мовою.

Мышление второго порядка, или Как принимать лучшие решения

02 серп. 2021

Это перевод статьи Евгения Лабунского - Agile Coach, Trainer, Head of Agile Practices в PandaDoc, управляющий партнёр Scrum Ukraine. Оригинал статьи "Second-Order Thinking or How to Make Better Decisions" находится здесь

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

Представим, что в одной части продукта, скажем, в Платежах, у вас есть очень опытная команда. Как только появляется какая-то работа, которую нужно выполнить в Платежах, вы передаете ее этой команде. Звучит здорово, но что будет происходить через год-два, если эту динамику продолжить? Вы с уверенностью скажете, что это можно предсказать. Вот что мы и называем мышлением второго порядка.

Основы анализа последствий решений

Остановимся ненадолго на этом примере и посмотрим, как он работает в динамике.

ScrumUA_Blog_Evgeniy_Labunskiy_First_Order_Consequence

В этом примере присутствует очевидное следствие первого порядка с явной положительной динамикой: скорость разработки. Когда команда A получает работу в Платежах, ее участники лучше понимают код внутри этого компонента, улучшая работу в области бизнеса или решении проблем клиентов.

Мы сможем увидеть эту динамику, используя следующую диаграмму причинно-следственной связи:

ScrumUA_Blog_Evgeniy_Labunskiy_Causal_loop_diagram

S — прямой эффект, O — противоположный эффект, || — задержка, R1,2 — название циклов

Чем лучше понимается кодовая база команды A, тем быстрее могут быть доставлены решения (не нужно изучать код). Это определенно сокращает время цикла для таких задач. Кроме того, это увеличит вероятность того, что следующие задачи из сферы платежей перейдут команде A (поскольку там они быстрее выполняются). Этот цикл мы назовем R1 - цикл усиления 1.

Обычно этого достаточно, чтобы решить, что это хороший способ работы. Однако давайте визуализируем побочную динамику, которая со временем будет нарастать: чем больше у команды A работы именно по платежам, тем глубже становится разрыв в их знаниях между компонентом Платежи и другими компонентами. Это фактически означает, что специализация команды будет расти. Чем более специализированной становится команда, тем сильнее становится желание дать им работу в знакомой области, поэтому вероятность получения новой задачи в сфере платежей тоже будет расти. Назовем это циклом усиления 2 (R2).

Это означает, что через некоторое время возникает негативный эффект:

ScrumUA_Blog_Evgeniy_Labunskiy_Second_Order_Consequence

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

Посмотрим на это в более широкой временной перспективе:

ScrumUA_Blog_Evgeniy_Labunskiy_Third_Order_Consequence

Если у нас есть команда А, специализирующаяся на платежах, определенно есть и другие команды, специализирующиеся на других компонентах. Допустим, у нас есть еще команда B, владеющая Каталогом Сайта, и команда C, владеющая Корзиной. Теперь, чтобы создать сквозную клиентскую функцию, вам необходимо интегрировать все ABC (чтобы интернет-магазин работал). Но если они оптимизированы локально (для разработки своей части), кому-то нужно оптимизировать их глобально. Поэтому в такой компании нужны координаторы глобальной работы, которые будут:

  • Разбивать задачи для областей ABC;
  • Синхронизировать команды ABC по приоритетам;
  • Управлять конвейером доставки;
  • Тестировать сквозной результат (да, теперь у вас, вероятно, будет еще и команда D – Команда тестирования);
  • Нести ответственность за сквозные сценарии;

Что делать, если у Команды А нет работы? Что делать, если в Платежах ничего делать не нужно? Вы никогда не столкнетесь с такой ситуацией при таких обстоятельствах – сотрудники будут заняты, поскольку не могут оставаться без работы. Тот, кто управляет их бэклогом, будет постоянно работать, чтобы занять их, даже если выполняемая ими работа не слишком важна. Так выглядит система локальной оптимизации.

Вот очень важное замечание: изначально не было цели создавать все это. Таковы результаты решения, которое могло быть принято 1-2 годами ранее, но проблема в том, что никто не сможет связать само это решение с его нынешним результатом. Так будет выглядеть разрыв с первопричиной, потому что нельзя сказать, что «сейчас мы нанимаем координаторов в нашу компанию, потому что год назад начали давать командам специализированные задачи».

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

Мышление второго порядка

Second-Order Thinking

Иллюстрация из https://fs.blog/2016/04/second-order-thinking/

Внутри картинки слева направо : Последствия первого порядка, второй порядок, третий порядок, плохие, хорошие

В книге The Most Important Thing Говард Маркс объясняет концепцию мышления второго порядка. Его концепция тесно связана с книгой Даниэля Канемана Thinking, Fast and Slow.

Мышление первого порядка: быстрые решения могут выглядеть очевидными, однако иметь долгосрочные отрицательные результаты. Например, давайте введем KPI, когда кто-то «ощущает», что команды не работают. Или вы курите, когда нервничаете. Такие решения действуют как таблетки — они снимают боль, но не устраняют первопричину.

Мышление второго порядка — это инструмент ментальной модели, который помогает думать о последствиях, пытаясь смоделировать возможные сценарии будущего. Главное здесь — увидеть то, чего не видят другие, и поделиться этими знаниями. Итак, мышление второго порядка — отличный инструмент для совместного обсуждения принятия решений.

Когда люди думают таким образом, они обычно задают себе следующие вопросы:

  • Каковы будут долгосрочные результаты моих решений? Через месяц? Год?
  • И что потом?
  • Каковы другие возможные результаты?
  • Какую часть картины я не вижу?
  • Есть ли другие возможности ошибиться? Кто может помочь узнать о них?

Чтобы использовать этот подход, вы можете смоделировать поведение системы во времени с помощью различных сценариев, подобных описанному выше.

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

Рекомендовані заходи

тренінг
Олексій Кривицький  

Олексій Кривицький запрошує вас на авторську поглиблену 6-тижневу дистанційну програму розвитку і прокачування Скрам-майстрів з можливістю подальшої сертифікації Advanced Certified Scrum Master (A-CSM℠) від Scrum Alliance. Програма розроблена і підійде тим, хто вже має 1 і більше року досвіду в ролі Скрам-майстра.

тренінг
Євген Лабунський  

Дводенний поглиблений клас присвячений фасилітації. Курс сертифікаційний, по його закінченню учасники отримують іменні сертифікати ICAgile Agile Team Facilitation (ICP-ATF Certified professional).

тренінг
Михайло Вязанкін  

Розвиток Канбан-систем 2-денний сертифікований Канбан Університетом тренінг.

Рекомендовані статті

Что такое Канбан-система и зачем там доска?

Слышали ли вы про Канбан? Почти наверняка вам попадались высказывания, что Kanban помогает навести порядок, сделать работу предсказуемой, уменьшить время выполнения задач. Но за счёт чего? Просто из-за того, что мы лепим стикеры на доску?

Звучит не очень реалистично и я с вами согласен. …

Зачем нужна сертификация специалистам, которые работают в Agile?

Автор статьи Дмитрий Незабытовский — аккредитированный и действующий ICAgile Instructor и Advanced Certified ScrumMaster® (A-CSM) от Scrum Alliance. Практикующий ScrumMaster в продуктовой компании Terrasoft (Creatio).
В этой статье хотим поделиться с вами треками развития Agile специалистов …

Что происходит в мире Agile в 2021 году?

Совсем недавно был опубликован очередной 15-ый отчёт State of Agile Report от компании Digital.ai Agility. В мире практикующих аджайлистов, последние годы, уже стало хорошей традицией следить за появлением последней версии этого отчёта, сравнивать между собой тенденции от года к году и т.д.

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

Із питань корпоративних програм:

+380 93 4974661
hello@scrum.ua

З приводу тренінгів, реєстрацій, рахунків:

+380 95 7402380
hello@scrum.ua

За всіма номерами телефонів - голос і telegram.

©2017 - 2021 Scrum Ukraine. Всі права захищені.

Політика конфіденційності