Сколько часов в неделю в долгосрочной перспективе должен работать разработчик программного обеспечения, чтобы добиться максимальной производительности? [закрыто]

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

Сколько часов ТИПИЧНЫЙ разработчик программного обеспечения должен работать в ДОЛГОСРОЧНОМ СРОКЕ, чтобы максимизировать свою ОБЩУЮ производительность?

Обратите внимание, что я говорю о разработчике программного обеспечения, занимающемся разработкой программного обеспечения. Кажется, я помню книгу Стива МакКоннелла, где он на самом деле приводит цифру из опубликованных исследований, но мне придется поискать ее. И я уверен, что есть и другие. Я надеюсь, что с помощью «краудсорсинга» на этот вопрос я получу более полный ответ.

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

Следует иметь в виду, что результат любого исследования в литературе всегда будет относиться к совокупности рабочих , а не к конкретным лицам. Кроме того, здесь есть сложные соображения, такие как, сколько часов «оплачивается», сколько потрачено на администрирование и сколько времени простоя.
Этот вопрос, вероятно, лучше подходит для персональной производительности SE.
Я думаю, вы близки к упрощению проблемы. Производительность человека зависит от множества параметров, часы, проведенные за клавиатурой, — лишь один из них.

Ответы (2)

Перерывы

  • Прежде чем думать о продолжительности рабочего дня, вы должны расставить приоритеты в перерывах. Для того, чтобы мозг был в хорошем рабочем состоянии, следует делать два 15-минутных перерыва утром и вечером и получасовой-часовой перерыв на обед. Это должно привести не только к перезарядке вашего мозга, но и к общению с коллегами, что является ключевым компонентом успешного рабочего места.

Часы

  • Когда я работаю, я стараюсь ограничивать себя не временем, а продуктивностью проекта. В начале каждого дня (а иногда и в конце предыдущего дня) я записываю, что мне нужно сделать на следующий день. Это происходит из моего еженедельного плана проекта, а иногда и из моего ежемесячного плана проекта. Вам определенно следует ограничить себя 10 часами в день (включая перерывы), если вы не можете закончить свои выполненные задачи раньше. Если вы в конечном итоге закончите их до 8 часов, возможно, найдите что-нибудь небольшое.
  • Опасность работы «ежечасно» заключается в том, что ваш мозг будет постоянно думать о времени и часах. На самом деле полезнее для здоровья, если у вас есть несколько часов каждый день. Если вы установите ограничение на 8-10 часов, ваш мозг будет работать быстрее и продуктивнее. Если вы говорите себе, что вам нужно работать по 10 часов в день каждый день, то в долгосрочной перспективе вы действительно не добьетесь ничего продуктивного. Если вы ограничите себя проектами и рабочей нагрузкой, то обнаружите, что уровень вашей продуктивности повысится.

Политика компании

  • Убедитесь, что вы понимаете политику компании в отношении изменчивого графика работы.
«Опасность работы «по часам» заключается в том, что ваш мозг будет постоянно думать о времени и часах»: в теории это звучит хорошо, но на практике людям есть где находиться в определенное время. Как бы это повлияло на вашу домашнюю жизнь, если бы вы всегда приходили домой в разное время.

У меня нет точного часа, и я не знаю ни одного исследования, которое изучало бы это, но у меня есть некоторые предложения о том, что для этого потребуется.

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

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

Принятие риска Каждый проект имеет определенный уровень риска. Если это означает разницу между первым выходом на рынок или достижением крупного клиента, компании предпочтут просто пойти на это. Речь идет о долгосрочных последствиях, но, к сожалению, немногие менеджеры могут думать дальше текущей чрезвычайной ситуации. Все «чрезвычайные ситуации» складываются, и, прежде чем вы это узнаете, персонал уйдет или, что еще хуже, сгорит. Близорукий менеджер узнает об этом последним.

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

Сколько часов в неделю в долгосрочной перспективе должен работать разработчик программного обеспечения, чтобы добиться максимальной производительности? [закрыто]
СпросиСетьПолитика конфиденциальности1y, 0v