Портал №1 по управлению цифровыми
и информационными технологиями

Метрика эффективности потока, похоже, совершенно бесполезна

Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику Flow Efficiency. Действительно, ещё со времён увлечения Lean нам известно, что далеко не всё время, которое заготовка проводит в нашей производственной системе, над ней кто-то работает. Существенную часть времени она находится в очередях, в ожидании, перемещаясь между участками работы и так далее. Потери, одним словом. Плохо.

И Lean, и Канбан-метод, и даже ребята из DevOps советуют измерять эффективность потока путём деления времени, потраченного на собственно работу по созданию ценности, на общее время, которое задача провела в потоке.

К примеру, вот что написано в словаре книжки “Essential Kanban Condensed” за авторством Д. Андерсона и А. Кармайкла:

Flow Efficiency — the ratio of the time spent working on an item (Touch Time) to the total Time in Process; measured in percentage.

Touch Time — the sum of all the times during which a work item is actively being worked on (excluding wait times; e.g., being held in stock or in queues; measured in units of time.

Time in Process — the total time that a work item remains in a state under consideration; measured in units of time. Alternatives: Lead Time (when referring to the time in process from the commitment to delivery point).

Книга “DevOps Handbook” (авторы Дж. Ким, Дж. Хамбл, П. Дебуа, Дж. Уиллис) в целом повторяет ту же мысль:

In the Lean community, lead time is one of two measures commonly used to measure performance in value streams, with the other being processing time (sometimes known as touch time or task time).

Whereas the lead time clock starts when the request is made and ends when it is fulfilled, the process time clock starts only when we begin work on the customer request — specifically, it omits the time that the work is in queue, waiting to be processed.
Because lead time is what the customer experiences, we typically focus our process improvement attention there instead of on process time. However, the proportion of process time to lead time serves as an important measure of efficiency—achieving fast flow and short lead times almost always requires reducing the time our work is waiting in queues.

Итак, раз учёные рекомендуют, нужно использовать. Вернёмся к формуле, рассмотрим сначала знаменатель.

Как посчитать Time in Process? Казалось бы, всё просто: это же то же самое, что Lead Time (намекают нам авторы “Essential Kanban Condensed” и “DevOps Handbook”). Поэтому если в нашей производственной системе чётко определено событие “Start”, начало работы, а также событие “Done!”, завершение работы, то достаточно вычесть из второго первое, получим Time in Process. Так ли это? Похоже, что нет. Таким расчётом мы получим астрономическое время, которое задача провела в потоке. Если наш поток работает круглосуточно прекрасно, можно использовать. Однако в большинстве случаев сотрудники в ИТ работают только 8 часов в день, и только в рабочие дни. Если не учитывать доступное рабочее время, то мы легко можем получить, что задачу довольно оперативно сделали за три дня, потратив, скажем суммарно 24 рабочих часа, но в потоке она провела три календарных дня, то есть 72 часа. Эффективность потока по формуле 33,3%, по факту 100%. Ерунда. И это мы ещё не рассматриваем ситуацию перехода через выходные.

Предположим, что мы хотим учитывать доступное рабочее время. Если бы в нашем потоке был один исполнитель, всё было бы просто: это его рабочий календарь и есть. Но во всех известных мне потоковых системах исполнителей немного больше. Чей календарь учитывать, если аналитики располагаются в Новосибирске, разработчики в Москве, а инженер по тестированию работает на полставки, потому что у неё ребёнок маленький? Рабочий график у всех разный. Похоже на тупичок… Применив метод “костыли и договорённости” из него, конечно, выбраться можно, но это уже будет не расчёт, а оценка.

Теперь рассмотрим числитель. Требуется рассчитать Touch Time, и здесь всё ещё хуже. В идеальном мире сотрудники, взяв из входящей очереди задачу, не отвлекаются, а выполняют её от начала и до конца, после чего перемещают в выходящую очередь (см. Lean, конвейер). В реальном мире между событиями “Взял” и “Отдал” есть не только работа, но ещё и консультации коллег по другим вопросам, небольшая оперативка команды, ситуация “ой, пришлось переключиться на устранение дефекта, потому что это экспедит”, кусочек фейсбука и, чего уж там, обед. Мне не известно ни одной команды, где фиксировалось бы время работы над задачей по таймеру. Значит, смотрим на изменения статусов в Jira и, фактически просто убираем из расчёта время в очередях. Значит, огрубляем. Значит, получаем ерунду, а не оценку эффективности потока. Чтобы понять масштаб бедствия (и категорическую непригодность данного метода) можно выполнить простой альтернативный расчёт: из общего ресурса команды (скажем, N человек х 8 часов в день х 5 рабочих дней) вычесть время, списанное на задачи, с которыми работали за данную неделю. Получим противоположность Touch Time время, которое было доступно, но ушло непонятно куда. Вот диаграмма Flow Efficiency одной из команд со значениями, рассчитанными по двум способам:

Несложно заметить, что результаты расчёта отличаются в 2-5 раз (не на единицы и не на десятки процентов). Несложно также предположить, что эффективность в 90% и более вряд ли имеет место быть в реальности.

И это мы ещё не рассматриваем ситуацию, при которой над данной задачей одновременно работают несколько исполнителей. А такое в ИТ бывает (см. front/back, например). Чьё тогда время учитывать в Process Time первого, второго, обоих вместе, самого долгого, или того, кто постарше?

Получается, что ни числитель, ни знаменатель этой простой формулы толком не посчитать. А значит, и результат деления не имеет большого смысла. Как же тогда быть с умными книжками?

Прошу понять меня правильно: я за работу по потоку, обеими руками. Я за измерение эффективности. Я даже с Jira готов мириться, если уж так рассудить.

Метрика эффективности потока мощный инструмент. Десятки раз я проводил очень простое, но очень полезное упражнение с разными командами: давайте представим ваш поток и для каждого шага прикинем сколько времени задача проводит на каждом этапе, а сколько времени на каждом этапе над задачей действительно работают. Разделив сумму второго на сумму первого, команды, как правило, очень удивляются полученным значениям в 10-25%, ведь по их ощущениям эффективность собственной работы никак не ниже 75-80%. Но это же не расчёт, это оценка.

Таким образом, метрика эффективности потока довольно бесполезна, и считать её не нужно. Может, даже и вредно. Грубая оценка да, отлично. Расчёт, диаграмма, анализ, выводы нет, не стоит.

Пожалуйста, переубедите меня. Научите считать. Покажите пример. Наверняка я что-то упускаю.

«Kanban Flow Metrics: управление потоковым производством на основе данных»
Тренажёр про метрики на реальных примерах

Комментариев: 12

  • Думается мне, что можно не ставить перед собой задачу получить абсолютное и точное “значение показателя эффективности”, но смотреть в сторону относительности показателя, котороый трудно вычислить точно. Договориться в команде об наиболее релевантных ограничениях и/или упрощениях, применяющихся к вычислению числителя и знаменателя дроби, и направить энергию на повышение этого показателя в некотором интервале не меняя правила расчета.
    Риск того, что в процессе мы увидим что идем не туда (наши меры по повышению эффективности не подтверждаются другими показателями косвенно подтверждающими ценность) остается всегда, и этот факт будет поводом остановиться и взглянуть на применяемые практики и ограничения расчета показателя эффективности, ценности от вычисленных значений.
    По своей сути, оценка, о которой идет речь, по своему характеру такова, что ее увеличение должно драматически сказываться на общих результатах команды, особенно, если попытаться определить удельную эффективность на единицу работы (практики в меня плюнут, там мору своих ограничений, но попробовать можно). Простаивающая команда может демонстрировать чудовищную эффективность, но низкую общую пропускную способность.
    Показатель, IMHO, лучше заменить детальной разверткой на длину очередей, т.к. именно через них вытягивающая система работает с временем ожидания. Общебольничный показатель “эффективности” на практике не очень полезен, т.к. не раскрывает те самые потери, которые негативно отражаются на производительности.

    • Андрей, согласен – скорее всего, эта метрика сложно обобщается для нескольких разных производственных систем, потому должна применяться с осторожностью.

  • А мне почему-то кажется, что здесь всё довольно просто (впрочем, дилетантам всегда так кажется):

    1. И числитель, и знаменатель разумно считать по “календарю заказчика”, также как время устранения инцидента в поддержке. Потому что если заказчик работает 7×24, то даже если группы разработки работают 5×8, время ожидания будет исчисляться сутками, а не рабочими днями. При таком подходе: а) метрика позволяет контролировать также снижение эффективности потока, вызванное “невыравненностью” календарей и б) проблема с разными календарями при расчёте не возникает в принципе.
    2. Touch Time (TT) нужно считать не как сумму времён исполнителей, а как сумму отрезков времени работы над задачей, не зависимо от того, сколько исполнителей работали над ней в каждый момент времени. Например, если Вася работал над задачей с 11 до 14 часов, а Петя – с 12 до 15, то Touch time составляет 4 часа (с 11 до 15 часов). Как следствие, а) расчёт соответствует логике оценки, для которой используется формула эффективности потока и б) проблема нескольких исполнителей не возникает в принципе.
    3. Если TT не посчитать, то, разумеется, не рассчитать и эффективность потока. Это довольно понятно, но не делает эту метрику бесполезной. Иначе при соблюдении твоих условий “время тратится на всё вперемешку” анализ записей расходования времени в принципе бесполезен, что автоматически делает практически бесполезным и time tracking в целом. Но ведь опыт (наш с тобой в том числе) показывает, что это не так.

    • Дим, спасибо за комментарий.
      1. В общем случае у производственной системы не один, а несколько заказчиков. И в жизни зачастую это тоже так. Предположим, производственная система есть продуктовая команда. У неё на входе много желающих поделиться работой: product owner, заинтересованные стороны, соседние продуктовые команды… Чей календарь считать календарём заказчика? Наверное, можно свести к “ну есть же product owner, он самый главный (наверное), вот по его календарю и будем считать”. Но это очень сильное допущение. Потому что потоковая организация работы не выставляет непреодолимого требования иметь продуктовое управление, а значит никакого product owner может и не быть вовсе. А заказчиков будет несколько, и ничего страшного в этом нет.
      2. Не всё так просто. С одной стороны, да, разумно считать как ты говоришь. С другой, это всё же не очень соответствует той идее, для которой мы хотим измерять эффективность потока. Ведь ситуация “несколько человек работают над задачей одновременно” не обязательно означает, что на данном участке работы требуются несколько исполнителей (это твой вариант, и он прекрасен, и для такого случая нужно, разумеется, считать как ты предлагаешь). Но есть ещё вариант “поток распараллеливается”, и мы сознательно так организуем производственную систему. В этом случае внутри системы возникает развилка, по которой поток должен продолжится одновременно. И если теперь считать по твоему методу, то мы не увидим ситуацию, когда первый исполнитель начал работу, а второй мог начать, но тупил (или постоянно тупит). Метрика будет показывать высокую эффективность потока, реальность же обратна.
      3. Согласен, что данный вопрос очень похож на учёт рабочего времени в принципе. Тогда следствие: не нужно называть эту метрику “эффективность потока”. Правильно называть её “доля времени на участках обработки”. Потому что из всех видов потерь мы наблюдаем только один – потери на ожидание в очередях. При этом есть большие сомнения, что это а) самые большие потери, б) вообще имеет смысл такой метрикой измерять очереди.

      • > 1. В общем случае у производственной системы не один, а несколько заказчиков…Чей календарь считать календарём заказчика?

        Почему это так важно? LT же измеряется не часами, а днями. Заметная разница возникает только в международных компаниях в связи с различием в праздничных днях. Это отличие настолько принципиально? Нельзя ввести стандартный бизнес-календарь, например по нахождению HQ?

        • Наверное, можно. Это ведь не единственное место, где придётся идти на допущения. Но много небольших допущений могут привести к бесполезности измерения.

  • Ну как так-то. Раз в год решил написать комментарий – и конечно, ДИ уже его написал.
    Остаётся только согласиться с ним.

  • AT

    И даже ещё проще. Эту метрику нужно считать не для сравнения с метриками других господ. Весь процесс строится для улучшения показателей, а не для какого-то конкретного хорошо. Потому показатель сравнивается с ним же после изменений и улучшений в рамках той же компании/подразделения. И никак иначе.

    • Да, похоже, что так. Исходя из способа расчёта (как договоримся) и способа оценки (сложно сравнить с соседом) применять эту метрику для оценки производственной системы из-вне не особо получится. Только изнутри.

  • Кстати. Некоторые читатели говорят, что из заголовка и беглого прочтения заметки может сложиться вот такое впечатление:

    “я не умею считать метрику, поэтому она не верная”

    Это не так. Я не утверждаю, что метрика неверная. Я хочу разобраться с ней подробнее, потому что “в лоб” она не несёт большой ценности, на мой взгляд.

  • Николай Смирнов

    Олег, заметка хороша, еще примечательно, что под ней пишут комменты в основном сотрудники Cleverics, и Роман Валерьевич)
    Немного от себя напишу.
    В комплексных системах, как правило используют простые формулы, так повелось, что ли) но это отступление, теперь по сути.

    На картинке из великолепнейшей книги Handbook DevOps есть допущение, там LeadTime начинается со времени создания тикета, это круто конечно, когда сервис работает именно так и начинает оправдывать ожидания заказчика именно там, но это уже называется Customer Lead Time и не всегда коррелирует с мощностью производственной системы/команды разработки) Это я к тому, что у каждого сервиса есть свои границы, которые неплохо определить, например на STATIK (тут во мне заговорил Kanban Coach)) или любым другим способом.
    Как уже обсуждали выше заказчиков у сервиса может быть много, это первое, второе видов/типов работ, которые пересекли границу сервиса, тоже может быть какое-то количество, и вот если получиться отделить их от других и по ним посчитать FE, ВАЖНО учитывая корректный расчет Toch Time, тогда эта формула, по моему мнению, перестают быть пугающе неточной)
    Хотя я могу ошибаться и готов это пообсуждать!
    За заметку спасибо, всегда приятно наблюдать рассуждения и альтернативный взгляд, наводит на мысли)


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM