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

Лучше делать хоть что-то, чем не делать ничего

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

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

Для начала откалибруем исходную ситуацию по шкале неопределённости. Например, такой:

Относительно стартовой точки мы можем находиться где-то в области «Да всё понятно, бери и делай», либо на другой стороне спектра «М-да, непонятно совсем ничего», ну или где-то посередине. Пройдём по порядку, слева направо.

Полная определённость

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

Как правило, результат создаётся не одним человеком, а коллективом, совместно. Это особенно заметно в ИТ: сложность технических решений, ИТ-систем, бизнес-процессов такова, что для решения даже небольшой задачи необходимо вовлечь нескольких исполнителей. А значит, работа выполняется постепенно, на разных участках. Если на том участке, где мы находимся, вдруг стало нечего делать, то это верный признак того, что на предыдущих участках что-то пошло не так. Рабочий процесс нарушен, и тогда от формулировки «хоть что-то» лучше перейти к более полезной и точной «пойти разобраться что пошло не так вверх по течению».

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

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

Скорее неопределённость

Теперь перейдём к области «Так себе определённость». Предположим, мы снова попали в ситуацию «делать нечего — что делать?». Браться за первую попавшуюся задачу не очень хорошо — есть довольно большая вероятность, что результат нашей работы не пригодится совсем, либо его придётся переделывать. Получается, что мы потратим ресурс, но бесполезно, а могли бы потратить с пользой. Хуже того: взятая нами задача может оказаться довольно сложной или крупной, потому даже после выхода из исходной ситуации «нам было нечего делать» мы будем продолжать доделывать то, что ненужно — не бросать же начатое, в самом деле?! Обычно мы очень плохо понимаем и ещё хуже принимаем концепцию нерелевантных издержек, а потому стараемся доделать всё, даже совершенно ненужное.

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

Полная неопределённость

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

Далее

Теперь для усиления эффекта поднимемся с уровня отдельного сотрудника на уровень ИТ-подразделения целиком. Предположим, у нас есть набор проектов, но часть из них непонятно кем делать, другую часть — непонятно как делать, третью — вроде начали делать, но не делается... Всё как обычно. Справедливо ли утверждение, что лучше делать хоть что-то, чем не делать ничего? Разумеется, нет. Делать хоть что-то в этой ситуации (то есть: выполнять хоть какой-то проект/проекты) означает увеличить степень хаоса, усложнить и так непростой управленческий ландшафт, а это даром не пройдёт — мы получим пустую трату ресурсов, потери времени и скорости, неоправданные ожидания и конфликты с заказчиками и бизнес-руководителями.

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

 

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

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

  • Евгений

    Здорово.

    Немного внесу сумбурных мыслей.

    Но как быть в итоге?

    Переодически останавливаться и рефлексировать по поводу задач, задавать себе вопрос, а то ли мы делаем?

    Главное не дойти до то, что все бессмысленно и задачи не имеют никакого значения в масштабах вселенной)))

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

    Даже если мы остановились, и задали себе вопрос, те ли задачи мы выполняем — фактически произвели действие.

    По итогу думаю все как всегда можно свести к гениальной и действительно рабочей фразе «нормально делай нормально будет»

    • Главное не дойти до то, что все бессмысленно и задачи не имеют никакого значения в масштабах вселенной)))

      Вот это отлично! 🙂

      По итогу думаю все как всегда можно свести к гениальной и действительно рабочей фразе «нормально делай нормально будет»

      Мне больше нравится немного другая фраза: «Нужно делать то, что нужно, а что не нужно, то делать не нужно».


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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT