В 2001 году двое профессоров из MIT Sloan — Нельсон Репеннинг и Джон Стерман — взяли неудобный вопрос: почему компании сжигают десятки миллиардов долларов на программы улучшений (TQM, Six Sigma, бережливое производство), а на выходе почти ноль? В 1997-м только на консультантов и тренинги американский бизнес потратил больше $100 млрд — и значительная часть ушла именно на попытки «дотянуться» до операционной эффективности лучших компаний. А результат? Меньше 10% компаний из Fortune 1000 смогли довести у себя TQM до рабочего состояния.
Их статья «Nobody Ever Gets Credit for Fixing Problems that Never Happened» — это не мотивационная жвачка про «культуру качества». Это, по сути, инженерный разбор организации как системы с обратными связями: они построили математическую модель и показали, где именно ломается механизм. И вот что меня в ней цепляет больше всего: тот же самый механизм превращает ваш чистый код в болото техдолга, а нормальную команду разработки — в пожарную часть на постоянном дежурстве. Давайте разберём, как это работает под капотом.
«Физика» улучшений: почему усерднее ≠ умнее
Авторы начинают с предельно простой модели. Производительность любого процесса = время за работой × способность процесса (capability). В производстве это буквально «человеко-часы × выработка на час». Хотите закрыть разрыв между планом и фактом — у вас всего две ручки, за которые можно дёрнуть:
🔁 «Работать усерднее» (балансирующий контур B1). Менеджер давит, люди впахивают, выработка растёт сразу. Но эффект живёт ровно столько, сколько длится переработка: подняли рабочую неделю на 20% — получили +20% выпуска, и ни часом дольше.
🧠 «Работать умнее» (балансирующий контур B2). Вместо давления — вложения в процесс: обучение, эксперименты, устранение коренных причин дефектов. Час, потраченный на улучшение, поднимает отдачу каждого последующего рабочего часа. Эффект устойчивый — но приходит с задержкой (от пары месяцев на простых процессах до нескольких лет на сложной разработке) и с риском: эксперимент может не выстрелить, корневую причину можно не найти.
Здесь начинается самое интересное — и самое инженерное. Способность процесса авторы моделируют как накопитель (stock): это актив, который копит в себе вложения. У него есть входящий поток (инвестиции в улучшение) и исходящий (эрозия — машины изнашиваются, процессы дрейфуют, документация устаревает, навыки гниют). Если накопитель не подпитывать, он стекает сам по себе.
Из-за этой асимметрии «усерднее» и «умнее» дают зеркально разные кривые:
📉 Работать усерднее = «лучше, потом хуже». Выпуск подскакивает мгновенно, но способность тихо проседает — и в какой-то момент проседание перебивает весь выигрыш от переработок.
📈 Работать умнее = «хуже, потом лучше». В моменте выпуск падает (люди ушли с производства в улучшение), зато потом способность вырастает с запасом, и производительность встаёт на новый, постоянно более высокий уровень.
Ловушка способностей: как система защёлкивается
А теперь добавляем третий контур — и капкан готов.
✂️ «Срезать углы» (балансирующий контур B3). Когда давление растёт, а часов в сутках больше не становится, люди начинают экономить на улучшении: пропускают плановое ТО, забивают на документацию, не приходят на ретро. Это освобождает время прямо сейчас — и разрыв временно закрывается. А способность? Она просядет, но не сразу. Между «срезал угол» и «прилетело» есть «период благодати».
И ключевой, четвёртый контур — тот, что делает всё необратимым:
♾️ «Реинвестиция» (усиливающий контур R1). Это положительная обратная связь, которая разгоняет то, что уже доминирует. Команда, которая вложилась в способность, получает рост производительности → у неё высвобождается ещё больше времени на улучшения → добродетельная спираль. Но команда, которую загнали в «усерднее + срезать углы», получает эрозию способности → разрыв растёт → давят ещё сильнее → времени на улучшение ещё меньше. Порочный круг, который Репеннинг и Стерман называют ловушкой способностей(capability trap).
Вот как описал это менеджер сборочного цеха в исследовании (пересказываю близко к тексту): мастера физически не успевали делать профилактику — всё время уходило на то, чтобы линия просто не встала; из-за этого процесс был в постоянном раздрае, дефекты вылезали уже после того, как наделали гору брака, разбираться в причинах было некогда — план горит. Снежный ком, который только нарастает.
Узнаёте? Это же дословное описание спринта, в котором тесты «потом», рефакторинг «потом», а прод падает «сейчас».
Почему менеджеры не замечают, что роют себе яму
Самая сильная часть статьи — психологическая, и здесь авторы беспощадны к руководству (без злорадства, чисто механически). Цепочка самообмана выглядит так:
🧩 Фундаментальная ошибка атрибуции. Мозг ищет причину рядом во времени и пространстве и предполагает один простой источник. Видишь оператора с кучей брака — виноват оператор. А реальная причина (плохое ТО, кривое обучение) — далеко и размазана по времени, её не видно. Вывод напрашивается сам: «люди ленятся».
🔁 Самоподтверждающаяся атрибуция. Менеджер не видит всех действий команды. Допустим, нужно +6 часов продуктивной работы в неделю. Он давит — люди режут перекуры и веб-сёрфинг, дают +2 часа. Оставшиеся +4 они добирают, срезая углы (то самое улучшение). Менеджер видит на табло +6 часов выпуска и приписывает весь эффект своему «закручиванию гаек», переоценивая его раза в три. Обратная связь не исправляет ошибку — она её подтверждает: «видите, надавил — и заработало, значит, действительно ленились».
🎭 Суеверное обучение. Эффект давления приходит быстро и однозначно, а эрозия способности — медленно, размыто и через месяцы. Никто не свяжет сегодняшнюю аварию с прессингом, который был полгода назад. А сотрудники, естественно, не бегут докладывать, что не вывозят, и прячут срезанные углы — что лишь укрепляет менеджера в мысли «им нельзя доверять». Дальше — больше мониторинга, жёстче KPI, и пророчество сбывается.
Тут авторы приводят детали, от которых хочется и смеяться, и плакать. В одной компании девизом инженеров было «никогда не признавайся в проблеме, пока у тебя нет решения». В другой еженедельные статус-митинги называли «клубом лжецов»: каждый завышал прогресс своей подсистемы и прятал известные дефекты в надежде, что чужие косяки всплывут раньше. А где-то даже завели отдельную касту «менеджеров по комплаенсу», чья единственная работа — следить, чтобы инженеры соблюдали новый процесс. Бюрократия как реакция на бюрократию.
И вот она, вишенка, давшая название статье. Организации, подсевшие на тушение пожаров, начинают награждать героев: тех, кто ценой подвига вытащил горящий проект или не дал встать линии. Повышают именно их. А того, кто тихо построил систему, благодаря которой пожаров просто не случилось, — не замечает никто. Цитата инженера автокомпании: «Никто не получает награды за проблемы, которых не было». Со временем всё руководство состоит из таких «героев войны», которые растят себе подобных, — и короткосрочное мышление зашивается уже в саму культуру и систему мотивации.
Почему это вообще-то статья про техдолг
Я не зря тащу сюда разработку — это делают и сами авторы. В статье прямым текстом разбирается инженер, который не запушил результаты симуляции на «полку» (engineering bookshelf — библиотеку переиспользуемых решений): в моменте сэкономил себе время и сдал проект быстрее, а в долгую угробил всю идею переиспользования. И software-инженер, которая забила на документацию ради дедлайна, а потом ловила баги, посаженные этим решением недели назад.
Поменяйте лексику — и вы получите точную модель того, как живёт технический долг:
⚙️ Накопитель «способность» — это ваша кодовая база, покрытие тестами, актуальность зависимостей, качество данных, инфраструктура.
⚙️ Эрозия — это dependency rot, дрейф моделей (model/data drift), хрупкие промпты, разъезжающаяся документация, разрастающийся легаси.
⚙️ «Срезать углы» — выкатить фичу без тестов, без мониторинга, с «// TODO: rewrite this».
⚙️ Период благодати — те самые недели/месяцы, пока техдолг ещё не предъявил счёт.
⚙️ Порочная реинвестиция — каждый аврал отнимает время у того, что аврал бы предотвратило.
А «никто не получает награды за пожар, которого не было» — это буквально диагноз SRE/on-call культуры. Инженер, героически дебажащий прод в три часа ночи, получает лавры. Инженер, который год назад спокойно настроил алерты и тем самым предотвратил десять таких ночей, не получает ничего, потому что предотвращённого инцидента нет в Jira.
Выход есть — но он стоит мужества (и недолго держится)
Самое ценное: авторы показывают, что из ловушки реально выбраться, и приводят два кейса.
DuPont. В 1991-м внутренний бенчмаркинг вскрыл парадокс: компания тратила на обслуживание на 10–30% больше конкурентов на доллар стоимости активов, а время безотказной работы было на 10–15% ниже. Менеджер Уинстон Ледет с командой построил системно-динамическую модель обслуживания и превратил её в ролевую симуляцию — The Manufacturing Game. Фокус был не в том, чтобы научить людей чинить насосы (это они и так умели), а в том, чтобы дать им за пару часов прожить динамику «хуже-потом-лучше», на которую в реальности уходят годы. Результаты у заводов, внедривших программу к концу 1993-го:
📈 Среднее время между отказами насосов росло на 12% при каждом удвоении наработки (против 5% у 23 сопоставимых заводов без программы).
📈 Прямые затраты на обслуживание упали в среднем на 20% (а у «контрольной группы» выросли на 7%).
📈 Завод Washington Works поднял производственную способность на 20%, качество сервиса на 90%, срок поставки срезал вдвое — почти без капвложений.
📈 По компании в целом — консервативно >$350 млн в год только на сэкономленном обслуживании.
British Petroleum, НПЗ в Лайме (Огайо). Завод, основанный аж в 1886-м Джоном Д. Рокфеллером, в 1980-е ушёл в ту же ловушку, и к началу 90-х BP подумывала его закрыть. В 1994-м там запустили ту же обучающую лабораторию — причём снизу, инициатива шла не от топов, а от инженера, специалиста по оборудованию и тренинг-супервайзера. В первые полгода затраты на обслуживание выросли на 30% — но менеджмент уже прожил эту «яму» в игре и был к ней готов. Итог по таблице результатов:
📈 Время между отказами насосов выросло с 12 до 58 месяцев (отказов: 640+ в 1991-м → 131 в 1998-м).
📈 Суммарно создано $43 млн новой стоимости в год при затратах $320 тыс. — соотношение 143:1.
📈 Один из примеров: команда свела сжигание бутана в факеле к нулю, экономия $1,5 млн/год, заняло две недели и $5000 — это ROI 30 000% годовых.
И вот деталь, ради которой стоит всё это читать. Про этот бутан команда знала — и проблему, и решение — восемь лет. У них было всё: знания, оборудование, материалы на площадке. Единственным барьером была ментальная модель: «нет ни времени, ни ресурсов на улучшения, это не в нашей власти, мы всё равно ничего не изменим». Лайм в итоге не закрыли — в 1998-м его выкупила Clark USA за $215 млн, и местная газета вышла с шапкой «Нефтезавод спасён».
А теперь моё личное «но». Триумфальные кейсы легко превращают статью в очередную success story — а она про другое. В том же тексте честно сказано, чем кончилось у DuPont: корпоративная программа сокращения издержек прокатилась по всей компании, ослабила контур реинвестиции и подрезала возможность масштабировать игру. Сам Ледет ушёл на раннюю пенсию. То есть флагманский успех подорвали ровно те же структурные силы, что создали ловушку. И это, на мой взгляд, главный неудобный вывод: выход из ловушки способностей — не разовая интервенция, а постоянная борьба с гравитацией. Стоит вниманию руководства или бюджету уехать на другое — и порочный круг тут же возвращается. «Сыграйте всей компанией в симулятор» — красивое решение, но оно очевидно не масштабируется на любую организацию и держится ровно до следующего раунда cost-cutting.
Что с этим делать в 2026-м
Я считаю, что статья 2001 года сегодня актуальнее, чем в момент выхода, — и вот почему. ИИ-инструменты разработки турбируют именно контур «работать усерднее»: фичи теперь можно штамповать в десять раз быстрее, а значит, соблазн «просто поднажать» стал ещё сильнее, а опция «вложиться в способность» — ещё легче откладывается. При этом эрозия в современных системах быстрее и незаметнее: модель дрейфует, данные протухают, зависимости гниют, промпты ломаются от смены версии API. Период благодати укоротился.
Что из этого следует утащить себе в практику:
🛠 Сделайте невидимое видимым. Ловушка живёт за счёт того, что «срезанные углы» не видны на табло. Меряйте стоимость тушения — долю времени на инциденты против времени на улучшения. Пока техдолг не лежит в трекере с ценником, его как бы нет.
🛡 Защищайте время на улучшение структурно. Не «когда будет свободная минута» (её не будет — контур реинвестиции съест), а выделенным бюджетом, который нельзя забрать под горящий релиз.
🧯 Перестаньте награждать пожарных. Если повышают только героев авралов, система сама воспроизводит авралы. Учитесь видеть и ценить тех, благодаря кому пожаров не случилось.
🧠 Готовьте руководство к «яме». Любой реальный выход из ловушки — это сначала просадка метрик. Без лидера, который понимает динамику «хуже-потом-лучше» и готов её пережить, улучшение убьют на первом же квартальном отчёте.
Главный тезис Репеннинга и Стермана, если выпарить его до сути: низкая эффективность — это почти всегда свойство системы, а не моральный изъян людей. И мой прогноз простой. В эпоху, когда LLM позволяют выкатывать фичи на бешеной скорости, выиграют не те команды, кто быстрее всех пушит, а те, кто сумеет выбраться из ловушки способностей на своей инфраструктуре, мониторинге и качестве данных. Потому что «герой войны» в мире AI-разработки соблазнительнее, чем когда-либо, — а накопитель способности продолжает тихо стекать, пока все аплодируют очередному ночному подвигу.
Источники
🔗 Nelson P. Repenning, John D. Sterman. «Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement» // California Management Review, Vol. 43, No. 4, Summer 2001 (первоисточник): https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf