Да, Вы можете измерять эффективность разработчиков
Долгое время считалось, что измерить и оценить производительность разработчиков почти невозможно. Но это далеко не так.
В отличие от таких ключевых сфер бизнеса как продажи или обслуживание клиентов, эффективность разработки ПО традиционно измеряется недостаточно. Многие в IT-секторе убеждены, что правильно измерить это сложно, и что только опытные инженеры могут оценить работу своих коллег. Но такой подход уже не устойчив. Сейчас, когда практически каждая компания становится в той или иной мере IT-компанией, руководителям важно знать, насколько эффективно они используют своих ключевых сотрудников.
Безусловно, измерить производительность программистов непросто. В других сферах это можно сделать довольно точно, иногда даже с помощью одного показателя. В программировании же связь между вложенными ресурсами и результатом не так очевидна. Это сложная, творческая и коллективная работа, требующая разнообразных метрик для разных уровней — и для команд, и для отдельных сотрудников. К тому же, даже при наличии желания правильно измерить эффективность, для этого могут потребоваться специализированные системы и ПО. В некоторых случаях для отслеживания стандартных метрик приходится полностью перестраивать технологические стеки, и это требует значительных долгосрочных инвестиций. Более того, сфера программирования быстро эволюционирует. Инструменты на базе искусственного интеллекта, такие как Copilot X и ChatGPT, могут удвоить скорость выполнения задач разработчиками.
Чтобы справиться с этими трудностями и сделать измерение производительности более реалистичным, мы разработали подход к измерению производительности разработчиков программного обеспечения, который легче применить с помощью опросов или существующих данных (например, в инструментах управления задачами). При этом мы опирались на существующие метрики производительности, которые лидеры отрасли разработали за годы, с целью выявления возможностей для улучшения производительности.
Этот новый метод уже применяется в почти двадцати компаниях из сфер технологий, финансов и фармацевтики, и первые результаты весьма обнадеживающие:
- снижение на 20-30% количества дефектов, о которых сообщают клиенты,
- повышение на 20% уровня удовлетворенности сотрудников
- улучшение на 60% рейтинга удовлетворенности клиентов (NPS)
Исследуем будущее работы вместе! HR-Tech, автоматизация, HR-Аналитика, digital EJM.
Использование данных для повышения производительности
Получив доступ к более детализированным данным о производительности, руководители смогут найти ответы на вопросы про своих инженеров, которых они так тщательно отбирали и стараются удержать. Среди этих вопросов:
- Что мешает инженерам работать на пике своих возможностей?
- В какой степени корпоративная культура и организационная структура влияют на их производительность?
- Как узнать, тратят ли они время на действительно важные и ценные задачи?
- Как определить, есть ли у нас все необходимые специалисты в области программной инженерии?
Понимание основ
Для эффективного измерения производительности разработчиков необходимо понимать три ключевых типа метрик: на системном уровне, на уровне команды и на индивидуальном уровне. В отличие от сферы, например, продаж, где можно использовать общесистемные показатели вроде заработанных долларов или заключенных сделок для оценки как команды, так и отдельных сотрудников, в программировании совместная работа имеет свои особенности, требующие разнообразных методов оценки. Например, частота релизов — отличный показатель для оценки системы или команды в целом, но он зависит от того, насколько хорошо каждый член команды выполняет свои задачи, и поэтому не подходит для оценки индивидуальной производительности.
Другой ключевой момент — понимание того, что метрики могут и не могут вам рассказать. Например, измерение частоты релизов или времени на внесение изменений в систему может дать ясную картину определенных результатов, но не покажет, насколько эффективна инженерная команда. И хотя такие показатели, как выполненные задачи или количество сбоев, могут помочь в оптимизации, для выявления действительно полезных улучшений нужно больше анализа.
В создании нашего комплекса метрик мы опирались на два уже существующих набора, разработанных в индустрии программного обеспечения.
Первый — это метрики DORA, названные в честь команды исследований и оценок DevOps от Google. Эти метрики являются наиболее близкими к стандарту в технологической отрасли и отлично подходят для оценки результатов. Если метрика DORA показывает неудовлетворительные результаты, это становится сигналом для детального расследования. Например, если частота релизов увеличивается или уменьшается, причин может быть множество. Выявить их и найти решение — задача далеко не тривиальная.
Второй набор метрик, принятый в индустрии, — это так называемые метрики SPACE (удовлетворенность и благополучие, производительность, активность, коммуникация и сотрудничество, эффективность и поток), разработанные GitHub и научно-исследовательским отделом Microsoft в дополнение к метрикам DORA. Сфокусировавшись на индивидуальном благополучии разработчиков, эти метрики прекрасно показывают, насколько эффективна инженерная команда. Например, рост числа простоев разработчиков сигнализирует о необходимости оптимизации.
На фоне этих уже весьма эффективных метрик, наш методологический подход направлен на выявление возможных улучшений в процессе поставки результатов, минуя сложные измерения. Сочетание метрик DORA и SPACE с метриками, фокусирующимися на возможностях, позволяет создать полноценный обзор производительности разработчиков ПО.
Эти метрики производительности с фокусом на возможности применяют различные методы для комплексного анализа разнообразных аспектов разработки программных продуктов.
Время, затраченное на внутренний и внешний циклы. Для выявления конкретных направлений улучшения полезно представить процесс разработки как состоящий из двух циклов (Рисунок 2). Внутренний цикл включает в себя задачи, напрямую связанные с созданием продукта: написание кода, сборку и юнит-тестирование. Внешний цикл охватывает другие задачи, которые разработчикам нужно выполнить для переноса кода в рабочую среду: интеграцию, интеграционное тестирование, релиз и развертывание. С точки зрения как производительности, так и личного опыта, желательно увеличить время, проведенное разработчиками во внутреннем цикле: это напрямую создает ценность и является тем, что большинство разработчиков с удовольствием делает. Внешний цикл большинством разработчиков воспринимается как необходимый, но скучный этап. Инвестиции в улучшение инструментов и автоматизацию внешнего цикла позволят разработчикам уделить больше времени внутреннему.
Лидеры технологического сектора стремятся к тому, чтобы разработчики тратили до 70% своего рабочего времени на задачи внутреннего цикла. Например, одна из компаний, успешно прошедшая Agile-трансформацию, выяснила, что разработчики вместо программирования занимаются малоценными задачами, такими как настройка инфраструктуры, ручное юнит-тестирование и управление тестовыми данными. Обладая этой информацией, компания запустила несколько новых инструментов и проектов автоматизации, чтобы облегчить выполнение этих задач на всех этапах разработки.
Оценка по индексу Developer Velocity. Developer Velocity Index (DVI) — это опросник, оценивающий технологические возможности, рабочие методы и организационную поддержку компании, сопоставляя их с отраслевыми стандартами. Этот анализ выявляет специфические области для улучшений, будь то управление задачами, тестирование или соблюдение стандартов безопасности. К примеру, одна компания, известная своим технологическим мастерством и выдающимися разработчиками, решила более тщательно проработать стандартные рабочие процедуры для межкомандного взаимодействия, после того как обнаружила высокий уровень недовольства, дефектов и неэффективности среди своих разработчиков.
Узнать больше про Developer Velocity Index можно здесь (англ.)
Contribution analysis — анализ вклада в проект. Оценка индивидуального вклада в задачи команды (исходя из данных инструментов управления задачами, таких как Jira, и применяя специализированный алгоритм для учета нюансов) может помочь выявить факторы, затрудняющие оптимизацию производительности команды. Такой анализ дает руководителям команды возможность четко формулировать ожидания и, соответственно, улучшать результаты. Это также может служить основой для выявления потребностей в дополнительном обучении или перераспределении ролей в команде (например, если у тестировщика качества достаточно обязанностей). Одна компания выяснила, что ее лучшие разработчики тратят слишком много времени на задачи, не связанные с кодированием, например, на дизайн-сессии или синхронизацию со смежными командами. В ответ на это, компания пересмотрела свою операционную модель и уточнила роли, чтобы эти ценные разработчики могли заниматься тем, что у них получается лучше всего: программированием. Другая компания, заметив низкий вклад новичков, пересмотрела свою программу адаптации и наставничества.
Talent capability score — оценка квалификации персонала. Исходя из отраслевых стандартов, эта оценка представляет собой сводку индивидуальных знаний, умений и навыков в конкретной организации. В идеальном случае, организации должны стремиться к такому распределению уровней профессионализма, где большинство разработчиков находятся в среднем диапазоне компетентности. Это может выявить потребности в коучинге и дополнительном обучении, а в крайних случаях — потребность в пересмотре стратегии подбора кадров. Например, одна компания выявила, что у нее слишком много разработчиков на начальном уровне. В ответ на это, они разработали персонализированные пути обучения, учитывая конкретные пробелы в знаниях, и смогли перевести 30% своих разработчиков на следующий уровень профессионализма за полгода.
Как избежать ошибок при использовании метрик
Данные о производительности разработчиков могут быть весьма полезными, но при неправильном использовании они могут нанести ущерб организациям. В своей практике мы сталкиваемся с двумя основными видами ошибок: неправильным применением метрик и устаревшими подходами к измерению.
Неправильное применение метрик часто возникает, когда компании решают использовать слишком упрощенные показатели, например, количество строк кода или число коммитов. Такие базовые метрики не только не предоставляют полезной информации, но и могут привести к нежелательным последствиям, например, к непродуманным решениям со стороны руководства. Оптимизация по времени выполнения задач или частоты релизов может ухудшить качество продукта. Сосредоточение на одном показателе или на слишком простом наборе метрик может также поощрять недобросовестные практики; в случае измерения коммитов, например, разработчики могут начать чаще отправлять мелкие изменения, чтобы «обойти» систему.
Для того чтобы действительно измерение производительности было по-настоящему полезным, как руководителям, так и разработчикам необходимо отказаться от устаревшего представления, что руководство не может понять все тонкости программной инженерии или что этот процесс слишком сложен для измерения. Значимость инженерных талантов для успеха компании и ожесточенная конкуренция за лучших разработчиков в последние годы подчеркивают, что измерения необходимы для улучшения программной разработки, впрочем, это актуально и для многих других процессов. Более того, привлечение и удержание топовых разработчиков во многом зависят от создания условий и предоставления инструментов, которые стимулируют их лучшую работу и креативность. Измерение производительности на уровне всей системы позволяет работодателям обнаружить скрытые «тормоза», препятствующие этой работе и креативному процессу.
Первые шаги
Запуск инициативы по улучшению производительности разработчиков может пугать, но сейчас — лучшее время для того, чтобы заложить основу. Преимущества эскалации дискуссии о производительности разработчиков на уровень высшего руководства, значительно превосходят возможные риски.
Распространенность и популярность удаленной работы — один из важнейших факторов. Разработчики уже давно привыкли работать в гибких командах, часто в одном офисе, и некоторые руководители в сфере технологий убеждены, что такая очная командная работа критически важна. Однако цифровые инструменты, столь неотъемлемые для их профессиональной деятельности, сделали переход к удаленной работе в период пандемии практически бесшовным. И как и во многих других отраслях, отменить этот переход теперь сложно. По мере того как удаленная и гибридная модели работы становятся новой нормой, компаниям придется опираться на объективные метрики для поддержания доверия к новым форматам работы и для постоянного улучшения процессов, от которых может зависеть их будущий успех или неудача. Учитывая, что сейчас рынки все больше фокусируются на масштабировании и окупаемости, необходимо понимать, как оптимизировать работу ценных инженерных кадров.
Другим ключевым моментом, подчеркивающим необходимость большей прозрачности, являются стремительные прогрессы в инструментах на базе ИИ, в частности, в больших языковых моделях и генеративных ИИ. Они уже существенно изменяют подходы к работе, и измерение производительности разработчиков — это всего лишь начальный этап в понимании, как эффективно распределяются эти ценные ресурсы.
Тем не менее, несмотря на все возрастающую важность производительности разработчиков, компаниям не стоит думать, что им необходимо немедленно начать глобальную и радикальную перестройку. Вместо этого они могут приступить к этому процессу эволюционно, выполнив несколько ключевых шагов:
Изучите основы. Всем топ-менеджерам, далеким от инженерии или давно работающим в управлении, необходимо базовое понимание процесса разработки ПО и его актуальных трендов развития.
Проанализируйте ваши системы. Так как ранее производительность разработчиков часто не подвергалась такому детальному анализу, какой необходим для выявления возможностей улучшения, технологические стеки многих компаний могут потребовать серьезной переконфигурации. Например, для оценки тестового покрытия кода (то есть, насколько хорошо различные части кода протестированы) команде разработчиков нужно интегрировать в свою кодовую базу специализированный инструмент, способный отслеживать выполненный код во время тестирования.
Разработайте план. Как и во многих других аналитических проектах, есть опасность заблудиться в массе данных. Важно начать с конкретной задачи, которая, как вы уверены, приведет к улучшениям — например, выявление узких мест и препятствий. Ясно определите рамки плана, потому что даже самые продуманные методы не будут универсальным решением всех проблем.
Не забывайте, что производительность измеряется в контексте. Главное — это рассмотреть всю систему в целом и понять, как можно улучшить условия работы на уровне системы, команды или отдельного сотрудника.
Независимо от выбранного подхода, цель измерения производительности — создать прозрачность и выявить ключевые точки для улучшения. Только после этого организации смогут разработать специфические инициативы, которые улучшат как производительность разработчиков, так и их опыт работы — что в конечном итоге принесет пользу как отдельным сотрудникам, так и всей компании.
Перевод статьи Yes, you can measure software developer productivity от mckinsey, 17.08.2023
Исследуем будущее работы вместе! HR-Tech, автоматизация, HR-Аналитика, digital EJM.
