{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Kanban.club: posts tagged баланс", "_rss_description": "Кратко и по делу о Kanban, Scrum, LeSS, SAFe и все, что может пригодиться в работе менеджеру", "_rss_language": "en", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/kanban.club\/?go=tags\/balans\/", "feed_url": "https:\/\/kanban.club\/?go=tags%2Fbalans%2Fjson%2F", "icon": false, "authors": [ { "name": "Роман Петров", "url": "https:\/\/kanban.club\/", "avatar": false } ], "items": [ { "id": "27", "url": "https:\/\/kanban.club\/?go=all\/flow-efficiency\/", "title": "Эффективность потока", "content_html": "
\n\"\"\n<\/div>\n

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

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

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

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

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

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

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

    Формула подсчета Эффективности потока<\/h2>\n

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

    \n\"\"\n<\/div>\n

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

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

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

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

    Очевидно, что нужно сбалансировать эффективность потока и эффективность ресурсов<\/h2>\n

    Для начала посмотрим о чем нам говорит закон Литтла:<\/p>\n

    \n\"\"\n<\/div>\n
    \n\"\"\n<\/div>\n

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

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

    Еще видео о ловушке утилизации ресурсов<\/p>\n

    \n