Управление проектами - Рейнджеры и солдаты: о подчинении в софтверной индустрии

Успешная человеческая многозадачность в софтверной разработке

&= nbsp;

УПРАВЛЕНИЕ ПРОЕКТАМИ № 2(19) - 20= 10

Виталий Цыбульник, к.ф.-м.н., Microsoft Corp.

Частое переключение между задачами принято рассматривать в науке управления проектами как исключительно негативный подход. Однако бизнес-модель софтверной разработки иногда требует прогресса в выполнении нескольких задач параллельно, чего можно достичь только частым переключением между ними. В статье автор делится собственным опытом и разработанными на его основании правилами, позволяющими эффективно работать над несколькими задачами одновременно. Соблюдение изложенных правил позволяет с большой вероятностью избежать падения продуктивности при многозадачной работе, = а в некоторых случаях даже добиться некоторого роста суммарной продуктивнос= ти.

&nbs= p;

Пожалуй, у каждого разр= аботчика хотябы раз в карьере возникала необходимость работы над несколькими задач= ами параллельно. Это как правило происходит по двум причинам: (а) задачи не рассчитаны на то, чтобы занимать всё рабочее время, но тем не менее не мо= гут быть выполнены "раз и навсегда", а должны выполняться постепенн= о, втечение более долгого интервала времени; (б) число высокоприоритетных за= дач превышает число сотрудников. Примеры задач класса (а) применительно к софтверной разработке: ревью кода, отчёт о проделанной за день работе, ежедневный митинг и т.п. Многозадачная работа такого класса как правило не вызывает больших проблем до тех пор, пока количество таких задач помещать= ся в рабочий день и несущественно отвлекает от основной задачи.

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

К сожалению, ни одна из существующих методологий софтверной разработки не подразумевает возможнос= ть параллельной работы над несколькими задачами, даже гибкие методики (Scrum, XP) не исключение. Происходит это потому, что, как известно из опыта и литературы, переключение между задачами не только отнимает время, необход= имое для того, чтобы вспомнить тебования, степень готовности задачи и детали реализации, но и пагубно сказывается на так называемом "потоке мышления", который прерывается при любом переключении внимания (в том числе и при переходе на другую задачу) и затем требует до 15 минут или да= же больше на восстановление. Руководитель, попавший в условия неизбежности параллельной работы, должен взять на себя смелость отказаться или отложить один из проектов. Однако такое решение может быть сопряжено с существенны= ми финансовыми потерями в виде утраты перспективного заказчика или затрат на простои команды после окончания одного проекта и ожидания следующего, кот= орые в сумме могут превосходить предполагаемую потерю производительности. Поэт= ому руководители всё-таки решаются на многозадачную работу команды или отдель= ных разработчиков, и это даже иногда превращается в своеобразный бизнес само = по себе, когда рабочее время разработчиков может быть "продано" ср= азу нескольким заказчикам.

В моей профессиональной практике бывали периоды, когда от меня или от отдельных членов моей коман= ды требовалось работа над 3-мя или даже более проектами одновременно. Согласно общеприня= тому мнению, продуктивность в такой ситуации должна была быть мизерной. Однако= в моём случае, сравнивая суммарную продуктивность в эти периоды и в периоды "затишья" (работа над одной областью задач в течение недели или более), я каждый раз с удивлением обнаруживал, что суммарная продуктивнос= ть в периоды параллельной работы оказывалась даже несколько выше! Исследуя этот феномен, я заметил, что в контексте многозадачности существует два типа разработчиков. Для одного из них переключение между задачами действительно является слишком большой нагрузкой и оказывается губительным для производительности. Другой же тип как раз наоборот предпочитает работать = над несколькими разнородными задачами или проектами, переключаясь между ними, нежели работать долгое время над одной задачей/проектом. Как правило, объяснение сводится к тому, что долгая работа над одной задачей быстро становится скучным, утомительным занятием, и продуктивность резко падает,= в то время как возможность переключения на другую задачу позволяет прогнать скуку и быстро отдохнуть от первой задачи.

Спустя некоторое время наблюдения за собой и своими командами, я пришёл к выводу, что "природная предрасположенность" не единственный фактор, влияющи= й на способность к параллельному выполнению задач. Мой опыт показывает, что им= ея крепкие нервы и хорошую мотивацию, и соблюдая ряд довольно простых правил, такого эффекта может добиться практически каждый, а регулярное переключен= ие между выполняемыми задачами может быть не только не вредным для продуктивности разработчика, но иногда даже полезным. Этот эффект можно стравнить с принципом суперсетов, известным среди спортсменов по отношению к мышечной усталости. Принцип этот заключается в том, что переключение нагрузки на другую группу мышц позволяет быстрее восстановиться, чем при обычном отды= хе, т.к. такое переключение уводит "центр усталости" в другое место, что значительно быстрее, чем просто ждать затухания этого центра со време= нем.

Осталось только сформул= ировать правила, позволяющие избежать падения продуктивности при таком переключен= иию Эти правила - общий итог моего собственного более чем пятилетнего опыта многозадачной работы над софтверными проектами, а также результат моих на= блюдений над многозадачной работой почти двух десятков других разработчиков, состоявших в разное время в моих командах:

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

2. Не прерывайте поток мышления. Идея этого правила в том, что у мозга есть периоды "просветления", когда решение задачи складывается в единое цело= е. Если разработчика прервали во время этого периода срочным вопросом или задачей - скорее всего его работа будет отброшена на пол часа назад. Дайте разработчику самому решать когда прерваться, это наступит достаточно скор= о, т.к. после периода просветления всегда наступает период отдыха. Не звоните разработчикам когда они заняты задачей и не прерывайте их личным разговор= ом, напишите лучше письмо с пометкой "срочно" или оставьте сообщение иного рода, которое будет прочитано во время периода отдыха. <= /span>

3. Не навязывайте слишк= ом жёстко порядок или время выполнения задач. Если вам нужно, чтобы нескольно задач было сделано - дайте возможность выбрать к какой из них "лежит душа" именно сегодня и именно сейчас. Если речь идёт о прогрессе в нескольких проектах одновременно - не пытайтесь достичь прогресса в каждо= м из них каждый день, задайте интервал в 2-3 дня, чтобы у разработчика по ходу была возможность решить: разделить ли какой-то день между проектами/задач= ами или посвятить целиком одному проекту/задаче. Помните, что очень многое в вопросе эффективности зависит не только от сложности и специфики задачи, = но и от настроения (физического и духовного состояния).

4. Минимизируйте давлен= ие и бюрократию. Не терроризируйте разработчика частыми вопросами о том, как и= дут дела, скорее всего это его будет только раздражать и отвлекать. Действуйте как в правиле 1 - дайте ему самому решить когда наступил удачный момент сообщить о своём прогрессе. По максимуму избавьте такого загруженного разработчика от бюрократии вроде детальных отчётов или двухчасовых команд= ных митингов. В вялотекущих проектах это всё необходимо, чтобы держать руку на пульсе прогресса и направлять поток разработки в нужное русло, но для разработчика в режиме многозадачности это менее актуально: его задачи как правило более ясны и обозримы, его сложность другого рода - работать над этими задачами параллельно. Даже если вы работаете по гибкому процессу ти= па Scrum, ежедневный stand-up митинг лучше проводить до начала работы или, например, сразу после обеда, чтобы минимально отвлекать команду.

5. Повышайте нагрузку постепенно. Не бросайте разработчика сразу на 3 проекта. Дайте ему один, через две недели ещё один. Выделите время настроиться и подрегулировать с= вой ритм.

6. Давайте разработчика= м отдых. Периоды многозадачной работы могут быть интереснее и результативнее размеренной работы над одной задачей, но они отнимают значитально больше ментальной и физической энергии, поэтому многозадачный режим не должен бы= ть перманентным. 2-3 недели "отдыха" раз в 3-4 месяца (в виде одной низкоприоритетной задачи) - хороший способ не "сгореть на работе&quo= t; и не "загнать лошадь". Уделите внимание поддержанию боевого духа в виде командных вечеринок и походов на пиво раз в несколько недель - это о= чень морально заряжает работников. Полностью исключите сверхурочные - вам нужен бодрый и полный сил работник.

Ну и последнее, пожалуй= самое важное: эти правила работают для меня и ещё многих разработчиков, однако = не рассчитывайте, что они работают всегда и для всех. Принцип суперсетов хор= ош для выносливого, тренированного атлета в отличной физической и психологической форме. Этот принцип категорически неприменим к новичкам и людям со слабым здоровьем. Но даже отличная форма и богатырское здоровье = ещё не есть гарантия успеха. Есть люди, которым это просто не подходит.

&= nbsp;