Ответим в течение 30 минут — contact@leadstartup.ru
+7 495 150 42 63 — с 8:00 до 21:00 МСК
Материалы курсов — в Telegram
Получите все материалы с наших тренингов — бесплатно
Закон Литтла ⏱ в Проектном и Продуктовом Менеджменте
Закон Литтла ⏱ в Проектном и Продуктовом Менеджменте
Закон Литтла ⏱ в Проектном и Продуктовом Менеджменте

Закон Литтла ⏱ в бизнесе, в проектном и продуктовом менеджменте

Количество отзывов (рецензий) 21
Средний рейтинг рецензии 5

Закон Литтла (на английском — Little's law) — это закон, согласно которому чем больше задач в системе выполняется одновременно, тем более медленной будет скорость выполнения каждой из них. Открыт этот закон Джоном Литтлом [John Little], поэтому и получил такое имя.

Что такое закон Литтла

Это закон, согласно которому работа оказывается наиболее эффективной при минималном количестве незавершенной работы ("работы в процессе").

Как работает закон Литтла

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

Как использовать закон Литтла

Сокращайте работу в процессе ("Work In Progress") у себя и у своих коллег. Для этого можно использовать канбан метод.

Закон Литтла

Также закон Литтла иногда называют результатом, леммой, формулой. Однако слово «закон» является наиболее распространенным, особенно в среде предпринимателей и менеджеров бизнеса.

Наиболее часто ссылки на закон Литтла можно встретить в фреймворке Kanban.

🎓
Доступ к Miro и Google–диску
Доступ к Miro и Google–диску — бесплатно

Формула Литтла

Как конкретно выглядит закон Литтла? Давайте разберем переменные и посмотрим формулу.

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

L = λW

Здесь всего три переменные. Давайте разберем каждую из них. Используем наглядную метафору с потоком воды.

закон литтла

Количество задач

L — это количество в системе заявок, запросов, или задач. Это все то, что требует выполнения, решения. Это то, над чем вы работаете.

У вашей команды/отдела, конечно, есть определенное количество задач, находящихся в процессе. В Kanban это так называется — Work In Progress (WIP), работа в процессе.  

Важно! WIP — это не все задачи вообще, которые есть у вас в бэклоге. Например, если у вас есть отдел сервисного обслуживания, у вас может быть в конкретный день 500 и более тикетов, которые вам нужно «разобрать».

Это не переменная WIP! К работе в процессе относятся только те задачи, которые вы уже взяли в работу — то есть делегировали конкретным людям или отделу в целом.

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

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

Время задачи в системе

W — это Lead Time, то есть среднее время, которое задача находится в системе.

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

В некоторых командах задачи выполняются день–в-день. Это очень низкий Lead Time, и это хорошо. А в некоторых они могут находиться «в работе» месяцами и годами — это очень плохо (сейчас разберемся, почему).

Пропускная способность

λ (лямбда) — это ваша «пропускная способность» (Throughput), то есть то, как много времени требуется на выполнение определенного количества задач.

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

Суть формулы Литтла

Что же со всем этим делать и как эту формулу понимать?

Все просто.

Предприниматель или менеджер эту формулу — L = λW — может читать дословно следующим образом: «Чем больше у нас задач в процессе, тем дольше будет каждая задача находиться в работе и тем хуже будет пропускная способность».  

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

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

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

И наоборот, чтобы ускорить процесс максимально — лучше, чтобы задачи выполнялись точно–в-срок (Just In Time), как бы сразу «падали» в самый низ и выходили из системы. Это самое лучшее, как можно заставить систему работать эффективно.

Получите доступ к 25 курсам LeadStartup — за 2750 рублей

Зачем нужно использовать закон Литтла

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

Логика простая — «невыполненная работа», то есть находящаяся в процессе, имеет нулевую ценность.  

Кто–то может возразить на это: «Нет, мы же выполняем важную работу, это нужно для таких–то целей!» Но факт остается фактом — пока вы только «выполняете» работу, ваш бизнес ничего не получает; также не получают ничего ваши клиенты.

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

Кроме того, использование этого закона на практике приводит и к другим преимуществам:

  • Сотрудники меньше выгорают — т.к. не нужно переключаться на разные задачи, плюс они максимально быстро видят результат своей работы. Это особенно важно для интеллектуального труда, где ощущение результативности работы может быть поставлено под вопрос.
  • Сотрудник выполняет работу качественнее — опять же, из–за того, что он не переключается, он может полностью сфокусироваться на всех элементах конкретной задачи, чтобы выполнить ее максимально качественно.
  • Прозрачность в командной работе — благодаря тому, что количество задач у человека в работе не очень большое, каждый знает, чем конкретно он занимается. Сотрудник при необходимости может очень легко напомнить, какие у него задачи прямо сейчас (т.к. их ограниченное и небольшое количество).
🎓
Получите доступ к нашему Google–диску — бесплатно
Скачать модель
Получите доступ к нашему Google–диску — бесплатно
Скачать модель

Где действует закон Литтла

Закон Литтла работает для любых систем, в которых соблюдаются следующие условия:

  • Система стабильная и содержание ее работы предсказуемо
  • Система работает непрерывно и циклично
  • Цикл работы системы предсказуем и не меняется

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

Для оптимизированной работы, согласно этому закону, вам нужна стабильная и циклическая система. Тогда вы сможете оптимизировать «рабочий поток» (Workflow).

Например, такая система может быть в области сервисного обслуживания. Цикл выглядит примерно так:

  • Возникновение заявки / запроса в системе;
  • Взятие заявки в работу;
  • Передача заявки на нужный отдел;
  • Закрытие заявки.

Поскольку рабочий процесс выглядит одинаково, здесь целесообразно применять закон Литтла и не брать много задач в систему одновременно. По крайней мере не давать несколько задач одному человеку!

Однако, на практике это бывает не так проблематично.

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

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

Вы научитесь масштабировать Agile–мышление на уровень всей корпорации и взаимодействовать с ТОП–менеджментом.
Вы научитесь управлять Scrum–командами, создавать Kanban–системы и руководить внедрением Agile фреймворков.
Обучитесь Agile-инструментам влияния на выживаемость бизнеса в условиях крайней неопределенности.
Вы научитесь создавать бизнес–модели цифровых продуктов и защищать их на презентации перед ТОП–менеджментом.
Вы научитесь управлять запуском цифровых инноваций и выступать в роли бизнес–трекера для внутренних стартапов.
Вы научитесь проводить глубинные интервью для поиска сильнейших инсайтов по развитию вашего продукта.
Вы научитесь визуализировать клиентский опыт взаимодействия с компанией, учитывая мысли, цели и задачи клиента через CJM.
Вы освоите методологию дизайн–мышления и научитесь использовать дизайн-мышление для поиска прорывных идей.
Вы освоите методологию развития аналитической культуры в корпорациях для достижения целей цифровой трансформации.
Обучение эмоциональному интеллекту — способ обновить и оживить корпоративную культуру компании.
Вы освоите методологию Growth Hacking — быстрого тестирования гипотез для кратного роста по прибыли.
Вы научитесь проводить интервью и исследования по методологии Jobs To Be Done для валидации идей роста.
Вы научитесь применять фреймворк LeSS для объединения нескольких Agile–команд при работе над продуктом.
Вы научитесь применять навыки Ситуационного Лидерства для развития самоорганизации на уровнях команд и организаций.
Вы научитесь проектировать Канбан–системы и работать с Канбан–доской в рамках продуктовой и проектной работы.
Вы научитесь управлять продуктовой стратегией и совместно со стейкходерами формировать дорожную карту развития продукта.
Вы научитесь радикально повышать вероятность выхода на положительную рентабельность новых бизнес–направлений.
Вы научитесь проводить оценку целесообразности запуска нового цифрового продукта или бизнес–направления.
Вы научитесь формировать амбициозные, значимые для бизнеса OKR–цели и совместно с сотрудниками достигать их.
Вы научитесь использовать сервис продуктовой аналитики Amplitude для нахождения точек роста прибыли продукта.
Вы освоите роль Владельца Продукта в Scrum, научитесь приоритизировать задачи и максимизировать бизнес–ценность.
Вы научитесь применять фреймворк SAFe для объединения нескольких Agile–команд при работе над продуктом.
Вы научитесь вести Scrum–команды к самоорганизации и высокой продуктивности, с получением сертификации PSM I.
Вы освоите все мероприятия, роли и артефакты фреймворка Scrum, и сможете применить Scrum на практике в своем отделе.
Вы научитесь определять точки кратного роста прибыли и обоснованно принимать решение где сфокусировать усилия.