Пропускная способность в Канбане: как считать и применять throughput

Пропускная способность, или throughput, показывает, сколько рабочих элементов команда завершает за выбранный период. Метрика помогает соотнести входящий поток с реальными возможностями системы, планировать объём работы и обсуждать с заказчиком достижимые сроки. Для набора оставшихся задач используйте прогноз срока проекта по пропускной способности с диапазоном сценариев. Чтобы увидеть, на каком этапе появляется затор, дополните её накопительной диаграммой потока. Но одно число мало что говорит без контекста: нужно одинаково определять элементы и интервалы, следить за динамикой и учитывать время производства.

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

Представим команду, которая развивает мобильное приложение. За месяц от заинтересованных сторон приходит 40 запросов, однако до готового состояния доходят только 15 задач. Её пропускная способность за этот интервал равна 15 задачам в месяц. Этот показатель отражает фактическую скорость развития продукта и показывает, насколько ожидания заказчиков совпадают с возможностями процесса.

Изменения удобно показывать на throughput run chart — линейном графике количества завершённых элементов по одинаковым периодам. Он помогает увидеть не только средний темп, но и колебания: стабильна ли работа или результат резко меняется от недели к неделе.

Метрика также подсвечивает скрытые затруднения. Падение может быть связано с долгими согласованиями, перегрузкой отдельного этапа или неудачным распределением работы. Если найти и устранить такое ограничение, поток способен стать быстрее и предсказуемее.

Внедрение начинается не с формулы, а с договорённостей. Если участники по-разному понимают, что считать завершённой единицей, сравнение периодов теряет смысл. Сначала определите рабочий элемент, затем выберите постоянный интервал и только после этого собирайте данные, визуализируйте их и используйте для прогнозов.

Есть три оговорки. Throughput измеряет количество элементов, но не их размер и сложность. Для полноценной картины его стоит сочетать с Lead Time, эффективностью потока и WIP-лимитами. Наконец, наблюдение должно быть регулярным: одинаковые определения и периоды позволяют сравнивать сопоставимые данные.

За каждым значением стоит конкретная история процесса: сколько работы было доступно, хватает ли людей, как распределены приоритеты и насколько слаженно действует команда. Даже настроение и качество взаимодействия могут отразиться на результате. Поэтому throughput нельзя трактовать как изолированную оценку производительности.

В NUBL можно вести Канбан-доску, фиксировать единое состояние готовности и отслеживать, сколько карточек дошло до последней колонки за неделю или спринт. Сам инструмент не увеличивает throughput автоматически, зато даёт команде общую картину потока и основу для разговора о причинах изменений.

Формула проста: throughput равен количеству завершённых задач, делённому на число единиц времени. Если за пять рабочих дней команда закрыла 20 задач, средняя пропускная способность составила четыре задачи в день. Для недельного показателя те же данные можно записать как 20 задач за неделю.

Считать нужно только полностью завершённую работу. Карточка, которая почти готова, но осталась на проверке, в throughput этого периода не входит. Она повлияет на показатель тогда, когда действительно достигнет финального состояния по принятому определению готовности.

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

Пропускная способность редко остаётся неизменной. На неё влияют сложность работы, доступность участников, устройство этапов и состояние команды. Чтобы понять направление, считайте завершённые элементы за одинаковые интервалы: устойчивое увеличение говорит о росте throughput, устойчивое снижение — о падении.

График делает направление заметнее, но рост — это не только большее количество карточек. Снижение разброса тоже ценно. Если результат скачет от очень высокого к очень низкому, процесс остаётся непредсказуемым и по нему трудно строить надёжные планы.

Не делайте вывод по одной удачной или неудачной неделе. Источник предлагает смотреть усреднённую динамику хотя бы за 4–6 итераций. Такой горизонт уменьшает влияние случайного всплеска и позволяет отличить изменение процесса от обычного колебания.

Гистограмма показывает, с какой производительностью команда работала в прошлом и как часто встречалось каждое значение. По горизонтальной оси откладывают фактическое число выполненных задач, по вертикальной — количество дней с таким результатом. Каждый столбик отвечает на вопрос, сколько раз система работала с определённым темпом.

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

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

Cumulative flow diagram, или CFD, связывает три важных показателя Канбан- и Agile-процесса: время производства, throughput и незавершённую работу. Диаграмма показывает интенсивность поступления новых элементов, скорость их завершения и зоны, где поток начинает расширяться.

Главная практическая задача CFD — обнаружить узкое звено. Если новых задач поступает меньше, чем команда заканчивает, запас работы со временем иссякнет. Если входящий поток выше скорости завершения, незавершённая работа будет накапливаться, система перегрузится, а отдельные задачи начнут теряться. Подробно логику ограничений разбирает материал про поиск узких мест в процессах.

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

Допустим, среднее значение — 12 задач в неделю. На две недели можно ориентировочно запланировать около 24 задач, а на месяц — около 48. Если заказчик просит добавить ещё десять, появляется предметный выбор: убрать часть текущего плана либо увеличить срок примерно на неделю.

Однако такой расчёт не обещает, что новая порция будет готова через неделю. Представим, что команда завершает 12 задач еженедельно, но время производства каждой в среднем составляет 30 дней. Throughput описывает выход системы, а не срок конкретного элемента. Поэтому прогноз нужно дополнять временем производства. Для отдельного запроса полезно сформулировать ожидание по сроку в Канбане на основе истории похожих завершений.

Исторический показатель даёт гибкость при изменении приоритетов. Команда понимает, можно ли добавить работу без последствий, что придётся убрать и как сдвинется ожидаемый результат. Для согласования объёма также полезны принципы планирования загрузки команды.

Пропускная способность — скорее следствие устройства работы и индикатор текущей картины, чем самостоятельный инструмент улучшения. Чтобы понять причину изменения показателя, проведите проверку здоровья Канбан-системы по всему пути задачи. Она показывает, сколько элементов выходит из системы, но не отвечает, хорошо это или плохо. Тридцать задач в месяц сами по себе не доказывают ни высокую, ни низкую эффективность.

Оценивать процесс помогает эффективность потока вместе с WIP-лимитами, Lead Time и throughput. Можно посмотреть, сколько времени карточка действительно обрабатывается, а сколько ждёт. Если задача проходит систему за 20 дней и 15 из них стоит в колонке «Готово к тестированию», основная потеря находится в ожидании на этом этапе.

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

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

Оцените сильные и слабые стороны участников, чтобы поручать задачи подходящим специалистам. Следите и за объёмом работы: перегрузка одного человека способна задержать всю систему, даже если у остальных остаётся свободное время. Тогда полезнее перераспределить карточки, чем требовать от узкого этапа ещё большей скорости.

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

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

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

Velocity отражает объём работы, выполненной за спринт, и обычно опирается на оценки в story points или часах. Throughput считает фактически завершённые элементы за любую выбранную единицу времени — например, задачи за неделю. Первая метрика связана с конкретной итерацией и оценкой объёма, вторая — с выходом системы.

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

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

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