«Пока не село Солнце»: Стоит ли заставлять программистов работать 80 часов в неделю

^[1]

/ фото Joshua Blount ^[2] CC ^[3]

В нашем блоге ^[4] на Хабре мы пишем о том, как используются облачные сервисы и каким спектром возможностей обладает ^[5] IaaS ^[6]. Также мы затрагиваем тему эффективной разработки сервисов и приложений, например, на прошлой неделе мы опубликовали материал ^[7], в котором дали несколько советов руководителям о том, как эффективно взаимодействовать с командой разработки.

Сегодня нам бы хотелось затронуть тему продолжительности рабочего дня. Один из пользователей социального сервиса Quora задал вопрос ^[8], который породил бурное обсуждение среди разработчиков. Он пытался выяснить, как заставить программистов оставаться в офисе 80 и более часов в неделю. Нас заинтересовала эта тема и мы решили посмотреть, что думают на этот счет сами разработчики.

Поверхностный взгляд

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

Низкая продуктивность разработчиков также связывалась с тем, что в команде нет сильного и авторитетного лидера, который воодушевляет ее своим примером. Решить проблему просто – нужно привлечь такого менеджера проектов, который бы разбирался в области программирования и заражал команду разработки энтузиазмом. Конечно, если руководство хочет, чтобы персонал работал по 80 часов в неделю, этот человек должен работать столько же, если не больше.

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

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

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

А если копнуть глубже?

Однако доля ответов, представленных выше, крайне мала. Большинство отвечающих программистов увидели в вопросе гораздо более глубокую подоплёку – проблему оценки труда и уважения подчиненных.

В основном люди заявляют, что программистам нет нужды работать по 60–80 часов в неделю для достижения оптимальной продуктивности. А все потому что продуктивность – не тождественна времени, проведенному в офисе. Программист может сидеть в офисе и 100 часов в неделю, но какой от этого толк, если больше половины времени он будет занят отвлеченной деятельностью, создавая иллюзию бурной деятельности?

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

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

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

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

На эту тему есть бородатый анекдот, которым поделился один из разработчиков, отвечавших на вопрос:

У мужчины была машина, и однажды она сломалась. Он пробовал чинить ее самостоятельно, но у него ничего не получилось. Он обращался к разным механикам, но ни один из них не преуспел. Но как-то раз один автослесарь вызвался починить авто, попросив за это в десять раз больше обычного. Мужчина согласился. Тогда механик взял гайку и, недолго думая, засунул ее куда-то под капот. Машина завелась.
– Это будет стоить 1000 долларов, – сказал механик.
– Вы шутите? Вы же работали всего три минуты! – возмутился мужчина.
На что автослесарь ответил:
– Мне достать гайку обратно?

Есть и другая вариация этой истории:

Одна женщина попросила Пикассо, тогда еще малоизвестного художника, нарисовать ее портрет. Мастер за 30 секунд набросал изображение. И сказал:
– Когда-нибудь этот шедевр будет стоить миллион долларов
– Шедевр? Вы потратили всего 30 секунд на написание, – удивилась женщина.
– Дорогая моя, я потратил 30 лет на то, чтобы научиться создавать шедевры за 30 секунд, – ответил Пикассо.

Чтобы набрать 80 часов, человеку придется работать по 12 часов практически каждый день. В неделе 168 часов. Из них 56 часов мы тратим на сон, 7 часов – на дорогу до работы, 80 – на работу, примерно 17 – на приготовление и потребление пищи, еще 7 часов уходит на домашние дела. Сколько времени остается на общение с семьей, занятия спортом, отдых, саморазвитие? 30 минут в неделю! 5 минут в день!

Технологический директор MD.com Брайан Фокс (Brian Fox) делится ^[8] своим горьким опытом: «Я работал на таких людей, которым не было дела до моей личной жизни. Когда я захотел уйти, они не понимали, почему я хочу это сделать, заверяли, что любят меня и предлагали увеличение вознаграждения и улучшение условий труда».

Да, в интернете полно историй разработчиков, которые в красках описывают длинные бессонные ночи и литры выпитого кофе. И они вполне себе правдивы. Вот только разработчики работали сверх нормы не постоянно, а в течение ограниченного промежутка времени.

Исследования показывают ^[9], что переработка оправдана в краткосрочных проектах. Однако после нескольких недель авральной работы, производительность сотрудников неминуемо снижается. Краткосрочный проект сравним со спринтом, в то время как обычная работа – с марафоном.

40-часовая рабочая неделя считается эталоном, потому что за 8 часов в день человек успевает выйти на свою пиковую производительность, но не успевает «выдохнуться». Пиковая производительность достигается примерно через 2 часа после начала рабочего дня – это время на «разгон».

За 2 часа до конца рабочего дня производительность падает, человек начинает отвлекаться, разговаривать с коллегами, строить планы на вечер. Таким образом, в день мы работаем примерно 4 часа, а не официальные 8.

Кроме того, количество несчастных случаев на производстве значительно возрастает ^[10], если рабочий день превышает 8 часов. Труд программиста нельзя назвать опасным, однако, работая сверхурочно каждую неделю, уставший сотрудник может попасть в аварию по дороге домой или другую неприятную ситуацию.

/ фото Nathan ^[11] CC ^[3]

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

Это приводит к появлению многочисленных ошибок в коде и багов в программе (разработчики заявляют, что количество багов увеличивается примерно в 2–3 раза, после продолжительного времени работы). Вряд ли работодателю будет выгодна такая ситуация, когда кроме оплаты сверхурочной работы придется оплатить и время на дебаггинг.

Так как можно поднять производительность, дабы закрывать проекты побыстрее, но не «сидеть на горбе» команды разработки? Выход есть – нанять больше разработчиков. Если вы хотите, чтобы программисты работали 80 часов в неделю, – увеличьте численность команды, работающей по 40 часов в неделю, вдвое.

Стоит присмотреться и к более опытным программистам, которые смогут сделать тот же объем работы, что и новички, но за меньшее время. В книге ^[12] The mythical Man-Month, описывающей разработку IBM OS/360, рассказывается, как компания отбирала разработчиков с производительностью в десять раз большей, чем у самых непродуктивных кадров.

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

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

Существует парадокс: если разработчик общается с руководством – он не работает, если разработчик просиживает штаны на совещании – он не работает, но, если он обсуждает вопросы программирования с коллегами – он работает.

Заключение

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

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

P.S. Интересные материалы из нашего блога:

• Облако IaaS в условиях гиперконвергированной инфраструктуры ^[13]
• Облако для тех, кто знает об облаках не понаслышке: использование IaaS компанией S7 Airlines ^[14]
• Обзор VM−инструментов VMware: разбираемся в особенностях ^[15]
• Как справиться с пиковыми нагрузками при помощи IaaS ^[16]
• Облачный кинотеатр: миграция инфраструктуры NETFLIX на IaaS в публичных облаках ^[17]

Автор: ИТ-ГРАД

Источник ^[18]