Заблуждения о программировании II
Один из организационных стереотипов - большая комната, полная кабинок, заполненных сотрудниками. Даже если программисты могут работать в таких условиях, неправильно спроектированная среда в определенной степени ограничивает творчество и производительность, затрудняя сотрудничество и общение сотрудников. Несмотря на наличие выделенных конференц-залов, важная часть общения происходит спонтанно. На открытых пространствах каждое временное прерывание может легко привести к непреднамеренной потере концентрации, что приводит к потере времени, так как нужно пересматривать цепочку мыслей и просматривать последний написанный код, а иногда и к ошибкам.
Ожидается, что программированием будет работа с 9 до 5 с эффективным рабочим временем 8 часов. За вычетом перерывов, необходимых пауз, эффективное рабочее время снижается примерно до 6 часов. Другими словами, чтобы достичь 8 часов эффективной продуктивности, нужно работать около 10 часов. Поэтому, если не спланировано должным образом, каждый проект начинается с 20% сверхурочных. Более того, даже если задача запланирована на 8 часов, с учетом потребности в информации выделенное время делится на несколько дней. Чем выше потребность в дополнительных разъяснениях, тем выше шансы расширения усилий. В крайнем случае, усилия могут удвоиться.
Длительное время, проведенное за компьютером, может отрицательно сказаться на физическом и психическом здоровье программистов. Тот же эффект имеет нехватка времени и некоторые из негативного поведения, которое имеет место в рабочей среде. Кроме того, коммуникативные навыки могут пострадать, если им не уделить должного внимания. К сожалению, немногие организации придают значение этим аспектам, немногие предлагают баланс свободного времени, даже если работа программиста подходит лучше всего и требует такого подхода. Еще более прискорбно, когда организации игнорируют сверхурочную работу, считая ее частью описания работы. Это также одна из основных причин ухода программистов, потери компетентной рабочей силы. В конце концов, всех можно заменить, но какова цена за это?
Тренинги обычно предлагаются в рамках действующих проектов, так как за них легко выставить счет. Помимо того факта, что такое поведение без необходимости отнимает время от графика проекта, оно может легко сделать обучение неэффективным, когда программисты не могут сразу использовать новые знания. Более того, с учетом ресурсов, которые приходят и уходят, нежелание вкладывать средства в программистов может иметь неисчислимые последствия для производительности организации и, соответственно, для их личного развития.
Организации обычно ищут самомотивированные ресурсы, и этот запрос часто охватывает всю мотивационную стратегию организации. Длинные проекты похожи на марафон, в котором сложно выдержать один и тот же ритм на протяжении всего проекта. Менеджеры и руководители команд должны работать над мотивацией программистов, если им нужна стабильная производительность. Они должны действовать как наставники и лидеры в целом, а не только контролировать статус задач и бушевать каждый раз, когда происходят отклонения. Легко пожаловаться на статус-кво, ничего не предпринимая для решения существующих проблем (проблем).
Программисты считают, что особенно в неблагополучных командах, руководство не может внести большой вклад в технические аспекты проекта, в то время как руководство видит мало или совсем нет пользы от включения разработчиков в процесс принятия решений по проекту. Более того, отсутствие прозрачности и общения приводит к широкому спектру трений между различными сторонами.
Вероятно, наиболее трудным для понимания является упрямство людей, ожидающих различного поведения, следуя одним и тем же методам и игнорируя здравый смысл. Поразительно, с какой легкостью люди игнорируют технологические принципы и передовые методы управления проектами. В человеческой природе заложено упорство усердного обучения, несмотря на предупреждения опытных людей, однако, несмотря на негативные последствия, зачастую процесс обучения минимален.
См. также:
Заблуждения о программировании: Часть I
Темная сторона программирования
® Изначально опубликовано на sql-Trouble
