Мышление второго порядка, или Как принимать лучшие решения | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale 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, когда кто-то «ощущает», что команды не работают. Или вы курите, когда нервничаете. Такие решения действуют как таблетки — они снимают боль, но не устраняют первопричину.

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

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

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

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

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

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

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

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

вебінар
Дмитро Незабитовський  

На цьому вебінарі ми поговоримо про масштабування ІТ-розробки та користувацької цінності. Реальна історія, намозолений досвід, неочікувані виклики зростання та відповіді на запитання аудиторії.

тренінг
Дмитро Незабитовський  

Decomposition for Agile Teams – це двомодульний, 12-годинний тренінг-інтенсив для охочих докладно розібратися в інструментах декомпозиції, оцінки та пріоритезування елементів для використання у своїх Agile командах. Після закінчення навчання ви отримаєте іменний сертифікат з унікальним номером, англійською мовою – "Decomposition for Agile T...

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

Скільки коштують ваші зустрічі? Та як не втрачати гроші.

Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …

Top 5 питань про Agile Retrospectives

Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

Чому коучинговий підхід актуальний у бізнесі?

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …

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

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

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

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