Как использовать пропускную способность (throughput) в Канбан-методе

Пропускная способность — это не просто метрика, а зеркало реальности команды. Она показывает, сколько задач реально завершается за определённый период, а не сколько было запланировано. В условиях, когда компании сталкиваются с растущими ожиданиями клиентов и ограниченными ресурсами, понимание throughput становится ключом к стабильной, предсказуемой и устойчивой работе. В Канбан-методе эта метрика выходит за рамки простого подсчёта — она превращается в инструмент для диагностики процессов, управления ожиданиями и построения доверия между командой и заказчиками. Но как её правильно измерить? Что влияет на неё? И как использовать данные, чтобы действительно улучшить производительность — без перегруза и выгорания?

Что такое пропускная способность (throughput) и зачем она нужна

Пропускная способность (от англ. throughput) — это количество рабочих элементов, которые команда успешно завершает за фиксированный интервал времени. Это не количество запланированных задач, не объём работы в баллах или оценках, а реальные результаты. Если команда за месяц завершила 15 задач — их пропускная способность равна 15. Даже если было запланировано 40, важно не то, что планировали, а то, что получилось.

Эта метрика отражает истинную скорость работы. Она не обманывает, не преувеличивает и не снижает оценки — она говорит правду. Когда заказчик спрашивает: «Когда мы получим результат?», ответ на этот вопрос можно дать только через throughput. Без него планирование становится угадыванием, а обещания — пустыми словами.

Три ключевые причины, почему throughput необходимы:

• Принятие решений: зная, сколько задач команда реально может завершить за неделю, руководитель может решить — брать ли новые задачи или сосредоточиться на текущих.
• Инспекция и улучшение процессов: если throughput падает, это сигнал о проблемах — возможно, задачи стали сложнее, возникли бутылочные горлышки или команда устала. Без этой метрики такие проблемы остаются незамеченными.
• Управление ожиданиями: если клиент знает, что команда в среднем завершает 12 задач в неделю, он перестаёт требовать «сделать всё завтра». Вместо этого он участвует в планировании, основываясь на реальных данных.

Throughput — это не показатель «насколько хорошо команда работает», а индикатор того, как устроен процесс. Он не оценивает личную производительность, а показывает системные особенности. Именно поэтому его нельзя использовать для сравнения разных команд — только для анализа одной команды в динамике.

Throughput vs. другие метрики: в чём разница

Часто throughput путают с другими метриками, такими как lead time (время производства) или cycle time. Но они измеряют разное.

Например, команда может иметь высокий throughput — завершает 20 задач в неделю. Но если каждая из них проводит 14 дней в ожидании согласования, то lead time слишком высокий. Это значит: команда работает быстро, но процесс тормозит. Без анализа lead time и эффективности потока throughput может ввести в заблуждение.

Поэтому throughput всегда нужно использовать в связке с другими метриками. Только тогда он становится мощным инструментом, а не просто цифрой в отчёте.

Как рассчитать пропускную способность: пошаговая инструкция

Расчёт throughput звучит просто, но на практике многие ошибаются в базовых шагах. Давайте разберём его поэтапно — от определения рабочего элемента до вычисления среднего значения.

Шаг 1: Определите, что считать рабочим элементом

Первое и самое важное решение — что именно вы будете считать. Это может быть:

• Пользовательская история
• Баг (ошибка)
• Технический долг
• Исследовательская задача (spike)
• Задача на улучшение процессов

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

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

Шаг 2: Выберите период измерения

Период должен быть одинаковым на каждом этапе. Часто выбирают:

• Неделя — для команд с высокой частотой выгрузки
• Две недели — если работаете по двухнедельным спринтам
• Месяц — для проектов с длительными циклами

Важно: не меняйте период в процессе анализа. Если вы начали с недельных данных, не переходите на дневные — это исказит тренды. Если вы хотите сравнить недельный throughput с месячным — делайте это только после сбора полного цикла данных.

Шаг 3: Отслеживайте завершённые задачи

Следите за тем, что задача действительно дошла до колонки «Готово». Не считайте задачи, которые «почти сделаны», «ждут тестирования» или «на ревью». Только те, которые полностью завершены и переданы заказчику или в эксплуатацию.

Используйте доску Канбан: каждая задача, перетаскиваемая в «Готово», должна фиксироваться. Можно использовать автоматизацию — например, интеграцию с Jira или WEEEK, где завершение задачи автоматически фиксирует дату и добавляет её в статистику.

Шаг 4: Считайте и усредняйте

Формула проста:

Throughput = количество завершённых задач / количество единиц времени

Пример: за последние 4 недели команда завершила 6, 9, 8 и 7 задач. Средний throughput:

6 + 9 + 8 + 7 = 30

30 ÷ 4 = 7,5 задач в неделю.

Если вы работаете по месяцам: за июнь — 14, июль — 18, август — 20. Средний throughput:

14 + 18 + 20 = 52

52 ÷ 3 ≈ 17,3 задачи в месяц.

Важно: не используйте максимальное значение как «норму». Если в одной неделе команда закрыла 15 задач — это не значит, что так должно быть каждый раз. Это может быть результатом переработки или временного сброса бэклога. Истинный показатель — это медиана или среднее за 4–6 периодов.

Шаг 5: Сохраняйте последовательность

Одна из самых частых ошибок — менять определения. Например, в январе вы считали только пользовательские истории, а в феврале добавили баги. Теперь ваш throughput «вырос» — но это не потому, что команда стала быстрее. Это потому, что вы изменили правила игры.

Чтобы этого избежать:

• Задокументируйте критерии рабочего элемента
• Убедитесь, что все члены команды понимают их одинаково
• Не меняйте определения без веских причин — и если меняете, начинайте отсчёт заново

Пропускная способность — это метрика, которая требует дисциплины. Без неё она теряет смысл.

Факторы, влияющие на пропускную способность

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

1. Количество задач в процессе

Казалось бы, чем больше задач — тем выше throughput. Но на практике всё иначе. Если вы дадите команде 50 задач одновременно — они не завершат их быстрее. Напротив, многозадачность снижает производительность. Каждый переход между задачами требует переключения внимания — и это уносит до 40% времени по данным исследований Harvard Business Review.

Канбан-метод предлагает решение: ограничить количество задач в работе (WIP-лимиты). Это не значит, что команда будет меньше работать — это значит, что она будет меньше «зависать» в незавершённых задачах. Когда команда фокусируется на 5–7 задачах одновременно, она завершает их быстрее. И throughput растёт.

2. Размер и структура команды

Чем больше людей — тем выше потенциальная пропускная способность. Но только до определённого предела.

Закон Бrooksа утверждает: «Добавление людей к запоздавшему проекту делает его ещё более запоздавшим». Почему? Потому что:

• Растут накладные расходы на коммуникацию
• Усложняется координация
• Появляются барьеры в передаче знаний

Оптимальный размер команды для Канбана — 5–9 человек. Больше — и начинаются затраты на синхронизацию, меньше — и не хватает ресурсов для устойчивого потока.

Важно: не просто добавлять людей, а улучшать структуру взаимодействия. Если у вас 12 человек, но они не общаются между собой — throughput будет ниже, чем у 6-человечной команды с хорошей культурой.

3. Уровень навыков и экспертизы

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

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

4. Эффективность процессов

Это, пожалуй, самый мощный фактор. Команда может быть талантливой, но если у неё нет чётких правил — throughput будет нестабильным.

Пример: команда работает 5 дней в неделю, но каждая задача проходит через 7 этапов согласования. Каждое согласование занимает 2–3 дня. Итого: задача «висит» в ожидании 14 дней, а реально работает — всего 2 дня. В результате throughput падает, хотя все работают на полную.

Как исправить? Анализируйте этапы процесса. Спросите: «Где задачи зависают?» Используйте кумулятивную диаграмму потока — она покажет, где накапливаются задачи. Чаще всего проблема — в неопределённых критериях «готово» или отсутствии SLA (уровней обслуживания) на этапы.

5. Технологии и инструменты

Инструменты не решают проблемы, но они могут их усугубить или облегчить. Неправильный таск-менеджер — это как автомобиль с ручной коробкой, если вы едете по трассе. WEEEK, Jira, Trello — они не делают работу лучше, но если правильно настроены, они:

• Автоматически фиксируют даты начала и завершения
• Позволяют визуализировать WIP-лимиты
• Генерируют отчёты по throughput без ручного ввода
• Связывают задачи с метриками lead time и cycle time

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

6. Эмоциональное состояние команды

Мало кто говорит об этом открыто, но оно критично. Усталость, выгорание, недоверие — всё это снижает throughput. Команда, которая боится ошибаться, не берёт сложные задачи. Команда, где нет автономии — не инициирует улучшения. Команда, которая чувствует, что её «считают за ресурс» — перестаёт вкладываться.

Канбан-метод напрямую противостоит этому: его принцип «Управляйте работой, а не людьми» создаёт пространство для доверия. Когда люди видят, что их работа измеряется не по «сделано ли всё», а по «как устроен процесс» — они начинают предлагать улучшения. А это напрямую влияет на пропускную способность.

Визуализация throughput: как сделать данные понятными

Числа в таблице — это сухие цифры. Графики — это истории.

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

1. График пропускной способности

Это линейный график, где по оси X — временные периоды (недели/месяцы), а по оси Y — количество завершённых задач. Каждая точка — это throughput за этот период.

Такой график показывает:

• Тренд: растёт ли throughput, падает или стабилен?
• Волатильность: насколько сильно скачут значения?
• Пиковые точки: что происходило в те недели, когда throughput был выше?

Например: если в неделю 12 throughput = 10, а в неделю 13 — 5, это сигнал. Возможно, кто-то ушёл в отпуск. Или добавили задачи с высокой сложностью. Визуализация помогает увидеть причину — а не просто констатировать факт падения.

2. Гистограмма пропускной способности

Гистограмма показывает, как часто команда достигала определённого уровня throughput. По оси X — количество завершённых задач за период, по оси Y — сколько раз это случалось.

Пример: команда за 20 недель завершила:

• 5 задач — 1 раз
• 6 задач — 3 раза
• 7 задач — 5 раз
• 8 задач — 6 раз
• 9 задач — 4 раза
• 10 задач — 1 раз

Гистограмма покажет, что чаще всего команда завершает 8 задач. Это — медиана. И если вы планируете на 12 — вы рискуете не уложиться. Если же планируете на 6 — вы недоиспользуете потенциал.

Этот инструмент идеален для прогнозирования. Он говорит: «Вероятность, что вы завершите 8 или больше задач — 75%».

3. Кумулятивная диаграмма потока (CFD)

Это, пожалуй, самый мощный инструмент в Канбане. CFD показывает три ключевых параметра одновременно:

• Throughput: наклон верхней линии — чем круче, тем выше производительность
• Lead time: вертикальное расстояние между нижней и верхней линиями — сколько времени задача проводит в системе
• WIP (Work in Progress): разница между количеством принятых и завершённых задач

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

Особенно полезно использовать CFD для ответа на вопрос: «Мы можем взять ещё 10 задач?»

Если CFD показывает, что WIP уже высокий — ответ: «Нет». Если WIP стабилен, а throughput растёт — тогда да. Но только если вы готовы удерживать WIP в пределах лимитов.

4. Дневная пропускная способность

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

• Влияние выходных
• Резкие скачки после внедрения новых практик
• Снижение производительности в определённые дни (например, по понедельникам)

Например: если в понедельники throughput падает на 40% — возможно, команда тратит время на «восстановление» после выходных. Решение: запускать короткий стендап-митинг в воскресенье вечером, чтобы «разогреть» процесс.

Как использовать throughput для прогнозирования и планирования

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

Прогнозирование на основе исторических данных

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

1. Соберите данные за последние 4–6 периодов (недель/месяцев)
2. Посчитайте среднее значение
3. Оцените волатильность: максимум и минимум
4. Создайте диапазон: среднее ± стандартное отклонение

Пример:

• Недели: 12, 14, 10, 13, 15, 11
• Среднее: (12+14+10+13+15+11) ÷ 6 = 12,5
• Минимум: 10, максимум: 15
• Диапазон прогноза: от 10 до 15 задач

Теперь вы можете сказать заказчику: «В следующем месяце мы, скорее всего, завершим от 10 до 15 задач. Если вам нужно 20 — мы можем взять только 15, и тогда придётся отложить остальные. Или мы можем увеличить срок на 2 недели».

Это превращает разговоры в переговоры на основе данных — а не эмоций.

Планирование спринтов на основе throughput

Если вы используете KPI в планировании:

• Возьмите средний throughput за последние 3–5 спринтов
• Учтите внешние факторы: отпуска, праздники, изменения в составе
• Не берите больше, чем средний показатель — даже если «все уверяют», что сейчас всё пойдёт отлично
• Оставляйте 10–20% резерва на непредвиденные задачи

Если ваша средняя throughput — 18 задач за спринт, и в следующем спринте у вас два человека в отпуске — не берите 20. Берите 14–16. Это снижает стресс, повышает надёжность и укрепляет доверие.

Пример: как команда научилась планировать по throughput

Команда из 7 человек работала над SaaS-продуктом. Каждый месяц заказчик требовал «всё за один спринт». Команда постоянно перерабатывала, но не успевала. В итоге — выгорание.

Они начали измерять throughput. За 4 месяца получили:

• Средняя пропускная способность: 14 задач/месяц
• Lead time: в среднем 22 дня
• WIP-лимит: 8 задач одновременно

Когда заказчик в следующий раз сказал: «Нужно сделать 25 задач за месяц» — команда ответила:

«Мы можем сделать 14 задач в месяц. Если вы хотите 25 — у нас есть два варианта: либо добавить ещё 3 человека, либо отложить 11 задач на следующий месяц. Мы можем показать вам, где именно возникают задержки — и если вы готовы их устранить, мы увеличим throughput».

Заказчик согласился. Через два месяца throughput вырос до 18 задач в месяц — благодаря устранению бутылочных горлышек на этапе тестирования. Но главное — заказчик перестал требовать «больше» и начал планировать вместе.

Как улучшить пропускную способность: практические шаги

Throughput — это результат, а не инструмент. Но вы можете влиять на факторы, которые его определяют.

1. Уменьшайте размер задач

Задачи размером «сделать функцию X» — это таймер. Они редко закрываются вовремя, потому что слишком велики. Разбивайте их на подзадачи: «создать дизайн», «написать API», «подключить UI». Каждая подзадача — отдельная единица работы. Это позволяет:

• Завершать задачи быстрее
• Получать обратную связь раньше
• Уменьшить lead time

Чем меньше задача — тем выше throughput.

2. Внедряйте WIP-лимиты

Ограничение задач в работе — это не ограничение производительности. Это увеличение фокуса.

Если команда работает с WIP=5, то:

• Каждый член команды знает, что делать
• Нет «я тут всё сделаю» — только «что сейчас на очереди?»
• Проблемы в процессе становятся видны сразу — если задача застряла, её можно заметить

Это прямой путь к стабильному throughput.

3. Устраняйте узкие места

Используйте CFD. Найдите столбец, где задачи «встают» чаще всего — это узкое место. Пример: если все задачи долго ждут в «Готово к тестированию» — значит, тестировщиков мало. Решения:

• Добавить автоматизацию тестирования
• Обучить разработчиков писать автотесты
• Назначить тестировщика на полставки в команду

Устраните узкое место — и throughput вырастет.

4. Стандартизируйте процессы

У всех ли задач есть чёткие критерии «готово»? Есть ли стандартный шаблон для задач? Есть ли проверка качества перед переходом в «Готово»?

Если нет — вы тратите время на переработки. Каждая задача, которая возвращается — это потеря throughput.

Создайте карточку «Критерии готовности» для каждого типа задачи. Повесьте её на доску. Спросите: «Можете ли вы сказать, что задача готова — без вопросов?»

5. Проводите регулярные ретроспективы

Спросите: «Что мешает нам завершать больше задач?»

Ответы часто одинаковые:

• «Слишком много встреч»
• «Никто не знает, кто за что отвечает»
• «Постоянно меняются требования»

Возьмите 2–3 проблемы — и решайте их системно. Не «попробуем», а измерим. После внедрения изменения — смотрите, как изменился throughput. Если вырос — это улучшение. Если нет — попробуйте другое.

6. Улучшайте коммуникацию

Слишком много «проверок», «согласований» и «митингов» — это убивает throughput. Каждая коммуникационная точка — это задержка.

Решение: внедрите практику «непрерывного согласования» — например, через Slack-каналы с тегами или автоматические уведомления. Сократите встречи до 15 минут, сделайте их регулярными — и ставьте конкретные вопросы: «Кто может подтвердить готовность?»

Ошибки, которые разрушают throughput

Несмотря на простоту метрики, её часто используют неправильно. Вот самые частые ошибки — и как их избежать.

Ошибка 1: Сравнивайте throughput разных команд

Это как сравнивать скорость лошади и автомобиля — они вообще разные системы. Две команды могут иметь одинаковый throughput, но совершенно разную эффективность: одна работает с WIP=20, другая — с WIP=5. Первая кажется «быстрее», но на самом деле она перегружена и рискует выгореть.

Вывод: сравнивайте только свою команду с собой в прошлом.

Ошибка 2: Используете throughput как KPI для отдельных сотрудников

Если вы скажете разработчику: «Ты должен закрывать 5 задач в неделю» — он начнёт делать мелкие, бесполезные задачи. Или станет бояться сложных. Throughput — метрика команды, а не личности.

Вывод: используйте её для улучшения процесса, а не контроля людей.

Ошибка 3: Не учитываете lead time

Вы можете иметь высокий throughput — но если каждая задача занимает 60 дней, это не успех. Это бедствие. Потому что заказчики ждут результаты, а не «количество завершённых».

Вывод: всегда смотрите на throughput и lead time вместе. Если один растёт, а другой — нет — есть проблема.

Ошибка 4: Слишком часто меняете периоды

Если вы считаете throughput за неделю, а потом переключились на месяц — вы теряете тренд. Данные становятся несопоставимыми.

Вывод: выберите период и придерживайтесь его минимум 3 месяца.

Ошибка 5: Игнорируете контекст

Throughput упал — значит, команда ленивая? Возможно. А может, вчера упал сервер, и все занимались авариями? Или пришлось срочно делать интеграцию с новым клиентом?

Вывод: всегда спрашивайте «почему?» — прежде чем делать выводы.

Заключение: throughput как фундамент устойчивого роста

Пропускная способность — это не метрика производительности. Это метрика зрелости.

Команда, которая измеряет throughput:

• Перестаёт обещать «сделаем всё»
• Начинает планировать реалистично
• Учится говорить «нет» на основе данных
• Перестаёт бояться изменений — потому что знает, как они влияют на результат
• Строит доверие с заказчиками — не через слова, а через предсказуемость

Канбан-метод учит нас: не пытайтесь заставить людей работать быстрее. Попробуйте сделать процесс быстрее. Throughput — это то, что показывает, насколько ваш процесс работает.

Если вы начинаете измерять throughput — вы начинаете управлять системой. А не людьми.

Начните с одного шага: выберите тип задач, определите период и начните считать. Не перегружайте. Просто смотрите. Анализируйте. Улучшайте.

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

Именно это — ключ к долгосрочному успеху в управлении проектами.