Миф о 100% загрузке: почему ваши программисты вечно заняты, а релизов всё нет

Загляните в любой корпоративный таск-трекер. Вы наверняка увидите там идеальную картину: у каждого разработчика в колонке «В работе» висит по 5-7 задач, никто не простаивает, утилизация ресурсов стремится к 100%. Менеджеры радостно потирают руки — деньги инвесторов отрабатываются по полной.

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

Как так получается, что все работают на пределе возможностей, а продукт стоит на месте?

Проблема в том, что большинство руководителей управляют интеллектуальным трудом так, будто это заводской конвейер. Но ИТ — это не завод. И требование 100% загрузки, это лучший способ убить скорость разработки и выжечь команду дотла. Давайте разберем на цифрах и законах математики, почему это так работает.

Чтобы понять абсурдность 100% загрузки, представьте себе современное шоссе. Какова его максимальная пропускная способность? Если вы заполните дорогу автомобилями на 100%, бампер к бамперу, движение не ускорится. Оно полностью остановится. Возникнет глухая пробка, и скорость упадет до нуля. Чтобы машины могли ехать со скоростью 100 км/ч, на дороге должно быть пустое пространство.

В разработке происходит то же самое. Это доказывает Закон Литтла — фундаментальная математическая теорема из теории массового обслуживания (и основа Канбан-метода).

Формула проста: Время выполнения = Количество задач в работе (WIP) / Пропускная способность.

Если ваша команда способна закрывать 10 задач в неделю, а вы напихали им в работу 50 тикетов, чтобы никто не сидел без дела, среднее время выполнения одной задачи математически увеличится до 5 недель. Разработчики не стали работать хуже. Просто система переполнилась. Любая новая задача, которую вы с криком «Это срочно!» кидаете в команду, только сильнее замедляет все остальные.

Бизнес обожает измерять ресурсную эффективность (занят ли человек?). Но клиенту плевать, насколько сильно потел программист. Клиенту важна потоковая эффективность (Flow Efficiency) — как быстро движется сама задача от стадии «Идея» до стадии «Релиз».

Возьмем типичную задачу, которая делалась 10 дней (Lead Time). Если вы сложите чистое время, когда разработчик реально писал код, а тестировщик его проверял, вы получите от силы 1-2 дня. Где задача была остальные 8 дней?

Она лежала в очередях. Ждала код-ревью, ждала, пока освободится QA, ждала деплоя. В большинстве ИТ-команд Flow Efficiency редко превышает 15%. То есть 85% времени задача просто пылится на доске.

И знаете почему? Потому что все заняты на 100%. Когда тестировщик находит баг, разработчик не может его быстро поправить — он уже по уши загружен новой «очень важной» фичей. Возникает затор.

Помимо математики очередей, есть еще физиология. Концепция Cognitive Load (Когнитивная нагрузка) из когнитивной психологии говорит прямо: оперативная память человека строго ограничена.

Когда вы заставляете разработчика жонглировать пятью задачами одновременно, его мозг тратит колоссальное количество энергии на переключение контекста. Каждое переключение сжигает до 20% мыслетоплива. В итоге программист тратит свои умственные силы не на решение бизнес-проблем (полезная нагрузка), а на попытки вспомнить, где он остановился, и борьбу с инфраструктурой (посторонняя нагрузка). Результат — глупые ошибки в коде, рост технического долга и выгорание.

Еще в начале 2000-х Том ДеМарко в своей культовой книге «Slack» доказал: чтобы система была быстрой и гибкой, в ней должен быть «люфт».

Slack Time — это осознанно запланированное свободное время команды (буфер), которое не забито продуктовыми задачами. В зрелых Agile-командах под продуктовые фичи планируют не более 70-80% времени спринта.

Оставшиеся 20% — это не время для просмотра YouTube. Это ваш стратегический кислород. Если падает сервер или прилетает критический баг, команда чинит его за счет этого буфера, не срывая сроки по основным фичам. Если форс-мажоров нет, разработчики тратят это время на рефакторинг, автоматизацию рутины, улучшение CI/CD или помощь зашивающимся тестировщикам (чтобы устранить те самые очереди).

Когда вы попытаетесь внедрить лимиты на работу и Slack Time, система начнет сопротивляться. Вот что вы услышите от классических менеджеров:

1. «Мы платим им за 8 часов работы, они должны кодить все 8 часов!»

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

2. «Если мы дадим им свободное время, они будут бездельничать»

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

3. «У нас жесткие дедлайны, мы не можем позволить себе буферы»

Именно потому, что у вас дедлайны, вам и нужен буфер. 100% утилизация математически гарантирует срыв сроков при малейшем форс-мажоре. Идеальных планов не существует.

4. «Надо просто нанять больше людей»

Добавление людей в перегруженную, запутанную систему только увеличит хаос и когнитивную нагрузку на коммуникацию (вспоминаем закон Брукса). Сначала наладьте поток, ограничив незавершенную работу.

Главное правило современного управления разработкой звучит парадоксально: Stop starting, start finishing (Перестаньте начинать, начните заканчивать).

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

P.S. Этот текст — адаптированная выжимка из базы знаний. Если вы хотите разобраться, как на самом деле управлять потоком с помощью Kanban, что такое метод Монте-Карло и как работают продуктовые метрики без воды — заглядывайте в мой глоссарий Your Agile Hub.