12 вещей, которые убивают продуктивность разработчика

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

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

Итак, давайте изучим список из 12 вещей, которые мешают вашим разработчикам быть продуктивными. Не стесняйтесь комментировать!

 

1) Перерывы и митинги

На мой взгляд, перерывы в работе — главный фактор снижения производительности для разработчиков. Разработчики не могут легко вернуться к тому месту работы, где они были прямо перед перерывом. Они должны снова включаться, и затем медленно проследить туда, где они остановились. Это может легко занять более 30 минут. И чем больше перерывов, тем меньше качественной работы, тем больше ошибок — и это продолжается.

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

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

 

2) Микроуправление

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

 

3) Неопределенность

Есть много способов проиллюстрировать неопределенность. Сообщения об ошибках типа: «Это сломано, исправьте!» не дают достаточно информации, чтобы разработчики могли поработать над ними. Кстати, наличие шаблона отчета об ошибках может помочь в этом случае.

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

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

4) Менеджер-чайка

Это происходит, когда менеджеры совершенно не вовлечены в работу, но… они просто время от времени появляются, чтобы обгадить все. «Это неправильно, и это, и это выглядит плохо» и т.д., прежде чем снова улететь. К сожалению, это случается чаще, чем мы хотели бы. Такое поведение глубоко разочаровывает разработчиков; они не смогут включиться в работу в течение следующих нескольких часов, а иногда даже дней.

 

5) Недоверие

Был ли у вас когда-нибудь менеджер или другой разработчик, который взял на себя всю ответственность за работу, которую вы проделали в последние недели? Разработчики ценят компетентность превыше всего. Взять на себя ответственность за кого-то другого — это взять компетенцию другого за себя и отнять ее у него или нее. Это создает такое напряжение, что просто на некоторое время разрушает производительность разработчика.

6) Окружающая среда — шумы, движение, дизайн рабочего пространства…

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

Точно так же, если рабочее пространство спроектировано так, чтобы иметь как можно больше движения, это не поможет им сосредоточиться! Или ориентировать экраны настольных компьютеров таким образом, чтобы они были хорошо видны менеджерам… ну, это создает дополнительный стресс.

 

7) Неконтролируемые изменения

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

Она превращает относительно простые запросы в ужасно сложных и трудоемких монстров! И чаще всего это происходит во время разработки! Например, для простой функции:

 Версия 1 (до реализации): функция «Показать карту местоположения»

 Версия 2 (когда версия 1 почти закончена): функция изменена на «Показать 3D карту местности»

 Версия 3 (когда версия 2 почти закончена): функция снова изменилась на «Показать 3D-карту местоположения, через которое пользователь может пролететь»

 

8) Процесс определения продукта

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

 

9) Недостаток внимания к технической задолженности

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

 Но если рефакторинг никогда не входит в число приоритетов, это повлияет не только на производительность, но и на качество продукции.

 

10) Разнообразие инструментов и оборудование

Разработчики используют много инструментов для программирования каждый день. Чем больше автоматизации, тем лучше. Само собой разумеется, что если вы используете «древние» инструменты, это повлияет на вашу производительность. Аналогично, наличие большого экрана вместо только ноутбука может оказать влияние. Учитывая стоимость оборудования и зарплату разработчика, увеличение производительности всего на 5% определенно окупит любые инвестиции в этот момент! Просто дайте инструменты и оборудование, которые предпочитает ваша команда разработчиков.

 

11) Ненужные комментарии

Когда мы учились писать код, нам приходилось комментировать часто. Идея в том, что лучше много комментариев, чем слишком мало. К сожалению, многие программисты неверно интерпретируют это, и начинают комментировать каждую строку кода. Часто получается полно комментариев, описывающих, что делает код, и нет ни одного, объясняющего, почему он это делает. Если в программе была ошибка, и вы наткнулись на этот код, вы не знали бы, с чего начать.

 

12) Невозможно сжатые сроки

Это связано с тенденцией менеджеров запрашивать оценку времени у разработчиков, затем подталкивать их к максимально возможному снижению этих оценок, а затем волшебным образом считать их сроками! Менеджеры даже считают, что, поскольку сами разработчики «определились» с оценкой, они взяли на себя обязательства по срокам, и поэтому сроки должны считаться подходящими, чтобы их можно было передать высшему руководству.

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

 

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

Если вы узнаете некоторые моменты, упомянутые выше, в вашей компании, было бы интересно обсудить их с вашими разработчиками. Поговорите с ними; выясните, является ли это проблемой и как ее можно решить. Что бы они ни говорили, самое главное — доверять их отзывам и идеям. И хотя современные технологии сильно отличаются от того, что было 30 лет назад, урок все тот же. Вы не можете игнорировать человеческий фактор, если учитывать производительность команды. Улучшайте свои процессы, среду и рабочие привычки в вашей команде, и пусть они укажут вам, как добиться максимальной производительности.

 

Источник