Scrum. Революционный метод управления проектами - Джефф Сазерленд

Слышу ваши возражения: «Ладно, Сазерленд, вы замечательно все объяснили. И эти составления дурацких табличек тоже довольно занимательны. Все это отлично объясняет вред от разговоров по сотовому… но я управляю целой компанией. Я должен одновременно делать кучу вещей — мои группы вынуждены справляться одновременно с пятью проектами. Я обязан сохранять конкурентоспособность. Я не могу себе позволить работать иначе».

Снова весьма кстати придется огромная библиотека на тему проектов по разработке программного обеспечения. Вы ведь помните, зачем исследователи занимались этой проблемой, зачем многие программисты стали изучать данные проектов и сопоставлять самые разные показатели? Потому что ежегодно тратились сотни миллионов долларов, а программные продукты устаревали, не успев выйти на рынок. Джеральд Вайнберг в одном из своих трудов Quality Software Management («Управление качеством программного обеспечения»)4 приводит таблицу, которая говорит о многом:

Количество параллельных проектов

Количество времени, доступного на каждый проект, %

Потери при переключении на другой контекст, %

1

100

0

2

40

20

3

20

40

4

10

60

5

5

75

Колонка «Потери при переключении на другой контекст» — это потери в чистом виде. Все верно. При пяти параллельных проектах целых 75 процентов вашей работы уходит в никуда — три четверти рабочего дня коту под хвост. Именно поэтому вы не могли писать ряды и столбики с одинаковой скоростью. Сказываются ограничения возможностей нашего мозга. В начале 1990-х годов психолог Гарольд Пашлер показал, что когда люди выполняют одновременно две задачи, их мыслительные возможности снижаются. Он назвал это явление «столкновением двух задач». Пашлер провел несколько простых экспериментов. Одну группу испытуемых он просил производить совсем простое действие, например нажимать на кнопку, когда загорался свет. Другой группе он давал такое же задание и еще одно в дополнение, скажем, нажимать на другую кнопку в зависимости от цвета загоревшейся лампочки. Стоило добавить вторую задачу — неважно, насколько простой она была, — и необходимое время увеличивалось вдвое. Пашлер предположил, что есть некое узкое место в обработке информации — на самом деле люди способны одновременно думать только об одной вещи. Чтобы прервать один мыслительный процесс, обратиться к памяти, выбрать нужную ассоциацию, связанную со вторым процессом, а затем начать осуществлять новую работу — для всего этого требуются определенные усилия. Каждый раз, когда мы переключаемся на другое задание, требуется дополнительное время5.

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

Недавно в рамках одного исследования с использованием функцио­нальной магнитно-резонансной томографии была нарисована схема мозга в процессе мышления. Данные свидетельствуют, что думать о двух задачах одновременно можно, только если каждый процесс происходит в своем полушарии. Но даже в этом случае, как показывают снимки, мышление не происходит одновременно, а, скорее, мозг постоянно переключается с одной задачи на другую. Упрощенно говоря, мозг включает функцию контроля, чтобы мы не начинали пререкаться сами с собой слишком рьяно6.

Вернемся от физиологии к нашим проектам. Что означает для нас понятие «выполнить задачу»? Возьмем для примера типичную группу. В этом году они решили взять три проекта. Назовем их A, B, C. Планируя свой год, группа заявила, что сначала немножко поработает над одним проектом, потом над другим, потом над третьим. Как выглядит их план на год, показано на рисунке.

РАССТАНОВКА ПРИОРИТЕТОВ

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

Разработчики не меняют ни объема работ, ни набора ресурсов, которые задействованы в их осуществлении, они просто одновременно выполняют все три задания. И в этом случае работа занимает чуть больше половины времени. Половины.

А другая половина? В нее входят чистые потери. Ничего больше не произведено. Ни одного доллара не сэкономлено. Не внедрено ни одной инновации. Пустая трата человеческой жизни. Тщетная работа.

Вот она, цена многозадачности. Мы все живем в мире, где к нашему времени предъявляются многочисленные требования. От нас все чего-то постоянно хотят: телефон, который разрывается от звонков; дети, вернувшиеся домой из школы; босс, приехавший на работу. И я тоже от вас кое-чего хочу. Чтобы вы осознали, наконец, цену переключения контекста. Это слишком важный фактор, чтобы его игнорировать. Вы обязаны постараться минимизировать свои затраты.

Если вы работаете над какой-то сложной задачей: составляете отчет; готовите презентацию; разрабатываете часть программы; пишете книгу — вам приходится держать в уме чрезвычайно сложный объект. Нужно учитывать десятки обстоятельств; помнить, что вы уже сделали; понимать, куда вам двигаться дальше; учитывать все трудности, с которыми вы можете столкнуться. Весьма непростая задача. Что происходит в том случае, если вас прерывают или вам приходится быстро переключаться на выполнение другой задачи — пусть даже на одну минуту? Вы угадали. Ваше тщательное построенное здание рушится. Теперь потребуются, может быть, часы работы лишь для того, чтобы вернуть себя в прежнее состояние сосредоточенности. Это тоже цена, которую мы платим. Поэтому настойчиво советую снова: минимизируйте потери, старайтесь выполнять за один раз только задачу, требующую особой концентрации. Выделите для нее определенные временные промежутки, когда вы сможете отключить телефон и повесить табличку «Не беспокоить».