Ловушка локальной оптимизации: как теория ограничений Голдратта помогает IT и бизнесу
В разработке программного обеспечения и операционном менеджменте регулярно возникает парадокс: инженерные команды закрывают рекордное количество задач в трекере, программисты внедряют AI-инструменты, отчетность рапортует о полной занятости людей, но релизы продолжают опаздывать, а клиенты неделями ждут обещанные функции. В публикации сообщества AvitoTech эта проблема рассматривается через классический управленческий бестселлер Элияху Голдратта «Цель», где сформулирована Теория ограничений (Theory of Constraints, TOC). Книга 1984 года сохраняет практическую ценность для цифровых сервисов, объясняя, почему ускорение отдельных звеньев без понимания общего потока лишь парализует компанию.
Триада метрик Голдратта: чем измерять реальный результат
Традиционный учет оценивает себестоимость операций и процент занятости каждого сотрудника. Теория ограничений предлагает иной подход: рассматривать бизнес как единую систему с главной целью — зарабатывать деньги сейчас и в будущем. Для измерения прогресса Голдратт ввел три взаимосвязанные величины:
- Проход (Throughput, T) — скорость, с которой система генерирует деньги через продажи готового продукта. В разработке аналогом прохода выступает ценность, которая реально дошла до пользователей на продакшене. Закрытые задачи в Jira или написанный код проходом не являются, пока функциональность не решает задачи клиентов.
- Запасы (Inventory, I) — средства, замороженные в незавершенном производстве. В IT эквивалентом запасов становится незавершенная работа (Work in Progress, WIP): код в очереди на code review, функциональность в тестировании или сборки, ожидающие согласования. Чем больше задач начато одновременно, тем больше денег компании обездвижено.
- Операционные расходы (Operational Expense, OE) — затраты на превращение запасов в проход: зарплаты, аренда, инфраструктура и лицензии.
Повышение локальной загрузки специалистов, не увеличивающее Throughput, лишь накапливает избыточный WIP и растит расходы, отдаляя компанию от цели.
Урок заводских роботов: почему ускорение одного звена ухудшает результат
В книге «Цель» на примере предприятия Алекса Рого описана типичная ошибка: завод закупил промышленных роботов для одного цеха. Локальная производительность взлетела, расчетная себестоимость деталей упала, но сборочные участки не успевали их собирать. Склады оказались завалены незавершенной продукцией, оборотные средства заморозились, а отгрузки заказчикам сорвались еще сильнее.
Та же картина возникает в IT-командах:
- Разработчики с помощью генеративных нейросетей начинают писать код быстрее;
- Объем пулреквестов лавинообразно нарастает;
- Этап проверки кода (code review) или тестирования (QA) оказывается перегружен;
- Ветви неделями ждут проверки, контекст забывается, копятся конфликты слияния и регрессионные ошибки;
- Срок доставки ценности пользователю увеличивается, а инженеры тратят время на разбор очередей.
Механику узкого места наглядно иллюстрирует метафора похода скаутов: скорость всей группы определяет самый медленный мальчик — Херби. Если лидеры бегут вперед, колонна растягивается на километры, строй теряет целостность, а общий темп не растет. Единственное решение — поставить Херби во главе отряда и разгрузить его рюкзак, распределив тяжелые вещи среди сильных участников.
В IT роль «Херби» выполняет перегруженный ведущий инженер, нехватка тестовых стендов или бюрократические согласования релизов. Пропускная способность системы всегда равна мощности ее самого узкого места.
Пять фокусирующих шагов теории ограничений
Для управления потоком создания ценности Голдратт разработал цикл из пяти шагов, подтвержденный исследованиями Goldratt Research Labs:
- Найти ограничение системы (Identify). Определить точку, перед которой стабильно скапливается очередь задач в ожидании обработки, проанализировав время цикла (Cycle Time) и зависшие карточки в трекере.
- Максимально использовать ограничение (Exploit). Устранить любые непроизводительные потери на узком месте: защитить ключевых специалистов от посторонних встреч, отсечь сырые вводные и автоматизировать базовые рутинные проверки до поступления на ревью.
- Подчинить остальные звенья принятому решению (Subordinate). Скорость генерации задач должна быть согласована с возможностями узкого места. Если этап ревью принимает три задачи в день, разработка не должна отправлять десять. Внедрение лимитов незавершенной работы (WIP limits) снижает локальную занятость авторов, но устраняет заторы и ускоряет релизы.
- Расширить ограничение (Elevate). Только после реализации первых трех шагов инвестировать в наращивание мощности: нанимать дополнительных специалистов, масштабировать инфраструктуру или переходить на автотесты. Вложения до наведения порядка лишь автоматизируют хаос.
- Вернуться к первому шагу без инерции (Repeat). Как только узкое место расширено, оно смещается на другой этап (например, к формированию требований). Важно не допустить, чтобы устаревшие правила стали новым тормозом.
Опасность стопроцентной загрузки: почему системе нужен буфер
Требование полной загрузки всех сотрудников на 100% — распространенная управленческая иллюзия. При максимальной утилизации у системы отсутствует резерв гибкости.
В реальных условиях задачи неравномерны: непредвиденный баг или инцидент вызывают цепную реакцию задержек. Когда все звенья работают на пределе, время ожидания задач в очереди возрастает лавинообразно. Свободная мощность на неограничивающих участках — не признак неэффективности, а осознанный буфер. Именно этот запас позволяет оперативно реагировать на внештатные ситуации и гарантировать предсказуемые сроки релизов.
Диагностический опросник для руководителя
Для аудита процессов в IT полезно ответить на шесть вопросов:
- Какой этап диктует общее время прохождения задачи от идеи до продакшена?
- Перед каким статусом стабильно накапливается очередь задач, и сколько дней они там ждут?
- Какая второстепенная работа отвлекает узкое место, и что можно делегировать уже сейчас?
- Защищено ли узкое место от сырых задач обязательными критериями готовности (Definition of Ready)?
- Готовы ли руководители ограничить поток новых задач и внедрить WIP-лимиты ради снижения очередей?
- Какой показатель подтверждает прогресс: темп выхода ценности к клиенту (Throughput) или просто число закрытых тикетов?
Теория ограничений учит видеть процесс целиком: зрелость команды определяется не скоростью написания кода, а слаженностью доставки ценности пользователю.