Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Применение принципа суперсетов к Software Development'у

Общеизвестно из литературы, что переключение между задачами не только отнимает время, необходимое для того, чтобы вспомнить тебования, степень готовности задачи и детали реализации, но и пагубно сказывается на так называемом "потоке мышления", который прерывается при любом переключении внимания (в том числе и при переходе на другую задачу) и затем требует от 15 до 30 минут на восстановление. Исследования показывают, что, отвлекая разработчика каждые 15 минут, его продуктивность можно свести к нулю.

Однако суровая правда жизни заключается в том, что очень часто бизнес диктует разработчику острую необходимость именно параллельного выполнения нескольких задач или как минимум регулярного переключения между задачами. В моей профессиональной практике бывали периоды, когда от меня требовалось работа над более чем 5 проектами одновременно, т.е. прогресс по каждому из проектов дожен был быть виден не реже, чем раз в два дня. Согласно общепринятому мнению, моя продуктивность в такие периоды должна была быть мизерной. Однако она была далека от мизерной. Более того, сравнивая мою суммарную продуктивность в эти периоды и в периоды "затишья" (работа над одной областью задач в течение недели или более), я каждый раз с удивлением обнаруживал, что суммарная продуктивность в периоды параллельной работы оказывалась даже несколько выше! Долгое время я приписывал этот эффект к своей "уникальности", т.к. для других разработчиков переключение между задачами действительно оказывалось губительным.

Однако со временем я начал встречать других девелоперов, которые предпочитали работать над несколькими разнородными задачами или проектами, переключаясь между ними, нежели работать долгое время над одной задачей/проектом. Как правило, объяснение сводилось к тому, что долгая работа над одной задачей быстро становится скучным, утомительным занятием, и продуктивность резко падает, в то время как возможность переключения на другую задачу позволяет прогнать скуку и быстро отдохнуть от первой задачи. Крайнее проявление этого эффекта общеизвестно: засадите своих разработчиков за выполнение одноообразных (пусть даже и кажущихся поначалу интересных) задач одного и того же долгоиграющего проекта - и на втором году такой работы от вас сбежит 90% команды.

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

Осталось только сформулировать те правила, которые позволят избежать падения продуктивности при таком переключении:

1. Не прерывайте поток мышления. Идея этого правила в том, что у мозга разработчика есть периоды "просветления", когда решение задачи складывается в единое целое. Прервите разработчика во время этого периода срочным вопросом или задачей - и скорее всего вы отбросите его работу на пару часов назад. Дайте ему возможность самому решать когда прерваться, это наступит достаточно скоро, т.к. после периода просветления всегда наступает период отдыха. Говоря проще, не звоните разработчику когда он занят задачей и не прерывайте его личным разговором, напишите ему письмо с пометкой "срочно" или оставьте сообщение иного рода. Во время периода отдыха он сам полезет проверять почту.

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

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

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

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


Categories: Management
Posted by Vitalii Tsybulnyk on Friday, July 10, 2009 4:09 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Comments (1) -

Vitaliy Pogosyan Russia

Wednesday, July 15, 2009 7:04 PM

Согласен.

Год назад на мне весело 7 разных проектов. Над ними работал не только я. Штат у нас большой. Но в каждом немалая часть моя. Тестеры и заказчики регулярно подкидывали новых задач и ошибок. На моё удивление, разнообразие задач и проектов давало дополнительный импульс, задачи щелкались как орешки. Не все, конечно. Если задача была сложной, я разбивал её на подзадачи и, таким образом, расставлял кейпоинты чтоли. И дойдя до ключевой точки в решении задачи, мог переключиться на другую задачу. Вывод мой такой. За неделю можно сделать 2 задачи последовательно. А можно без потери времени сделать 5-10 параллельно. В определенном состоянии я решаю одни задачи (или хочу решать),в другом - решаю какие-то другие задачи.

Add comment




  Country flag

b i u quote
Loading