Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …
Мышление второго порядка, или Как принимать лучшие решения
02 серп. 2021Это перевод статьи Евгения Лабунского - Agile Coach, Trainer, Head of Agile Practices в PandaDoc, управляющий партнёр Scrum Ukraine. Оригинал статьи "Second-Order Thinking or How to Make Better Decisions" находится здесь
Большинству руководителей знакома следующая динамика: хорошее решение сегодня может обернуться огромной проблемой в более длительных временных рамках. Вот пример такой ситуации.
Представим, что в одной части продукта, скажем, в Платежах, у вас есть очень опытная команда. Как только появляется какая-то работа, которую нужно выполнить в Платежах, вы передаете ее этой команде. Звучит здорово, но что будет происходить через год-два, если эту динамику продолжить? Вы с уверенностью скажете, что это можно предсказать. Вот что мы и называем мышлением второго порядка.
Основы анализа последствий решений
Остановимся ненадолго на этом примере и посмотрим, как он работает в динамике.
В этом примере присутствует очевидное следствие первого порядка с явной положительной динамикой: скорость разработки. Когда команда A получает работу в Платежах, ее участники лучше понимают код внутри этого компонента, улучшая работу в области бизнеса или решении проблем клиентов.
Мы сможем увидеть эту динамику, используя следующую диаграмму причинно-следственной связи:
S — прямой эффект, O — противоположный эффект, || — задержка, R1,2 — название циклов
Чем лучше понимается кодовая база команды A, тем быстрее могут быть доставлены решения (не нужно изучать код). Это определенно сокращает время цикла для таких задач. Кроме того, это увеличит вероятность того, что следующие задачи из сферы платежей перейдут команде A (поскольку там они быстрее выполняются). Этот цикл мы назовем R1 - цикл усиления 1.
Обычно этого достаточно, чтобы решить, что это хороший способ работы. Однако давайте визуализируем побочную динамику, которая со временем будет нарастать: чем больше у команды A работы именно по платежам, тем глубже становится разрыв в их знаниях между компонентом Платежи и другими компонентами. Это фактически означает, что специализация команды будет расти. Чем более специализированной становится команда, тем сильнее становится желание дать им работу в знакомой области, поэтому вероятность получения новой задачи в сфере платежей тоже будет расти. Назовем это циклом усиления 2 (R2).
Это означает, что через некоторое время возникает негативный эффект:
Давайте продолжим и посмотрим, что произойдет дальше, скажем, через год после принятия решения (это может произойти быстрее или медленнее, в зависимости от вашего контекста). Такое решение замедлит работу всей организации, поскольку теперь у вас есть команды, которые могут вести только специфическую работу. Поэтому возникнет тенденция к локальной оптимизации: менеджмент постарается найти больше задач в Payments, чтобы команда была занята, даже если в бэклоге есть более ценные задачи из других областей.
Посмотрим на это в более широкой временной перспективе:
Если у нас есть команда А, специализирующаяся на платежах, определенно есть и другие команды, специализирующиеся на других компонентах. Допустим, у нас есть еще команда B, владеющая Каталогом Сайта, и команда C, владеющая Корзиной. Теперь, чтобы создать сквозную клиентскую функцию, вам необходимо интегрировать все ABC (чтобы интернет-магазин работал). Но если они оптимизированы локально (для разработки своей части), кому-то нужно оптимизировать их глобально. Поэтому в такой компании нужны координаторы глобальной работы, которые будут:
- Разбивать задачи для областей ABC;
- Синхронизировать команды ABC по приоритетам;
- Управлять конвейером доставки;
- Тестировать сквозной результат (да, теперь у вас, вероятно, будет еще и команда D – Команда тестирования);
- Нести ответственность за сквозные сценарии;
Что делать, если у Команды А нет работы? Что делать, если в Платежах ничего делать не нужно? Вы никогда не столкнетесь с такой ситуацией при таких обстоятельствах – сотрудники будут заняты, поскольку не могут оставаться без работы. Тот, кто управляет их бэклогом, будет постоянно работать, чтобы занять их, даже если выполняемая ими работа не слишком важна. Так выглядит система локальной оптимизации.
Вот очень важное замечание: изначально не было цели создавать все это. Таковы результаты решения, которое могло быть принято 1-2 годами ранее, но проблема в том, что никто не сможет связать само это решение с его нынешним результатом. Так будет выглядеть разрыв с первопричиной, потому что нельзя сказать, что «сейчас мы нанимаем координаторов в нашу компанию, потому что год назад начали давать командам специализированные задачи».
Вот как из хороших решений можно сделать плохой результат. Чтобы избежать этого или осознавать это, нужно мыслить вторым порядком.
Мышление второго порядка
Иллюстрация из https://fs.blog/2016/04/second-order-thinking/
Внутри картинки слева направо : Последствия первого порядка, второй порядок, третий порядок, плохие, хорошие
В книге The Most Important Thing Говард Маркс объясняет концепцию мышления второго порядка. Его концепция тесно связана с книгой Даниэля Канемана Thinking, Fast and Slow.
Мышление первого порядка: быстрые решения могут выглядеть очевидными, однако иметь долгосрочные отрицательные результаты. Например, давайте введем KPI, когда кто-то «ощущает», что команды не работают. Или вы курите, когда нервничаете. Такие решения действуют как таблетки — они снимают боль, но не устраняют первопричину.
Мышление второго порядка — это инструмент ментальной модели, который помогает думать о последствиях, пытаясь смоделировать возможные сценарии будущего. Главное здесь — увидеть то, чего не видят другие, и поделиться этими знаниями. Итак, мышление второго порядка — отличный инструмент для совместного обсуждения принятия решений.
Когда люди думают таким образом, они обычно задают себе следующие вопросы:
- Каковы будут долгосрочные результаты моих решений? Через месяц? Год?
- И что потом?
- Каковы другие возможные результаты?
- Какую часть картины я не вижу?
- Есть ли другие возможности ошибиться? Кто может помочь узнать о них?
Чтобы использовать этот подход, вы можете смоделировать поведение системы во времени с помощью различных сценариев, подобных описанному выше.
Мыслить таким образом непросто, поскольку мы созданы для принятия быстрых решений, да и организации тоже очень их ценят. Но чем больше вы тренируетесь, тем более правильные решения будете принимать!