Когда заказчики требуют ускорить выпуск продукта, интуитивная реакция большинства менеджеров — немедленно взять новые задачи в работу. Кажется логичным: чем раньше мы начнем, тем быстрее закончим. На практике это приводит к катастрофе. Команда тонет в мультизадачности, сроки срываются, а качество падает.
Эту проблему объясняет Закон Литтла. Изначально это теорема из теории массового обслуживания, доказанная профессором Джоном Литтлом в 1961 году. Сегодня это фундаментальная математическая основа Канбан-метода. Закон Литтла научно доказывает: если вы хотите, чтобы работа выполнялась быстрее, вам нужно парадоксальным образом уменьшить количество того, что вы делаете одновременно.
Суть формулы и три главные метрики
Закон Литтла связывает три базовые метрики потока в одно простое уравнение. Формула гласит: среднее время выполнения задачи (Cycle Time) равно среднему количеству незавершенной работы (WIP), разделенному на среднюю пропускную способность (Throughput).
Cycle Time = WIP / Throughput
Давайте разберем это на примере кофейни. Пропускная способность бариста — 2 чашки кофе в минуту. В очереди (в процессе приготовления) сейчас находится 10 заказов. Применяем формулу: 10 делим на 2, получаем 5 минут. Именно столько в среднем придется ждать клиенту свой кофе.
Если в кафе зайдет толпа и очередь (WIP) вырастет до 20 заказов, время ожидания (Cycle Time) автоматически увеличится до 10 минут. Бариста не стал работать хуже, просто система переполнилась. То же самое происходит в разработке программного обеспечения. Если вы набрали в колонку «В работе» 50 тикетов, а ваша команда закрывает 5 тикетов в неделю, среднее время выполнения одной задачи составит 10 недель. Математику обмануть невозможно.
Сравнение подходов к ускорению работы
| Стратегия ускорения | Традиционный подход | Подход на основе Закона Литтла |
|---|---|---|
| Реакция на давление сроков | Начать работу над новыми задачами как можно скорее | Остановить взятие новых задач и сфокусироваться на завершении старых |
| Отношение к WIP (незавершенной работе) | Чем больше задач в работе, тем выше утилизация ресурсов | Строгое ограничение WIP для поддержания высокой скорости потока |
| Способ сократить Cycle Time | Заставить людей работать быстрее (овертаймы, давление) | Снизить лимиты WIP (бесплатный и мгновенный эффект) |
| Предсказуемость процесса | Низкая, система постоянно перегружена и нестабильна | Высокая, система работает как часы благодаря балансу |
Глубокое погружение: Пять условий стабильной системы
Многие команды пытаются подставить свои цифры из трекера в формулу Литтла и обнаруживают, что она не сходится. Эксперт по метрикам потока Дэниел Ваканти объясняет это тем, что закон работает только в стабильных системах. Чтобы математика сошлась, ваш процесс должен соблюдать пять базовых допущений.
Первое и главное правило: средняя скорость поступления новых задач должна быть равна средней скорости их завершения. Вы не можете брать в работу 20 задач в неделю, если закрываете только 10. Второе правило гласит, что вся работа, которая вошла в систему, должна из нее выйти. Нельзя бросать задачи на полпути и оставлять их гнить на доске.
Третье и четвертое условия касаются возраста задач. Общий объем незавершенной работы (WIP) и средний возраст этих задач не должны постоянно расти или падать. Они должны колебаться вокруг одного стабильного значения. И пятое правило — вы должны использовать одинаковые единицы измерения для всех метрик (например, считать всё в штуках задач и календарных днях).
Канбан-метод со своими лимитами WIP и вытягивающей системой (Pull System) — это по сути практический инструмент для принудительного соблюдения этих пяти допущений. Ограничивая WIP, вы стабилизируете систему, и Закон Литтла начинает работать на вас, позволяя строить точные прогнозы.
Резюме: Математика против интуиции
Закон Литтла разрушает главный миф менеджмента о том, что для ускорения работы нужно больше работать. Он доказывает, что единственный бесплатный и мгновенный способ сократить время доставки ценности клиенту — это ограничить количество работы в процессе.
Ключевой вывод состоит в том, что вы не можете напрямую управлять временем выполнения (Cycle Time). Вы можете управлять только двумя рычагами: пропускной способностью (что сложно и дорого) и лимитами WIP (что требует только дисциплины). Успешные Agile-команды всегда выбирают управление лимитами.
Часто задаваемые вопросы (FAQ)
Да, абсолютно. Спринт в Scrum — это по сути жесткий WIP-лимит, ограниченный временем. Вы берете фиксированный объем работы на две недели и не добавляете новые задачи до конца итерации. Это стабилизирует систему и позволяет применять принципы Закона Литтла для прогнозирования.
Нет. Закон Литтла оперирует средними значениями за длительный период. Благодаря закону больших чисел разница в размерах задач сглаживается. У вас будут и мелкие баги, и крупные фичи, но на дистанции в несколько месяцев средний Cycle Time и Throughput будут отражать реальную картину без необходимости оценивать каждую задачу в часах.
Математически — да. Практически — это очень сложно. Чтобы увеличить Throughput, вам нужно нанять новых людей (что сначала замедлит команду из-за адаптации), купить новые серверы или радикально изменить архитектуру. Снижение WIP-лимитов дает тот же математический эффект ускорения, но не стоит компании ни копейки.
Это диагноз вашему процессу. Если формула не работает, значит, ваша система нестабильна. Скорее всего, вы нарушаете базовые допущения: берете задач больше, чем можете сделать, позволяете карточкам стареть на доске месяцами или удаляете незавершенную работу из трекера. Начните наводить порядок в потоке, и цифры сойдутся.
Используйте аналогию с дорожным движением. Если на шоссе выедет слишком много машин (высокий WIP), образуется пробка, и время в пути (Cycle Time) для каждого водителя увеличится в несколько раз, хотя пропускная способность дороги (Throughput) осталась прежней. Чтобы машины ехали быстро, на дороге должно быть свободное место.