«Пока не село Солнце»: Стоит ли заставлять программистов работать 80 часов в неделю
/ фото Joshua Blount CC
В нашем блоге на Хабре мы пишем о том, как используются облачные сервисы и каким спектром возможностей обладает IaaS. Также мы затрагиваем тему эффективной разработки сервисов и приложений, например, на прошлой неделе мы опубликовали материал, в котором дали несколько советов руководителям о том, как эффективно взаимодействовать с командой разработки.
Сегодня нам бы хотелось затронуть тему продолжительности рабочего дня. Один из пользователей социального сервиса Quora задал вопрос, который породил бурное обсуждение среди разработчиков. Он пытался выяснить, как заставить программистов оставаться в офисе 80 и более часов в неделю. Нас заинтересовала эта тема и мы решили посмотреть, что думают на этот счет сами разработчики.
Люди, далекие от разработки программного обеспечения, дали автору вопроса стандартные советы по повышению мотивации сотрудников к сверхурочной работе. Менеджерам рекомендовали создать в офисе условия, которые программисты не захотели бы покидать: бесплатная еда, тренажеры, место для сна, душ, развлечения. По мнению участников обсуждения, такой подход особенно хорошо работает по отношению к программистам-холостякам, для которых жизнь в таком офисе будет привлекательней жизни дома.
Низкая продуктивность разработчиков также связывалась с тем, что в команде нет сильного и авторитетного лидера, который воодушевляет ее своим примером. Решить проблему просто — нужно привлечь такого менеджера проектов, который бы разбирался в области программирования и заражал команду разработки энтузиазмом. Конечно, если руководство хочет, чтобы персонал работал по 80 часов в неделю, этот человек должен работать столько же, если не больше.
Если компания практикует выплаты долевыми инструментами, то размер вознаграждения должен быть достойным — как минимум сопоставимым с зарплатой сотрудника. Но если руководство хочет добиться повышенной производительности, то и вознаграждение должно быть соответствующим — двойной, тройной, десятикратный размер зарплаты, в зависимости от способностей работника.
Многие отметили, что разработчик сам будет работать до изнеможения, если решает интересную проблему. Если проект нудный и рутинный, человека нужно лишь правильно замотивировать, представить скучное задание в другом свете — разработчик сам начнет выполнять его с бешеным рвением.
У сотрудника появляется внутренняя мотивация, если он осознает, что работает над общественно полезным проектом, например, над технологией диагностирования рака или системой распознавания отпечатков пальцев. В этом случае разработчику будет не нужна внешняя мотивация.
А если копнуть глубже?Однако доля ответов, представленных выше, крайне мала. Большинство отвечающих программистов увидели в вопросе гораздо более глубокую подоплёку — проблему оценки труда и уважения подчиненных.
В основном люди заявляют, что программистам нет нужды работать по 60–80 часов в неделю для достижения оптимальной продуктивности. А все потому что продуктивность — не тождественна времени, проведенному в офисе. Программист может сидеть в офисе и 100 часов в неделю, но какой от этого толк, если больше половины времени он будет занят отвлеченной деятельностью, создавая иллюзию бурной деятельности?
Если менеджер оценивает работу разработчика отработанными часами — он неопытен, а значит, его можно обмануть. Ушлый разработчик не откажется от предложения повременной работы, если знает, что может закончить проект гораздо быстрее регламентированных сроков.
Примечательно, что человек, несведущий в программировании, не отличит работающего программиста от притворяющегося таковым. То же самое касается оплаты за объем написанного кода — люди, далекие от разработки ПО, не знают, что даже самую простую операцию можно описать сколь угодно большим количеством строк.
Время работы программиста трудно поддается оценке. Он может просидеть весь день в интернете, потому что у него нет вдохновения, а вечером, моясь в душе, — придумать рабочий код. Вдохновение может прийти ночью в выходные, поэтому разработчику придется работать в свое личное время, которое работодатель вряд ли оплатит.
Также программисты жалуются, что руководство не способно адекватно оценить их труд. Менеджер может попросить добавить новую кнопку в приложении, не понимая, что за ней стоят сотни строк кода и часы работы. Если же программисту задача знакома, и он написал код за пару дней, опираясь на прошлый опыт, платить ему только за отработанное время — несправедливо и оскорбительно. Работодателям следует понять, что при оценке стоимости труда нужно учитывать не только время, проведенное в офисе, но также опыт и умения.
На эту тему есть бородатый анекдот, которым поделился один из разработчиков, отвечавших на вопрос:
У мужчины была машина, и однажды она сломалась. Он пробовал чинить ее самостоятельно, но у него ничего не получилось. Он обращался к разным механикам, но ни один из них не преуспел. Но как-то раз один автослесарь вызвался починить авто, попросив за это в десять раз больше обычного. Мужчина согласился. Тогда механик взял гайку и, недолго думая, засунул ее куда-то под капот. Машина завелась.
— Это будет стоить 1000 долларов, — сказал механик.
— Вы шутите? Вы же работали всего три минуты! — возмутился мужчина.
На что автослесарь ответил:
— Мне достать гайку обратно?
Есть и другая вариация этой истории:
Одна женщина попросила Пикассо, тогда еще малоизвестного художника, нарисовать ее портрет. Мастер за 30 секунд набросал изображение. И сказал:
— Когда-нибудь этот шедевр будет стоить миллион долларов
— Шедевр? Вы потратили всего 30 секунд на написание, — удивилась женщина.
— Дорогая моя, я потратил 30 лет на то, чтобы научиться создавать шедевры за 30 секунд, — ответил Пикассо.
Чтобы набрать 80 часов, человеку придется работать по 12 часов практически каждый день. В неделе 168 часов. Из них 56 часов мы тратим на сон, 7 часов — на дорогу до работы, 80 — на работу, примерно 17 — на приготовление и потребление пищи, еще 7 часов уходит на домашние дела. Сколько времени остается на общение с семьей, занятия спортом, отдых, саморазвитие? 30 минут в неделю! 5 минут в день!
Технологический директор MD.com Брайан Фокс (Brian Fox) делится своим горьким опытом: «Я работал на таких людей, которым не было дела до моей личной жизни. Когда я захотел уйти, они не понимали, почему я хочу это сделать, заверяли, что любят меня и предлагали увеличение вознаграждения и улучшение условий труда».
Да, в интернете полно историй разработчиков, которые в красках описывают длинные бессонные ночи и литры выпитого кофе. И они вполне себе правдивы. Вот только разработчики работали сверх нормы не постоянно, а в течение ограниченного промежутка времени.
Исследования показывают, что переработка оправдана в краткосрочных проектах. Однако после нескольких недель авральной работы, производительность сотрудников неминуемо снижается. Краткосрочный проект сравним со спринтом, в то время как обычная работа — с марафоном.
40-часовая рабочая неделя считается эталоном, потому что за 8 часов в день человек успевает выйти на свою пиковую производительность, но не успевает «выдохнуться». Пиковая производительность достигается примерно через 2 часа после начала рабочего дня — это время на «разгон».
За 2 часа до конца рабочего дня производительность падает, человек начинает отвлекаться, разговаривать с коллегами, строить планы на вечер. Таким образом, в день мы работаем примерно 4 часа, а не официальные 8.
Кроме того, количество несчастных случаев на производстве значительно возрастает, если рабочий день превышает 8 часов. Труд программиста нельзя назвать опасным, однако, работая сверхурочно каждую неделю, уставший сотрудник может попасть в аварию по дороге домой или другую неприятную ситуацию.
/ фото Nathan CC
Программирование — это творческая и в то же время монотонная и изматывающая работа, а отсутствие отдыха убивает креативность в человеке. Уставший разработчик начинает дольше вспоминать названия функций, становится рассеянным, ему сложнее принимать технические решения.
Это приводит к появлению многочисленных ошибок в коде и багов в программе (разработчики заявляют, что количество багов увеличивается примерно в 2–3 раза, после продолжительного времени работы). Вряд ли работодателю будет выгодна такая ситуация, когда кроме оплаты сверхурочной работы придется оплатить и время на дебаггинг.
Так как можно поднять производительность, дабы закрывать проекты побыстрее, но не «сидеть на горбе» команды разработки? Выход есть — нанять больше разработчиков. Если вы хотите, чтобы программисты работали 80 часов в неделю, — увеличьте численность команды, работающей по 40 часов в неделю, вдвое.
Стоит присмотреться и к более опытным программистам, которые смогут сделать тот же объем работы, что и новички, но за меньшее время. В книге The mythical Man-Month, описывающей разработку IBM OS/360, рассказывается, как компания отбирала разработчиков с производительностью в десять раз большей, чем у самых непродуктивных кадров.
Надо учесть, что при найме программистов обязательно должен присутствовать человек, способный оценить их навыки, которые не зависят от таких факторов, как внешний вид человека и название законченного им учебного заведения.
Выделите в деятельности программиста основные и второстепенные задачи, чтобы он мог сконцентрироваться на первых. Избавьте команду разработки от микроменеджмента и сведите длительность бизнес-ритуалов (собраний, совещаний, отчетов) к минимуму.
Существует парадокс: если разработчик общается с руководством — он не работает, если разработчик просиживает штаны на совещании — он не работает, но, если он обсуждает вопросы программирования с коллегами — он работает.
ЗаключениеВажно помнить, что разработчики приложений — это категория работников, к которым нужен особый подход. Не стоит заставлять их работать сверхурочно постоянно — это создаст лишь иллюзию продуктивной деятельности. Впрочем, такое утверждение справедливо и по отношению к другим профессиям.
Менеджерам следует понять, что их подчиненные — тоже люди со своими проблемами, желаниями, семьями и друзьями. Создание в организации доверительной дружеской атмосферы при грамотном подборе кадров и наличии достойной цели решит большую часть проблем компании (зависящих от внутренней среды), в том числе проблему производительности труда.
P.S. Интересные материалы из нашего блога:
- Облако IaaS в условиях гиперконвергированной инфраструктуры
- Облако для тех, кто знает об облаках не понаслышке: использование IaaS компанией S7 Airlines
- Обзор VM−инструментов VMware: разбираемся в особенностях
- Как справиться с пиковыми нагрузками при помощи IaaS
- Облачный кинотеатр: миграция инфраструктуры NETFLIX на IaaS в публичных облаках
