Портал №1 по управлению цифровыми
и информационными технологиями

Action Bias — известная ловушка, в которую мы всё равно постоянно попадаем

Иногда на наших семинарах по цифровым трансформациям, продуктовым подходам и прочему DevOps Foundation мы с группой делаем упражнение: «Найдите среди предлагаемых утверждений ложные, обоснуйте своё мнение». Среди утверждений можно разместить, например, такие:

  • Простаивающий ресурс — это потери для бизнеса
  • Лучше делать хоть что-то, чем не делать ничего
  • Чем раньше начнём, тем раньше закончим
  • ...

Интересные утверждения, у нас их заготовлено полтора десятка. С некоторыми участники разбираются проще, иные даются тяжелее. Очень полезное упражнение, каждый раз приводящее к открытиям и заставляющее задуматься.

Пример из практики

Вот и на прошлой неделе на корпоративном семинаре группа участников выполняла такое задание. Почти все из 13 человек согласились, что «Лучше делать хоть что-то, чем не делать ничего» — занятие вредное. И даже можно обосновать почему именно.

Та же группа уже на этой неделе почти в полном составе участвовала в деловой игре «Проект Феникс — DevOps на практике». Уже на первом раунде из четырёх возникло действо, которое можно озаглавить так: «давайте делать апгрейды нашей ИТ-инфраструктуры впрок — наверняка потом пригодится». На втором раунде оно было дополнено следующим: «Простаиваешь? Возьмись за новую задачу!». Но как же так? На рефлексии после второго раунда мы коротко обсудили происходящее и отметили, что ровно то, что было признано вредным «в теории», группа совершенно естественно и не задумываясь делает «на практике».

В чём проблема?

Мне кажется, существенная часть проблемы состоит в том, что это не просто утверждение — это убеждение. Оно сидит глубоко, мы его не осознаём. Мы из него исходим, оно влияет на принимаемые нами решения и на наши действия. Даже если мы на минуту остановимся и задумаемся — правда ли нужны эти апгрейды? — мы, скорее всего, быстро придём к ответу — конечно! Вовсе не потому, что мы знаем к каким будущим запросам бизнеса мы с помощью апгрейдов подготовимся (на самом деле не знаем). И не потому, что простаивающий ресурс отнимут (не отнимут). А потому, что мы заранее знаем «правильный» ответ. В этом и состоит сила убеждений — действуя глубоко изнутри, они подталкивают нас в определённую сторону, и мы уже сами можем затем придумать объяснение, почему эта сторона правильная. Хотелось бы, чтобы наши решения были на 100% рациональными, но нет. Известное дело.

Убеждение, о котором идёт речь, по-взрослому именуется Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам.

Почему это плохо?

Во-первых, мы часто исходим из неполной или недостоверной информации, находимся в условиях неопределённости. То есть результат действий может не пригодиться совсем, либо его придётся переделывать. При этом задумываться о том, какой результат действительно нужен, какой информации не хватает, нам ни к чему — нужно действовать!

Во-вторых, очень часто результат создаётся совместно, коллективом. Это особенно характерно для ИТ-деятельности. Если мы будем просто действовать, то перепроизводство на одном участке повлечёт заторы и замедление на последующих участках. Нехорошо.

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

Далее, «делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой. Все заняты, все загружены — вот же, создаём ценность! Нет, это может оказаться лишь иллюзией.

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

Итого, можно сформулировать следующий контртезис: нужно делать то, что нужно, а что не нужно, то делать не нужно. А вот Action Bias нас постоянно сбивает.

Будем же стараться помнить о нём и не попадать в ловушку.

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 3

  • Очень созвучно известной проблеме.

    «Что нужно делать в непонятных ситуациях ? — Думать!» Все это знают.

    Что мы делаем в большинстве случаев, сталкиваясь с непонятной ситуацией? — Делаем привычное 🙂

    Это оно же? Зачем расширять контекст, усложнять/менять задачу?! Продолжаем! («Некогда точить. Пилить надо»)

    Возможно, этот самый bias — всего лишь естественная попытка защититься о боли. Ведь думать «больно» (поэтому лучше уж как-нибудь без этого).

    Или это что-то другое?

    • Думаю, похоже — делаем привычное.

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

  • Андрей Вишняков

    вопрос, в каком квадранте cynefin мы находимся на текущий момент...


Добавить комментарий

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
    • 15 самых неправильно употребляемых слов в ИТ
      Очевидно, что люди любят говорить о технологиях. Но они не всегда правильно используют терминологию. Или они кооптируют фразы. Вот 15 наиболее часто неправильно используемых слов, с которыми они сталкивались в ИТ.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT