2 заметки с тегом

Поток

Эффективность потока

Первое, с чего стоит начать, чтобы измерять эффективность потока, очевидно, что нужен поток. Упрощенно, поток можно разделить на следующие этапы:

  1. Работа которую возможно надо делать, но по ней мы не дали обещания, что ее сделаем (еще ее называют Backlog)
  2. Запланированная работа, которую мы уже пообещали сделать, но ее не приступили к ней (To do)
  3. Работа над которой работаем (in Progress)
  4. Сделанная работа, по которой наши обещания исполнилось (Done)

Обратите внимание на первый пункт: это список работ, где есть элементы работы, которые не надо делать никогда. И здесь нужно учитывать контекст, где ваш поток находится. Если это ресторан, то людей, которые находятся в очереди на входе в ресторан вы не обязаны обслужить всех и более того, можете выбирать кого обслужить, а кого нет. Например, соответствует вашему дресс-коду или нет. (вспоминаем про  конкурс красоты ) Если вы техническая поддержка или служба оперативного реагирования, то вам нужно обслужить все запросы и как можно скорее. В этом случае, у вас нет пункта backlog и вся работа сразу попадает в To Do, а это значит, что вы по ней уже дали обещание (SLA договоренность об уровне сервиса) и время для клиента начинает тикать моментально.

Давайте подумаем, а как мы вообще начали думать об эффективности потока?

Бизнес всегда думает об эффективности, и первая эффективность которой легче всего управлять — это эффективность использования ресурсов. Т. е. мы должны следить, чтобы у всех людей обе руки были заняты и чтобы все станки в цеху, столики в ресторане, операторы в колл-центре и т. д. были в работе 100% (или близко к этому) времени, в реальности получается 75-80%, остальное уходит на перерывы, покурить, ненужные встречи и т. д.

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

Обычно, следующий шаг — это увеличить количество людей (аналитиков, поваров, кассиров, программистов и т. д.), так как кажется что именно в этом вся проблема. СТОП. Если вы пришли к этой точке, то это тот самый момент, когда пора подумать, а что же у нас с эффективностью потока?

Формула подсчета Эффективности потока

Подсчет эффективности потока делается следующим образом:
Эффективность потока (в %) = Время работы / (Время работы + Время ожидания)
Где,
Время работы = Времени, когда карточка находилась в колонках вида “В работе” (т. е. когда создавала ценность) минус время, когда в них карточка была заблокирована
Время ожидания = Время блокировки плюс Время, когда карточка находилась в колонках вида “Готово”, “Закончено”, “Сделано” плюс Время в бэклоге (если наши обязательства распространяются на колонку Бэклог)

Обычная эффективность около 15%, т. е. 85% времени с элементом работы никто не занимался.

Чтобы подсчет эффективности потока стал возможен нам потребуется визуализация, как минимум в виде канбан-доски и сбор статистики по выполненным элементам работы.

Эффективность ресурсов и эффективность потока — это две стороны одной медали. Мы привыкли фокусироваться на активную составляющую нашей работы: написание автотестов, обучение сотрудников, выстраивание devops трубы, качество приготовляемой еды на кухне, скорость работы кассира и т. д. Это все правильно, но работа только на этим может быстро перестать давать положительный эффект и каждым новым уровнем улучшения стоит дороже, но и есть темная сторона: это время, когда мы просто ждем и природа этого времени может быть разной: зависимости, смена приоритетов, ожидание следующего этапа, блокировки и т. д.

То, что задача находится в работе и то, что над ней кто-то работает не одно и тоже, и Эффективность потока показывает как часто это бывает правдой.

Очевидно, что нужно сбалансировать эффективность потока и эффективность ресурсов

Для начала посмотрим о чем нам говорит закон Литтла:

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

Дальше, мы должны убедиться, что мы рассматриваем единую систему создания ценности (в начале, в конце или с обоих концов должен быть внешний клиент) — это поможет нам избежать ловушки локальной оптимизации. И вот только теперь мы начинаем смотреть на корневые причины возникновения этапов “Ожидания”, делаем эксперименты по уменьшению времени ожидания и подбор лимитов незавершенной работы (об этом можно почитать:
WIP лимиты — часть 1
WIP лимиты — часть 2 ) .

Еще видео о ловушке утилизации ресурсов

WIP лимит — часть 1. Особенности погони за семью зайцами.

Канбан обычно связывают с ожиданиями по повышению пропускной способности системы. Канбан содержит простой, но мощный инструмент — ограничение количества незавершенной работы или WIP (work in progress) лимиты. В этой статье разберемся, как они работают, на примере отдельной операции. Во второй части мы разберемся как этот механизм работает при наладке производственной цепочки

Эксперимент с многозадачностью

Наверняка вы обращали внимание, что попытка делать несколько задач одновременно скорее приводит к тому, что все задачи делаются и дольше и хуже. Насколько именно? Проведем небольшой эксперимент с друзьями. Попросим одного из них (назовем его разработчик) переписать имена всех остальных друзей (заказчиков), по одному имени на каждой отдельной карточке. Заказчики записывают время начала и окончания работы на своей карточке с именем (более подробно можно посмотреть здесь https://www.crisp.se/gratis-material-och-guider/multitasking-name-game).

Это упражнение проводим дважды. В первом случае (многозадачный режим), разработчик пишет по одной букве для каждого заказчика, и каждый раз переключается между заданиями. Во втором случае (последовательный режим), разработчик выполняет задачу от начала до конца не переключаясь.

Результаты видны на рисунке (синий — первый вариант, оранжевый — второй):

Результат 1. Время, необходимое на завершение одной задачи в «последовательном» варианте в несколько раз меньше, чем в «многозадачном» (обратите внимание на длину оранжевых и синих отрезков)

Этот эффект нашел свое отражение в законе Литтла, который связывает средние значения времени пребывания задачи в системе, число задач в ней и пропускной способности (см рисунок)

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

Результат 2. Время выполнения всей работы в «многозадачном» режиме существенно больше, чем в «последовательном» (обратите внимание на разницу между вертикальными красной и зеленой линиями).

Типичный разброс значений 1.5-3 раза. Это приводит к тому, что как правило заказчик получивший свой продукт в «многозадачном» варианте раньше других все равно проигрывает самому последнему заказчику из «последовательного» сценария

О чем это говорит? В обоих сценариях был проделан один и тот же объем работы — написано одно и тоже количество одинаковых имен. Различия только в способе организации работы. Оказывается, вечная «проблема» менеджеров «мы не можем сделать эту задачу, если у нас не будет новых ресурсов» имеет еще одну неожиданную грань — управляя числом задач, принимаемых в работу (т. е. управляя WIP лимитом), можно добиваться увеличения (и уменьшения) пропускной способности системы в разы.

Стоимость переключения между задачами сама по себе не бесплатна. Для человека она обычно составляет 10-15% при добавлении каждой новой, одновременно выполняемой задачи. Попытка делать 5 задач одновременно скорее приведет не к пятикратному замедлению выполнения задач, а к работе системы практически «в холостую», когда большая часть мощности будет тратиться на переключение контекста, а не на реальную работу.

Оптимальный WIP для рабочей группы

Проецируя эти выводы на рабочую группу, можно ожидать, что существует такое оптимальное значение WIP лимита, которое обеспечивает её наилучшую производительность. Выше или ниже этого уровня, система будет или не нагруженной или перегруженной. Для выбора оптимального значения WIP нужно учитывать как зависит время выполнения задачи и пропускная способность системы от него

От нуля и до момента «насыщения» системы работой, её пропускная способность будет расти с увеличением числа задач. По мере наполнения системы этот рост прекратится, и скорее всего даже сменится снижением (помните еще про стоимость переключения контекста?). Время выполнения задачи наоборот, до этого момента, будет постоянной (помните шутку про то, что девять женщин не родят за 1 месяц ребенка?), а затем начнется увеличиваться в соответствии с законом Литтла и внутренними потерями на переключение контекста.

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

Ждите продолжения и оставайтесь с нами! ))

Продолжение http://kanban.club/all/wip-limit2/