Прочитал на днях критическую статью на тему применения метрик менеджерами и захотел оставить комментарий. Но он получился достаточно большой и вырос в небольшую статью.
На мой взгляд все просто – автор путает понятия метрики и диагностики. Метрика служит для прямого отображения действия, а диагностика – всего лишь для отображения следствий. Например, если я рублю дрова для заказчика, то количество нарубленных дров является отличной метрикой. И ее можно успешно использовать для поощрений, наказаний, анализа производительности. Похожим образом обстоят дела и у рабочего за станком. Метрикой в данном случае является количество готовых качественных деталей. Никого не волнует как и почему их получилось столько.
У нас в IT индустрии настоящих метрик достаточно немного. К ним можно отнести количество нарушений при статическом анализе кода, сложность кода, плотность покрытия модульными тестами (с большими оговорками), Running Tested Features, Cycle Time, Lead Time и некорые другие. Большая же часть повсеместно используемых измерений, включая приведенное автором статьи количество найденных багов заказчиком или пользователями, являются диагностиками.
Диагностика является лишь способом понять, что где-то могут быть проблемы, но никак не выявить их. Например, врач измеряет мне температуру. Если температура высокая, то есть повод разбираться детальнее – сдать анализы, пройти другие диагностики, показаться другим врачам. Но врач не ставит диагноз по одной только температуре. Так же как и не говорит, что у вас все отлично, если температуры нет. У вас могут по-прежнему быть проблемы с сердцем, печенью, глазами и прочими органами.
Теперь вернемся к примеру из статьи. Количество найденных багов конечными пользователями – очень важная диагностика для меня. Если их много, то явно где-то есть проблема и надо разбираться. Если мало, то не стоит думать, что все хорошо. Но для начала стоит проверить не мешает ли что-то правильному сбору диагностики (список возможных препятствий приведен в статье). Метрикой же она являться не может, потому что найденный баг может иметь десятки разных причин и не характеризует работу команды напрямую.
Иногда между метрикой и диагностикой очень тонкая грань. Но не осознав истинной сути измерения, можно “наделать дел”. О неправильном применении метрик уже рассказано и написано много смешных историй. А что вы думаете по этому поводу? Какие еще примеры ошибочного применения вы встречали? Какие еще настоящие метрики в IT вы знаете? Буду рад услышать ваше мнение в комментариях.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Если решение правильной проблемы ему не нужно, то пусть не разбирается и палит наугад – может повезет. Только тогда непонятно зачем вообще считать – пустая трата сил и времени.
Обобщать можно и нужно. К примеру, CEO компании совершенно неважно, что среди 1000 сотрудников есть тестировщик Вася, который любит на работе смотреть фильмы. Уровень немного другой. Для него команды – крупные неделимые единицы. И для заказчиков многих точно так же.
Так можно дойти до абсурда. Смотришь, а у тебя денег не осталось. А ты и не паришься – мало ли почему их не осталось, ведь миллион причин может быть. Зачем разбираться?
Я все время забываю что некоторые люди живут и работают в аутсорсинге 🙂
Усложнять надо. Детали прятать не надо. Всеми этими некорректными обобщениями и упрощениями мы сами себе заботливо раскладываем грабли на будущее. Ровно как и шаблонным мышлением, когда из всех возможных выводов по изменению циферки делаем те к которым привыкли/которые нам больше нравятся.
Не усложняй. Дрова я заказал и их привези, лежат во дворе. Лесоруба я нанял их только порубить.
Приведенные метрики работают замечательно, потому что скрывают ненужные детали. Если я заказчик, то мне важно с какой скоростью команда переводит мои идеи в рабочий продукт. Скорость упала – беда, поднялась – хорошо. А есть у вас тестировщик или нет, работаете по Agile или по code & fix – мне все равно. Если показатели метрики упали, стоит разобраться почему. А глубже пусть компания подядчик разбирается. 🙂 Там есть свои метрики и диагностики.
Система хотя бы потому что у лесоруба откуда-то берутся дрова. Факап на поставке дров и производительность упала. И лесоруб тут ни при чем от слова “вообще”. И тысячи таких мелочей.
Running Tested Features, Cycle Time и остальное что тут названо метриками страдает от точно тех же проблем – они просто показывают что работать стало медленнее, например. Или фичи стали больше. А причин может быть море – заказчик тормозит, технический долг поднакопился, Вася заболел и так до бесконечности.
В этом же и отличие, о котором я и говорю. Лесоруб в данном случае не система (если ты конечно не будешь рассматривать руку лесоруба, мозг и топор как части надуманной системы). Поэтому я и могу метрику применять. И мне все равно как лесоруб будет улучшать свою производительность – может купить крутой топор, нанять помощника и т.д. В случае твоего примера с багами действительно действовала сложная система и неясно кого винить.
Ты, как заказчик, оцениваешь исходящее из системы. Т.е. рассматриваешь систему производящую полезные тебе дрова в целом (это несколько больше чем просто лесоруб), а не конкретного лесоруба. Подмена того что ты оцениваешь приводит к тому что ты будешь пытаться исправлять/мотивировать лесоруба даже в случаях когда это проблема системы.
Это слишком поверхностное отношение к метрикам. К слову, measurable имеет однокоренным существительным measurement – измерение, а не метрику. Так вот не любое измерение является метрикой. 🙂
На мой взгляд метрика это то, что поддается измерению, или как говорят что-то measurable. Так что измерение температуры это метрика.
Ну а диагностика это… поиск неисправностей. Частным случаем можно считать и просто ручное тестирование: “я вот … там … это делаю и … а потом ломается” – все проблема диагностирована.
Зря ты так думаешь. Мне как заказчику совершенно все равно почему и как появились дрова. Для меня важно их количество и критерии качества (размер например). Критерии я устанавливаю жестко, иначе просто не принимаю работу. Плачу за количество дров, поэтому чем больше их, тем более производительный с моей точки зрения лесоруб.
С “нарубленными дровами” как оценкой эффективности есть большая проблема – ее нельзя использовать для наказаний, поощрений и анализа производительности.
1. Мы можем упереться в определение того какие дрова считать нарубленными. Ну ок, избавляемся от упырей и такие споры сами исчезнут. Может быть.
2. Скорость нарубки дров совсем не обязательно зависит от лесоруба.