Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику 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: управление потоковым производством на основе данных

Тренажёр про метрики на реальных примерах