Lean и бережливое производство в разработке: поток, потери, вытягивание

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

Механика же есть, и она количественная. Lean — это набор решений одной задачи: сократить время между моментом, когда кто-то попросил, и моментом, когда он получил, не наращивая ресурсы. Тайити Оно, главный инженер Toyota, сформулировал это одной фразой: «Всё, что мы делаем, — смотрим на временную линию от момента, когда клиент даёт нам заказ, до момента, когда мы получаем деньги. И сокращаем эту линию, убирая не добавляющие ценности потери» (Ohno, Toyota Production System, 1988).

Эта статья — про то, как из этой фразы получается работающий инструментарий, какие его части переносятся на разработку без изменений, какие — с оговорками, а какие не переносятся вообще. Метрики потока (Little, cycle time, CFD) уже разобраны в Kanban и управлении потоком — здесь мы берём слой ниже: откуда эти метрики взялись и что с ними делать, кроме как измерять.

Часть 1. Родословная: что именно изобрели в Toyota

Полезно знать хронологию, потому что половина споров о Lean — это спор о том, чьё определение брать.

Три вещи, которые обычно упускают.

Первое: «lean» — не японское слово и не самоназвание. Toyota никогда не называла свою систему бережливой; термин придумал исследователь MIT Джон Крафчик в 1988 году, описывая, что завод NUMMI выпускает столько же машин при вдвое меньших запасах, площадях и дефектах — «тощий» в смысле «без жира». Всё, что вы читаете как «Lean», — это западная реконструкция TPS, сделанная по наблюдениям снаружи. Реконструкция хорошая, но неполная: инструменты видны, а управленческая культура, которая их держит, — нет. Отсюда системная проблема: копируют доски и карточки, не копируют то, что делает их осмысленными.

Второе: TPS вырос из дефицита, а не из философии. Послевоенная Toyota не могла себе позволить ни запасов, ни специализированных линий под каждую модель, ни брака. Ограничение породило конструкцию: если денег на склад нет, приходится делать точно вовремя; если нет денег на переделку — приходится ловить дефект на месте. Это важно, потому что организация без ограничения обычно не воспроизводит поведение, а имитирует его.

Третье: Деминг был раньше. PDCA, статистическое мышление, «качество нельзя проинспектировать, его нужно встроить» — это У. Эдвардс Деминг, читавший лекции японским инженерам с 1950 года. Lean без статистического слоя вырождается в набор ритуалов; собственно, ровно это и происходит в большинстве внедрений.

Часть 2. Два столпа: точно вовремя и дзидока

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

Точно вовремя (Just-in-Time) — производить только то, что нужно, только когда нужно, и только в нужном количестве. Не «быстро», а «вовремя»: работа не начинается, пока её не вытянули. В разработке это WIP-лимит и pull из очереди вместо распределения задач сверху.

Дзидока (自働化, «автономизация с человеческим прикосновением») — станок должен останавливаться сам при обнаружении отклонения, а человек — иметь право и обязанность остановить линию. Легенда про андон-шнур на конвейере Toyota правдива в главном: любой рабочий может дёрнуть шнур, и линия встанет, если проблему не решат за такт. Экономически это выглядит безумием — остановка конвейера стоит тысячи долларов в минуту. Логика в другом: дефект, ушедший дальше по линии, стоит на порядок больше, а без остановки система никогда не узнает свою настоящую частоту отказов.

Прямой аналог в разработке — stop-the-line на красной сборке. Не «поправим потом», а «до зелёного никто не мержит».

Разница между настоящим stop-the-line и его имитацией измерима: возьмите время от падения основной ветки до её восстановления (p50 и p95) и число коммитов, залитых поверх красного. Если поверх красного коммитят — андона нет, есть плакат про андон. Метрики и практики зелёного транка подробнее — в Качество и поставка.

Amazon воспроизвела эту идею буквально: оператор поддержки, увидевший системную проблему у покупателей, может «дёрнуть шнур» и снять товар с продажи до разбирательства — описано в «Working Backwards» Брайара и Карра. Это и есть перенос дзидока: право остановки делегировано вниз, а не поднято наверх.

Часть 3. Пять принципов Lean Thinking — и что в них ломается для софта

Вомак и Джонс в «Lean Thinking» (1996) свели систему к пяти шагам. Разберём каждый честно.

Отдельный принцип, вокруг которого больше всего путаницы, — «ценность». В производстве операция добавляет ценность, если клиент заплатил бы за неё отдельно: сварка кузова — да, перевозка кузова между цехами — нет. В разработке этот критерий даёт странные результаты: клиент не заплатит отдельно ни за код-ревью, ни за unit-тесты. Значит ли это, что ревью — потеря? Нет. Правильная классификация трёхчастная, она есть уже у Оно:

• добавляет ценность — меняет продукт так, что клиенту становится лучше;
• не добавляет ценности, но необходимо (type 1 muda) — ревью, тесты, миграции, соответствие требованиям регулятора: убрать нельзя, но нужно делать дешевле и быстрее;
• не добавляет ценности и не нужно (type 2 muda) — вот это и есть цель устранения.

Смешение первых двух категорий — самая дорогая ошибка Lean-внедрений в IT. «Тесты не добавляют ценности, давайте сократим» — формально верная посылка и катастрофический вывод.

Часть 4. Потери: семь муда, восьмая и две забытые «му»

Классические семь потерь Оно (мнемоника TIMWOOD) и их перенос на разработку, сделанный Мэри и Томом Поппендиками в «Lean Software Development» (2003):

Западные пересказы почти всегда останавливаются на муда. В самой TPS потерь три, и муда — самая безобидная:

• муда (無駄) — потери, работа без ценности;
• мура (斑) — неравномерность, вариабельность нагрузки;
• мури (無理) — перегрузка людей и оборудования сверх устойчивого предела.

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

Практический перевод для IT: если в команду одновременно валятся релиз, дежурство, срочный запрос от продаж и квартальное планирование — это мура. Если после этого команда работает по 10 часов и все загружены на 100% — это мури. Баги, простой на ревью и переписанная дважды фича — это муда, и бороться с ними напрямую бессмысленно. Именно поэтому выравнивание (хейдзунка) и резерв мощности стоят в Lean раньше устранения потерь.

Часть 5. Карта потока создания ценности: как считать по-настоящему

Value Stream Mapping (VSM) — единственный Lean-инструмент, который почти всегда окупается с первого применения, потому что делает видимым то, чего нет ни в одном отчёте: время, в которое с задачей ничего не происходит.

Три метрики карты:

• PT (process time) — время, когда над задачей реально работают.
• LT (lead time) — календарное время этапа вместе с ожиданием перед ним.
• %C/A (complete and accurate) — доля работы, которую следующий этап принял без возврата.

Из них считаются два числа, ради которых всё и затевается:

$$\eta_{flow} = \frac{\sum PT}{LT_{total}}, \qquad RTY = \prod_{i=1}^{n} %C/A_i$$

Эффективность потока $\eta_{flow}$ в типичной корпоративной разработке лежит в диапазоне 5–25%. Это не аномалия, это норма: очереди почти всегда длиннее работы. Практический вывод жёсткий — ускорять работу почти бессмысленно, пока эффективность потока ниже 40%. Ускорить программирование вдвое при $\eta = 16%$ означает сократить lead time на 7%.

Rolled throughput yield RTY показывает вероятность пройти весь поток без единого возврата. При пяти этапах с %C/A = 0{,}9 получается $0{,}9^5 \approx 59%$: почти половина работы куда-то возвращается, и эти возвраты не видны в плане, потому что каждый из них выглядит как «мелкая правка».

"""Расчёт метрик карты потока. Сложность: O(n) по времени, O(1) по дополнительной памяти."""
from dataclasses import dataclass


@dataclass(frozen=True)
class Stage:
    name: str
    process_time_days: float   # PT: чистая работа
    wait_before_days: float    # ожидание в очереди ПЕРЕД этапом
    complete_and_accurate: float  # %C/A как доля: 0.85 = 85% принято без возврата


def analyze(stages: list[Stage]) -> dict:
    process = sum(s.process_time_days for s in stages)
    wait = sum(s.wait_before_days for s in stages)
    lead = process + wait

    rty = 1.0
    for s in stages:
        rty *= s.complete_and_accurate

    # узкое место потока — этап с максимальным вкладом в календарь,
    # а не с максимальным объёмом работы: это разные вещи
    bottleneck = max(stages, key=lambda s: s.wait_before_days + s.process_time_days)

    # цена возвратов: сколько работы в среднем переделывается на каждом этапе
    rework_days = sum(
        s.process_time_days * (1 - s.complete_and_accurate) for s in stages
    )

    return {
        "lead_time_days": round(lead, 2),
        "process_time_days": round(process, 2),
        "flow_efficiency": round(process / lead, 3),
        "rolled_throughput_yield": round(rty, 3),
        "bottleneck": bottleneck.name,
        "bottleneck_share_of_lead": round(
            (bottleneck.wait_before_days + bottleneck.process_time_days) / lead, 3
        ),
        "avg_rework_days_per_item": round(rework_days, 2),
    }


stream = [
    Stage("Анализ",        0.5, 3.0, 0.80),
    Stage("Разработка",    1.5, 2.0, 0.70),
    Stage("Ревью",         0.4, 4.0, 0.85),
    Stage("Тестирование",  0.6, 1.5, 0.90),
    Stage("Релиз",         0.4, 8.0, 0.98),
]

for key, value in analyze(stream).items():
    print(f"{key:28} {value}")

lead_time_days               21.9
process_time_days            3.4
flow_efficiency              0.155
rolled_throughput_yield      0.42
bottleneck                   Релиз
bottleneck_share_of_lead     0.384
avg_rework_days_per_item     0.72

Карта, нарисованная на воркшопе по памяти, — это гипотеза. Проверять её нужно данными о переходах статусов. Если у вас есть таблица событий изменения статуса (её отдаёт любой трекер через API или экспорт), поток считается запросом:

-- Время в каждом статусе по завершённым задачам за квартал.
-- Ключевая идея: длительность статуса = разница до следующего перехода той же задачи.
WITH transitions AS (
    SELECT
        issue_id,
        to_status                                            AS status,
        changed_at                                           AS entered_at,
        LEAD(changed_at) OVER (
            PARTITION BY issue_id ORDER BY changed_at
        )                                                    AS left_at
    FROM issue_status_changes
    WHERE changed_at >= DATE '2026-04-01'
),
durations AS (
    SELECT
        status,
        EXTRACT(EPOCH FROM (left_at - entered_at)) / 86400.0 AS days
    FROM transitions
    WHERE left_at IS NOT NULL
)
SELECT
    status,
    COUNT(*)                                                  AS items,
    ROUND(AVG(days)::numeric, 2)                              AS avg_days,
    ROUND(PERCENTILE_CONT(0.5)  WITHIN GROUP (ORDER BY days)::numeric, 2) AS p50,
    ROUND(PERCENTILE_CONT(0.85) WITHIN GROUP (ORDER BY days)::numeric, 2) AS p85,
    -- статусы ожидания помечаем заранее: именно их сумма и есть потери
    CASE WHEN status IN ('Ready for Review', 'Ready for QA', 'Ready for Release',
                         'Blocked', 'Waiting for Approval')
         THEN 'очередь' ELSE 'работа' END                     AS kind
FROM durations
GROUP BY status
ORDER BY p85 DESC;

Смотреть нужно на p85, а не на среднее: среднее прячет длинный хвост, а именно хвост создаёт срывы обещаний (подробно — в Оценки и планирование).

Типичная ошибка VSM-воркшопа — нарисовать карту «как надо» вместо «как есть», получить красивый плакат и разойтись. Правило Rother и Shook из «Learning to See»: карта текущего состояния рисуется по факту прохождения одной реальной задачи, а не по регламенту. Регламент описывает счастливый путь; задача проходит настоящий.

Часть 6. Вытягивание: чем pull отличается от push механически

Слово «вытягивание» звучит философски, но за ним стоит конкретное правило: работа переходит на следующий этап только по сигналу этого этапа, и число сигналов конечно. Конечность сигналов и есть WIP-лимит; без неё pull не отличается от push.

В push-системе загрузка каждого этапа максимальна, а очереди между этапами растут до тех пор, пока кто-нибудь не начнёт их разгребать вручную (обычно менеджер, обычно в пятницу). В pull-системе загрузка ниже 100% — и именно это даёт короткий lead time: формула Кингмана из статьи про Kanban показывает, почему ожидание растёт как $\rho/(1-\rho)$.

Три уточнения, которых обычно нет в пересказах.

Pull не означает «никаких планов». В TPS вытягивание работает поверх плана производства, выровненного по объёму и номенклатуре. Вытягивание управляет моментом запуска, а не составом работ. Команда, которая «перешла на pull» и перестала планировать состав, получила не Lean, а отсутствие приоритизации.

Сигнал должен быть физическим и видимым. Карточка канбана — не метафора: у неё есть материальный носитель, её нельзя «взять ещё одну», потому что их конечное число. Электронная доска без жёсткого лимита в настройках трекера этого свойства не даёт: превысить лимит можно молча. Настройте блокирующий лимит в колонках, а не «предупреждающий цветом».

Два вида буферов — не одно и то же. В TPS различают «супермаркет» (запас типовых единиц, из которого берут, и пополняют по факту изъятия) и FIFO-полосу (жёсткая очередь фиксированной длины). В разработке аналог супермаркета — пул готовых, независимых, небольших задач «на подхват»; аналог FIFO-полосы — очередь на ревью. Смешивать их вредно: супермаркет допускает переупорядочивание, FIFO — нет, и попытка переупорядочивать FIFO-очередь ревью «по срочности» превращает её в неуправляемый LIFO, где старые PR не разбираются никогда.

Часть 7. Размер партии и SMED: главный рычаг, который дешевле всего

Если из всего Lean оставить один инструмент, это будет сокращение размера партии. Оно улучшает почти всё сразу: lead time, качество обратной связи, стоимость отладки, риск релиза.

Экономика классическая — модель EOQ, которую Рейнертсен перенёс на разработку в «The Principles of Product Development Flow». Суммарная стоимость на единицу — это стоимость транзакции (накладные на партию: сборка, регресс, релизная процедура, согласования), делённая на размер партии, плюс стоимость удержания (ценность лежит невыпущенной, риск накапливается), растущая с размером:

$$C(Q) = \frac{S}{Q} + \frac{H \cdot Q}{2}, \qquad Q^{\ast} = \sqrt{\frac{2S}{H}}$$

Два следствия, которые важнее самой формулы.

Оптимум пологий. Ошибка в размере партии в два раза в любую сторону стоит около 25% надбавки к оптимальной стоимости. Поэтому не тратьте время на вычисление $Q^{\ast}$ — вычислять надо порядок величины, а не значение.

$Q^{\ast}$ пропорционален корню из стоимости транзакции. Это и есть настоящий рычаг: снизив стоимость релиза в четыре раза, вы сдвигаете оптимальный размер партии вдвое вниз — и получаете все выгоды малых партий бесплатно. В производстве это SMED (Single-Minute Exchange of Die) Сигео Синго: переналадка пресса, занимавшая часы, была доведена до минут, что сделало экономически возможным выпуск малыми сериями. В разработке SMED — это ровно CI/CD-конвейер, автоматический регресс, миграции без даунтайма и фича-флаги. DevOps — это SMED для программного обеспечения, и связь с DORA-метриками прямая: см. DORA и инженерные метрики.

"""Экономика размера партии: где оптимум и насколько дёшево от него отклониться.
Сложность: O(k) по числу проверяемых размеров."""

def batch_cost(batch_size: int, transaction_cost: float, holding_cost_per_item: float) -> float:
    """transaction_cost — накладные на один релиз (человеко-часы регресса, координации, окна).
    holding_cost_per_item — цена того, что одно изменение сутки лежит невыпущенным."""
    return transaction_cost / batch_size + holding_cost_per_item * batch_size / 2


def report(transaction_cost: float, holding_cost: float) -> None:
    sizes = [1, 2, 5, 10, 20, 50, 100, 200]
    costs = {n: batch_cost(n, transaction_cost, holding_cost) for n in sizes}
    best = min(costs, key=costs.get)
    print(f"S={transaction_cost:>5.0f}  H={holding_cost:>4.1f}   оптимум ≈ {best} изменений в релизе")
    for n, c in costs.items():
        marker = " <- оптимум" if n == best else ""
        print(f"   партия {n:>3}: стоимость {c:7.1f}  ({c / costs[best]:.2f}× от лучшей){marker}")


# До автоматизации: релиз стоит 40 часов ручного регресса и координации
report(transaction_cost=40.0, holding_cost=0.4)
print()
# После CI/CD: релиз стоит 0.5 часа — оптимум уезжает к непрерывной поставке
report(transaction_cost=0.5, holding_cost=0.4)

S=   40  H= 0.4   оптимум ≈ 10 изменений в релизе
   партия   1: стоимость    40.2  (2.50× от лучшей)
   партия   2: стоимость    20.4  (1.27× от лучшей)
   партия   5: стоимость     9.0  (1.12× от лучшей)
   партия  10: стоимость     6.0  (1.00× от лучшей) <- оптимум
   партия  20: стоимость     6.0  (1.00× от лучшей)
   партия  50: стоимость    10.8  (1.79× от лучшей)
   ...

S=  0.5  H= 0.4   оптимум ≈ 2 изменений в релизе
   партия   1: стоимость     0.7  (1.00× от лучшей)
   партия   2: стоимость     0.7  (1.00× от лучшей) <- оптимум
   партия   5: стоимость     1.1  (1.62× от лучшей)

Обратите внимание на плоское дно: при $S = 40$ партии в 10 и в 20 изменений практически неразличимы по стоимости. Спорить о том, релизить ли 12 или 16 изменений, — потеря; сокращать $S$ с 40 часов до получаса — работа.

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

Часть 8. Кайдзен: A3, PDCA и почему «пять почему» опасны

Инструмент улучшения в Lean — не ретроспектива со стикерами, а структурированное решение проблемы. Канонический формат — A3: весь разбор помещается на лист A3, потому что ограничение места заставляет думать, а не пересказывать.

# A3: один лист, семь блоков. Формат из Toyota, описан у Джона Шука в «Managing to Learn».
a3:
  title: "Ожидание ревью — 4,0 дня из 21,9 дня lead time"
  owner: "тимлид платформенной команды"

  background: >
    Квартальный VSM показал: очередь перед ревью — второй по величине источник
    ожидания. Затрагивает все 4 команды, влияет на срок каждой фичи.

  current_state:
    измерено: "события переходов статусов за Q2, n=214 задач"
    p50_ожидания_ревью: "1,8 дня"
    p85_ожидания_ревью: "6,4 дня"
    средний_размер_PR: "480 изменённых строк"
    доля_PR_старше_3_дней: "31%"

  goal:
    метрика: "p85 ожидания ревью"
    было: "6,4 дня"
    цель: "1,5 дня к концу квартала"
    ограничение: "без роста change failure rate выше текущих 9%"

  analysis: >
    Корреляция размера PR и времени ожидания: PR до 200 строк разбирают за
    медианные 4 часа, свыше 400 строк — за 3,5 дня. Ревьюеры откладывают
    крупные PR, потому что не могут выделить непрерывный час. Это не проблема
    дисциплины, а проблема размера партии (см. раздел 7).

  countermeasures:
    - действие: "жёсткий лимит 400 строк на PR в CI, блокирующая проверка"
      гипотеза: "принудительное дробление снизит время до первого комментария"
    - действие: "слот 11:00–11:30 у каждой команды на разбор очереди ревью"
      гипотеза: "убирает ожидание непрерывного окна, снижает мура"
    - действие: "автоназначение ревьюера по CODEOWNERS, без ручного поиска"
      гипотеза: "убирает потерю на поиск исполнителя"

  plan:
    - "неделя 1: включить лимит строк в режиме предупреждения, собрать базу"
    - "неделя 3: перевести в блокирующий режим"
    - "неделя 6: замер p85, решение о продолжении"

  follow_up:
    проверка: "через 6 недель на тех же данных, тем же запросом"
    отмена_если: "p85 не снизился на 30% ИЛИ CFR вырос выше 12%"

Ключевое в A3 — блоки goal и follow_up. Улучшение без числовой цели и без даты проверки — это не кайдзен, а пожелание. Toyota Kata Майка Ротера («Toyota Kata», 2009) формализует это в цикл из четырёх вопросов: куда идём (целевое состояние), где сейчас, какое препятствие ближайшее, какой следующий шаг и когда посмотрим результат. Причём шаг делается маленьким намеренно: цель — не решить проблему, а быстро узнать, верна ли модель.

Теперь про «пять почему». Метод честный по происхождению — Оно использовал его на цеху, где причинные цепочки действительно линейны: лужа масла → изношен подшипник → не было фильтра → фильтр не заказали → нет процедуры заказа. Проблема начинается при переносе на сложные социотехнические системы. Аварии в них не имеют одной причины: у них есть набор условий, каждое из которых по отдельности безобидно. Нэнси Левесон в «Engineering a Safer World» показывает, что модель «домино» систематически приводит к неверным контрмерам, а Джон Оллспоу в «The Infinite Hows» предлагает заменить вопрос «почему» вопросами «как»: как решение выглядело разумным в тот момент, как человек понимал систему, как он узнал бы о проблеме раньше.

Практическое правило: «пять почему» годятся для повторяющихся детерминированных проблем (сборка падает по одной и той же причине), но не годятся для инцидентов в проде. Для вторых — blameless postmortem с моделью условий, а не цепочки.

Часть 9. Где Lean ломается: разработка — не завод

Это самый важный раздел статьи, и его почти нет в популярных курсах. Перенос TPS в разработку имеет фундаментальные ограничения, и Рейнертсен разбирает их подробно.

Отсюда четыре типичных провала «Lean по учебнику».

1. Устранение вариабельности вместо управления ею. В производстве разброс — зло. В разработке отсутствие разброса означает, что вы не пробуете ничего нового. Правильная цель — не убрать вариабельность, а сделать её дешёвой: малые партии, быстрая обратная связь, обратимые решения. Рейнертсен формулирует это как «вариабельность нужно не уменьшать, а экономически выгодно располагать».

2. Устранение слака. «Свободная мощность — потеря» верно для станка и неверно для системы с очередями: без резерва любой всплеск превращается в очередь, которая не рассасывается. Том ДеМарко посвятил этому книгу «Slack»; практический ориентир — плановая загрузка команды 70–85%, а не 100%.

3. Стандартизация как заморозка. Стандартная работа в TPS — это текущая лучшая известная практика, которую обязан улучшить тот, кто по ней работает. В корпоративной трансляции она становится регламентом, который меняет только процессный офис. Это инверсия смысла: стандарт был точкой отсчёта для улучшения, стал запретом на улучшение.

4. Lean как эвфемизм сокращения. Боб Эмилиани назвал это L.A.M.E. — Lean As Misguidedly Executed. Если первое видимое следствие внедрения — увольнения, то через квартал вы получите организацию, где никто не показывает потери, потому что показать потерю значит указать на себя. В TPS повышение производительности явно не приводило к увольнению — иначе система улучшений остановилась бы за месяц.

Часть 10. Lean Startup: та же петля, другая переменная

Эрик Рис перенёс на стартапы не инструменты TPS, а их логику: если главная потеря на заводе — произвести деталь, которая не нужна, то главная потеря в продукте — построить функцию, которая не нужна. Цикл build–measure–learn — это PDCA, где проверяемая гипотеза не про процесс, а про продукт; MVP — минимальная партия, достаточная для получения информации; validated learning — единица прогресса вместо выпущенных фич.

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

Второй перекос — inno­vation accounting в организации, которая не готова закрывать направления. Метрики проверяемого обучения работают, только если «гипотеза не подтвердилась» является допустимым и не наказуемым исходом. Иначе эксперимент всегда «частично успешен», и вы получаете дорогой театр. Продуктовая сторона вопроса — в треке Product Management.

Часть 11. Признаки карго-культа: чек-лист

Быстрая диагностика одним вопросом: «покажите последнее изменение процесса, инициированное человеком, который по этому процессу работает, и число, которое подтвердило эффект». Если такого нет — Lean в организации отсутствует независимо от количества плакатов.

Часть 12. Как это выглядит в проде: 90 дней

Порядок, который реально работает и не требует «трансформации».

Числа из типового случая (продуктовая команда, 4 разработчика, монолит + два сервиса) до и после такого цикла:

Последняя строка — суть Lean. Ни одна из мер не касалась скорости работы людей: все касались очередей, размеров партий и права остановиться.

Что важно не сделать в эти 90 дней: не начинать с переименования ролей, не заводить отдельный отдел улучшений, не внедрять «Lean-метрики» поверх существующих KPI без отмены старых. И не измерять успех числом проведённых кайдзен-сессий — это ровно тот случай, когда метрика заменяет цель (закон Гудхарта, разобранный в DORA-статье).

Мини-итог

• Lean решает одну задачу: сократить время от запроса до поставки, не увеличивая ресурсы. Всё остальное — средства.
• Два столпа: точно вовремя (не начинай, пока не вытянули) и дзидока (останови линию при отклонении). Второй забывают чаще, а без него первый превращается в конвейер по производству дефектов.
• Потери бывают трёх видов, и муда — самая безобидная. Мура (неравномерность) порождает мури (перегрузку), мури порождает муда. Работать надо с причиной.
• Классификация трёхчастная: добавляет ценность / необходимо, но не добавляет / не нужно. Сокращать надо третье и удешевлять второе; смешение первых двух категорий убивает тесты и ревью.
• VSM даёт два числа: эффективность потока $\eta = \sum PT / LT$ (типично 5–25%) и RTY $= \prod %C/A$. При $\eta < 40%$ ускорять работу почти бессмысленно — рычаг в очередях.
• Размер партии — главный рычаг, а оптимум пологий: не считайте $Q^{\ast}$, снижайте стоимость транзакции $S$, и оптимум сам уедет вниз. DevOps — это SMED для софта.
• Кайдзен без числа и даты проверки — не кайдзен. A3 работает благодаря блокам «цель» и «повторный замер», а не благодаря формату листа.
• Разработка — не завод: вариабельность здесь частично полезна, слак необходим, стандарт обязан меняться снизу. Игнорирование этих различий и есть источник большинства провалов Lean-внедрений.

Источники

• Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production, 1988 — первоисточник про JIT, дзидока и три «му».
• James Womack, Daniel Jones, Daniel Roos. The Machine That Changed the World, 1990; Womack & Jones. Lean Thinking, 1996 — пять принципов; Lean Enterprise Institute.
• John Krafcik. Triumph of the Lean Production System, Sloan Management Review, 1988 — статья, давшая термин.
• Mike Rother, John Shook. Learning to See — методика VSM; Mike Rother. Toyota Kata, 2009; John Shook. Managing to Learn — формат A3.
• Shigeo Shingo. A Revolution in Manufacturing: The SMED System, 1985 — сокращение стоимости переналадки.
• Mary & Tom Poppendieck. Lean Software Development: An Agile Toolkit, 2003 — перенос семи потерь на разработку.
• Donald Reinertsen. The Principles of Product Development Flow, 2009 — экономика очередей, U-кривая размера партии, критика прямого переноса TPS.
• W. Edwards Deming. Out of the Crisis, 1982 — The Deming Institute; статистический фундамент улучшений.
• Tom DeMarco. Slack, 2001 — почему стопроцентная загрузка ломает поток.
• Gene Kim, Jez Humble, Patrick Debois, John Willis. The DevOps Handbook, 2016 — Три пути как прямое продолжение Lean.
• Eric Ries. The Lean Startup, 2011; Colin Bryar, Bill Carr. Working Backwards, 2021 — андон в Amazon.
• Nancy Leveson. Engineering a Safer World, 2011; John Allspaw. The Infinite Hows — почему «пять почему» не годятся для инцидентов.
• Bob Emiliani. Lean vs. L.A.M.E. — про подмену Lean сокращениями.

Что дальше

Lean дал принципы (поток, вытягивание, малые партии), Scrum — ритм итерации, Kanban — механику ограничения WIP. На практике команды почти никогда не берут что-то одно в чистом виде: берут спринт для планирования, доску с лимитами для исполнения и вытягивание для запуска работы. Как это совмещают осмысленно, а не «просто перестали делать спринты» — в следующей статье.

• Scrumban и гибридные процессы: как совмещают Scrum и Kanban

Полезно перечитать рядом:

• Kanban и управление потоком — метрики, на которых держится вся эта статья.
• Качество и поставка — дзидока в виде quality gates и зелёного транка.
• DORA и инженерные метрики — как измерить, что размер партии действительно уменьшился.
• Масштабирование — WSJF и стоимость задержки, экономический слой поверх потока.