Почему ваши Agile-метрики могут вас обманывать
Представьте: статистика по решению ошибок в вашей команде выглядит как золотые медали Олимпиады. Но качество продукта разваливается, как дешёвый костюм в сезон дождей. Добро пожаловать в театр Agile-метрик — где то, что измеряется, поддаётся манипуляциям, а то, что поддаётся манипуляциям, в конечном итоге калечит ваш продукт.
Я видел, как это происходит. Три года назад CTO с гордостью внедрил целевые показатели «количество решённых ошибок за спринт». Через несколько месяцев разработчики:
- регистрировали незначительные изменения в пользовательском интерфейсе как «ошибки»;
- пропускали код-ревью, чтобы увеличить индивидуальные показатели;
- избегали сложных функций, как вампиры — чеснока.
Метрики сияли ярко. Продукт? Он стал цифровой свалкой.
Соблазнительная иллюзия контроля
Agile-метрики обещают ясность, но часто доставляют камуфляж. Учтите эти скрытые ловушки:
1. Вихрь тщеславных метрик Команды тяготеют к метрикам, которые делают их хорошими, а не эффективными. Скорость? Она надёжна, как прогноз погоды в урагане. Как отмечает Age-of-Product, скорость искажается из-за:
* изменений в составе команды (приём на работу/увольнение);
* непредвиденной технической задолженности;
* даже плохой еды в столовой (совершенно серьёзно!).
2. Налог на инновации Когда «завершённые стори-пойнты» становятся священными, команды избегают работы с высоким риском и высокой наградой. Зачем создавать следующую Tesla, если можно выпускать велосипедные клаксоны весь квартал?
3. Слепота к контексту Метрики выхода игнорируют результаты. Исправление 100 ошибок звучит героически — если только это не опечатки, в то время как критические уязвимости безопасности остаются без внимания. Platinum Edge подводит итог идеально:
«Люди ведут себя в соответствии с тем, как их измеряют. Метрики, ориентированные на результаты, упускают из виду желаемые результаты».
Когда метрики становятся токсичными
Реальные катастрофы из-за неправильного использования метрик:
Метрика | Предполагаемая цель | Фактический результат |
---|---|---|
Ошибки/спринт | Качество | Поверхностные обзоры; игнорирование сложной работы |
Скорость | Предсказуемость | Завышенные оценки; выгорание |
% Запланированной работы | Фокус | Игнорирование чрезвычайных ситуаций у клиентов |
Как обнаружила одна команда (Вибхор Чандел), цель «решённые ошибки» привела к краху парного программирования и поощрила игру с тикетами. Результат? Увеличение показателя на 500%, маскирующее ухудшение качества на 500%.
Построение здравомыслящей системы метрик (не сжигая при этом свою команду)
Шаг 1: «Зачем» — допрос
Перед отслеживанием любой метрики задайте ей вопросы:
- «Эта метрика измеряет ЦЕННОСТЬ или ЗАНЯТОСТЬ?» (Подсказка: время цикла > стори-пойнты)
- «Можно ли её исказить? Как?» (Если ответ «да», переработайте её)
- «Поможет ли это нам УЧИТЬСЯ или просто СУДИТЬ?»
Шаг 2: Исправление обратной связи
Годовые обзоры метрик? Это как диагностировать аппендицит с помощью рентгеновского снимка прошлого года. Вместо этого:
Пример: замените «спринт-сгорание» на «процент успешных задач пользователей после релиза»
Шаг 3: Протоколы защиты от манипулирования
Постройте метрики, которые самостоятельно корректируют манипуляции:
- Метрики коллегиального рецензирования: команда еженедельно голосует за «наиболее ценного участника» (а не за «самого продуктивного»).
- Сопряжённый результат: отслеживайте скорость вместе с оценками удовлетворённости клиентов.
- Анонимность: используйте такие инструменты, как FunRetro, для честных обзоров спринтов.
«В тот момент, когда метрика становится целевым показателем, она перестаёт быть хорошей метрикой». — Закон Гудхарта в действии.
Человекоцентричная альтернатива
Попробуйте эти нетрадиционные показатели:
- Журнал «Что за/Неделя» Подсчитайте, как часто товарищи по команде говорят: «Почему это так сложно?» (Высокие показатели сигнализируют о технической задолженности).
- Индекс «дай пять» Измеряйте количество межкомандных взаимодействий на функцию.
- Оценка тишины Отслеживайте продолжительность молчания на встречах (Чем больше тишины, тем выше психологическая безопасность). Команда Klaxoon известна тем, что заменила отчёты о спринтах на «Стену замешательства» — физическую доску, на которую разработчики прикрепляли то, что они находили сбивающим с толку. За несколько недель это выявило больше узких мест, чем любая диаграмма спринта.
Заключение: метрики как компасы, а не кандалы
Agile-метрики должны освещать путь, а не заключать в тюрьму. Когда ваши информационные панели начинают напоминать проверки у надзирателя, помните: лучшие команды измеряют, чтобы учиться, а не чтобы зарабатывать или искупать вину.
В следующий раз, когда вы увидите красивую диаграмму сгорания, спросите: «Это маяк, который нас направляет, или просто фейерверки, ослепляющие заинтересованные стороны, пока корабль тонет?»
Что касается той команды, которая занималась «решёнными ошибками»? Они отказались от этой метрики, ввели беспристрастные постмортемы и теперь измеряют только две вещи: радость клиентов и частоту развёртываний. Ошибки? Они снизились аутентично на 70%. Иногда лучшая метрика — это вообще отсутствие метрик.