The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Вопрос был задан на StackExchange девять лет назад (почти сразу после запуска сайта): “Если не строки кода, то какие метрики можно использовать для измерения эффективности удаленных программистов?”. Ответы предсказуемо шли в одном направлении: программистов не следует измерять! Я уверен, что ответившие сами были программистами. В самом деле, зачем программисту интересно быть измеренным и сводиться к простому числу?
Сначала давайте разберемся, почему установление метрики для программиста может считаться плохой практикой (мое мнение: это просто оправдания слишком оплачиваемых программистов/менеджеров, которые просто пытаются сохранить свои рабочие места, делая ничего что хотят и тратя деньги работодателя впустую):
«Менталитет героя, если не контролировать его, разрушает командный дух», говорит Бхуван Джайн, менеджер продукта в Quovantis.
“Оценки производительности разрушают мораль и уничтожают командный дух”, говорит Сэмюэл А. Калберт, профессор управления в Школе менеджмента Андерсона Университета Калифорнии в Лос-Анджелесе (UCLA).
“Индивидуальные награды способствуют конкуренции в среде, где сотрудничество является необходимым условием для успеха”, говорит Авиенаш Ширалиге, тренер по Agile в AgileBuddha.
“Индивидуальные метрики не способствуют командному сотрудничеству”, говорит Sean McHugh, Мастер Scrum в Axosoft.
“Обзоры производительности вредны и совершенно ненужны”, говорит Кейн Мар, сооснователь и главный консультант компании Scrumology.
“Измерение показателей производительности подавляет инициативу, инновации и риск,” говорит Джерри З. Мюллер, автор книги “Тирания показателей”. (Источник: aeon.co, press.princeton.edu, press.princeton.edu)
“Человеческую природу нельзя свести к числу”, говорит Джими Фосдик, сертифицированный тренер Scrum.
Как тебе такое? “Продолжай мне платить, но не ожидай, что я что-то верну! И не смей проверять мою производительность!” - это то, что я слышу, и меня это не удивляет. Это называется революцией в управлении производительностью, и суть в том, что современное управление настолько слабо, что нам срочно нужно официальное название для этого хаоса, чтобы избежать путаницы. Agile - это название.
Больше не менеджеры управляют, а программисты. И это печально.
Однако не все верят в эту анархию. Некоторые эксперты считают, что метрики на самом деле полезны. Брэдли Киркман и др. утверждают, что “признание одного участника команды кажется имеет положительный и заразительный эффект на всех остальных участников команды”, и знаменитая Кривая Жизнеспособности, предложенная Джеком Уэлчем в 2001 году, все еще с нами.
Я считаю, что вся негативность, направленная на метрики, вызвана их некорректным использованием. Действительно, если единственной метрикой производительности программистов, например, является количество часов, проведенных ими в офисе, это будет говорить только о плохих вещах в отношении всех метрик. Такие метрики действительно вредны, об этом нет сомнений. Но отсутствие хороших метрик вредит еще больше. Как их выбрать - это настоящий вопрос. Позвольте мне предложить несколько вариантов вместо известной и некорректной метрики LoC. Идеально было бы выбрать комбинацию из этого списка, или даже использовать их все вместе:
Объединенные запросы на слияние. Каждый запрос на слияние должен пройти проверку со стороны коллег, чтобы убедиться, что он логичен и соответствует стандарту качества проекта. Запросы на слияние, которые слишком малы или слишком большие, должны быть отклонены.
Исправленные ошибки. Ошибки работают так же, как и функциональные возможности, но обычно являются меньшими. Чем больше ошибок закрывает программист, тем лучше. Конечно, закрытие должно быть выполнено менеджерами продукта или другими программистами, которые сообщили об ошибке.
Сообщенные ошибки. Как только ошибка сообщена и принята проектом, автору сообщения начисляется дополнительный балл. Именно так проект повышает свою качественность: поощряя всех сообщать об ошибках.
Опубликованные релизы. В дисциплинированных проектах новые версии выпускаются каждый день; в других - каждую неделю или каждые несколько месяцев (или никогда). Каждый релиз является стрессовой операцией, и кажется логичным вознаграждать программистов за их выполнение.
Время работы. Существует набор метрик DevOps, который демонстрирует качество обслуживания в производственной среде, включая MTBF, MTTF, скорость отказов и так далее. Чем дольше время работы, тем лучше программисты и их продукт.
Стоимость запроса на слияние. Я считаю, что чем меньше времени занимает слияние запроса на слияние, поданным программистом, тем лучше сам программист. Чем быстрее их запросы на слияние проходят пиринговые обзоры и контроль качества, тем лучше. Младшие программисты обычно подают слишком большие или сложные запросы на слияние, вызывая много проблем во время пирингового обзора. Они также вызывают конфликты слияния и иногда даже заброшенные ветки и запросы на слияние, которые невозможно успешно слиять.
Опубликованные страницы документации. Страницы с часто задаваемыми вопросами (FAQ), блоки Javadoc, страницы вики, блог-посты и так далее – они помогают проекту приблизиться к пользователям и будущим разработчикам, улучшая поддерживаемость. Конечно же, каждый текст должен быть проверен перед публикацией.
Результаты учеников. Старшие программисты могут быть наставниками для более молодых коллег и могут быть вознаграждены за достижения своих учеников. Все вышеперечисленные метрики могут функционировать таким образом, вознаграждая или наказывая наставников в зависимости от успехов или неудач их студентов.
Я не могу достаточно подчеркнуть: каждая метрика должна иметь механизм контроля качества. Просто измерение сообщенных ошибок без проверки их качества приведет к мошенничеству: программисты будут сообщать о том, что им нравится, просто чтобы увеличить цифры. Каждую ошибку должен проверить архитектор: дубликаты или некачественные отчеты об ошибках должны быть отклонены. То же самое верно для каждой метрики: доверие без контроля ведет к мошенничеству.
Стоит также упомянуть, что функции, ошибки, запросы на включение изменений и страницы документации могут иметь разную сложность, срочность и серьезность, что также следует учитывать, увеличивая или уменьшая числа в каждой метрике.
Большую часть этих метрик можно собирать автоматически, без какого-либо взаимодействия с человеком, например, с использованием API GitHub.
В идеальном мире идеального управления проект компенсирует работу своих программистов в соответствии с собранными метриками. Вместо зарплат программисты получают деньги за функции, ошибки, страницы документации и так далее. Насколько далек ваш проект от этой утопии - это показатель вашей профессиональности как руководителя проекта. Плохие менеджеры ничего не измеряют и делают всех “счастливыми”, поддерживая высокие зарплаты и низкий контроль… пока деньги в проекте не закончатся. С другой стороны, исключительно хорошие менеджеры позволяют метрикам контролировать всех, делая лучших счастливыми и худших… быстро находящими путь к выходу.
Is there a metric to measure programmers' performance objectively?
— Yegor Bugayenko (@yegor256) July 19, 2020
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:14
