Первое, с чего стоит начать, чтобы измерять эффективность потока, очевидно, что нужен поток. Упрощенно, поток можно разделить на следующие этапы:
- Работа которую возможно надо делать, но по ней мы не дали обещания, что ее сделаем (еще ее называют Backlog)
- Запланированная работа, которую мы уже пообещали сделать, но ее не приступили к ней (To do)
- Работа над которой работаем (in Progress)
- Сделанная работа, по которой наши обещания исполнилось (Done)
Обратите внимание на первый пункт: это список работ, где есть элементы работы, которые не надо делать никогда. И здесь нужно учитывать контекст, где ваш поток находится. Если это ресторан, то людей, которые находятся в очереди на входе в ресторан вы не обязаны обслужить всех и более того, можете выбирать кого обслужить, а кого нет. Например, соответствует вашему дресс-коду или нет. (вспоминаем про конкурс красоты ) Если вы техническая поддержка или служба оперативного реагирования, то вам нужно обслужить все запросы и как можно скорее. В этом случае, у вас нет пункта backlog и вся работа сразу попадает в To Do, а это значит, что вы по ней уже дали обещание (SLA договоренность об уровне сервиса) и время для клиента начинает тикать моментально.
Давайте подумаем, а как мы вообще начали думать об эффективности потока?
Бизнес всегда думает об эффективности, и первая эффективность которой легче всего управлять — это эффективность использования ресурсов. Т. е. мы должны следить, чтобы у всех людей обе руки были заняты и чтобы все станки в цеху, столики в ресторане, операторы в колл-центре и т. д. были в работе 100% (или близко к этому) времени, в реальности получается 75-80%, остальное уходит на перерывы, покурить, ненужные встречи и т. д.
Что мы получаем в итоге: у нас все люди заняты и много недовольных клиентов, потому, что для них время ожидания в очереди или в процессе обслуживания очень большое, которое их явно не устраивает.
Обычно, следующий шаг — это увеличить количество людей (аналитиков, поваров, кассиров, программистов и т. д.), так как кажется что именно в этом вся проблема. СТОП. Если вы пришли к этой точке, то это тот самый момент, когда пора подумать, а что же у нас с эффективностью потока?
Формула подсчета Эффективности потока
Подсчет эффективности потока делается следующим образом:
Эффективность потока (в %) = Время работы / (Время работы + Время ожидания)
Где,
Время работы = Времени, когда карточка находилась в колонках вида “В работе” (т. е. когда создавала ценность) минус время, когда в них карточка была заблокирована
Время ожидания = Время блокировки плюс Время, когда карточка находилась в колонках вида “Готово”, “Закончено”, “Сделано” плюс Время в бэклоге (если наши обязательства распространяются на колонку Бэклог)
Обычная эффективность около 15%, т. е. 85% времени с элементом работы никто не занимался.
Чтобы подсчет эффективности потока стал возможен нам потребуется визуализация, как минимум в виде канбан-доски и сбор статистики по выполненным элементам работы.
Эффективность ресурсов и эффективность потока — это две стороны одной медали. Мы привыкли фокусироваться на активную составляющую нашей работы: написание автотестов, обучение сотрудников, выстраивание devops трубы, качество приготовляемой еды на кухне, скорость работы кассира и т. д. Это все правильно, но работа только на этим может быстро перестать давать положительный эффект и каждым новым уровнем улучшения стоит дороже, но и есть темная сторона: это время, когда мы просто ждем и природа этого времени может быть разной: зависимости, смена приоритетов, ожидание следующего этапа, блокировки и т. д.
То, что задача находится в работе и то, что над ней кто-то работает не одно и тоже, и Эффективность потока показывает как часто это бывает правдой.
Очевидно, что нужно сбалансировать эффективность потока и эффективность ресурсов
Для начала посмотрим о чем нам говорит закон Литтла:
Т. е. при сохранении скорости потока (сколько элементов работы выходят из нашей системы в единицу времени), мы можем сократить среднее время выполнения за счёт того, что сократим количество одновременно выполняемой работы. К чему это приведет: заказчики встанут в очередь и кому-то из них нужно говорить “нет” или “подожди”, а некоторые сотрудники будут простаивать, ведь при меньшем количестве работы ее может на всех не хватить и это хорошо.
Дальше, мы должны убедиться, что мы рассматриваем единую систему создания ценности (в начале, в конце или с обоих концов должен быть внешний клиент) — это поможет нам избежать ловушки локальной оптимизации. И вот только теперь мы начинаем смотреть на корневые причины возникновения этапов “Ожидания”, делаем эксперименты по уменьшению времени ожидания и подбор лимитов незавершенной работы (об этом можно почитать:
WIP лимиты — часть 1
WIP лимиты — часть 2 ) .
Еще видео о ловушке утилизации ресурсов