вторник, 26 июня 2012 г.

(милли)метрики

(При написании этой статьи ни один Талеб не пострадал)


Так уж сложилось, что в моих приватных интернетах развернулось некоторое количество обсуждений метрик. Их слишком много чтобы отвечать всем по отдельности, так что отвечу всем скопом тут.

Сразу скажу что я, слава Б-гу, ниразу никогда не менеджер. Зато за свою жизнь я какой только ерундой по их велению не занимался. Чего стоят почасовые отчеты о рабочем дне, которые никто не читает, даже если там пообещать хороший коньяк (обещание до сих пор в силе, если что).

Почему мы хотим что-то мерить?


Есть старая, и не совсем корректная, цитата из Деминга:
"Вы не можете управлять тем, что не можете измерить"
Может из-за нежелания копаться в первоисточниках, а может еще по какой причине многие менджеры (да и не только менеджеры, чего уж там) свято верят в то, что управлять без измерений невозможно. В клинических случаях мы видим людей которые пытаются измерить все и делать далеко идущие выводы из этих измерений. Это явление можно встретить везде, так что на вермя можете забыть об исключительности и мессианстве IT отрасли.

Но тут есть ряд проблем.

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

Вторая - то, что многие очень важные вещи, которыми очень нужно управлять, совершенно невозможно нормально померить. Деминг приводит пример с обучением - персонал нужно и можно обучать, это стоит денег, процессом обучения нужно управлять, но корректно оцифровать это практически невозможно. Аналогично с поддержанием дома в порядке и воспитанием детей (это уже примеры из Экоффа). И если вы уже придумали как измерять воспитания детей, обучение или поддержание в порядке дома - лучше дочитайте до конца и подумайте раз двадцать.

Третья - проблема индукции. Другими словами - если мы что-то очень долго наблюдали, то это еще ничерта не значит что наши выводы на основе этих наблюдений будут верны (забудем зануду Канта - он мне не нравится). Талеб приводит для этого отличный пример с индюшкой которую кормят (причем все больше и лучше со временем), но через какое-то время наступает День Благодарения, для которого эту индюшку кормили. С точки зрения индюшки ничто не предвещало. У нее была крутая модель и отличная метрика по количеству приходящей жратвы (хорошо, точно и легко измеряется и прочая прочая, которую классический БДСМ-менеджер любит).

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

Но из песни слов не выкинуть - менеджер измеряет чтобы управлять.

Что мы можем мерить?


Собственно в предыдущем пункте все написано - мерить мы можем что угодно, если есть время, деньги и желание. Да, могут возникнуть некоторые проблемы с точностью (которая, кстати, вообще никакого значения не имеет) и особо ретивый менеджер может с легкостью завалить себя всем этим мусором, но со всем этим можно научиться так или иначе справляться.

Для наглядности возьмем метрику с богатой историей ректального применения - Defect Escape Ratio (мутационное тестирование страдает от подобного, но это отдельная история).

Дальше начинается тяжелейший сарказм, так что людям без чувства юмора читать крайне не рекомендуется.

Допустим мы хотим измерить качество тестирования (уже идея достойная Эйнштейна).
Для этого некоторым людям в голову приходит гениальная идея измерять это качество тем, сколько багов было обнаружено пользователями. 
У меня даже крутая формула есть - берем все баги обнаруженные пользователями, вычитаем из них те баги которые были зарепорчены тестировщиками (такое бывает, мы все знаем), делим на общее количество багов. Чтобы отсеить совсем уж ерунду - считаем только блокерокритикалы.
Если циферка сильно растет, то считаем что в тестировании что-то не так и нужно заняться ручным управлением. Если циферка уменьшается - менеджер крутой и может выдать себе премию.
Круто?
Нет.
У всего этого добра есть пара ньюансов:
  1. Приоритеты багов имеют свойство со временем меняться, так что ваш волшеный график в один прекрасный день может изменить все свое прошлое.
  2. Поток багов от юзеров подвержен все тем же проблемам что и поток багов от бетатестеров.
На втором пункте немного остановимся. Какие же это могут быть проблемы?
  • Ваш продукт настолько отстойный что никто не хочет даже баги репортить
  • Вам очень сложно зарепортить баг
  • Вам очень сложно понять что за ерунду зарепортил вам пользователь
  • Ваш продукт настолько интуитивно непонятен, что пользователю очень сложно добраться до самых бажных областей, а тестировщики там уже пару раз были
Можно еще много придумать отличных примеров, которые сведут все ваши статистические развлечения вокруг этой метрики к тому, что рано или поздно вы станете индюшкой на День Благодарения. И наверняка особо энергичный менеджер к этому дню успеет паре команд прописать различные "улучшения" процесса и/или мотивации.

Вместо послесловия


Очень не хотелось писать эту банальность (ее на курсе логики сдают в университете все), но придется в тысяча первый раз повторить.

Циферки, наверное, очень прикольны для управления, но в лучшем случае они могут показать вам что что-то не так. И даже самый хороший набор метрик ничего вам не гарантирует, т.к. отсутствие доказательства проблемы совсем не является доказательством отсутствия.

Так что когда вам в следующий раз захочется покататься на велосипеде в ночном лесу руководствуясь одним только дорогущим барометром - удачи.

4 комментария:

  1. Не смог сделать на iPad копипасту, пришлось оформить комментарий в виде статьи - http://xpinjection.com/2012/06/29/metrics-vs-diagnostics.

    ОтветитьУдалить
    Ответы
    1. Так да. Увы в литературе это повсеместно называется метриками и используется соответственно. Но и "диагностика" тоже плохое слово. Ставить диагноз на основе таких наблюдений нельзя. Только гипотезы выдвигать и бороться с проблемами вида confirmation bias. А если диагноз не ставится, то какая это к черту диагностика.

      Удалить
    2. И да, в случае того же мутационного тестирования DER'ом реально измеряют эффективность тестов.

      Удалить