1. Отвлечения и совещания
Отвлечение – самый главный убийца продуктивности у разработчиков. Программистам непросто вернуться к работе после того, как их кто-то прервал. Чтобы войти обратно в ритм, им может понадобиться около 30 минут.
А что насчет совещаний? Единственная разница между совещанием и отвлечением заключается в том, что совещание – запланированное отвлечение, и это еще хуже. Разработчики не могут работать над задачей, зная, что их вскоре отвлекут от нее.
Как этого избежать? Проводите короткие собрания в начале дня или перед обедом.
Фото: Unsplash
2. Микроменеджмент
Микроменеджеры – худшие менеджеры для программистов. Конечно, они любят проводить ненужные совещания и отвлекать от работы. Но они делают не только это. Они не доверяют сотрудникам и постоянно ставят под сомнение их навыки и способности выполнять задачи. Такое поведение убивает мотивацию разработчиков. Кроме того, микроменеджеры могут быть первой причиной, почему программисты захотят уйти из компании.
3. Неопределенность
Сообщения вроде «Программа сломалась, почини ее!» не предоставляют разработчикам достаточно информации для работы. К категории неопределенности также можно отнести нечеткую спецификацию функции и неясную приоритизацию. Все эти ошибки отнимают у программистов время, а этого можно легко избежать.
4. Чайка-менеджмент
Слышали о таком? Чайка-менеджмент – это стиль управления, при котором менеджеры внезапно налетают на объект, поднимают много шума, а затем улетают, и остальные должны разобраться с беспорядком. Такое поведения огорчает разработчиков; после погрома они не смогут вернуться к работе несколько часов, а то и несколько дней.
Фото: Unsplash
5. Воровство чужих заслуг
Вы знаете менеджеров или разработчиков, которые присваивают себе заслуги других? Программисты прежде всего ценят компетентность. Брать на себя чужие заслуги – то же самое, что отнимать чью-то компетентность. Это очень злит разработчиков и убивает на некоторое время их продуктивность.
6. Среда – шум, движение, дизайн офиса
Среда, в которой вынуждены работать разработчики, оказывает огромное влияние на их производительность. Например, белый шум – машины за окном – помогают им лучше сконцентрироваться.
Если же рабочее пространство спроектировано таким образом, что в нем чересчур много движения, программисты не смогут сфокусироваться. Они также не смогут нормально работать, если их компьютеры будут видны начальнику.
7. Неконтролируемое изменение области работ (англ. – Scope creep)
Scope creep – это неконтролируемое разрастание границ проекта, приводящее к срыву сроков, перерасходу бюджета или снижению качества.
Относительно простой запрос превращается в ужасно сложного и времязатратного монстра. И все это зачастую происходит уже во время разработки! Например:
- Версия 1 (до имплементации): функция: «Показывать карту местоположения».
- Версия 2 (когда версия 1 почти закончена): «Показывать 3D-карту местоположения».
Фото: Unsplash
8. Процесс определения продукта
Если команда по продукту определяет приоритеты и не проверяет необходимость каких-то функций (посредством пользовательского фидбека), и разработчик увидит, что ими никто не пользуется, ему покажется, что его работа бесполезна, и он потеряет свою мотивацию.
9.
Технический долг
Технический долг – намеренное решение внедрить не лучшую программу или написать не лучший код, чтобы побыстрее выпустить ПО. Уход в технический долг просто неизбежен, и в краткосрочной перспективе это может увеличить скорость разработки. В долгосрочной перспективе это приводит к сложности системы, которая замедляет программистов. Многие недооценивают потерю продуктивности и стремятся всегда двигаться вперед, и это проблема.
10. Инструменты и железо
Разработчики используют множество инструментов для написания кода. Чем больше автоматизации, тем лучше. Очевидно, если вы будете использовать древние инструменты, вы будете работать менее продуктивно. То же самое можно сказать и об аппаратуре. Предоставьте своим разработчикам устройства и инструменты, которые они предпочитают.
Фото: Unsplash
11. Неясные комментарии
В самом начале обучения программированию нам говорят комментировать код как можно чаще. Лучше указать слишком много комментариев, чем слишком мало. К несчастью, многие программисты перебарщивают с этим и комментируют каждую строчку кода. Проблема в следующем: многие описывают, что делает код, но не указывают, почему он это делает. Если в программе есть баг, и вам нужно будет его найти в таком коде, вы не поймете, с чего начать.
12. Невероятно сжатые дедлайны
Иногда менеджеры спрашивают у разработчиков приблизительные сроки окончания задачи, затем вынуждают их снизить эти оценки и называют их дедлайнами. Неудивительно, что разработчикам такие сроки кажутся необоснованными и чересчур сжатыми; так возникает давление и неспособность сфокусироваться.
Почему эти 12 пунктов касаются только разработчиков?
На самом деле, они затрагивают почти любую профессию, связанную с работой с проектами. Просто влияние каждого из них куда важнее для программистов, потому что им нужно глубоко фокусироваться на задаче, чтобы продвинуться вперед.
Если вы считаете, что одна из этих проблем существует и в вашей компании, поговорите с разработчиками. Спросите, является ли это проблемой, и как это можно решить. Что бы они ни сказали, главное – доверяйте их фидбеку.
Не забывайте также учитывать человеческий фактор при планировании. Слушайте сотрудников. Только так вы сможете понять, что нужно делать, чтобы повысить их продуктивность.
Источник: https://rb.ru/story/productivity-killers-developers/
