One Metric To Rule Them All – Существует ли одна единственная универсальная метрика?

    «One Ring To Rule Them All»
    J.R.R.Tolkien

    «Управлять можно только тем, что можно измерить»
    П.Друкер


    Когда речь заходит о метриках, то на ум приходят десятки, а то и сотни различных вариантов.
    Каких только измерений не придумали!

    Но вот беда, когда смотришь на эти красивые картинки, часто бывает совершенно непонятно, что они обозначают.

    Да и вообще совершенно неясно, правильно ли были выбраны эти метрики или стоило бы смотреть на совершенно другие?

    Хочется какой-то одной метрики, такой, чтобы посмотрел, и всё сразу стало понятно.
    Но существует ли она? Или волшебства нет?

    Давайте разберемся и посмотрим на конкретном примере...

    Часто, всё, что мы имеем – только некий набор входных данных с которым не очень непонятно, что делать.

    Jira и её задачи


    Представьте, что в вашей компании используется таск-трекер Jira и все разработчики обязаны отмечать в нём события взятия задач в работу и их решения.

    Можно получить выгрузку по задачам Jira, но что с ней делать дальше?

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

    Почитайте, например, статью «Прозрение по метрикам: как я понял, что такое метрики и в чём их главная прелесть»

    А если добавить сюда еще и книги «Lean Analytics», «Running Lean» и Дао Toyota, то становится понятным, что в случае Jira правильнее всего управлять и измерять время поставки разработанного функционала в пром.

    Итак, цель выбрана – мы хотим измерять время поставки ПО, но сделать это можно сотней разных способов. Например, можно измерить длину каждого из шагов разработки, а еще добавить к этому измерения потери времени на ожидания, исправления дефектов, переоткрытия и т.п. Даже на вскидку можно назвать около 50-70 различных метрик, относящихся в разработке ПО.



    Как же быть? Существует ли та самая Одна Единственная Метрика, по которой одним взглядом можно всё понять?

    Если Вы видели своими глазами те десятки метрик, которых идёт речь выше, то я заранее знаю Ваш ответ – Вы скажет: Нет! А так хочется…

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

    Удивительно, но похоже, есть одна достойная метрика, которая может смело претендовать на звание Одной Единственной и Неповторимой.

    Давайте взглянем на неё поближе.

    Есть в Jira такой отчёт как «Диаграмма суммарного потока»…



    «Стоп-стоп-стоп… Его же все знают, — скажите Вы, ничего нового я тут не найду»
    В общем да, отчёт всем известный, но всё же давайте взглянем на него чуть более подробно. Уверяю, Вас ждёт несколько «приятных» сюрпризов.

    Вот как обычно он выглядит:



    Какие-то полосы. К чему они? Зачем? Что обозначают? А вот что…

    Тёмно-красная полоса – количество реализованных задач нарастающим итогом. Синяя – количество задач в работе, а желтая – новые задачи, зарегистрированные в бэклоге.

    Нарастающий итог это когда сделанные задачи всё время прибавляются количеству сделанных ранее.

    Например, представьте, что позавчера Вы сделали 2 задачи. На графике в позавчерашней точке будет отмечено: 2.

    Вчера Вы сделали еще 3 задачи. Следующая точка на графике будет равна 2(позавчерашние)+3(вчерашние)=5.

    А сегодня Вы сделали еще одну задачу. Сегодняшняя точка на графике будет равна 2(позавчерашние)+3(вчерашние)+1(сегодняшние)=6

    Т.е. график будет всё время увеличиваться.

    И вот, если расположить на графике количество сделанных задач, количество задач в работе и новых задач, то можно извлечь ту самую нашу Одну Единственную и Неповторимую Метрику.

    Рассмотрим реальный пример (выгрузка из Kibana и Elasticsearch):



    Видите?

    По сути, мы можем посчитать скорость (или производительность) разработки. 200 новых задач сделаны за 17 дней. Отсюда получаем, что текущая скорость скорость разработки – 11,76 задач/сутки, т.е. на одна задача выполняется 0,085 дня.

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

    При текущей скорости разработки 800 новых задач, созданных 17.06.2018, будут выполнены только через 68,03 суток.

    Нормально? По-моему, не очень.

    Говоряще? Однозначно!

    Вот еще один реальный пример (отчёт Jira). Это график исполнения тикетов службой технической поддержки:



    Точно также вычисляем производительность службы поддержки – 2,7 задач/сутки.

    Есть к чему стремиться


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

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

    В службе поддержки работает 15 человек. Получается, что на человека приходится 0,18 задач/сутки.

    Допустим, Вы захотели увеличить скорость исполнения и сделать так, чтобы служба смогла отрабатывать не 2,7 задач в сутки, а 10 (целевое значение).

    Один человек делает 0,18 задач в сутки, значит 10 задач сделают 56 человек.

    Ну, или как вариант, можно увеличить скорость работы одного человека.

    При скорости работы 1 задача в сутки, на 10 задач Вам понадобиться уже не 56 человек, а всего 10.

    Управляем временем поставки


    Получается, что метрика позволяет Вам, по сути, повлиять на время поставки.

    Сравнивая текущую производительность с целевым значением можно понять во сколько раз требуется ускорить процесс.

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

    А где еще это применимо?


    На самом деле аналоги метрики можно увидеть во многих областях.

    Возьмём, например, DevOps. DevOps используется для сокращения промежутка времени между созданием дистрибутива и его развёртывания на пром, т.е. здесь, также как и в примерах выше, нужно управлять временем поставки.

    Очевидно, что метрика идеально подходит и для DevOps. Просто посчитайте сколько дистрибутивов (сборок) дошло до пром за определенное время и получите текущую производительность Вашего конвейера.

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

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

    Вывод


    Как видите, Одна Единственная Универсальная Метрика всё-таки имеет право на жизнь, по крайней мере в области разработки ПО и в сервисных подразделениях (служба тех поддержки).

    Она с проста для расчета, содержит в себе смысл, и может быть использована для сравнения с целевым значением.

    Конечно, её нельзя применять бездумно. Перед тем как приступать к реализации подумайте, а действительно она Вам нужна.

    А что Вы думаете по поводу универсальной метрики?

    Какую метрику Вы используете в качестве универсальной?
    Поделиться публикацией

    Комментарии 11

      +2

      (почти оффтопик) Волшебство всё-таки есть. Но не совсем то, что требуется: стоит начать использовать любую из упомянутых вами метрик для оценки разработчиков — и она превратится в тыкву.

        0
        Да, согласен, что оценка людей — последнее дело. Она никогда никого до добра не доводила.
          0

          Ну, оценивать всё-таки приходится (иначе придётся всем зарплату давать одинаковую или случайную). Главное в процессе не сломать что-то нужное :-)

            0
            Моё мнение, что любая оценка людей субъективна и оценивает в первую очередь того, кто эту оценку дает :-)
            Особенно хорошо эффективность такой оценки видна в больших компаниях. Вернее, отсутствие какого-либо эффекта.
        0
        Я не понял. Судя по тексту, метрика — кол-во закрытых задач за единицу времени. Каким боком здесь участвует «Диаграмма суммарного потока»?
          0
          По диаграмме можно определить количество задач и время, за которое они были закрыты
            0

            Боже упаси от таких менеджеров, которые вместо управленческих решений смотрят в графики и считают скорость в задачах.
            Такое усложнение и сужение взгляда на управление просто верх некомпетентности.
            Не мешайте людям работать, смотрите на рузультат. Разработка ПО сильно сложнее чем снятие пары тривиальных метрик.
            Меня всегда удивляет, тот факт, что айтишники в основном с техническим образованием. Но при этом менеджеры сложную модель разработки пытаются уложить в 2-3 метрики и на их основе принимать решение, один скрам с велосити чего стоит.
            Нерадивые менеджеры отсутствие навыков управления пытаются компенсировать наличием нерелевантных метрик.

              0
              Приведите аргументы вместо обвинений.
              Почему Вы считаете, что метрика нерелевантная?
                0
                Сотрудник А закрыл за сегодня 10 задач на каждую из которых ему понадобилось 5 минут (поменять цвет кнопки, добавить уведомление и т.п.)
                Сотрудник Б закрыл за сегодня 1 задачу — добавление нового сложного функционала. И делал он ее 3 дня

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

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

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

                  Посчитав текущую производительность конвейера и сравним её с целевой Вы сможете это понять, верно?
              0
              Ну, или как вариант, можно увеличить скорость работы одного человека

              Мы, к примеру, узнали, что нам нужно 1,5 землекопа 10 менеджеров вместо одного, посмотрели свой бюджет и поняли, что можем максимум два. Значит, нам нужно придумать, как эту скорость увеличить. Поэтому мы идем и смотрим другие метрики, и не одну, ведь мы же не хотим нарушить целостность системы.

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое