5 советов по измерению продуктивности разработчиков
3 июня 2023 г.Технологии нашли свое применение во всех аспектах современного рабочего места. Эксплуатационные расходы, безопасность, связь, удовлетворенность сотрудников и клиентская база — все это часть технологического уравнения. Сообразительный ИТ-директор знает, что существует прямая зависимость между высокоэффективной ИТ-организацией и успешным бизнесом.
SEE: Получите навыки Agile и Scrum, которые помогут повысить вашу производительность.
Как технологический лидер, вы должны отстаивать способность измерять, насколько быстро работает ваша команда и движется ли она в правильном направлении. Вы не можете улучшить то, что не измеряете.
Перейти к:
- Учитесь на недостатках предыдущих подходов к измерению
Используйте подход, основанный на данных, для измерения доставки программного обеспечения
Учитывайте другие факторы, влияющие на эффективность команды.
Выделите время для оценки данных о производительности
Стимулируйте изменения на основе данных о производительности
Учитесь на недостатках предыдущих подходов к измерению
Попытка оценить, как работает техническая команда, может быть сложной задачей. Команда — это совокупность личностей. А в случае ИТ-организации эти люди выполняют отдельные сложные задачи. На протяжении многих лет менеджеры групп разработчиков программного обеспечения перепробовали множество подходов к измерению производительности, большинство из которых страдают двумя фундаментальными недостатками:
- Ориентация на результат, а не результат.
Акцент на отдельных людях, а не на командах.
Эти несовершенные подходы породили несколько анти-шаблонов, которые не только не обеспечивают значимых показателей производительности, но и могут привести к ухудшению морального духа команды.
Строки кода
Возможно, самая известная и самая ненавидимая неудачная попытка измерить производительность разработчиков — это подсчет строк кода. Существует небольшая корреляция между тем, сколько строк кода пишет разработчик, и общей ценностью, которую разработчик приносит организации.
Фактически, вознаграждение разработчиков за написание строк кода приводит к раздуванию кода и, в конечном итоге, к более высоким затратам на его поддержку.
Скорость
С преобладанием Agile в разработке программного обеспечения в какой-то момент некоторые тренеры Agile, вероятно, порекомендуют использовать скорость как способ измерения производительности вашей команды. Скорость команды, а не скорость отдельных участников, является полезным показателем для планирования рабочих нагрузок.
Однако в качестве меры производительности он не оправдывает ожиданий. Приравнивание скорости к производительности только заставит разработчиков завышать оценки, тем самым не только искажая эффективность команды, но и потенциально обесценивая полезность измерения при планировании загрузки.
Использование
Во многих консалтинговых организациях загрузка разработчика — то есть, сколько времени он тратит на работу над кодом — используется в качестве показателя производительности. Это вдвойне ошибочно, потому что мы все знаем, что усилия не всегда означают результат, и потому что эта мера стимулирует менеджеров проектов заставлять разработчиков работать на 100%.
В математике теория очередей говорит нам, что когда загрузка достигает 100%, время выполнения заказов приближается к бесконечности. Это потому, что ресурс, используемый на 100 %, не способен к инновациям, улучшениям или изменениям.
Используйте подход, основанный на данных, для измерения доставки программного обеспечения
В 2018 году Николь Форсгрен, Джез Хамбл и Джин Ким опубликовали статью Accelerate, которая включала кластерный анализ более 23 000 ответов от более чем 2 000 уникальных организаций. Они обнаружили четыре общие характеристики в данных, которые помогли классифицировать команды разработчиков программного обеспечения как высокоэффективные, среднеэффективные и низкоэффективные:
- Время внесения изменений: сколько времени требуется, чтобы перейти от фиксации кода к запуску в производство?
Частота развертывания: как часто ваша команда доставляет обновления программного обеспечения для активной клиентской базы?
Среднее время восстановления: сколько времени требуется вашей команде для восстановления службы при обнаружении сбоя в рабочей среде?
Интенсивность неудачных изменений: какой процент изменений в производственной среде впоследствии требует исправления?
Источник таблицы: Accelerate, опубликовано IT Revolution 2018.
Учитывайте другие факторы, влияющие на эффективность команды.
Помимо мер, строго основанных на коде, есть несколько культурных факторов, которые могут помочь оценить, как работает ваша команда разработчиков программного обеспечения.
- Информация активно разыскивается членами команды.
Мессенджеров не наказывают за плохие новости.
Обязанности разделены.
Кросс-функциональное сотрудничество вознаграждается.
Неудачи рассматриваются как возможности для улучшения.
Новые идеи всегда приветствуются.
Выделите время для оценки данных о производительности
Как только вы узнаете, какие показатели показывают, как работает команда, вы как ИТ-директор должны выделить время и ресурсы для создания панели мониторинга для измерения. Скорее всего, необходимые данные не будут поступать из одного места, поэтому вам нужно будет собирать и преобразовывать данные из нескольких источников, а затем использовать специальный инструмент визуализации, такой как Tableau или PowerBI, для их представления.
Лучше начать с простого и расширяться там, где вы получаете наибольшую ценность. Часто вы можете получить большую часть необходимых количественных данных из API вашей системы контроля версий и конвейеров кода. Для более качественных показателей рассмотрите возможность использования ежеквартальных опросов.
Стимулируйте изменения на основе данных о производительности
В конце концов, сбор данных и метрик, даже небольшой, будет напрасным трудом, если организация не будет постоянно проверять данные и использовать их для корректировки курса.
Несмотря на то, что вы можете получить определенные преимущества, если доверите это отдельным командам, организация, выделяющая время для регулярного анализа показателей, сбора информации и внесения изменений на основе данных, — это самый быстрый путь к тому, чтобы стать высокоэффективным ИТ-предприятием.
Оригинал