---
title: Кумулятивная диаграмма потока: почему команда не успевает
metaTitle: Кумулятивная диаграмма потока
description: Почему команда не успевает при полной загрузке и как увидеть, где застревает работа, с помощью кумулятивной диаграммы потока.
date: 2026-09-28
tags: [team-workflows, metrics, ai-implementation]
cover: cover.webp
coverAlt: "Подготовка зала к празднику: у двери подвозят новые коробки, девушка с розовыми волосами несёт сразу ковёр, стул и цветы, а у сцены готовы только две стойки"
---

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

## Почему все заняты, а сроки всё равно срываются

Занятость и пропускная способность - разные вещи. Пропускная способность - сколько задач команда доводит до конца за неделю. Человек может быть занят с утра до вечера, а его задачи при этом стоят на месте.

Вот эпизод, восстановленный по рабочей переписке одной компании. В 10:00 руководитель продукта написал задачу дизайнеру. Дизайнер был занят - открыл задачу через три часа, почитал десять минут и задал вопросы, потому что что-то было непонятно. Руководитель продукта сидел на встречах и ответил ещё через три часа. К тому моменту дизайнер уже не успевал: рабочий день закончился. Созвонились утром следующего дня, и только тогда появился черновик. Работа на два часа растянулась на три дня и всё равно вышла с ошибками. Задача больше ждала, чем делалась.

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

Полная загрузка людей ничего не говорит о том, когда задача будет готова.

## Как устроена кумулятивная диаграмма потока

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

Полос столько, сколько статусов в процессе. В трекере задач это могут быть: бэклог (список ещё не начатых задач), «к выполнению», «в работе», «проверка», «заблокировано», «сделано». Обработка заказов интернет-магазина, сделки в системе учёта клиентов, задачи маркетинга - везде есть статусы, и везде можно нарисовать такую диаграмму.

Нижняя полоса «сделано» только растёт: задачи, закрытые однажды, никуда не деваются. Верхний край всей фигуры - это всё, что поступило с начала наблюдения. Толщина любой полосы на конкретной неделе показывает, сколько задач в этом статусе прямо сейчас. Толщина полосы «в работе» - это число задач в работе (в трекерах их часто обозначают WIP, от английского work in progress).

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

### Учебный пример: таблица по неделям

Числа в этом примере условные. В первую неделю пришло 20 задач, дальше приходит по 12 в неделю; начинают по 10 в неделю, заканчивают по 5.

| Неделя | Поступило всего | Начато всего | Сделано всего | В очереди | В работе |
|--------|----------------|--------------|---------------|-----------|----------|
| 1 | 20 | 10 | 5 | 10 | 5 |
| 2 | 32 | 20 | 10 | 12 | 10 |
| 3 | 44 | 30 | 15 | 14 | 15 |
| 4 | 56 | 40 | 20 | 16 | 20 |
| 5 | 68 | 50 | 25 | 18 | 25 |
| 6 | 80 | 60 | 30 | 20 | 30 |

«В очереди» - это «Поступило всего» минус «Начато всего». «В работе» - «Начато всего» минус «Сделано всего».

Чтобы нарисовать диаграмму по этой таблице, нужны три линии: по столбцам «Поступило всего», «Начато всего» и «Сделано всего». Между первой и второй линией получится полоса очереди, между второй и третьей - полоса задач в работе. Полоса «в работе» растёт на 5 задач каждую неделю - это первый из трёх рисунков: полоса расширяется. Верхняя линия поднимается на 12 в неделю, нижняя на 5 - второй рисунок, расходящиеся наклоны. Если бы приходило, начиналось и заканчивалось по 5 задач в неделю, три линии шли бы параллельно, а толщина полос не менялась бы - третий рисунок, здоровый поток.

## Три рисунка, которые видно сразу

В таблице ниже дефект - это ошибка в уже сделанной работе: её приходится исправлять, и она тоже встаёт в очередь.

| Что видно на диаграмме | Что это значит | Что делать |
|------------------------|----------------|------------|
| Полоса «в работе» расширяется | Задачи начинают быстрее, чем заканчивают; каждая новая ждёт дольше | Ввести лимит задач в работе и сначала доделывать начатое |
| Верхняя линия круче нижней | Новые требования и дефекты приходят быстрее, чем их закрывают; очередь растёт, и темп внутри команды её не догонит | Считать приток отдельно по видам, решать, от чего отказаться, убирать причины дефектов |
| Полосы идут ровно и параллельно | Здоровый поток: сколько пришло, столько начали и закончили; срок предсказуем | Держать лимит и смотреть на диаграмму раз в неделю |

### Как это выглядело у одной команды

Диаграмму одной команды построили по данным её трекера задач. На старте у неё уже было около 100 задач. В первые пять недель в работу брали примерно по восемь задач в неделю. Линии «взято в работу» и «сделано» расходились по наклону: команда каждую неделю брала больше задач, чем успевала нормально закончить - и это было видно без всяких расчётов.

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

Позже команда стала брать меньше задач в работу. Но накопленное уже сработало: задача, начатая примерно на четвёртой неделе, дошла до сдачи примерно на шестнадцатой - около 12 недель на одну задачу. Одни задачи делались за день, другие за месяц: так сказывались большие проекты.

## Закон Литтла: сколько будет идти задача

Формула называется закон Литтла. Она связывает три числа.

**Среднее время выполнения равно среднему числу задач в работе, делённому на пропускную способность.**

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

Но то же деление годится и для быстрого прогноза на сейчас. Возьмём учебные данные из таблицы выше: если задачи берут по очереди, у задачи, начатой на шестой неделе, впереди 30 задач. Команда закрывает по 5 в неделю, значит, от начала работы до сдачи пройдёт около 6 недель.

Но задачи ещё и ждут в очереди. Если смотреть на заявку, которая поступила на шестой неделе: впереди неё 20 задач в очереди и 30 в работе, вместе 50 задач - при темпе 5 в неделю это около 10 недель.

Из них около четырёх недель задача просто ждёт, пока до неё дойдут руки.

Это прогноз при нынешнем темпе, а не среднее по закону Литтла. В примере поток неустойчив - очередь и число задач в работе растут, поэтому сам закон здесь в точном виде неприменим. Если приходит 12 задач в неделю, а заканчивают 5, каждая следующая задача будет ждать дольше.

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

## Приток против закрытия: почему план по остатку не сходится

![В швейной мастерской расписание на стене отрывается под новыми бирками, рядом корзина возвратов, а девушка с розовыми волосами дошивает одно изделие](/blog/cumulative-flow-diagram/fig-inflow.webp "Новые заказы и возвраты приходят быстрее, чем их успевают закрыть, и расписание не выдерживает")

Типичный план звучит так: надо сделать 150 единиц работы, команда закрывает по 15 в неделю - значит через 10 недель всё готово.

Но работа ещё и приходит: дефекты, уточнения, новые требования. В учебном примере: если каждую неделю добавляется 5 единиц, остаток снижается на 10 в неделю, а не на 15.

Если остаток уменьшается на 10 в неделю, 150 единиц уйдут за 15 недель.

На пять недель дольше плана. А если добавляется 15 единиц в неделю - остаток не снижается вообще.

Представьте ванну: если вливается столько же, сколько выливается, уровень не падает. Спешка ускоряет закрытие задач и одновременно производит новые дефекты - те, которых пока никто не видит. Работа над продуктом может расходиться: остаток растёт, хотя все заняты закрытием задач.

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

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

С притоком работают отдельно: считают его по видам - новые требования, дефекты, срочное, - решают, от чего отказаться, и убирают причины дефектов, чтобы те не возвращались в очередь.

Счёт одних закрытых задач показывает только половину картины.

## Лимит задач в работе: как ввести его без революции

![Девушка с розовыми волосами ставит штамп на готовый заказ, на полке выдачи три ячейки и одна свободна, а новые коробки ждут на тележке](/blog/cumulative-flow-diagram/fig-limit.webp "На полке всего три места: следующий заказ берут в работу, когда готовый уходит к покупателю")

Лимит задач в работе - это договорённость о максимальном числе задач на этапе или у одного человека.

Как это делается на практике:

1. Посчитайте, сколько задач сейчас в работе на каждом этапе или у каждого человека.
2. Договоритесь о лимите ниже этого числа.
3. Новую задачу берут только тогда, когда закончена одна из текущих.
4. Держите очередь на виду и раз в неделю решайте, что делать первым и от чего отказаться.
5. На ежедневной короткой встрече задавайте один вопрос: что тебя сейчас блокирует.
6. Раз в неделю смотрите на диаграмму: полоса «в работе» должна перестать расширяться.

Учебный расчёт: команда закрывает 5 задач в неделю, лимит задач в работе - 10.

При 10 задачах в работе и темпе 5 задач в неделю срок от начала работы до сдачи составит 2 недели.

Против шести недель при 30 задачах в работе из примера выше - при той же пропускной способности.

У лимита есть три оговорки.

Общий срок от поступления заявки до результата сокращается, только если управлять очередью: решать, что делать первым и от чего отказаться. Иначе ожидание просто переезжает из полосы «в работе» в очередь, и суммарный срок не меняется.

Если приходит 12 задач в неделю, а команда закрывает 5, лимит этот перекос не исправит. Нужно снижать приток или поднимать пропускную способность - или и то, и другое.

После снижения притока сроки не падают сразу. Сначала надо доделать то, что уже накопилось - это видно по истории команды выше: она стала брать меньше задач, а срок уже успел вырасти до 12 недель.

## Что меняет AI и с чего начать

AI ускоряет и поток, и хаос. Если один человек с AI-агентами резко ускорился, он упрётся в систему вокруг, и её скорость его затормозит.

Автоматизировать сломанный процесс - значит получить тот же сломанный процесс, только быстрее и в большем масштабе. Эта ошибка внедрения разобрана в статье [почему AI-проекты не достигают целей](/ru/blog/ai-implementation-process/).

Диаграмму потока можно построить автоматически. AI-агент делает это по выгрузке задач из трекера с датами смены статусов - дёшево и быстро. Но результат нужно проверить так же, как любой другой отчёт агента. Как это выглядит на сложных таблицах, показано в статье [как AI разбирает сложный Excel и собирает дашборд](/ru/blog/ai-excel-dashboard-audit/).

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

Первая реакция на кумулятивную диаграмму потока обычно такая: «наверное, у всех так». На деле это просто никто не мерил. Что не измеряете - тем не управляете, и многие решения, которые кажутся эффективными, на цифрах быстро оказываются неэффективными.

Majento внедряет ИИ в рабочие процессы и начинает с одного процесса: нужен владелец процесса, данные, доступ и критерии - что считать хорошим результатом. Для первого разговора полезно описать один процесс, системы в нём и то изменение, которое хотите измерить. Среднее время задачи и число задач в работе - хорошее начало. Подробнее о подходе - на странице [внедрение ИИ](/ru/ai-implementation/). Как рабочая задача команды превращается в проект внедрения, показано на [демонстрации пилота](/ru/team-ai-pilot/).

## Вопросы и ответы

### Чем кумулятивная диаграмма потока отличается от диаграммы сгорания задач?

Диаграмма сгорания показывает один остаток: сколько работы ещё не сделано. Если остаток перестал падать, по ней не понять, команда стала медленнее закрывать задачи или работы стало больше приходить. Кумулятивная диаграмма потока рисует приток, работу и закрытие отдельными линиями, и причина видна сразу.

### Подходит ли диаграмма, если у нас не разработка?

Да. Любой процесс со статусами подходит: обработка заявок, движение сделок в системе учёта клиентов, задачи маркетинга, заказы интернет-магазина. Нужны данные с датами смены статусов, выгруженные из трекера задач или системы учёта клиентов.

### Какой лимит задач в работе поставить?

Начните с числа ниже текущего. По закону Литтла лимит примерно равен желаемому времени выполнения, умноженному на пропускную способность команды. Учебно: команда закрывает 5 задач в неделю и хочет укладываться в 2 недели - значит, лимит задач в работе около 10. Это стартовая точка: потом лимит корректируют по тому, что показывает диаграмма.

### Почему после того, как стали брать меньше задач, сроки не сократились сразу?

Сначала доделывают то, что уже накопилось. Задачи, начатые в период высокой загрузки, всё ещё идут через систему. Диаграмма покажет это: полоса «в работе» будет постепенно сужаться.

### Можно ли поручить построение диаграммы AI-агенту?

Да, по выгрузке из трекера с датами смены статусов. После этого нужно проверить: число задач в каждом статусе на выбранную дату должно совпадать с тем, что трекер показывает на ту же дату. Так ошибка выгрузки не попадёт в выводы.

Если хотите разобрать поток задач своей команды и найти, где застревает работа, напишите в [Telegram](https://t.me/shimaoz) или на [hello@majento.ai](mailto:hello@majento.ai).