*Изображение заголовка от Shen Comix
Производительность разработчиков — горячая тема в наши дни, особенно во время COVID-19, когда большинство из нас работает из своих домашних офисов. Руководители чувствуют сильную потребность в измерении производительности разработчиков и вводят метрики, которые выглядят очевидно надежными и хорошими с их точки зрения, но в действительности не имеют практически никакого отношения к сложной работе разработчиков, подрывая их мотивацию и моральный дух.
В этой статье мы подробно рассмотрим понятие производительности разработчика, выявим связанные с ним проблемы и узнаем от лучших гуру о том, как измерить производительность разработчика и как распознать качественные метрики.
Оглавление
Метрики производительности разработчика, которые не работают
Что не так с измерением производительности разработчика?
- Что такое выход разработчика?
- Что такое входные данные разработчика?
- Что такое феномен 10-кратной вариации?
Как максимизировать точность метрик производительности разработчика
10 лучших показателей производительности разработчика
- Частота развертывания
- Время выполнения
- Время цикла
- Время выполнения изменений
- Скорость
- Незавершенное производство
- Интенсивность отказов изменений
- Время восстановления обслуживания
- Показатель удовлетворенности клиентов
- Здоровье команды
Готовы ли вы улучшить производительность разработчиков?
Показатели эффективности разработчиков, которые не работают
Показатели эффективности разработчиков относятся к тому, насколько хорошо работают команды разработчиков и насколько успешны операции по разработке в компании.
Руководители стремятся измерить производительность команд разработчиков по ряду причин. Стив Макконнелл, эксперт по управлению проектами и программной инженерии, приводит следующие наиболее распространенные причины:
Самая большая проблема с измерением производительности разработчиков в настоящее время заключается в том, что менеджеры вводят метрики, которые практически не имеют смысла в отношении производительности разработчиков. Вот несколько наиболее распространенных примеров худших показателей производительности разработчиков:
- Отработанные часы
- Строки кода
- Исправленные ошибки
- Выполненные задачи
- Количество коммитов
- Баллы скорости
- Количество запросов на перетягивание
- Отгруженные функции
- Метрики компьютерной активности
Использование этих метрик с большой вероятностью нанесет ущерб моральному состоянию разработчиков и росту бизнеса: ни одна из них не учитывает опыт разработчиков, результаты бизнеса или то, чем на самом деле является программирование. Так же как строки кода не отражают усилий разработчика, количество исправленных ошибок не означает лучшего качества программного обеспечения, а низкая активность клавиатуры или мыши не означает вообще ничего. Напротив, эти метрики приглашают разработчиков играть с ними: писать ненужный код, создавать глючные программы или даже писать скрипты для имитации работы компьютера.
Компании, которые так поступают, просто ужасны. Я знаю одного человека, который работает в такой компании и потратил время на написание скриптов для имитации активности со случайными движениями мыши, нажатиями клавиш и т.д. из страха быть замеченным в бездействии в неподходящее время суток. Довольно яркий пример враждебной рабочей среды.
Теперь давайте посмотрим, почему производительность разработчиков так трудно измерить, почему большинство руководителей используют плохие показатели производительности разработчиков и существуют ли вообще надежные показатели.
Что не так с измерением производительности разработчиков?
Начнем с определения производительности, которая равна отношению объема производства к объему вводимых ресурсов.
Производительность = Выход / Вход
Эта формула выглядит просто, но многие вопросы, связанные с измерением производительности разработчиков, можно решить, вернувшись к этому определению, в частности, к тому, что мы понимаем под входом и выходом в работе разработчика. Если любой из этих компонентов определен неверно, то производительность не будет измерена объективно.
Что такое выход разработчика?
Что следует считать результатом работы разработчика? Строки кода, потому что это именно то, что производят разработчики? Это функциональные точки? Или исправленные ошибки? Напротив, эти показатели практически не имеют отношения к экономике бизнеса и сами по себе не отражают степень усилий разработчика.
Если мы уберем экономику бизнеса из определения результата, то получим определение производительности, изолированное от прибыли бизнеса. Допустим, работа над проектом была завершена успешно, но продукт оказался полным провалом на рынке, поэтому он не имеет потенциала для получения дохода. Если судить с этой точки зрения, имеет ли значение, что проект был завершен вовремя и работа разработчиков была эффективной?
Что такое вклад разработчиков?
Вклад относится к инвестициям, сделанным разработчиками, таким как время и усилия. Сравнение времени по видам деятельности не имеет смысла, поскольку деятельность разработчиков представляет собой нечто большее, чем набор схожих задач — она включает в себя различные степени сложности, сотрудничество и другие факторы, которые подрывают надежность одной лишь метрики времени.
Или как измерить усилия разработчика? Программное обеспечение для отслеживания активности пыталось измерить «продуктивное» поведение пользователей, регистрируя щелчки мыши, нажатия на клавиатуру, типы используемых приложений и веб-сайтов и время, проведенное на них. Хотя это минимальная единица измерения деятельности разработчика, она не имеет ничего общего с продуктивностью или усилиями.
Если вы углубитесь в изучение возможных входов и выходов, вы не сможете определить, что такое вход и выход разработчика, а это значит, что вы вряд ли сможете выбрать надежные метрики производительности разработчика. Более того, точность этих измерений, скорее всего, будет подвержена феномену 10-кратной вариации.
Что такое феномен 10-кратной вариации?
В 1968 году Сакман, Эриксон и Грант провели исследование, в котором попытались определить, насколько продуктивнее люди программируют онлайн или офлайн. Они изучили профессиональных программистов со средним стажем работы 7 лет и обнаружили следующее:
- Диапазон времени начального кодирования: 20:1
- Диапазон времени отладки: 25:1
- Диапазон размеров создаваемых программ: 5:1
- Диапазон скоростей выполнения программ: 10:1
Они обнаружили, что не смогли определить, какая группа программистов была более продуктивной, поскольку индивидуальные различия в производительности заглушали различия, связанные с онлайн и офлайн производительностью. Таким образом, различия, обнаруженные во времени кодирования, времени отладки и размере программы, подтверждают общее утверждение о различиях в производительности, т.е. о 10-кратной разнице.
С 1968 года был проведен ряд аналогичных исследований. Взгляните на их коэффициенты продуктивности для команд и отдельных людей.
Все эти исследования доказывают, что различия в продуктивности очень велики как на индивидуальном, так и на командном уровне, что позволяет сделать следующие выводы:
Результаты этих исследований доказали, что если мы измеряем влияние какого-либо процесса, практики или фактора окружающей среды, то измерения будут подвержены фактору 10-кратной индивидуальной вариации, что означает, что они вряд ли будут достоверными.
А если мы попытаемся оценить индивидуальную или командную производительность, то эти измерения будут сбиты с толку различиями в процессах, практике или окружающей среде между проектами.
Как максимизировать точность показателей производительности разработчиков
Хорошая новость заключается в том, что мы можем максимизировать точность метрик. Стив Макконнелл разработал список признаков для определения надежных показателей производительности. Более того, он оценил в соответствии с ними наиболее часто используемые измерения производительности разработчиков на уровне команды:
Итак, ведущим измерением является scorecard: она содержит набор метрик производительности разработчиков, что делает ее высоконадежной и точной в плане отражения производительности. Если вы включите метрики, учитывающие трудозатраты всей команды и отражающие полученную бизнес-ценность, ваша система показателей будет отображать наиболее точную оценку производительности разработчиков с 10-кратным коэффициентом индивидуальной вариации, сведенным к минимуму.
Даже если вы не хотите вводить оценочные листы, самый главный урок заключается в том, чтобы полагаться на набор метрик, учитывающих вклад и результат разработчиков, и избегать отдельных показателей, таких как строки кода (самые ненадежные, согласно оценкам Стива Макконнелла), выполненные задачи, сделанные коммиты или отгруженные функции.
Итак, давайте посмотрим, какие лучшие метрики производительности разработчиков вы можете начать отслеживать в своей команде разработчиков.
10 лучших показателей эффективности разработчиков?
Ниже мы собрали 10 лучших показателей производительности разработчиков для команд, признанных Google (4 метрики DORA), Аби Нода — старшим менеджером по продуктам в GitHub и Роем Ошеровым — автором книги «Искусство модульного тестирования» и «Записки руководителя команды разработчиков» с более чем 20-летним опытом работы в технической & роли тестировщика.
1. Частота развертывания (DORA)
Что измеряет: Как часто организация успешно выпускает продукт в производство.
Измерение: Развертывания в день
Потенциал воздействия: Повышение ценности для клиентов за счет сокращения времени выхода на рынок.
2. Время выполнения заказа
Что измеряет: Сколько времени проходит между началом разработки проекта и его сдачей заказчику.
Измерение: Время выполнения заказа в днях
Потенциал воздействия: Повышение точности планирования проекта
3. Время цикла (Рой Ошеров)
Что измеряет: Сколько времени занимают отдельные этапы проекта.
Измерение: Время цикла в днях
Потенциал воздействия: Повышение точности планирования проекта
4. Время подготовки к изменениям (DORA)
Что измеряет: Сколько времени требуется для внедрения изменений в производство.
Измерение: Время выполнения в днях
Потенциал воздействия: Повышение эффективности работы разработчиков
5. Скорость (метрика Agile)
Что она измеряет: Объем работы, который ваша команда может выполнить за определенный промежуток времени (спринт).
Измерение: Человеко-часы или сюжетные точки
Потенциал воздействия: Улучшение планирования проекта и спринта
6. Незавершенное производство (метрика Agile)
Что измеряет: Состояние незавершенной работы.
Измерение: Количество незавершенных задач
Потенциал воздействия: Выявление узких мест и невозвратных затрат.
7. Частота неудачных изменений (DORA)
Что измеряет: Процент развертываний, приводящих к ухудшению обслуживания, которое необходимо устранить.
Измерение: Количество инцидентов, деленное на количество развертываний.
Потенциал воздействия: Повышение удовлетворенности клиентов за счет снижения количества отключений.
8. Время восстановления обслуживания (DORA)
Что измеряет: Сколько времени требуется организации для восстановления после сбоя в
производстве
Измерение: Время восстановления в часах
Потенциал воздействия: Повышение удовлетворенности клиентов за счет снижения количества отключений.
9. Показатель удовлетворенности клиентов
Что измеряет: Насколько клиент удовлетворен вашей продукцией или услугами
Измерение: Опросы со шкалами и открытыми вопросами
Потенциал воздействия: Улучшение отношений с клиентами и повышение удовлетворенности
10. Здоровье команды (Agile)
Что измеряет: Распределение работы между членами команды
Измерение: Распределение рабочих элементов по типу и количеству
Потенциал воздействия: Создание справедливого распределения рабочей нагрузки в команде
Готовность к улучшению производительности разработчиков
Измерить эффективность работы разработчиков непросто: вам необходимо отслеживать показатели управления проектами, рассчитывать затраты и прибыль бизнеса, а также полагаться на показатели времени, чтобы максимально точно планировать проекты. Сегодня большинство из этих задач можно решить с помощью систем управления временем и проектами.
Например, actiTIME предоставляет систему управления временем и проектами, в которой вы можете управлять рабочей нагрузкой, просматривать ход выполнения проектов, видеть затраты и прибыль бизнеса и многое другое.
Создавайте пользовательские рабочие процессы, назначайте задачи членам вашей команды и смотрите, как распределяются временные и денежные затраты между задачами, этапами проекта, проектами и клиентами.
Устанавливайте сроки, оценки времени, бюджеты времени и затрат. Создавайте пользовательские поля для задач, чтобы улучшить отчеты о времени, затратах и производительности и увидеть, как работают похожие элементы.
Выбирайте из 2 000+ интеграций, включая JIRA, GitHub и JitLab. Присоединяйтесь к 10 000+ компаний, таких как DHL, Huawei, Philips и Xerox — попробуйте бесплатную 30-дневную пробную версию (кредитная карта не требуется).