Чарльз Гудхарт, главный советник по денежно-кредитной политике Банка Англии и профессор Лондонской школы экономики и политических наук постулировал в 1975 году, что
Любая наблюдаемая статистическая закономерность склонна к разрушению, как только на неё оказывается давление с целью управления
Принцип означает, что попытка управлять системой через жесткие метрики приводит к манипуляциям ими, что искажает реальную картину и разрушает полезность показателя.
«Когда мера (показатель) становится целью, она перестает быть хорошей мерой»
Системы, использующие измерения, стимулируются к определенному поведению — они самооптимизируются. Построение систем с использованием плохих показателей не останавливает их самооптимизацию, они просто оптимизируются в направлении чего-то, чего вы не хотели.
Примеры подобного, встречаются в разных областях, в применении к ИТ можно наблюдать:
Поддержка: Оценка работы техподдержки по скорости закрытия тикетов приводит к тому, что операторы быстро закрывают их, не решая проблему
Разработка: Измерение эфективности разработчиков к строках кода
или комитах, приводит к эмитации работы.
Качество: Измерения качества продукта в количесвте дефектов, приводит к сокрытию дефектов, объеденению многих в один, передаче информации мимо системы управления задачами и т.п. Покрытие кода тестами, приводит к покрытию тестами всего подряд от простейших функций до создания псевдо позитивных асертов.
Управление:Измерение производительности команды количеством стори поинтов и велосити, приводит к раздуванию оценок, изменению процесса в угоде формально закрыть больше задач, например отрезая не готовый кусок в новую сторю следующего спринта и подобная дичь.
Как с этим жить, чтобы избежать негативных последствий
Избегать метрик-мешений, которых необходимо достичь любой ценой. Постараться исспользовать метрику как индикатор процесса, который может колебатся в некоторых пределах, и всего лишь отрадажает, что в системе происхоят некоторые события. Представьте что у вас есть метрика-мешень, держать температуру тела 36.6, как бы изменилось поведение, если бы награждали или наказывали за отклонения.
Использовать набор разнообразных метрик, которые не связаны линейно, так называемые балансировочные метрики. В идеале иметь пару которая работает в противовес измеряемой метрики, делая попытки манипуляции бессмысленными. Например:
Инфляция сторипоинтов
Основная метрика: Velocity или обязательство закрыть X% задач спринта.
Балансировочная метрика: Качество реализации (например, количество новых багов, связанных с завершёнными задачами, или прирост задач в бэклоге из-за технического долга). Количество сторей выпущенных в релизе.
Как это работает: Погоня за скоростью приводит к инфляции сторипоинтов и накоплению долга (по качеству, технического, незавершенки). В итоге команда может рапортовать о успешном закрытии задач спринта или деливери 100 стори поинтов, но при этом генерировать еще 50 в тех долг и не приводить к финальной отгрузки функционала для пользователей. При комплексном наборе измеряемых показателей, мы смещаем цель с «закрыть как можно больше в спринт» на «отгрузить готовую фичу с минимальным количеством дефектов».
Материалы по теме:
Тирания показателей. Как одержимость цифрами угрожает образованию, здравоохранению, бизнесу и власти | Мюллер Джерри |
