Backpressure для команды: почему больше работы не означает больше результата

В распределённых системах есть простая проблема: producer может создавать работу быстрее, чем consumer успевает её обрабатывать.

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

Для этого существует backpressure — механизм, с помощью которого система говорит:

«Я больше не успеваю принимать работу с такой скоростью».

С командами происходит почти то же самое.

Бизнес приносит задачи быстрее, чем команда успевает их завершать.

Разработчики открывают PR быстрее, чем коллеги успевают проводить ревью.

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

Но вместо backpressure организация часто отвечает:

«Давайте возьмём ещё одну срочную задачу».

В результате растёт WIP — количество одновременно начатой, но ещё не завершённой работы.

Появляются:

— очереди на ревью; — постоянные переключения контекста; — стареющие задачи; — новые зависимости; — незавершённая работа; — ощущение, что все очень заняты, а результат почему-то выходит медленно.

WIP limit выполняет примерно ту же функцию, что backpressure в технической системе.

Он говорит:

«Пока мы не освободили пропускную способность, новую работу не запускаем».

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

Особенно заметной эта проблема стала с появлением AI-агентов.

Раньше количество параллельной работы хотя бы естественно ограничивалось количеством разработчиков. Теперь один человек может запустить сразу несколько агентов и получить несколько изменений почти одновременно.

Throughput генерации вырос.

Но скорость ревью, тестирования, интеграции и принятия решений могла вообще не измениться.

Получается классическая очередь. Только вместо сообщений в Kafka в ней лежат PR.

И если открыть ещё пять PR, узкое место никуда не исчезнет. Очередь просто станет длиннее, изменения начнут конфликтовать, а ревьюер будет тратить всё больше времени на восстановление контекста.

Ускорение producer-а ещё не делает быстрее всю систему.

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

Где сейчас находится ваше узкое место: в разработке, ревью, тестировании или принятии решений?