Совещания и дедлайны: 12 убийц продуктивности разработчика

Одна из самых важных и распространенных проблем менеджеров проектов и технических руководителей — повышение продуктивности разработчиков. Ей посвящено много статей. Давайте рассмотрим, где кроется корень проблемы.

Почти 30 лет назад вышла книга Тома ДеМарко и Тимоти Листера «Человеческий фактор», но проекты продолжают терпеть убытки из-за огромных потерь производительности. И у этой беды много причин.

Перерывы и совещания

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

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

Одно совещание, может сорвать целый день, разбив его на две части, каждая из которых слишком мала, для решения сложной задачи. — Пол Грэм

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

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

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

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

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

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

К неопределенностям относятся и нечеткие приоритеты. Горящие задачи могут выполняться первыми, только если разработчик знает об их приоритетности. Иначе он может делать что-то другое. И тут не избежать разочарований.

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

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

Присваивание заслуг

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

Окружение

Сюда относятся такие факторы, как: шум, перемещения, интерьер помещения, рабочее место.

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

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

Расползание проекта

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

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

Вот простой пример расползания проекта, на примере функции определения местоположения:

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

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

Как определение продукта влияет на продуктивность разработчиков?

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

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

Отсутствие учета технического долга

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

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

Инструменты и оборудование

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

А еще программистам удобнее работать с большим монитором и мощным компьютером, чем с маленьким монитором и постоянно тормозящим компьютером.

Отсутствие внятной документации кода

Когда мы только начинаем изучать программирование, то постоянно сталкиваемся с тезисом про важность комментирования кода. Многие программисты неверно понимают этот тезис и комментируют практически каждую строку кода. Давайте посмотрим на пример кода из статьи Джеффа Этвуда «Кодирование без комментариев»:

r = n / 2; //установить значение r равное n деленного на 2

// цикл пока r - (n/r) больше чем t

while (abs(r - (n/r)) > t) {
    r = 0.5 * (r + (n/r)); // установить значение r равное половине r + (n/r)
}

У вас есть понимание, для чего нужен этот код? Как он может быть применен? А где? Скорее всего, нет. Хотя в этом коде комментариев более чем достаточно. Проблема в том, что они рассказывают, что происходит, а не дают ответа на вопрос «Зачем это делается?».

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

Невозможные дедлайны

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

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

Заключение

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