Теория ограничений и бережливое мышление

На проекте вы постоянно выбираете, куда направить ограниченное внимание команды и заказчика: на десятки мелких хотелок или на то, что реально тормозит поставку ценности. Теория ограничений (Theory of Constraints, TOC) и бережливое мышление (Lean thinking) дают две взаимодополняющие линзы: TOC — где узкое место определяет пропускную способность системы, Lean — где потери съедают ценность для потребителя. Статья отвечает на вопрос: как искать ограничение, устранять muda и синтезировать оба подхода в работе аналитика — после 01.01 Понятие системы и системного подхода, 01.02 Ментальные модели аналитика и 01.03 Техники анализа проблем.

1. Суть темы

Теория ограничений (Элияху Голдратт, The Goal, 1984) утверждает: у любой системы в каждый момент есть одно (или очень мало) доминирующее ограничение, определяющее её throughput. Улучшение чего-либо за пределами этого ограничения не даёт значимого системного эффекта — «цепь не прочнее своего самого слабого звена».

Бережливое мышление (Toyota Production System, TPS; адаптация для ПО — Lean Software Development, Поппендики) направлено на максимизацию ценности для заказчика через устранение всего, что ресурсы потребляет, но ценности не создаёт.

TOC и Lean не конкурируют. TOC отвечает «где сейчас главный тормоз?», Lean — «где в потоке лишняя работа и ожидание?». Кажущееся противоречие между Lean-принципом Optimize the Whole и TOC-фокусом «работай только с одним ограничением» снимается через подчинение системы ограничению (Subordinate): оптимизировать целое — значит не разгонять некритичные участки быстрее узкого места, а направлять усилия на throughput всей цепочки от идеи до потребителя. Локальная эффективность без учёта ограничения создаёт запасы (inventory) и увеличивает lead time — это потеря и с точки зрения TOC, и с точки зрения Lean.

Это фундаментальная рамка раздела 01: здесь — мышление и базовые инструменты; операционный Kanban, SAFe и детальная приоритизация — в 05.02 Scrum и Kanban (аналитик в Agile), 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках и 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

2. Ключевые понятия

2.1. Три меры TOC и типы ограничений

TOC оценивает систему через три меры:

Ориентация TOC: увеличивать T, а не локальную загрузку отдельных ролей. Рост I без роста T — симптом неправильного фокуса (перепроизводство требований, «завалы» перед тестированием).

Типы ограничений — для аналитика в knowledge work важнее классификация, чем поиск «медленного сервера»:

Политические ограничения часто скрыты: команда видит «мало тестировщиков», а корень — правило «без полной спецификации разработка не стартует».

Уровень системы. «Одно ограничение» всегда относится к выбранной границе системы. На уровне команды узкое место может быть review аналитика; на уровне release train — согласование архитектуры между потоками; на уровне портфеля — пропускная способность бизнеса принимать релизы. Ошибка — лечить симптом на уровне команды, когда throughput сдерживает правило выше (или наоборот). Перед пятью шагами зафиксируйте границу: «какую систему мы оптимизируем в этом цикле?» Масштабирование потока и уровни координации — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

2.2. Пять фокусирующих шагов TOC

Итеративный цикл управления ограничениями:

1. Найти ограничение (Identify). Узкое горлышко в потоке создания ценности — ресурс или правило.

   • Вопрос аналитика: «Где скапливается больше всего работы?», «Где самый долгий отклик?», «Какое правило заставляет действовать неоптимально?»

2. Максимально использовать ограничение (Exploit). Выжать максимум без крупных инвестиций: убрать простои, отдать непрофильные задачи, обеспечить идеальное качество входящих артефактов.

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

3. Подчинить всё остальное (Subordinate). Вся система работает в ритме ограничения — нельзя «гонять» поток быстрее узкого места.

   • Пример: если тестировщики — ограничение, разработчики не штампуют непротестированный код.

4. Расширить ограничение (Elevate). Увеличить пропускную способность: люди, автоматизация, пересмотр процесса — только после шагов 2 и 3.

5. Вернуться к шагу 1 (Repeat). Ограничение переместится; старое узкое место не должно стать новой «политикой по инерции».

2.3. Мыслительные процессы TOC (Thinking Processes)

Инструменты логического анализа вокруг трёх вопросов: Что изменить? Во что изменить? Как вызвать изменение? Детальная методика построения деревьев — в 01.03 Техники анализа проблем; здесь — обзор и артефакты на выходе для работы аналитика.

• Дерево текущей реальности (Current Reality Tree, CRT): связывает нежелательные явления (НЖЯ) в причинно-следственную сеть до корневой причины. Выход: схема на воркшопе по 02.01.01 Определение бизнес-проблем и возможностей или раздел «корневая причина» в отчёте об анализе; список НЖЯ для backlog улучшений процесса.

• Диаграмма «Грозовая туча» (Evaporating Cloud): вскрывает конфликт потребностей между стейкхолдерами — не расчёт равновесия стратегий, как в 01.04 Теория игр для аналитика, а поиск правила, которое делает два желания «несовместимыми». Классическая схема Goldratt для фасилитации:

        Цель A                    Цель B
          |                         |
    Потребность C              Потребность C′
          |                         |
   Требование D  ←— конфликт —→  Требование D′

• A, B — цели сторон (часто общая цель системы с разными акцентами);
• C, C′ — потребности, без которых цель не достижима;
• D, D′ — действия или правила, которые кажутся взаимоисключающими;
• инъекция (injection) — изменение допущения или правила, снимающее конфликт без компромисса «50/50».

Выход: согласованная инъекция в change request, ADR или обновление регламента; протокол воркшопа для 09.03 Управление конфликтами и переговоры.

• Дерево будущей реальности (Future Reality Tree, FRT): проверка, что предложенные изменения устранят корень. Negative Branches — ветви «что пойдёт не так», если инъекцию внедрить слепо. Выход: список рисков и контрмер для 08.05 Управление рисками на этапе анализа; уточнённые критерии приёмки изменения процесса.

2.4. Метод «Барабан–Буфер–Канат» (Drum-Buffer-Rope, DBR)

Управление потоком работ с синхронизацией по ограничению:

• Барабан (Drum): ритм работы ограничения — задаёт темп всей системе.
• Буфер (Buffer): защитный запас времени или работы перед ограничением, чтобы оно не простаивало.
• Канат (Rope): механизм управления впуском новой работы, жёстко привязанный к ритму барабана — система не принимает задач, пока ограничение не готово их принять.

Отличие от простого лимита WIP: лимит WIP ограничивает количество задач «в работе» на доске, но не обязательно синхронизирует вход с мощностью конкретного узкого места. «Канат» в DBR — сигнал «можно выпускать следующую партию» только когда ограничение освободилось; в ИТ это часто правило release cadence или pull-политика бэклога от capacity самого медленного этапа. Операционные практики Kanban, лимиты колонок и политики доски — 05.02 Scrum и Kanban (аналитик в Agile).

2.5. Бережливое мышление: muda, mura, muri

TPS выделяет три категории потерь:

Устранение muda без борьбы с mura и muri часто возвращает потери: сократили согласования, но оставили пиковые нагрузки — дефекты и переделки вернутся как muda.

Семь принципов Lean Software Development (Поппендики) — устранение потерь, обучение, поздние решения, быстрая доставка, права команды, целостность, оптимизация целого — для аналитика сводятся к одному практическому критерию: может ли команда отказаться от работы без ценности и остановить поток, не нарушая контракт с бизнесом. Если нет — любой принцип остаётся декларацией; операционная проработка Lean в команде — 05.02 Scrum и Kanban (аналитик в Agile).

2.6. Восемь видов потерь (8 Mudas) в разработке ПО

Классический TPS насчитывает семь видов muda. Для knowledge work к ним добавляют восьмой — Unused Talent (нереализованный потенциал): игнорирование знаний и идей людей. Таблица ниже следует каноническому порядку семи потерь TPS; Unused Talent выделен отдельно как стандартное расширение для интеллектуального труда (Поппендики, сообщество Lean SD):

Inventory в TOC (мера I) и Запасы как muda №5 — одна сущность с двух сторон: TOC считает незавершённую работу деньгами, замороженными в системе; Lean классифицирует те же бэклоги и WIP как потерю. Рост I без роста T — и финансовый, и lean-сигнал перепроизводства «вперёд» узкого места.

2.7. Вытягивание (Pull) и картирование потока (VSM)

Pull (вытягивание): следующий этап запрашивает работу, когда готов её принять — а не получает «партии на год вперёд». В аналитике это Just-in-time requirements: детализировать требования к моменту старта разработки, а не складировать полные спецификации «про запас». Pull работает только вместе с критериями готовности: 02.04.02 Критерии приёмки (Acceptance Criteria) и согласованный Definition of Ready задают, что именно «запрашивает» разработка — иначе pull превращается в «меньше документов» без управляемого handoff. Управление объёмом бэклога — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями, 02.05.02 Управление приоритетами в условиях изменчивости.

Value Stream Mapping (VSM) здесь — мысленная и workshop-модель для аналитика: где в цепочке от идеи до релиза растёт lead time, где NVA, где узкое место. Нарисовать карту AS-IS/TO-BE, выбрать нотацию и закрепить метрики потока — в 03.04.04 Цепочка создания ценности (VAD) и EPC и 08.01 Метрики и KPI процесса анализа; в этой статье достаточно умения «пройти поток глазами» и связать шаги с TOC/Lean.

3. Как применяется в работе аналитика

3.1. Эвристики поиска ограничения

После формулировки проблемы (02.01.01 Определение бизнес-проблем и возможностей) пройдите поток требований/разработки на выбранном уровне системы (команда, train, портфель) и задайте:

1. Где растёт очередь? — этап с максимальным WIP перед ним часто питается быстрее, чем перерабатывается.
2. Где lead time стабильно самый длинный? — сравните этапы на VSM или по данным трекера.
3. Где простаивает ограничение? — если «узкое место» ждёт входа, проблема выше по потоку (качество handoff, буфер).
4. Какое правило нельзя обойти? — policy constraint: регламент, KPI, матрица согласований.
5. Что произойдёт, если добавить ресурс именно сюда? — если throughput системы не вырастет, это не ограничение.

3.2. TOC и Lean в цифровой и продуктовой среде

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

• Policy constraint: матрица согласований, Definition of Ready, требование полной спецификации до спринта. DoR может быть и exploit (качественный вход в ограничение — review не простаивает из-за сырых артефактов), и искусственный тормоз (перегруженный чеклист, muda overprocessing). Критерий: правило увеличивает throughput ограничения или только копит inventory перед ним? Если второе — кандидат на упрощение или Subordinate.

• Ограничение качества / review: один архитектор или ведущий аналитик на несколько потоков; bottleneck в рецензировании требований, а не в написании. Симптом — очередь на согласование при «свободных» авторах. Exploit: стандартизировать формат ревью, чеклист только для рискованных зон, параллельное ревью неконфликтующих частей. Связка с 02.04.03 Управление качеством требований и 08.04 Рецензирование и инспекции (техники Фейгана).

• Интеграционное ограничение: среда, тестовые данные, контракты между командами — см. 03.01.04 Интерфейсы и интеграционные взаимодействия.

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

• Ограничение «объём идей», а не capacity: throughput сдерживает не скорость этапа, а очередь инициатив — сотни элементов бэклога, параллельные «стратегические» потоки. TOC-фокус здесь — не ускорять каждый этап, а отсечь хвост с высокой стоимостью задержки (Cost of Delay) и согласовать локальные KPI с системным T (02.01.02 Цели, KPI и критерии успеха (SMART, GQM)). Методы отсечения и WSJF — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

Лимиты WIP и политики Kanban для команды — см. 05.02 Scrum и Kanban (аналитик в Agile); Lean на уровне портфеля и стратегического потока — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

3.3. Синтез: таблица и сквозной кейс

Пример (иллюстрация, не нормативная цифра). Бизнес жалуется на долгий time-to-market.

• Линейный подход: нанять больше разработчиков.
• Lean + TOC:
  1. Построить VSM от идеи до prod на уровне одного продукта.
  2. Найти ограничение: 3 недели на этапе утверждения требований бизнесом — одновременно Waiting (muda) и policy constraint: регламент «три подписи + еженедельный комитет».
  3. Exploit + Subordinate: короткие регулярные слоты решений, делегирование полномочий product owner, ограничение глубины проработки «на берегу» в пользу итераций; pull с 02.04.02 Критерии приёмки (Acceptance Criteria) вместо полного пакета спецификаций.
  4. Lean: убрать ожидание; детализировать требования партиями под спринт.
  5. Elevate (если шаги 2–4 исчерпаны): назначить выделенного approver или автоматизировать типовые согласования.

Типичный порядок эффекта: заметное сокращение lead time на этапе согласований без увеличения штата — за счёт снятия политического ограничения, а не ускорения кодирования. Конкретный процент зависит от baseline; не используйте его как KPI по умолчанию.

4. Типовые ошибки и ограничения

Границы применимости: TOC и Lean избыточны при единичном срочном исправлении, тривиальном объёме работ (один аналитик, один разработчик, один релиз) или когда процесс жёстко зафиксирован регулятором без возможности менять правила. В таких случаях достаточно здравого смысла и 01.03 Техники анализа проблем; полный VSM и DBR оправданы при повторяющемся потоке поставки и измеримой стоимости задержки.

Связи с другими разделами базы

• Предшественники: 01.01 Понятие системы и системного подхода, 01.02 Ментальные модели аналитика, 01.03 Техники анализа проблем
• Соседняя рамка (игры vs конфликт потребностей TOC): 01.04 Теория игр для аналитика
• Продолжение фундамента: 01.06 Принципы и паттерны проектирования решений
• Выявление и анализ проблем бизнеса: 02.01.01 Определение бизнес-проблем и возможностей
• Throughput vs локальные KPI: 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)
• Приоритизация и Cost of Delay (WSJF): 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)
• Критерии приёмки и готовность к разработке: 02.04.02 Критерии приёмки (Acceptance Criteria)
• Качество требований и review как узкое место: 02.04.03 Управление качеством требований, 08.04 Рецензирование и инспекции (техники Фейгана)
• Управление потоком и объёмом требований: 02.05.02 Управление приоритетами в условиях изменчивости, 02.05.03 Управление объёмом (Scope Creep) и ожиданиями
• Управление потоком в Agile/Kanban: 05.02 Scrum и Kanban (аналитик в Agile)
• Lean на уровне портфеля: 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках
• Моделирование потока создания ценности: 03.04.04 Цепочка создания ценности (VAD) и EPC
• Метрики потока: 08.01 Метрики и KPI процесса анализа
• Negative Branches и риски изменений: 08.05 Управление рисками на этапе анализа
• Разрешение конфликтов требований: 09.03 Управление конфликтами и переговоры

Источники и дополнительные материалы

Книги и стандарты

• Элияху Голдратт — The Goal («Цель»): вводная business novel по TOC и пяти фокусирующим шагам
• Уильям Детмер — Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement (мыслительные процессы и 5 шагов)
• Мэри и Том Поппендик — Lean Software Development (Addison-Wesley); эссе авторов: https://www.leanessays.com/
• Дон Райнертсен — The Principles of Product Development Flow (очереди, стоимость задержки, поток); разбор на русском: https://artemushanov.ru/?go=all/reynertsen-post-1/

Статьи и видео

• Gary Worthington — The Pragmatic Engineer's Guide to the Theory of Constraints (Medium): https://morethanmonkeys.medium.com/the-pragmatic-engineers-guide-to-the-theory-of-constraints-011625605c9c
• Theory of Constraints — TOCICO: https://www.tocico.org/page/theoryofconstraints
• Lean development: Principles, best practices and common pitfalls — Tempo.io: https://www.tempo.io/guides/lean-roadmap
• A Guide to Value Stream Mapping in Software Development — Waydev: https://waydev.co/value-stream-mapping/
• Drum Buffer Rope (DBR) — Six Sigma Development Solutions: https://sixsigmadsi.com/glossary/drum-buffer-rope/
• The Human Perspective: Why «Empower the Team» is a Definition of Success — Martinelli: https://martinelli.ch/the-human-perspective-why-empower-the-team-is-a-definition-of-success-in-2025/
• Элияху Голдратт — лекция Beyond the Goal (YouTube)
• Value stream mapping: a complete guide for software engineering teams — DX: https://getdx.com/blog/value-stream-analysis/