Многозадачность – зло

Многозадачность – зло

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

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

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

Вот три проекта:

  • Проект 1: Напишите буквы от А до И в первом столбце.
  • Проект 2: Напишите числа от 1 до 10 в среднем столбце.
  • Проект 3: Напишите римские цифры от I до X в третьем столбце.

Конечный результат – три столбца, заполненные следующим образом:

  • А | 1 | I
  • Б | 2 | II
  • В | 3 | III и т. д.

Начните со сценария многозадачности, который подразумевает выполнение одной строки за раз. Вам нужно заполнить три столбца, работая строка за строкой, начиная с A, затем 1, затем I в первой строке, двигаясь вниз по странице, пока все три проекта не будут завершены. Засеките свое время.

Теперь начните сценарий без многозадачности, в котором вы начинаете один проект, завершаете его, затем начинаете следующий проект. Другими словами, вы должны начать со столбца 1 и записать буквы от А до И, затем перейти ко второму столбцу и записать цифры от 1 до 10, затем перейти к следующему столбцу, записав от I до X. Не забудьте засечь время.

Если вы не какой-то фрик, то вы должны увидеть, что вы были быстрее, когда не использовали многозадачность. Ну же, признавайтесь: вам даже не нужно было смотреть на время? Многозадачность даже по ощущению была дольше. Вы делали ошибки, когда использовали многозадачность? Я делал. Но, возможно, я не лучший пример здесь – мне приходится выключать радио, когда я проезжаю светофор.

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

Одна из основных причин, по которой Agile-подходы работают, заключается в том, что они позволяют людям и командам «выполнять одну задачу». То есть методология Agile заставляет нас сосредоточиться на выполнении только одной небольшой задачи за раз. Итерации ограничивают количество функций, которые может начать команда, и большинство команд быстро обнаруживают, что гораздо проще, когда каждый человек работает над одной задачей за раз. Хорошо организованные команды по техническому обслуживанию, как правило, работают над несколькими небольшими задачами одновременно. Работа небольшими партиями – это ключевое новшество бережливого производства и канбан-команд по разработке программного обеспечения. Гораздо проще сделать одну небольшую задачу правильно за раз, чем одну большую или много мелких.

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

Автор: Кларк Чинг
Источник

Виктор Вальчук
Критическая цепь. Управление проектами по ТОС

Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.

Тренер: В.В. Вальчук. Старт: Май 2025.

ПОДРОБНЕЕ
Прорыв

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!


Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.

Редактор сайта TOCPEOPLE.COM. Переводчик материалов по Теории ограничений
Организации: «АРБ-Консалтинг», Академия Теории ограничений
Звоните: +7 (351) 245-03-03
Пишите: info@tocpeople.com