Автор материала: Джон Лафлер, соучредитель Anaxi 

Предприниматель Джон Лафлер в своей колонке на Medium рассказал о вещах, которые больше всего раздражают разработчиков и мешают им продуктивно работать.

1. Отвлечения и совещания

Отвлечение – самый главный убийца продуктивности у разработчиков. Программистам непросто вернуться к работе после того, как их кто-то прервал. Чтобы войти обратно в ритм, им может понадобиться около 30 минут.

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

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

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

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

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

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

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

Слышали о таком? Чайка-менеджмент – это стиль управления, при котором менеджеры внезапно налетают на объект, поднимают много шума, а затем улетают, и остальные должны разобраться с беспорядком. Такое поведения убивают разработчиков.

5. Воровство чужих заслуг

Вы знаете менеджеров или разработчиков, которые присваивают себе заслуги других? Программисты прежде всего ценят компетентность. Брать на себя чужие заслуги – то же самое, что отнимать чью-то компетентность. 

6. Шум и движение

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

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

7.  Постоянные правки

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

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

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

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

8. Добавление ненужных функций в продукт

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

9.  Спешка

Спешка– намеренное решение внедрить не лучшую программу или написать не лучший код, чтобы побыстрее выпустить ПО. Часто, спешка просто неизбежна, и в краткосрочной перспективе это может увеличить скорость разработки. В долгосрочной перспективе это приводит к сложности системы, которая замедляет программистов. Многие недооценивают потерю продуктивности и стремятся всегда двигаться вперед, и это проблема.

10. Инструменты и железо

Разработчики используют множество инструментов для написания кода. Чем больше автоматизации, тем лучше. Очевидно, если вы будете использовать древние инструменты, вы будете работать менее продуктивно. То же самое можно сказать и об аппаратуре. 

11. Неясные комментарии

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

12. Вынуждение дедлайны

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