Управленческие апдейты сложнее инженерных

Онтологическое трение: почему управленческие апдейты сложнее инженерных

Системное мышление · Теория управления

Сентябрь 2026

——————————————————————————

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

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

Два класса изменений

Пол Вацлавик в книге «Change: Principles of Problem Formation and Problem Resolution» (1974) разграничил два фундаментально разных типа изменений в системах. Изменение первого порядка происходит внутри системы — её параметры меняются, но правила игры остаются прежними. Изменение второго порядка меняет саму систему: переписываются правила, по которым принимаются решения о параметрах.

«Изменение первого порядка всегда выглядит как "больше того же самого" — даже когда это выглядит как противоположность. Изменение второго порядка — это смена правил игры, а не хода внутри неё.»

— Пол Вацлавик, Джон Уикленд, Ричард Фиш, 1974

Инженерный апдейт — почти всегда первый порядок. Код меняется внутри системы тестов, типов, контрактов. Система сама предоставляет сигнал успеха: тесты прошли или нет. Управленческий апдейт — почти всегда второй порядок. Он меняет критерии, по которым оцениваются будущие инженерные апдейты. У него нет встроенного сигнала успеха — потому что сигнал — это и есть то, что меняется.

Крис Аргирис развил ту же идею применительно к организациям, назвав это различие одинарной и двойной петлёй обучения. Одинарная петля: система замечает отклонение и корректирует поведение в рамках существующих норм. Двойная петля: система замечает, что сами нормы порождают систематические отклонения, и меняет нормы. Аргирис показал, что организации чрезвычайно хорошо умеют одинарную петлю и системно избегают двойной — потому что двойная петля требует ставить под вопрос принципы, на которых держится авторитет участников процесса.

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

Теорема хорошего регулятора и проблема самомодели

В 1970 году Роджер Конант и Уильям Росс Эшби опубликовали работу с намеренно провокационным названием: «Every Good Regulator of a System Must Be a Model of That System». Теорема утверждает: чтобы система управляла другой системой, она должна содержать внутреннюю модель объекта управления — изоморфную ему по релевантным измерениям.

Приложим это к управленческому апдейту. Governance-система регулирует поведение организации. Чтобы изменить governance-систему, нужна мета-governance-система, которая её регулирует. Но мета-governance-система, по теореме, должна содержать модель governance-системы — то есть включать её в себя как часть собственной структуры. Это означает, что любое изменение правил требует, чтобы регулирующая система одновременно:

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

Инженерный апдейт не сталкивается с этой проблемой — он не меняет инструмент, которым сам производится. Управленческий апдейт всегда работает тем же инструментом, который изменяет. Это и есть самореференция.

Закон необходимого разнообразия: метауровень не проще

Другой закон Эшби — Закон необходимого разнообразия — гласит: разнообразие регулятора должно быть не меньше разнообразия регулируемой системы. Чем сложнее система, тем сложнее должен быть регулятор.

Следствие для governance: мета-governance-система не может быть проще governance-системы. Если governance-система управляет сложной инженерной организацией, то мета-governance должна быть способна моделировать всё разнообразие ситуаций, которые эта governance охватывает. Нет никакого «упрощения сверху». Есть только перенос сложности на уровень выше.

Это объясняет, почему попытка внедрить «простое правило» на уровне governance систематически проваливается: простое правило не имеет достаточного разнообразия, чтобы регулировать сложный исполнительный слой. Либо правило становится сложным (и появляется проблема его точной артикуляции), либо оно остаётся простым и создаёт пробелы, которые система заполняет произвольно.

Странная петля: почему нет атомарного перехода

Дуглас Хофштадтер в «Гёдель, Эшер, Бах» (1979) и «Я есть странная петля» (2007) описал класс систем, в которых иерархические уровни не разделены чисто — они замыкаются друг на друга. Странная петля возникает тогда, когда, двигаясь по уровням системы, вы неожиданно оказываетесь там, откуда начали.

Управленческий апдейт — классическая странная петля. Чтобы изменить правило, вы используете правило о том, как изменять правила. Но именно это правило находится под ревизией. Переходное состояние — когда старое правило уже не действует, а новое ещё не установлено — не имеет чистого атомарного определения. В программировании есть транзакция: либо commit, либо rollback. В governance нет транзакционной семантики. Система продолжает работать в момент изменения правил, которые её регулируют.

Это объясняет типичный паттерн блокеров при управленческих апдейтах: каждый шаг установки нового правила сам требует интерпретации в рамках текущих правил — которые меняются. Исполнитель всегда находится в неопределённой зоне между двумя системами норм одновременно.

Артикуляционный разрыв

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

Инженерное решение можно коммитить с любой степенью точности и получить немедленный бинарный сигнал: работает или нет. Управленческое решение не имеет такого сигнала. Оно должно быть сформулировано с достаточной точностью ещё до того, как будет передано на исполнение — потому что исполнитель не может провести тест, который скажет ему, правильно ли он понял правило.

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

Это означает, что стоимость ошибки в governance несимметрично выше стоимости инженерной ошибки. Следствие: порог точности формулировки, при котором правило можно передавать на исполнение, должен быть значительно выше — но в большинстве систем нет роли, которая явно владеет работой по достижению этого порога. Решение принимается на одном уровне, исполнение происходит на другом, а трансляция между ними — точная артикуляция — проваливается в зазор.

Что реально снижает онтологическое трение

Явное владение артикуляцией

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

Итеративное снижение планки первого черновика

Дорогостоящую точность формулировки не нужно производить одним актом. Ценно явное разрешение на «черновик с известными пробелами» — который обозначает намерение и позволяет собрать обратную связь до того, как правило попадает в живую онтологию. Это аналог pull request review — но применительно к правилам, а не к коду.

Явная самореференция

Система должна явно фиксировать, когда изменение затрагивает метауровень. «Это правило меняет правила о правилах» — не метафора, а маркер, требующий отдельного режима обработки. Без такой маркировки мета-изменения обрабатываются теми же инструментами, что и объектные — и страдают от структурной несовместимости.

Знак качества вне петли

Если governance-система меняет саму себя, её внутренняя модель в момент изменения недостаточна — она описывает старое состояние, а не новое. Это означает, что хотя бы один элемент знака качества на управленческий апдейт должен находиться вне изменяемой системы. Внешний review — не бюрократия, а структурная необходимость.

——————————————————————————

Хорошая новость в том, что онтологическое трение не уменьшается само по себе с ростом системы — но оно поддаётся проектированию. Системы, явно разграничивающие объектный и метауровень, с ролевым мандатом на артикуляцию и внешним знаком качества, справляются с управленческими апдейтами значительно надёжнее — не потому что избавляются от самореференции, а потому что перестают притворяться, что её нет.