Продуктивность программиста – отвлечение от работы, совещания и удаленная работа

The_Park_Northpoint_-_Open_Plan_Office_Space

В моем предыдущем посте о том, чего хотят программисты, я поместил работу на дому в конце списка. Некоторые комментаторы оценили удаленную работу выше, а K (имя вымышленное) даже прислал ссылку на отличное видео с конференции TED от Джейсона Фрида (из 37signals) на тему, почему на работе тяжело заниматься работой. Вначале Джейсон делится своими наблюдениями о том, что для выполнения работы программисту необходимо в течение длительного времени не отвлекаться, после чего автор рекомендует избегать совещаний и минимизировать отвлекающие факторы, используя чат и имейл, вместо прямого общения. Несмотря на то, что я согласен с частью, касающейся совещаний, я готов поспорить насчет отвлекающих факторов. Кроме того, я ценю общение лицом к лицу больше, чем он.

ВЗАИМОДЕЙСТВИЕ В ОФИСЕ

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

Джейсон рекомендует переходить от активного взаимодействия (лицом к лицу или по телефону) к пассивному (имейл или чат), чтобы не отвлекать людей от работы. Этот совет хорош, чтобы исключить отвлекающие факторы. Но после первого вопроса, чем быстрее вы перейдете к разговору, тем лучше. Письменное общение подходит для простых вопросов и ответов. Однако, разговор с кем-либо как минимум на порядок эффективнее в случаях, когда между вами присутствует хоть капля недопонимания или двусмысленности. Например, если я получу письмо с вопросом «Мы поддерживаем функцию XXX?», ответ в большинстве случаев не будет простым «да» или «нет». Возможно, ответ будет зависеть от того, какой функционал уже есть у пользователя. Либо мы могли только что разработать более эффективную функцию YYY, которую они смогут использовать вместо XXX. Чтобы записать всё это, придется потратить некоторое количество времени и сил. В свою очередь, разговор (лицом к лицу или по телефону) позволяет мгновенно получать обратную связь, вместо письменного растекания мыслью по древу.

ПОЛЕЗНЫЕ ОТВЛЕКАЮЩИЕ ФАКТОРЫ

Несмотря на то, что я полностью согласен с Джейсоном в том, что для достижения продуктивности программисты подолгу не должны ни на что отвлекаться, существуют случаи, когда к отвлекающим фактором следует относиться с пониманием. Если кто-то работает над решением проблемы (тестировщик, инженер поддержки или другой разработчик), и у него возникает вопрос, на который я знаю ответ — я не буду против, если меня отвлекут. Конечно, это слегка ударит по моей продуктивности, но нам следует повышать эффективность всей компании, а не только мою. Если один (или несколько) сотрудников компании застрянут над какой-то задачей, то им лучше спросить моей помощи и получить ответ за минуту, чем искать ответ в коде или в документации.

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

СОВЕЩАНИЯ — НЕЭФФЕКТИВНОЕ РАСХОДОВАНИЕ ВРЕМЕНИ

Что касается совещаний, тут я согласен с Джейсоном: чем их меньше, тем лучше. Очень часто это — пустая трата времени. Когда я работал в Ericsson, у нас была еженедельная планерка для отдела исследований и разработки, которая проходила по вторникам в 10 утра. Поэтому в 9:30 у тебя не было никакого желания заняться чем-то новым, поскольку ты знал, что тебя отвлекут. Осознание того, что скоро придется идти на совещание, ведет к уменьшению выполненной работы. Если же ты отвлекаешься незапланированно, то, по крайней мере, ты не знаешь об этом заранее. Еще одной из проблем планерок было то, что, по большому счету, вся сообщаемая на них информация могла быть с легкостью передана по имейлу.

Кроме того, совещания неэффективны еще и потому, что очень часто присутствующие на них люди не нужны в течение всего совещания, поэтому их время тратится впустую. В компании Symsoft у меня было очень мало совещаний. Вместо созыва сотрудников на совещания, я просто подходил к необходимым людям (все разработчики находились не далее, чем в 5 офисах от меня) и обсуждал с ними возникший вопрос. Никаких планерок, и отвлекать приходилось только людей, имеющих непосредственное отношение к делу. Что гораздо лучше, чем неэффективные совещания.

ЭТО НЕ ТАК ТЯЖЕЛО

Рабочее место, описанное Джейсоном, выглядит довольно мрачным. Но это не значит, что так будет везде. Я никогда не работал с менеджером, который бы часто подходил ко мне, интересуясь состоянием проекта, возможно потому, что все они тоже были программистами, и знали, что отвлекать людей — плохо. Когда я работал в Symsoft, у меня почти не было планерок. То же самое я могу сказать и о своей работе в Tilgin. Создать подходящую среду для разработчика ПО не так сложно. Меня тоже отвлекают, но практически всегда — по соответствующим причинам. Я становлюсь менее продуктивным, но мы становимся продуктивнее. И у меня остается еще уйма времени для тихой, спокойной разработки новых функций и устранения багов. А у вас?

Оригинал


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

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

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

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>