Flow Efficiency: как измерить эффективность потока

Команда усердно и быстро работает, в бэклоге всегда мало задач — все они в работе, но сроки продолжают срываться, заказчики остаются недовольными, а команда выгорает. В чем причина? В этом поможет разобраться метрика Flow Efficiency. С ее помощью можно понять, какие этапы процесса нужно оптимизировать, где и почему возникают простои. 

Что такое Flow Efficiency: КПД, формула и интерпретация

Чтобы легче понять, что такое Flow Efficiency, вспомним школьную физику — обратимся к КПД теплового двигателя.  

Коэффициент полезного действия в физике — это соотношение полезной работы, затраченной системой, к энергии, которую эта системы получила, чтобы выполнить работу. 

Например, если система потратила 10 единиц сил на завершение работы, из которых только 5 ушло на реально полезные действия, то КПД равен 50%:

Куда-то делись еще 5 единиц сил, которые система по каким-то причинам потратила на выполнение работы.

Flow Efficiency (эффективность поток) — это КПД бизнес-процессов. Он рассчитывается из времени, выделенного и затраченного на задачу. Например, разработчику выделили 50 часов на разработку новой функции. Он выполнил ее за 15 часов, но сдал только через 50 часов с начала цикла работы. 

Flow Efficiency в таком случае равен:

В нашем случае 50 часов — это Lead time, то есть, время от точки принятия до точки отдачи обязательств, а 15 часов — Value-adding time, реально затраченное на задачу время. Чем выше их процентное соотношение, темы эффективнее работает команда. 

Тогда формула Flow Efficiency такая: 

Возникает вопрос: куда ушли еще 35 часов? Почему программист потратил только 30% свободного времени на задачу? 

Чтобы ответить на эти вопросы, нам нужно знать Flow Efficiency. Разберем ниже, как это значение помогает выявлять причины простоев. 

Почему без Flow Efficiency не обойтись 

Рассмотрим, чем отличается Flow Efficiency от других популярных IT-метрик. 

Velocity

Velocity — это скорость команды, а не ее эффективность. Метрика показывает, сколько задач (или story points) закрывает команда за спринт. Например, команда закрыла за спринт 5 задач весом в 2 story points каждая. Тогда Velocity равен 10 стори поинтам. Это значение не поможет нам выявить базовую эффективность команды. С помощью него мы можем только сравнить Velocity прошлого спринта, чтобы сказать, на сколько эффективнее сработали сотрудники за этот спринт. 

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

Чтобы сделать выводы о Flow Efficiency, нам не нужно сравнивать прошлое значение эффективности потока с предыдущим. Если оно не равно 100% — команде всегда есть к чему стремиться. Flow Efficiency — качественная величина, Velocity — количественная.

Cycle Time

Cycle Time — отрезок времени от старта работы над задачей до ее реализации. Метрика помогает отслеживать, на каком этапе и сколько времени находилась задача.

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

Cycle Time помогает оценить Flow Efficiency, но не заменяет его. Время цикла помогает оценить эффективность потока каждого этапа задачи.

Throughput

Метрика пропускной способности показывает объем работы, который выполнила команда за определенный период. 

В Kaiten можно группировать задачи по разным категориям: ответственным, типам задач, меткам, дорожкам и прочему. 

Как и Velocity, Throughput — количественная метрика, которая помогает измерять производительность команды в сравнении с прошлыми показателями.  

Какие метрики помогают IT-проектам выстраивать эффективные бизнес-процессы — разобрали в статье вместе с проектным менеджером.

Инструкция: как измерить и увеличить Flow Efficiency 

4 шага, как измерить эффективность потока и увеличить КПД команды через понятные практики.

I этап: определить период и этапы, которые проходит задачи за выбранный отрезок времени

Для этого зафиксируйте:

1. Lead time: на какой этап приходится точка принятия обязательств и когда происходит их  отдача;

2. Посмотрите, сколько дней/часов сотрудники действительно работали над задачей. В этом может помочь тайм-трекер. Например, в Kaiten есть модуль «Учет времени». Если его подключить к пространству, каждый сотрудник может запустить таймер, когда начнет выполнять задачу, остановить его в перерыве, запустить снова и отключить в момент завершения поручения.

А руководитель увидит полную отчетность по затраченному времени на каждую задачу. 

Пример: есть задача для IT-отдела — разработать мини-посадочную для новых пользователей. 

Lead time задачи — 10 рабочих дней, то есть, 80 часов. Активное время по сотрудникам, которое выявил руководитель с помощью таск-трекера:

• 1 день: дизайнер нарисовал макет, 7 часов.  
• 5 день: разработчик написал код посадочной за 8 часов.  
• 8 день: тестировщик проверил код за 4 часа.  

Итого активного времени: 19 часов.

II этап: рассчитать текущий Flow Efficiency и зафиксировать настоящий Cumulative Flow 

Считаем эффективность потока по стандартной формуле: делим время реальной работы на запланированное на задачу время. 

В нашем примере получаем 24% по формуле:

Также можно зафиксировать накопительную диаграмму потока (CDF), чтобы потом сравнить производительность команды после устранения узких мест процесса и повышения показателя КПД.

Kaiten собирает CDF автоматически за выбранный период:

III этап: оценить процесс тормозится и снижает производительность команды

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

Тогда можем предположить такие этапы процесса и распределение по ответственным:

Изобразить процесс с помощью kanban-колонок можно в разных системах управления проектами. Например, в Kaiten это выглядит так:

В нашем примере можно соотнести дни простоя и работы с колонками. Получаем такую картину:

Исходя из этого, делаем вывод: простой попадает на этапы согласования от менеджера. Но виноват ли проджект в том, что проект тормозится? Чтобы это выяснить, идем к сотрудникам и спрашиваем, как они видят процесс. Потому что для полного понимания работы и простоев мало видеть цифры. Бизнес-процессы — это, в первую про людей, а не данные. 

IV этап: общение с сотрудниками

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

В примере дизайнер взял макет в работу в течение первого же часа и выполнил ее максимально быстро. Но перед этапами «Разработка» и «Тестирование» есть простои в несколько дней. Есть искушение просто обвинить проджекта в долгом согласовании, но все может быть иначе. 

При разговоре с каждым из членов команды тимлид выясняет:

• в процессе своего согласования проджект каждый раз несет проект на осмотр бизнес-аналитика, что добавляет примерно 6 часов к «полезной» работе. При этом у проджекта нет прав на доске, чтобы передвигать карточку — он может лишь оставить комментарий о том, что задача готова к разработке или тестированию;
• у разработчика слишком много задач, поэтому он не может сразу приступить к текущей. Из-за этого каждая задача дополнительно лежит по 10 часов в ожидании разработки;
• такая же ситуация в отделе тестирования — в компании всего один тестировщик с огромной очередью проектов на тестирование. В среднем, он берется за задачу через 12 часов после согласования.

V этап: отображение причин застоя. Блокировки и буферные колонки

Теперь тимлид хочет проверить, насколько слова сотрудников действительно соответствуют истине. Он добавляет дополнительные колонки на доску, чтобы та была более приближенной к реальным процессам компании. 

Новые колонки:

• согласование бизнес-аналитика;
• очередь на разработку;
• очередь на тестирование.

С помощью этих этапов он может проверить, на сколько слова сотрудников соответствуют реальности. Также он полноценно подключает к пространству проджекта, чтобы тот вовремя передвигал карточку в буферные колонки бэклога. 

VI этап: пересчет полезного времени

После того как тимлид добавил колонки, он увидел, что данные сотрудников совпадают с реальностью:

• согласование суммарно занимает около 6 часов;
• задачи «простаивают» в бэклогах разработчика и тестировщика 10 и 12 часов.

С учетом этих 6 часов полезной работы, тимлид получает новый расчет эффективности потока:

VII этап: сокращение простоев

После пересчета КПД процесса вырос на 7%. Но руководитель видит, что можно еще увеличить производительность. Какие пути у него есть, чтобы это сделать?

Добавление ресурсов

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

Новый тестировщик взял на себя часть задач текущего, что увеличило производительность отдела тестирования и сократило простой процесса на 10 часов. 

Теперь общее время, которое тратит команда на создание посадочной, составляет 62 часа (минус 8 и 10 часов за счет перераспределения задач разработки и найма нового тестировщика). 

Новое значение Flow Efficiency = 40%. 

WIP-лимиты

Также тимлид заметил, что у разработчика всегда находится по 5 задач в работе. Это слишком большая нагрузка для одного человека. Он поставил WIP-лимиты для ограничения числа задач в колонке разработчика. 

В Kaiten WIP-лимиты выглядят следующим образом:

• зеленое значение в колонке указывает, что число задач на выбранном этапе ниже максимального;
• желтый — равно максимальному;
• красный — превышает максимум.

Также можно установить нулевой лимит, если нужно пропустить этап. 

После установления лимитов огромный объем задач перестало давить на разработчика, и он стал заканчивать задачи на час быстрее. Это сократило и полезное время и Lead Time на 1 час. КПД остался на уровне 40%, но заказчиков радует более быстрое окончание работ над проектами. 

Предупреждения о застоях

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

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

После установки предупреждений разработчики и тестировщики стали брать задачи в работу на 5 часов быстрее. Это вырастило эффективность потока до 47%.

Напоминания о сроках и действиях с карточкой

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

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

Такое решение помогло сократить Lead time еще на 20%. Теперь эффективность потока равна 60%, что в 3 раза больше начального показателя. 

Заключение: как и зачем использовать FLow Efficiency

Flow Efficiency, или эффективность потока — КПД рабочего процесса. Метрика показывает производительность команды и помогает оптимизировать процессы для увеличения эффективности и сокращения Lead Time. 

Flow Efficiency отличается от Velocity, Cycle Time и Throughput тем, что отражает качество бизнес-процесса, а не количество закрытых задач. 

Увеличить эффективность потока можно с помощью:

• разговора с каждым членом команды;
• более точного отображения процессов на доске;
• установки WIP-лимитов;
• настройки сроков предупреждения и напоминаний о действиях в карточке.

Все эти возможности есть в Kaiten. Протестировать их можно бесплатно.