Прерывания и встречи

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

«Чем чаще вы меня отвлекаете перед тем, как я начинаю работать — тем больше времени мне нужно, чтобы сосредоточиться. Если вы заполните мое утро ненужными мне перерывами, потом не удивляйтесь, что день выдастся непродуктивным», — разработчик с Reddit.

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

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

Микроменеджмент

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

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

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

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

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

Чайка-менеджмент

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

Присвоение чужих заслуг

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

Изменение масштабов

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

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

 

Неправильная постановка целей

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

Нехватка внимания к техническому долгу

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

Плохое качество инструментов

Разработчики используют множество инструментов для программирования — чем больше автоматизации, тем лучше. Очевидно, что если вы используете «древние» инструменты, это будет ухудшать вашу производительность. Точно так же выбор ноутбука или ПК влияет на конечный результат (для всех по-разному).

Повышение производительности разработчика всего на 5% стоит того, чтобы в него инвестировать. Поэтому предоставьте ему инструменты и оборудование, которые он предпочитает.

Неправильные комментарии к коду

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

r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

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

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

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

Ранее AIN.UA приводил материал о десяти стратегических трендов развития технологий в 2019 году.