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

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

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

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

Но как измерить что-то настолько абстрактное, сложное и творческое, как разработка ПО? Давайте обсудим.

Трудности измерения эффективности разработчиков

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

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

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

Остерегайтесь суетных метрик

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

Вот несколько примеров суетных показателей, которые не только неинформативны, но и могут стимулировать неправильное поведение:

  • Отработанные часы. Приравнивание большого количества часов к высокой продуктивности создает культуру переутомления и бессмысленной «напряженной работы». Потраченное время не обязательно приводит к эффективному результату.
  • Строки кода. Длинный код обычно является признаком низкого качества. Если руководители привязывают производительность к количеству ежедневно написанных строк кода, они побуждают разработчиков придерживаться плохих практик, чтобы достичь своих KPI.
  • Коммиты кода. Опять же, большее количество фиксаций не обязательно свидетельствует о большей эффективности или положительном результате. Разработчики могут намеренно отправлять более мелкие изменения чаще, чтобы обмануть систему, или торопиться с фиксацией, упуская из виду качество кода.
  • Исправленные ошибки. Не все ошибки одинаково сложны. Некоторые разработчики могут намеренно выбирать легко устранимые ошибки, чтобы раздуть их количество, пренебрегая более сложными проблемами.
  • Частота развертывания. Хотя этот показатель полезен для оценки работы команд или систем, он зависит от выполнения всеми своих функций и не является надежным показателем индивидуальной эффективности.

Что на самом деле нужно измерять

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

Соблюдение сроков

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

Качество кода

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

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

Навыки решения проблем

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

Общение и сотрудничество

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

Удовлетворенность работой и благополучие

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

Заключительные соображения

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