Измерение производительности разработчиков — сложная задача. Традиционные метрики, ориентированные на время цикла разработки и пропускную способность — ограничены, и нет очевидных ответов на вопрос, к каким метрикам ещё можно обратиться. Качественные метрики предлагают мощный способ измерения и понимания производительности разработчиков с помощью данных, полученных от самих разработчиков. Организациям следует уделять первоочередное внимание измерению производительности разработчиков с помощью данных, полученных от людей, а не от систем.
Где-то, прямо сейчас, руководитель технологического отдела говорит своим директорам: «Нам нужен способ измерить производительность наших инженерных команд». Собирается рабочая группа для изучения потенциальных решений, и спустя несколько недель обсуждений предлагается внедрить метрики: время выполнения, частота развёртывания и количество пулл-реквестов, созданных каждым инженером.
Вскоре после этого руководители высшего звена собираются, чтобы просмотреть только что созданные дашборды. Сразу же возникают вопросы и сомнения. Один из руководителей говорит: «Наше время выполнения заказа составляет два дня, что является „низким показателем“ в соответствии с этими контрольными показателями — но есть ли проблема на самом деле?». Другой руководитель говорит: «Неудивительно, что некоторые из наших команд деплоят реже других. Но я не уверен, открывает ли эта информация возможности для улучшений».
Эта история знакома многим — включая крупнейшие технологические компании мира. Нередко программы измерения оказываются несостоятельными, когда такие показатели, как DORA, не дают тех результатов, на которые рассчитывало руководство.
Однако есть и более эффективный подход. Подход, который фокусируется на получении информации от самих разработчиков, а не только на базовых показателях скорости и производительности. Мы помогли многим организациям перейти к такому подходу, ориентированному на человека. И мы убедились в том, что он позволяет значительно улучшить понимание продуктивности разработчиков.
Мы имеем в виду качественные измерения. В этой статье мы расскажем об этом подходе, основываясь на нашем опыте помощи многим организациям на этом пути. Мы начнём с определения качественных показателей и того, как доказать их ценность. Также мы приведём практические рекомендации по сбору, отслеживанию и использованию этих данных.
Сегодня на фоне ужесточения налогового законодательства и продвинутых технологий производительность разработчиков является важным объектом внимания компаний. Кроме того, опыт разработчиков и разработки привлекает всё больше внимания, поскольку предприятия выходят за рамки Agile и DevOps. Общим для всех этих проблем является зависимость от измерений, которые помогают принимать решения и отслеживать прогресс. А для этого ключевое значение имеют качественные измерения.
Примечание: под «производительностью разработчика» мы имеем в виду не индивидуальную производительность разработчиков, а степень, в которой разработчики могут беспрепятсвенно выполнять работу. Некоторые компании не любят термин «производительность разработчика» из-за того, что разработчики могут неправильно его истолковать. Поэтому мы рекомендуем использовать термин «опыт разработчика», который имеет более позитивную коннотацию для разработчиков.
Рисунок 1: Качественные метрики — это оценка, полученная от людей
Определение слова «метрика» однозначно. Термин «качественный», однако, не имеет общепринятого определения, как отмечается в статье 2019 года What is Qualitative in Qualitative Research:
Еще один аргумент, который мы слышали, заключается в том, что результаты анализа настроений являются количественными, потому что в результате анализа получаются цифры. Хотя мы согласны с тем, что данные, полученные в результате анализа настроений, являются количественными, исходя из нашего первоначального определения, это всё же качественная метрика (т. е. количество, полученное качественным путем), если только не придерживаться позиции, что «качественная метрика» — это вообще оксюморон.
Помимо проблемы с определением того, что такое качественная метрика, мы также столкнулись с проблематичными разговорными оборотами. Одним из примеров является термин «мягкая метрика» (“soft metric”). Мы предостерегаем от использования этой фразы, потому что она неверно подразумевает, что данные, собранные от людей, слабее «жёстких метрик» (“hard metrics”), собранных из систем. Мы также не рекомендуем использовать термин «субъективные метрики», поскольку он неверно истолковывает тот факт, что данные, собранные от людей, могут быть либо объективными, либо субъективными — о чём поговорим в следующем разделе.
Качественные метрики: Оценки, полученные от людей:
Позже в этой статье мы предоставим руководство по сбору и использованию этих оценок, но сначала мы приведём реальный пример применения этого подхода на практике.
Peloton — американская технологическая компания, чья стратегия измерения производительности разработчиков основана на качественных метриках. Для сбора качественных метрик компания раз в полгода проводит опрос разработчиков, возглавляемый командой Tech Enablement & Developer Experience, которая является частью подразделения Product Operations.
Танша Садачарам, руководитель отдела обучения и анализа технологий, объясняет: «Я верю и полагаю, что многие наши инженеры также очень ценят подход, согласно которому инженеры — не роботы, а люди. И простое изучение основных цифр не позволяет понять всю историю. Поэтому для нас было очень важно иметь действительно комплексный опрос, который помог бы нам понять весь опыт разработчиков».
Каждый опрос отправляется случайной выборке примерно половины разработчиков. Благодаря такому подходу отдельным разработчикам приходится участвовать только в одном опросе в год, что позволяет свести к минимуму общие затраты времени на заполнение анкет, избежать усталости от опросов и при этом получить статистически значимый репрезентативный набор данных. Команда Tech Enablement & Developer Experience также отвечает за анализ и распространение результатов опросов среди руководителей всей организации.
Чтобы узнать больше об исследовании опыта разработчиков Peloton, послушайте интервью с Таншей Садачарам (Thansha Sadacharam).
Избегайте противопоставления качественных и количественных показателей.
Мы видели, как некоторые организации вступают во внутреннюю «битву метрик», что не является разумным использованием времени и энергии. Наш совет чемпионам — избегать противопоставления качественных и количественных показателей друг другу по принципу «или-или». Лучше привести аргументы в пользу того, что они являются взаимодополняющими инструментами.
Мы обнаружили, что в основе неприятия качественных данных лежат заблуждения, которые мы рассмотрим ниже. Позже в этой статье мы расскажем о преимуществах самоотчётных данных, таких как их способность измерять нематериальные факторы и раскрывать критический контекст.
Как мы описываем в следующем разделе, опросы также могут собирать объективную информацию о фактах или событиях. Программа DevOps Research and Assessment (DORA) компании Google является отличным примером.
Некоторые примеры объективных вопросов для опроса:
Некоторые организации опасаются, что люди могут лгать в ходе опросов. Это действительно может произойти в ситуациях, когда сотрудники не знают, как полученные данные будут использованы. По нашему опыту, когда опросы используются в качестве инструмента, помогающего понять и устранить узкие места, с которыми сталкиваются разработчики, у респондентов нет причин лгать или как-то по-другому обманывать систему.
Хотя данные опросов не всегда точны на 100 %, мы часто напоминаем руководителям, что системные метрики тоже часто несовершенны. Например, многие организации пытаются измерить время сборки CI, используя данные, собранные из пайплайнов — и обнаруживают, что для получения точного результата требуется приложить значительные усилия для очистки данных (например, исключить фоновые задачи, учесть параллельные задачи).
DORA ежегодно публикует контрольные показатели по таким параметрам, как время подготовки изменений, частота развёртывания и количество отказов от изменений.
Возможность одновременно собирать данные об отношении и поведении — это значительное преимущество качественных измерений.
Например, поведенческие данные могут показать, что ваш процесс проведения релизов быстр и эффективен. Но только данные об отношении могут подсказать, является ли этот процесс гладким и безболезненным, что имеет важное значение для предупреждения выгорания и для удержания разработчиков.
Если использовать нетехнологическую аналогию — представьте, что вы чувствуете недомогание и пришли к врачу. Врач измеряет давление, температуру, пульс и говорит: «Похоже, что все показатели в норме. Да, с вами всё в порядке». Вы удивитесь и возразите: «Подождите, я говорю вам, что что-то не так».
Существует три основных преимущества качественных метрик, когда речь идет об измерении производительности разработчиков.
Интересный пример представляет собой технический долг. В компании Google исследование по определению метрик технического долга включало анализ 117 показателей, которые предлагались в качестве потенциальных индикаторов. К разочарованию исследователей Google, ни одна метрика или комбинация метрик не была признана достоверным показателем (подробнее о том, как Google измеряет технический долг, читайте в этом интервью).
Хотя, возможно, существует еще не найденная объективная метрика технического долга, можно предположить, что это невозможно из-за того, что оценка технического долга основывается на сравнении текущего состояния системы или кодовой базы с её воображаемым идеальным состоянием. Другими словами, необходимо человеческое суждение.
Невозможно получить представление обо всех этих действиях, используя только данные из наших систем. И даже если бы мы теоретически могли собрать все данные с помощью систем, существуют дополнительные трудности, связанные со сбором метрик с помощью инструментов.
Например, сложно нормализовать метрики для различных рабочих процессов в команде. Например, если вы пытаетесь измерить, сколько времени уходит на выполнение задач от начала до конца, вы можете попытаться получить эти данные из тикет-системы. Но у отдельных команд часто разные рабочие процессы, а это затрудняет получение точной метрики. Может быть гораздо проще просто спросить разработчиков, сколько времени обычно занимают задачи.
Другой распространённой проблемой является кросс-системная видимость. Например, небольшой стартап может измерить TTR (Time to Recovery, время на восстановление), используя только баг-трекер, например, Jira. Однако крупной организации, скорее всего, потребуется консолидировать и связывать данные на основе их атрибутов в системах планирования и конвейерах развёртывания, чтобы получить сквозную видимость системы. Это может занять целый год, в то время как сбор таких данных от разработчиков позволяет быстро получить основные данные.
Приведём в пример код-ревью: попытка его ускорения является типичной оптимизацией. Это кажется логичным, поскольку ожидание код-ревью может привести к потере времени или нежелательному переключению контекста. Можно было бы измерять время, необходимое для завершения ревью, и стимулировать команды к его улучшению. Но такой подход может поощрять негативное поведение: ревьюеров, торопящихся с обратной связью, или разработчиков, не нашедших нужных экспертов для выполнения ревью.
Код-ревью существуют для важной цели: обеспечить высокое качество поставляемого программного обеспечения. Если мы проведём более целостный анализ — сосредоточившись скорее на результатах процесса, чем на скорости — то обнаружим, что оптимизация код-ревью должна обеспечивать хорошее качество кода, снижение рисков безопасности, формирование общих знаний у членов команды, а также гарантировать, что наши коллеги не заставят себя ждать. Качественные показатели могут помочь нам оценить, достигаются ли эти результаты.
Другой пример — процесс адаптации разработчиков. Разработка программного обеспечения — это командная деятельность. Поэтому если мы измеряем только индивидуальные показатели, например, как скоро новые разработчики сделают первый коммит, мы упускаем важные результаты — например, действительно ли мы используем идеи, которые привносят разработчики, чувствуют ли они себя в безопасности, задавая вопросы, и сотрудничают ли они с коллегами других профилей.
Ниже приведены несколько хороших правил составления опросов, которые помогают избежать наиболее распространённых ошибок:
После сбора ответов оцените вопросы с множественным выбором, используя средний балл или баллы по верхней границе. Средние баллы рассчитываются путём присвоения каждому варианту значения от 1 до 5 и взятия среднего значения. Балл по верхней границе рассчитывается по проценту ответов, в которых выбран один из двух наиболее благоприятных вариантов.
Не забудьте просмотреть развёрнутые текстовые ответы — они могут содержать много полезной информации. Если вы собрали большое количество комментариев, то с помощью инструментов LLM, например, ChatGPT, можно извлечь основные темы и предложений. По завершении анализа результатов не забудьте поделиться своими выводами с респондентами, чтобы они почувствовали, что их время на заполнение опроса было потрачено не зря.
По нашим наблюдениям, организации добиваются успеха, когда начинают с качественных метрик, чтобы установить базовые значения и определить, на чем следует сосредоточиться. Затем следует использование количественных метрик для более глубокого изучения конкретных областей.
Руководители инженерных подразделений считают такой подход эффективным, поскольку качественные метрики обеспечивают целостный взгляд и контекст, давая широкое понимание потенциальных возможностей. Количественные метрики, с другой стороны, обычно доступны только для более узкого круга процессов поставки программного обеспечения.
По этой же причине Google советует своим руководителям инженерных служб сначала изучать данные опросов, а потом просматривать данные логов. Инженер-исследователь Google Ciera Jaspan объясняет: «Мы рекомендуем руководителям сначала изучить данные опроса, потому что если вы будете смотреть только на данные логов, это не даст вам чёткого представления о том, хорошо это или плохо. Например, у нас есть метрика, которая отслеживает время, затраченное на внесение изменений, но сама по себе эта цифра бесполезна. Вы не знаете, хорошо ли это? Плохо ли? Есть ли у нас проблема?».
Смешанные методы позволяют использовать преимущества как качественных, так и количественных метрик и получить полное представление о производительности разработчиков:
Однако, в конечном итоге важно помнить: организации много тратят на высококвалифицированных специалистов, которые могут наблюдать и выявлять проблемы, чего не могут сделать метрики, основанные на логах. Обращаясь ко мнению и голосам разработчиков, организации могут получить информацию, которую ранее считалось невозможно получить.
habr.com
Где-то, прямо сейчас, руководитель технологического отдела говорит своим директорам: «Нам нужен способ измерить производительность наших инженерных команд». Собирается рабочая группа для изучения потенциальных решений, и спустя несколько недель обсуждений предлагается внедрить метрики: время выполнения, частота развёртывания и количество пулл-реквестов, созданных каждым инженером.
Вскоре после этого руководители высшего звена собираются, чтобы просмотреть только что созданные дашборды. Сразу же возникают вопросы и сомнения. Один из руководителей говорит: «Наше время выполнения заказа составляет два дня, что является „низким показателем“ в соответствии с этими контрольными показателями — но есть ли проблема на самом деле?». Другой руководитель говорит: «Неудивительно, что некоторые из наших команд деплоят реже других. Но я не уверен, открывает ли эта информация возможности для улучшений».
Эта история знакома многим — включая крупнейшие технологические компании мира. Нередко программы измерения оказываются несостоятельными, когда такие показатели, как DORA, не дают тех результатов, на которые рассчитывало руководство.
Однако есть и более эффективный подход. Подход, который фокусируется на получении информации от самих разработчиков, а не только на базовых показателях скорости и производительности. Мы помогли многим организациям перейти к такому подходу, ориентированному на человека. И мы убедились в том, что он позволяет значительно улучшить понимание продуктивности разработчиков.
Мы имеем в виду качественные измерения. В этой статье мы расскажем об этом подходе, основываясь на нашем опыте помощи многим организациям на этом пути. Мы начнём с определения качественных показателей и того, как доказать их ценность. Также мы приведём практические рекомендации по сбору, отслеживанию и использованию этих данных.
Сегодня на фоне ужесточения налогового законодательства и продвинутых технологий производительность разработчиков является важным объектом внимания компаний. Кроме того, опыт разработчиков и разработки привлекает всё больше внимания, поскольку предприятия выходят за рамки Agile и DevOps. Общим для всех этих проблем является зависимость от измерений, которые помогают принимать решения и отслеживать прогресс. А для этого ключевое значение имеют качественные измерения.
Примечание: под «производительностью разработчика» мы имеем в виду не индивидуальную производительность разработчиков, а степень, в которой разработчики могут беспрепятсвенно выполнять работу. Некоторые компании не любят термин «производительность разработчика» из-за того, что разработчики могут неправильно его истолковать. Поэтому мы рекомендуем использовать термин «опыт разработчика», который имеет более позитивную коннотацию для разработчиков.
Что такое качественная метрика?
Мы определяем качественную метрику как измерение, состоящее из данных, предоставленных людьми. Это практическое определение — мы не нашли единого определения в социальных науках, а у альтернативных определений есть недостатки, которые мы обсудим далее.
Рисунок 1: Качественные метрики — это оценка, полученная от людей
Определение слова «метрика» однозначно. Термин «качественный», однако, не имеет общепринятого определения, как отмечается в статье 2019 года What is Qualitative in Qualitative Research:
Альтернативное определение, которое мы слышали, гласит, что качественные метрики измеряют качество, а количественные — количество. Мы считаем это определение проблематичным по двум причинам: во-первых, термин «качественная метрика» включает в себя термин «метрика», который подразумевает, что результатом является количество (т. е. измерение). Во-вторых, качество обычно измеряется с помощью порядковых шкал, которые переводятся в числовые значения и баллы — что опять же противоречит определению.
Еще один аргумент, который мы слышали, заключается в том, что результаты анализа настроений являются количественными, потому что в результате анализа получаются цифры. Хотя мы согласны с тем, что данные, полученные в результате анализа настроений, являются количественными, исходя из нашего первоначального определения, это всё же качественная метрика (т. е. количество, полученное качественным путем), если только не придерживаться позиции, что «качественная метрика» — это вообще оксюморон.
Помимо проблемы с определением того, что такое качественная метрика, мы также столкнулись с проблематичными разговорными оборотами. Одним из примеров является термин «мягкая метрика» (“soft metric”). Мы предостерегаем от использования этой фразы, потому что она неверно подразумевает, что данные, собранные от людей, слабее «жёстких метрик» (“hard metrics”), собранных из систем. Мы также не рекомендуем использовать термин «субъективные метрики», поскольку он неверно истолковывает тот факт, что данные, собранные от людей, могут быть либо объективными, либо субъективными — о чём поговорим в следующем разделе.
Качественные метрики: Оценки, полученные от людей:
Тип | Определение | Пример |
Оценочные метрики | Субъективные чувства, мнения или отношение к определённому предмету. | Насколько вы удовлетворены своей IDE по шкале от 1 до 10? |
Поведенческие метрики | Объективные факты или события, относящиеся к опыту работы человека. | Сколько времени вам требуется для внедрения изменений? |
Peloton — американская технологическая компания, чья стратегия измерения производительности разработчиков основана на качественных метриках. Для сбора качественных метрик компания раз в полгода проводит опрос разработчиков, возглавляемый командой Tech Enablement & Developer Experience, которая является частью подразделения Product Operations.
Танша Садачарам, руководитель отдела обучения и анализа технологий, объясняет: «Я верю и полагаю, что многие наши инженеры также очень ценят подход, согласно которому инженеры — не роботы, а люди. И простое изучение основных цифр не позволяет понять всю историю. Поэтому для нас было очень важно иметь действительно комплексный опрос, который помог бы нам понять весь опыт разработчиков».
Каждый опрос отправляется случайной выборке примерно половины разработчиков. Благодаря такому подходу отдельным разработчикам приходится участвовать только в одном опросе в год, что позволяет свести к минимуму общие затраты времени на заполнение анкет, избежать усталости от опросов и при этом получить статистически значимый репрезентативный набор данных. Команда Tech Enablement & Developer Experience также отвечает за анализ и распространение результатов опросов среди руководителей всей организации.
Чтобы узнать больше об исследовании опыта разработчиков Peloton, послушайте интервью с Таншей Садачарам (Thansha Sadacharam).
Защита качественных метрик
Руководители часто скептически относятся к надёжности или полезности качественных метрик. Даже такие высоконаучные организации, как Google, вынуждены преодолевать эти предубеждения. Руководители инженерных подразделений склоняются к системным метрикам, поскольку они привыкли работать с телеметрическими данными для проверки систем. Однако мы не можем полагаться на этот же подход при оценке работы людей.Избегайте противопоставления качественных и количественных показателей.
Мы видели, как некоторые организации вступают во внутреннюю «битву метрик», что не является разумным использованием времени и энергии. Наш совет чемпионам — избегать противопоставления качественных и количественных показателей друг другу по принципу «или-или». Лучше привести аргументы в пользу того, что они являются взаимодополняющими инструментами.
Мы обнаружили, что в основе неприятия качественных данных лежат заблуждения, которые мы рассмотрим ниже. Позже в этой статье мы расскажем о преимуществах самоотчётных данных, таких как их способность измерять нематериальные факторы и раскрывать критический контекст.
Заблуждение: качественные данные являются исключительно субъективными
Традиционные опросы обычно сосредоточены на субъективных мнениях и ощущениях сотрудников. Поэтому многие руководители инженерных компаний интуитивно полагают, что опросы могут собирать только субъективные данные разработчиков.Как мы описываем в следующем разделе, опросы также могут собирать объективную информацию о фактах или событиях. Программа DevOps Research and Assessment (DORA) компании Google является отличным примером.
Некоторые примеры объективных вопросов для опроса:
- Сколько времени требуется, чтобы пройти путь от написания кода до его успешного запуска в продакшен?
- Как часто ваша организация деплоит код в продакшен или делает релизы для конечных пользователей?
Заблуждение: качественные данные ненадёжны
Одна из проблем исследований заключается в том, что вопросы для них пишут люди с самым разным опытом работы, не имеющие специальной подготовки. В результате многие опросы на рабочем месте не отвечают минимальным стандартам, необходимым для получения надёжных и достоверных показателей. Однако хорошо спланированные опросы позволяют получить точные и надёжные данные.Некоторые организации опасаются, что люди могут лгать в ходе опросов. Это действительно может произойти в ситуациях, когда сотрудники не знают, как полученные данные будут использованы. По нашему опыту, когда опросы используются в качестве инструмента, помогающего понять и устранить узкие места, с которыми сталкиваются разработчики, у респондентов нет причин лгать или как-то по-другому обманывать систему.
Хотя данные опросов не всегда точны на 100 %, мы часто напоминаем руководителям, что системные метрики тоже часто несовершенны. Например, многие организации пытаются измерить время сборки CI, используя данные, собранные из пайплайнов — и обнаруживают, что для получения точного результата требуется приложить значительные усилия для очистки данных (например, исключить фоновые задачи, учесть параллельные задачи).
Два типа качественных метрик
Есть два основных типа качественных метрик:- Оценочные метрики (данные об отношении): фиксируют субъективные чувства, мнения или отношение к определённому предмету. В качестве примера можно привести числовое значение, полученное в ответ на вопрос: «Насколько вы удовлетворены своей IDE, по шкале от 1 до 10?».
- Поведенческие метрики: фиксируют объективные факты или события, относящиеся к рабочему опыту человека. Примером поведенческого показателя может служить число, полученное в ответ на вопрос: «Сколько времени вам требуется, чтобы внедрить изменение?».
DORA ежегодно публикует контрольные показатели по таким параметрам, как время подготовки изменений, частота развёртывания и количество отказов от изменений.
Возможность одновременно собирать данные об отношении и поведении — это значительное преимущество качественных измерений.
Например, поведенческие данные могут показать, что ваш процесс проведения релизов быстр и эффективен. Но только данные об отношении могут подсказать, является ли этот процесс гладким и безболезненным, что имеет важное значение для предупреждения выгорания и для удержания разработчиков.
Если использовать нетехнологическую аналогию — представьте, что вы чувствуете недомогание и пришли к врачу. Врач измеряет давление, температуру, пульс и говорит: «Похоже, что все показатели в норме. Да, с вами всё в порядке». Вы удивитесь и возразите: «Подождите, я говорю вам, что что-то не так».
Преимущества качественных метрик
Одним из аргументов в пользу качественных метрик является то, что они позволяют разработчикам не чувствовать себя «измеряемыми» руководством. Хотя мы считаем это верным — особенно в сравнении с метриками, полученными из данных разработчиков в Git или Jira, — это не учитывает основных объективных преимуществ, которые могут обеспечить качественные метрики.Существует три основных преимущества качественных метрик, когда речь идет об измерении производительности разработчиков.
Качественные метрики позволяют измерить то, что иначе не измерить
Системные метрики, такие как время выполнения заказа и объём развертывания, отражают то, что происходит в наших пайплайнах или тикет-системах. Но существует множество других аспектов работы разработчиков, которые необходимо понять, чтобы повысить производительность: например, способны ли разработчики оставаться в потоке работы или легко ориентироваться в своих кодовых базах. Качественные метрики позволяют измерить эти нюансы, которые иначе сложно или невозможно измерить.Интересный пример представляет собой технический долг. В компании Google исследование по определению метрик технического долга включало анализ 117 показателей, которые предлагались в качестве потенциальных индикаторов. К разочарованию исследователей Google, ни одна метрика или комбинация метрик не была признана достоверным показателем (подробнее о том, как Google измеряет технический долг, читайте в этом интервью).
Хотя, возможно, существует еще не найденная объективная метрика технического долга, можно предположить, что это невозможно из-за того, что оценка технического долга основывается на сравнении текущего состояния системы или кодовой базы с её воображаемым идеальным состоянием. Другими словами, необходимо человеческое суждение.
Качественные метрики обеспечивают недостающую видимость по командам и системам
Метрики из тикет-систем и пайплайнов дают нам представление о некоторых видах работы, которую выполняют разработчики. Но сами по себе эти данные не могут дать нам полной картины. Разработчики выполняют много работы, которая не отражается в тикетах или сборках: например, проектируют ключевые фичи, определяют направление проекта или помогают членам команды влиться в коллектив.Невозможно получить представление обо всех этих действиях, используя только данные из наших систем. И даже если бы мы теоретически могли собрать все данные с помощью систем, существуют дополнительные трудности, связанные со сбором метрик с помощью инструментов.
Например, сложно нормализовать метрики для различных рабочих процессов в команде. Например, если вы пытаетесь измерить, сколько времени уходит на выполнение задач от начала до конца, вы можете попытаться получить эти данные из тикет-системы. Но у отдельных команд часто разные рабочие процессы, а это затрудняет получение точной метрики. Может быть гораздо проще просто спросить разработчиков, сколько времени обычно занимают задачи.
Другой распространённой проблемой является кросс-системная видимость. Например, небольшой стартап может измерить TTR (Time to Recovery, время на восстановление), используя только баг-трекер, например, Jira. Однако крупной организации, скорее всего, потребуется консолидировать и связывать данные на основе их атрибутов в системах планирования и конвейерах развёртывания, чтобы получить сквозную видимость системы. Это может занять целый год, в то время как сбор таких данных от разработчиков позволяет быстро получить основные данные.
Качественные метрики обеспечивают контекст для количественных данных
Будучи технарями, легко зациклиться на количественных показателях. В конце концов, они кажутся чёткими и понятными. Однако есть риск, что без более полных данных мы не сможем увидеть картину целиком, и что сфокусируемся не на том.Приведём в пример код-ревью: попытка его ускорения является типичной оптимизацией. Это кажется логичным, поскольку ожидание код-ревью может привести к потере времени или нежелательному переключению контекста. Можно было бы измерять время, необходимое для завершения ревью, и стимулировать команды к его улучшению. Но такой подход может поощрять негативное поведение: ревьюеров, торопящихся с обратной связью, или разработчиков, не нашедших нужных экспертов для выполнения ревью.
Код-ревью существуют для важной цели: обеспечить высокое качество поставляемого программного обеспечения. Если мы проведём более целостный анализ — сосредоточившись скорее на результатах процесса, чем на скорости — то обнаружим, что оптимизация код-ревью должна обеспечивать хорошее качество кода, снижение рисков безопасности, формирование общих знаний у членов команды, а также гарантировать, что наши коллеги не заставят себя ждать. Качественные показатели могут помочь нам оценить, достигаются ли эти результаты.
Другой пример — процесс адаптации разработчиков. Разработка программного обеспечения — это командная деятельность. Поэтому если мы измеряем только индивидуальные показатели, например, как скоро новые разработчики сделают первый коммит, мы упускаем важные результаты — например, действительно ли мы используем идеи, которые привносят разработчики, чувствуют ли они себя в безопасности, задавая вопросы, и сотрудничают ли они с коллегами других профилей.
Как фиксировать качественные метрики
Многие технари-практики не понимают, насколько сложно написать хорошие вопросы для опроса и разработать качественные инструменты для опроса. На самом деле, существуют целые области исследований, с этим связанные — такие как психометрика и промышленная психология. Важно по возможности привлекать или наращивать экспертизу в этой области.Ниже приведены несколько хороших правил составления опросов, которые помогают избежать наиболее распространённых ошибок:
- Пункты опроса должны быть тщательно сформулированы, и каждый пункт должен содержать только один вопрос.
- Если вы хотите сравнить результаты разных опросов, будьте осторожны и не меняйте формулировки вопросов так, будто вы измеряете что-то другое.
- Если вы меняете какую-либо формулировку, необходимо провести тщательные статистические тесты.
Сегментируйте результаты по командам и персонам
Частая ошибка лидеров организаций заключается в том, что они фокусируются на результатах работы всей компании, а не на данных, разбитых по командам и персонам (например, по ролям, стажу, опыту работы). Как было описано ранее, опыт разработчиков высоко контекстуален и может кардинально отличаться в разных командах или ролях. Если сосредоточиться только на совокупных результатах, это может привести к упущению проблем, затрагивающих небольшие, но важные группы в компании, например, мобильных разработчиков.Комментарии в свободной форме часто оказываются наиболее ценными
Мы уже говорили о качественных метриках, но комментарии в свободной форме — чрезвычайно ценная форма качественных данных. Помимо описания трений или рабочего процесса, у разработчиков может быть множество отличных идей по улучшению их опыта, и свободные комментарии позволяют нам зафиксировать их и определить, с кем следует работать дальше. Комментарии в свободной форме также могут выявить области, которые не были охвачены вашим опросом и которые могут быть добавлены в будущем.Сравните результаты с контрольными показателями
Сравнительный анализ помогает контекстуализировать данные и подтолкивает к действиям. Например, отношение разработчиков к качеству кода обычно бывает негативным, что затрудняет выявление истинных проблем и оценку их масштаба. Более действенной точкой отсчёта является вопрос: «Расстроены ли наши разработчики качеством кода сильнее, чем другие команды или организации?». Команды с более низкими показателями настроений, чем их коллеги, и организации с более низкими показателями, чем их коллеги по отрасли, могут выявить заметные возможности для улучшения.Используйте транзакционные опросы, когда это уместно
Транзакционные опросы позволяют получить обратную связь внутри какого-то разработческого процесса. Например, команды разработки платформ могут использовать транзакционные опросы, чтобы попросить разработчиков оставить отзыв в процессе создания нового сервиса на внутреннем портале разработчиков. Транзакционные опросы также могут дополнить данные периодических опросов, позволяя чаще собирать обратную связь.Избегайте эффекта усталости от опросов
Многим организациям трудно поддерживать высокий уровень участия в опросах в течение длительного времени. Отсутствие реальных действий после проведения опросов может привести к тому, что разработчики почувствуют, что повторное участие в опросах не имеет никакого смысла. Поэтому очень важно, чтобы руководители и команды следили за ходом опросов и предпринимали значимые действия после их завершения. Хотя для большинства организаций оптимальным является проведение опросов раз в три месяца или полгода, мы видели, как некоторые организации добивались успеха при проведении более частых опросов, которые были интегрированы в регулярные командные ритуалы, такие как ретроспективы.Шаблон опроса
Если вы не знаете, с чего начать, посмотрите пример короткого опроса в формате Google Forms. Шаблон намеренно прост, но по мере развития стратегии измерений опросы обычно растут в объёме. Например, опрос разработчиков Shopify длится около 20 минут (подробнее об этом — в подкасте), а Google — более 30 минут.После сбора ответов оцените вопросы с множественным выбором, используя средний балл или баллы по верхней границе. Средние баллы рассчитываются путём присвоения каждому варианту значения от 1 до 5 и взятия среднего значения. Балл по верхней границе рассчитывается по проценту ответов, в которых выбран один из двух наиболее благоприятных вариантов.
Не забудьте просмотреть развёрнутые текстовые ответы — они могут содержать много полезной информации. Если вы собрали большое количество комментариев, то с помощью инструментов LLM, например, ChatGPT, можно извлечь основные темы и предложений. По завершении анализа результатов не забудьте поделиться своими выводами с респондентами, чтобы они почувствовали, что их время на заполнение опроса было потрачено не зря.
Совместное использование качественных и количественных метрик
Качественные и количественные метрики — это взаимодополняющие подходы к измерению продуктивности разработчиков. Качественные метрики, полученные в результате опросов, дают целостное представление о производительности, включающее как субъективные, так и объективные оценки. Количественные метрики, с другой стороны, также дают определённые преимущества:- Точность. Человек может сказать вам, быстро или медленно происходит сборка в CI/CD (то есть длительность сборки составляет около минуты или около часа), но он не может сообщить о времени сборки с точностью до миллисекунды. Количественные метрики нужны, когда требуется высокая степень точности измерений.
- Непрерывность. Как правило, организация может опрашивать своих разработчиков не чаще одного-двух раз в квартал. Чтобы собирать метрики чаще или непрерывно, необходимо собирать данные систематически.
По нашим наблюдениям, организации добиваются успеха, когда начинают с качественных метрик, чтобы установить базовые значения и определить, на чем следует сосредоточиться. Затем следует использование количественных метрик для более глубокого изучения конкретных областей.
Руководители инженерных подразделений считают такой подход эффективным, поскольку качественные метрики обеспечивают целостный взгляд и контекст, давая широкое понимание потенциальных возможностей. Количественные метрики, с другой стороны, обычно доступны только для более узкого круга процессов поставки программного обеспечения.
По этой же причине Google советует своим руководителям инженерных служб сначала изучать данные опросов, а потом просматривать данные логов. Инженер-исследователь Google Ciera Jaspan объясняет: «Мы рекомендуем руководителям сначала изучить данные опроса, потому что если вы будете смотреть только на данные логов, это не даст вам чёткого представления о том, хорошо это или плохо. Например, у нас есть метрика, которая отслеживает время, затраченное на внесение изменений, но сама по себе эта цифра бесполезна. Вы не знаете, хорошо ли это? Плохо ли? Есть ли у нас проблема?».
Смешанные методы позволяют использовать преимущества как качественных, так и количественных метрик и получить полное представление о производительности разработчиков:
- Начните с качественных данных, чтобы определить основные возможности.
- Как только вы узнаете, что именно хотите улучшить, используйте количественные метрики для более глубокого анализа.
- Отслеживайте свой прогресс, используя как качественные, так и количественные метрики.
Однако, в конечном итоге важно помнить: организации много тратят на высококвалифицированных специалистов, которые могут наблюдать и выявлять проблемы, чего не могут сделать метрики, основанные на логах. Обращаясь ко мнению и голосам разработчиков, организации могут получить информацию, которую ранее считалось невозможно получить.
Измерение продуктивности разработчиков с помощью данных, полученных от людей
Измерение производительности разработчиков — сложная задача. Традиционные метрики, ориентированные на время цикла разработки и пропускную способность — ограничены, и нет очевидных ответов на вопрос, к...
habr.com