Одна из важнейших проблем проектных менеджеров и технических руководителей – повышение продуктивности разработчиков. Давайте поищем ее корни.
Почти 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)
}
Вы понимаете, для чего создан этот код? Вероятно, нет, хотя комментариев в нем более чем достаточно. Беда в том, что они рассказывают, какие действия происходят, а не зачем они происходят. Более-менее опытный программист способен понять, как работает присваивание или цикл, но догадаться, какие данных здесь обрабатываются без дополнительной информации, невозможно. Ошибки, возникающие в таких программах, исправлять довольно тяжело.
Невозможные дедлайны
Этот пункт связан с плохой привычкой менеджеров запрашивать у разработчиков временные оценки реализации, добиваться их максимального уменьшения, а затем волшебным образом превращать эти оценки в жесткие сроки. Менеджеры любят сроки, видят их даже там, где их еще нет, и могут искренне считать, что разработчики установили их сами.
Неудивительно, что программисты считают такую постановку вопроса необоснованной. Это создает напряженность и мешает сосредоточиться.
Универсальные убийцы продуктивности
Взглянем еще раз на получившийся список. Все 12 убийц производительности распространены повсюду – в разных областях деятельности человека. Они не специфичны только для сферы разработки ПО.
Однако программистам для решения задач необходима глубокая сосредоточенность, поэтому каждый из этих факторов может легко подорвать их продуктивность. Конечно, технологии сильно продвинулись, но нельзя игнорировать человеческий фактор. Чем комфортнее программисту творить, тем он эффективнее.
Поделитесь в комментариях, что мешает работать вам?
Оригинал: Top 12 Things That Destroy Developer Productivity by John Lafleur
Комментарии