Метрики процесса review

Вы научитесь выбирать метрики, которые нельзя накрутить без пользы для дела; читать их как совокупность, а не по одной; и определять, какое именно изменение процесса стоит за сдвигом цифр.

Метрики кода — сложность, связность, покрытие — в теме Метрики качества кода курса Pro. Здесь только про процесс.

Единственное правило, определяющее, поможет измерение или навредит: метрики ревью измеряют процесс, а не людей. Как только «число комментариев» попадает в оценку работы, начинается соревнование в количестве замечаний, и качество ревью падает.

Показательные примеры того, как накручиваются самые популярные метрики:

Все пять достигаются без единого улучшения продукта. Поэтому метрики публикуются по команде, а не по людям, и обсуждаются на разборах процесса, а не на оценке производительности.

Единственное исключение — распределение нагрузки: доля ревью на человека нужна именно персонально, потому что перекос вредит и команде, и самому человеку. Но и она используется как сигнал перегрузки, а не как показатель усердия.

Проверьте себя. Есть ли в вашей компании метрика ревью, попадающая в оценку сотрудника? Что будет, если её начать накручивать?

Частая ошибка. Показывать таблицу «кто сколько комментариев оставил». Через месяц команда научится её улучшать, не улучшая ревью.

Метрик вокруг ревью можно построить десятки. Реально решения принимаются по четырём.

Время до первого ответа. Медиана, в рабочих часах. Главная метрика скорости: именно ожидание первого отклика формирует ощущение «мой PR никому не нужен». Ориентир — до 4 часов.

Время повторного ответа. Отдельно от первого. Почти всегда хуже, и почти всегда его не измеряют. Причина: после правок PR уходит в конец очереди ревьюера. При трёх раундах именно эта метрика определяет общее время.

Число раундов. Сколько раз PR возвращался автору. Растёт при плохом описании PR, при непонятных требованиях, при разной калибровке у ревьюеров. Ориентир — до двух.

Медиана размера PR. В строках содержательных изменений. Это не метрика ревью, а его главный входной параметр: большинство проблем с качеством и скоростью — следствие размера.

Полезное дополнение — распределение замечаний по уровням. Больше половины nit означает, что ревьюеры уходят в мелочи; меньше десятой доли blocker при большом объёме комментариев — что ревью поверхностное. Здесь важно не оптимизировать пропорцию, а замечать её резкое изменение.

Проверьте себя. Измерьте эти четыре числа за последний месяц. Скорее всего, повторный ответ окажется медленнее первого.

Частая ошибка. Смотреть среднее вместо медианы. Один PR, забытый на три недели, сдвигает среднее так, что оно перестаёт что-либо описывать.

Отдельная метрика почти всегда допускает противоположные объяснения. Смысл появляется в сочетаниях.

Последняя строка — напоминание, что метрики процесса ничего не говорят о качестве найденного. Хороший процесс с бесполезными замечаниями выглядит идеально на любом дашборде.

Проверьте себя. Сопоставьте свои четыре метрики с этой таблицей. Какая строка описывает вашу команду?

Частая ошибка. Реагировать на одну метрику. Ускорение ревью при больших PR даёт формальные одобрения — то есть ухудшение под видом улучшения.

Четыре метрики DORA описывают поставку в целом, и ревью влияет на две из них напрямую.

Время от коммита до прода включает ожидание ревью. В командах с медленным ревью это часто главная составляющая — до половины общего времени. Если вы улучшаете поставку, начинать разумно с измерения этой доли.

Частота развёртывания ограничена размером PR: крупные изменения выкатываются реже по определению.

Доля неудачных изменений и время восстановления связаны с ревью слабее, чем принято думать. Тщательное ревью снижает первую, но сильнее на неё влияют тесты и постепенная выкатка.

Практический вывод: если задача звучит как «ускорить поставку», посчитайте, какую долю времени от коммита до прода занимает ожидание ревью. Дальнейшие усилия имеет смысл прикладывать там, где эта доля наибольшая.

Проверьте себя. Какую долю времени от коммита до прода в вашей команде составляет ожидание ревью?

Частая ошибка. Улучшать частоту развёртывания, не уменьшая размер PR. Это верхняя граница, которую нельзя обойти.

Строки кода в любом виде. Меньше строк обычно лучше — метрика указывает в неверную сторону.

Число PR на человека. Зависит от типа задач сильнее, чем от продуктивности.

Число найденных багов на ревьюера. Создаёт стимул находить формальные проблемы и портит отношения в команде.

Процент одобренных с первого раза. Толкает к тому, чтобы не писать замечания.

Время, потраченное на ревью. Неизмеримо честно и провоцирует приписывать.

Общее у всех пяти: они измеряют активность, а не результат, и легко накручиваются. Полезная проверка перед вводом любой метрики: представьте, что команда решила улучшить её любой ценой. Если результат вам не понравится — метрика негодная.

Проверьте себя. Примените эту проверку к каждой метрике на вашем дашборде.

Частая ошибка. Собирать всё, что умеет выгружать платформа. Дашборд с двадцатью графиками не читают, и решений по нему не принимают.

Инженерный менеджер приносит квартальные цифры и предложение.

Предложение: «Процесс ревью значительно ускорился, шесть из семи метрик улучшились. Предлагаю закрепить практику и распространить на соседние команды. Рост инцидентов, вероятно, связан с увеличением объёма поставки».

Что видит опытный участник. Метрики ревью улучшились, а результат работы ухудшился почти втрое. Это классическая картина: процесс оптимизирован по показателям за счёт того, для чего он существует.

Читаем сочетания. Комментариев на PR упало с 8.7 до 2.3, доля PR с замечаниями — с 74 % до 31 %. То есть две трети PR теперь проходят без единого замечания. Одновременно время до первого ответа — 2.1 часа. Сочетание «быстро и без замечаний» при росте инцидентов означает одно: ревью перестало происходить, осталось одобрение.

PR на разработчика в неделю вырос с 4.2 до 11.4, а медиана размера упала с 310 до 95 строк. Само по себе уменьшение PR — то, к чему стремятся. Но втрое больше PR при том же составе команды и почти втрое меньший размер наводят на мысль о дроблении: одна задача разрезается на несколько PR, каждый из которых по отдельности не имеет смысла и потому не вызывает вопросов. Ревьюер видит «переименована переменная» и ставит одобрение, не понимая целого.

Раунды упали с 2.8 до 1.2 — что при осмысленном ревью почти невозможно. Обычно это следствие того, что замечаний нет.

И главное: рост инцидентов объяснён ростом объёма поставки, но объём в строках не изменился — изменилось только число PR. То есть поставляется столько же, а ломается втрое чаще.

Комментарии к предложению:

Чем закончилось. Перечитали 12 одобренных без замечаний PR, за которыми последовали инциденты. В девяти было что находить: в двух — отсутствие обработки ошибки, в трёх — неучтённый граничный случай, в одном — гонка. Все девять были частями раздробленных задач: ревьюер видел фрагмент и не мог оценить целое.

Выяснилась и причина ускорения: за квартал ввели цель «время до мержа меньше 8 часов» и показывали её по людям на еженедельной встрече. Люди начали дробить PR и быстрее ставить одобрения — ровно то, что метрика вознаграждала.

Изменения: цель по времени убрали из персональных показателей и оставили как командную; ввели правило «PR должен быть осмысленным сам по себе, дробление по слоям — да, механическое — нет»; на дашборд добавили долю изменений, приведших к инциденту, и поставили её первой строкой.

Через квартал: время до первого ответа 3.2 часа (чуть хуже), комментариев на PR 6.1, PR с замечаниями 62 %, инцидентов 6. Процессные метрики стали немного хуже, результат вернулся к норме.

Это самая важная иллюстрация урока: дашборд, на котором нет метрики результата, всегда будет улучшаться за его счёт.

Процессные изменения, которые двигают эти метрики, — Процесс и workflow. Технические настройки, влияющие на скорость, — Инструменты и интеграции. Метрики самого кода — Метрики качества кода.