Портал №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%. Но это же не расчёт, это оценка.

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

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

«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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT