Ментальные модели: почему участники видят разные системы

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

Типичная сцена. Постмортем, тридцать минут, четыре человека:

• дежурный: «упал сервис заказов, откатили релиз, не помогло»;
• автор клиентской библиотеки: «зависимость флапала, я поднял таймаут — стало лучше»;
• DBA: «пришёл тяжёлый запрос, база встала, нужен индекс»;
• продакт: «мы третий раз за квартал теряем пиковую конверсию, инженерия не справляется».

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

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

Что такое ментальная модель — и что ей не является

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

Термин не метафора и не из бизнес-литературы. Кеннет Крейк в 1943 году (The Nature of Explanation) сформулировал тезис: мозг строит «уменьшенную модель» реальности и прогоняет её вперёд, чтобы выбрать действие до того, как действовать. Дональд Норман в сборнике Mental Models (Gentner & Stevens, 1983) описал наблюдаемые свойства таких моделей у людей, работающих с техникой, и они прямо объясняют всё дальнейшее:

1. Неполные. Модель покрывает кусок системы, а не систему.
2. Нестабильные. Детали забываются, особенно те, что редко используются.
3. Без чётких границ. Похожие устройства путаются; правило из одного контекста тащится в другой.
4. Ненаучные. Люди спокойно держат «суеверные» правила («после деплоя надо подождать пять минут»), если они работали.
5. Экономные. Человек предпочитает лишнее физическое действие лишнему мысленному усилию: проще перезапустить под, чем вспомнить, почему он падает.

Что ментальной моделью не является:

• не мнение и не позиция. «Считаю, что надо переписать на Go» — это предложение, а не модель. Модель — это «если переписать, p99 упадёт вдвое, потому что уйдут паузы GC»: утверждение с механизмом и следствием;
• не ценность. «Надёжность важнее скорости поставки» — предпочтение. Оно не проверяется экспериментом и спорить о нём фактами бессмысленно (об этом отдельный раздел ниже);
• не «латтис ментальных моделей» из популярных списков вроде «бритва Оккама, эффект Даннинга — Крюгера, …». Это коллекция эвристик для принятия решений, полезная или нет, но другая вещь: здесь речь о причинной модели конкретной системы, у которой есть наблюдаемые переменные и проверяемые следствия;
• не документация. Документ — проекция модели, обычно устаревшая. Питер Наур в «Programming as Theory Building» (1985) сформулировал это жёстко: программа — это теория в головах команды, а код и документация — её неполные отпечатки; когда команда расходится, теория теряется, и восстановить её по артефактам нельзя (текст статьи). Отсюда практический вывод, знакомый всем, кто принимал чужой сервис: код есть, тесты зелёные, а почему здесь именно 30 секунд таймаута — не знает никто.

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

Пять механизмов расхождения

Расхождение моделей — не следствие невнимательности. Оно порождается структурой, и механизмов ровно пять. Полезно уметь называть их, потому что лечатся они по-разному.

1. Разные границы

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

Диагностический признак: спорящие используют слово «система» без уточнения и обозначают им разное.

2. Разная наблюдаемость

Второй механизм — главный, и он же самый недооценённый. Каждый участник видит свой участок причинной цепи: тот, на который у него настроены дашборды, алерты и логи.

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

Практическое следствие: прежде чем спорить о причине, выложите на стол, кто на какие графики смотрел. В половине случаев спор рассасывается за пять минут, потому что выясняется, что двое смотрели непересекающиеся окна.

3. Разный горизонт времени

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

Диагностический признак: участники соглашаются насчёт механизма и расходятся насчёт «это хорошо или плохо».

4. Разные целевые функции

Модель человека формируется под то, за что его спрашивают. Если у дежурного метрика — «время закрытия алерта», он выучит систему как набор быстрых способов гасить алерты, и его модель будет точной именно в этом. Если у SRE-функции метрика — «число повторов инцидента», модель будет про механизмы. Метрика — не измеритель, а формирователь модели; почему это опасно, разобрано в главе о метриках продукта.

5. Разная выборка опыта

Модель обучается на том, что человек лично пережил. Инженер, работавший с монолитом на одной машине, переносит модель «перезапуск чинит» на распределённую систему, где перезапуск усиливает шторм. Инженер, переживший потерю данных, ставит безлимитные ретраи. Обе модели были правильными на своей выборке и переносятся на новую систему без пометки о применимости — свойство 3 по Норману.

Именно это, а не глупость, объясняет наблюдение Ричарда Кука: катастрофы в сложных системах почти всегда выглядят как последовательность разумных локальных решений (How Complex Systems Fail, how.complexsystems.fail). Принцип называется локальной рациональностью: в момент принятия решения человек действовал разумно с точки зрения доступных ему тогда данных и своей модели. Разбор, который этого не принимает, находит виноватого и не находит механизма.

Петля самоподтверждения

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

Разбор диаграммы:

• Контур R (модель → действия → поведение → наблюдение → модель) содержит ноль минусов, то есть усиливающий. Он делает модель всё более уверенной вне зависимости от её правильности: наблюдение отбирается моделью, а не наоборот. В литературе по организационному обучению это называют self-sealing — самозапечатывающейся моделью (Крис Аргирис). В логике тот же механизм известен как систематическая ошибка подтверждения, разобранная в главе про когнитивные искажения.
• Контур B через инцидент — единственный, который в этой схеме способен модель поправить, и у него огромная задержка. Отсюда честная оценка: ментальные модели обновляются в основном авариями, и это дорогой способ обучения.
• Пунктирная стрелка — то, что происходит, когда разбор персонализируют: модель не обновляется, вместо неё в неё добавляется одно исключение («в тот раз был странный трафик»), и R-контур продолжает работать. Отличие ветки на U от пунктира — это разница между двойной и одинарной петлёй обучения у Аргириса: править действия внутри старой модели или править саму модель.

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

Заявленная модель против действующей

Аргирис и Дональд Шён разделили espoused theory — то, что человек говорит о своих принципах, и theory-in-use — то, что реально выводится из его действий. Разрыв между ними обычно велик, и человек его не замечает.

Инженерные примеры разрыва, которые видно за один день:

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

У этого приёма есть эмпирическая основа сильнее, чем у большинства разговоров о моделях. Ричард Нисбетт и Тимоти Уилсон («Telling More Than We Can Know», Psychological Review, 1977) показали: люди уверенно объясняют причины собственных решений, и эти объяснения систематически расходятся с экспериментально установленными причинами. Вывод для практики: доверяйте предсказаниям и артефактам, а не объяснениям постфактум — своим в том числе.

Отсюда же следует, почему архитектурные решения полезно записывать в момент принятия, а не восстанавливать потом: ADR фиксирует модель до того, как она отредактируется исходом (архитектурные решения и ADR).

Как вытащить чужую модель за десять минут

Вопрос «почему ты так думаешь» не работает: он получает рационализацию. Работают вопросы, требующие предсказания или наблюдения.

Четыре рабочих формулировки:

1. «Что ты ожидал увидеть?» — про уже случившееся. Вскрывает разрыв между моделью и фактом.
2. «Что должно произойти, если ты прав, и чего не произойдёт?» — превращает мнение в проверяемое утверждение.
3. «Какое наблюдение заставило бы тебя изменить решение?» — если ответа нет, это не модель, а позиция, и обсуждать её надо иначе.
4. «Какое число ты держишь в голове?» — таймаут, RPS, размер очереди, время восстановления. Числа расходятся чаще, чем схемы, и расхождение видно сразу.

Как это выглядит в живом разборе:

Обратите внимание на последний обмен: самая ценная находка разбора — не «кто был прав», а дыра в наблюдаемости, из-за которой петлю не видел никто. Такие находки конвертируются в задачи, которые реально снижают повторяемость; «быть внимательнее» — нет. Практика разбора инцидентов как процесса — дежурства и инциденты и постмортемы в SRE Book; канонический текст про безблеймовость — Blameless PostMortems Джона Оллспоу.

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

Разногласие о фактах или о целях

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

Практический алгоритм различения занимает одну минуту:

1. Сформулируйте разногласие как утверждение о наблюдаемой величине.
2. Спросите каждую сторону: «если бы факт оказался противоположным, вы изменили бы решение?»
3. Оба ответили «да» — это спор о фактах, идите измерять; спорить дальше словами бессмысленно.
4. Хотя бы один ответил «нет» — это спор о целях или ценностях. Переводите его в явный выбор с ответственным, а не продолжайте обмениваться графиками.

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

Журнал предсказаний: как сделать модели проверяемыми

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

# prediction-log/2026-07-16-retry-budget.yaml
change: "Ввести общий бюджет ретраев 10% и убрать ретраи в клиенте заказов"
decided_at: 2026-07-16
check_at: 2026-07-30          # дата обязательной сверки, назначается заранее
predictions:
  - author: dev-a
    claim: "p99 чекаута в пике упадёт ниже 400 мс"
    p: 0.7
  - author: dev-a
    claim: "доля 5xx у клиента вырастет более чем вдвое"
    p: 0.6
  - author: sre-b
    claim: "p99 чекаута в пике упадёт ниже 400 мс"
    p: 0.2                    # расхождение 0.5 — вот что надо мерить
  - author: sre-b
    claim: "число инцидентов класса «шторм» за месяц станет нулевым"
    p: 0.8

Две функции, которые с этим журналом делают работу. Первая считает счёт Брайера — средний квадрат ошибки вероятностного предсказания:

$$\mathrm{BS} = \frac{1}{n}\sum_{i=1}^{n} (p_i - o_i)^2$$

где $o_i \in \lbrace 0, 1 \rbrace$ — исход. Ноль — идеально; 0.25 — уровень «всегда отвечаю 50%»; больше 0.25 — вы предсказываете хуже монетки и при этом уверены. Вторая функция ищет утверждения, по которым участники расходятся сильнее порога: именно они — кандидаты в эксперименты, всё остальное обсуждать бессмысленно.

from dataclasses import dataclass


@dataclass
class Prediction:
    """Одно предсказание одного участника, сделанное ДО изменения."""
    author: str
    claim: str                     # утверждение о наблюдаемой величине
    p: float                       # субъективная вероятность, 0..1
    outcome: bool | None = None    # заполняется в дату сверки


def brier(preds: list[Prediction]) -> float:
    """Счёт Брайера по проверенным предсказаниям.

    0.0 — идеально, 0.25 — уровень случайного угадывания,
    1.0 — максимальная уверенность в неверном.
    Время O(n), память O(1).
    """
    scored = [pr for pr in preds if pr.outcome is not None]
    if not scored:
        raise ValueError("нечего оценивать: ни одно предсказание не проверено")
    return sum((pr.p - float(pr.outcome)) ** 2 for pr in scored) / len(scored)


def contested(preds: list[Prediction], threshold: float = 0.4) -> list[str]:
    """Утверждения, по которым модели участников расходятся сильнее порога.

    Их и надо проверять экспериментом: остальное — согласие,
    пусть даже согласие в заблуждении.
    Время O(n), память O(k) по числу различных утверждений.
    """
    by_claim: dict[str, list[float]] = {}
    for pr in preds:
        by_claim.setdefault(pr.claim, []).append(pr.p)
    return [
        claim
        for claim, ps in by_claim.items()
        if len(ps) > 1 and max(ps) - min(ps) >= threshold
    ]

Что даёт эта практика на горизонте нескольких месяцев:

• Разрушает R-контур самоподтверждения. Предсказание записано до исхода, поэтому память его не отредактирует. Это прямая контрмера против ошибки хиндсайта — одного из наиболее устойчиво воспроизводимых эффектов в психологии решений (Баруш Фишхофф, 1975).
• Показывает, чья модель лучше — в конкретной области. Счёт Брайера по десяти-пятнадцати записям уже различает людей, чьи оценки стоит взвешивать выше. Это не рейтинг сотрудников и не должно им становиться (см. ловушки ниже).
• Отделяет проверяемое от непроверяемого. Утверждение, для которого никто не может назвать наблюдение и дату, в журнал не попадает — и это само по себе полезный фильтр.
• Стоит десять минут на изменение. Дороже не нужно: точность вероятностей здесь вторична, ценна фиксация расхождений.

Дисциплина вероятностных предсказаний и калибровки подробно разобрана у Филипа Тетлока (Superforecasting, 2015) и в главе про научное и инженерное рассуждение.

Жизненный цикл общей модели команды

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

Три следствия из этой схемы:

1. Состояние «скрытое расхождение» не наблюдаемо изнутри и может длиться месяцами. Его единственный дешёвый детектор — регулярное принудительное столкновение моделей: разбор архитектуры, game day, учебный инцидент, ревью алертов. Дороже — ждать аварии.
2. Переход в «окопы» определяется формой вопроса, а не тяжестью аварии. «Почему ты так сделал» и «что ты ожидал увидеть» ведут в разные состояния схемы.
3. Выход T → [*] — уход человека — уничтожает модель целиком, потому что она нигде не записана (тот самый тезис Наура). Отсюда практическая ценность ADR, runbook с объяснением «почему», комментариев к порогам алертов: это не бюрократия, а единственный носитель модели вне головы.

Организационная структура задаёт, между кем модели вообще могут выравниваться: люди согласуют модели там, где общаются, и расходятся там, где не общаются. Это классический аргумент Мелвина Конвея («How Do Committees Invent?», 1968), и он объясняет, почему интерфейсы между командами ломаются чаще внутрикомандных.

Типовые ловушки

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

Согласие принимают за правильность. Выровненные модели команды могут быть согласованно неверными, и тогда команда быстрее и увереннее едет не туда. Общая модель — не цель, а средство; цель — модель, соответствующая системе. Хорошая проверка: когда мы в последний раз что-то предсказали и ошиблись? Если «никогда» — вы не предсказываете.

Диаграмма как инструмент власти. Нарисованная схема выглядит как результат анализа, хотя является его постановкой. Тот, кто держит маркер, задаёт границы и набор переменных, и дальше обсуждение идёт внутри его модели. Противоядие механическое: сначала каждый рисует свою схему за пять минут молча, потом сравниваете. Разница между схемами — материал главы; на общей схеме её уже не будет. Техника построения и проверки схем — диаграммы причинных связей; совместное построение модели домена — event storming.

Одно слово — две модели. «Готово», «нагрузка», «инцидент», «таймаут», «пользователь» в разных частях компании означают разное, и расхождение обнаруживается на интеграции. Это ровно та проблема, ради которой в DDD введены единый язык и ограниченные контексты. Дешёвая профилактика — глоссарий с указанием, где термин перестаёт действовать; работа со стейкхолдерами и их словарями — выявление требований и стейкхолдеры.

Журнал предсказаний превращают в оценку сотрудников. Как только счёт Брайера попадает в перформанс-ревью, люди начинают предсказывать безопасное и общее, а не то, что действительно думают. Метрика уничтожает данные, которые измеряет, — частный случай эффекта, разбираемого в главе о локальной оптимизации. Журнал должен быть командным и по возможности анонимным при сборе.

Перенос модели без пометки о применимости. «У нас в прошлой компании работало» — сильный сигнал: модель обучена на другой топологии, другом масштабе и другой команде. Не отбрасывать, а требовать явных условий применимости: при каком RPS, при какой связности, при какой стоимости ошибки это было верно.

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

Честно про доказательную базу

Тема ментальных моделей — место, где системное мышление легче всего скатывается в приятные разговоры. Разделим уровни доказательности прямо.

Прочно.

• Люди систематически ошибаются в задачах с накоплением и задержкой. Джон Стерман (Management Science, 1989) и эксперимент beer game: даже при постоянном спросе участники раскачивают цепочку поставок, потому что не учитывают заказы «в пути». Свини и Стерман («Bathtub dynamics», System Dynamics Review, 2000) показали, что студенты MIT массово ошибаются в элементарных задачах «запас — поток», нарисованных на одном графике. Воспроизведено многократно на разных выборках. Это прямое экспериментальное основание тезиса «интуитивная модель динамики систематически неверна», и оно не зависит ни от какой философии.
• Ошибка хиндсайта. Фишхофф (1975) и последующие десятилетия работ: узнав исход, человек искренне считает, что предвидел его. Это делает ретроспективные объяснения ненадёжными и обосновывает журнал предсказаний.
• Ненадёжность интроспекции. Нисбетт и Уилсон (1977): самоотчёты о причинах решений расходятся с экспериментально установленными причинами. Работа критиковалась за широту выводов, но базовый эффект — «объяснение постфактум ≠ реальная причина» — держится.
• Локальная рациональность в разборе аварий. Не лабораторный результат, а обобщение большого корпуса расследований в авиации, медицине и IT (Расмуссен, Вудс, Деккер, Кук). Статус — сильная методологическая рекомендация с богатой эмпирикой случаев, не РКИ.

Слабее, чем принято думать.

• «Общие ментальные модели повышают эффективность команды». Литература по shared mental models существует и даёт положительные корреляции — мета-анализ ДеЧёрч и Месмер-Магнус (Journal of Applied Psychology, 2010) находит умеренную связь когнитивных структур команды с результатом. Но: измерения «общности моделей» разнородны и спорны, дизайны в основном корреляционные, а направление причинности не установлено — успешные команды могут выравнивать модели, а не наоборот. Утверждать «выровняйте модели, и продуктивность вырастет на N%» — выдавать корреляцию за механизм.
• Двойная петля обучения Аргириса. Влиятельная и практически полезная рамка, но доказательная база — кейсы и наблюдения консультанта, не контролируемые эксперименты. Пользуйтесь как языком описания, не как установленным законом. Стартовый текст — «Teaching Smart People How to Learn» (HBR, 1991).
• Списки когнитивных искажений. Часть эффектов воспроизводится хорошо (хиндсайт, якорение), часть заметно пострадала в кризисе воспроизводимости (особенно прайминг-эксперименты). Ссылаться на «известное искажение» как на доказательство — плохая практика; подробности — в главе о когнитивных искажениях.
• «Ментальные модели» как жанр деловой литературы. Списки эвристик из популярных книг не имеют отношения к тому, о чём эта глава, и их предсказательная сила не измерялась.

Практический смысл разделения: стройте практику на первом блоке (предсказания, наблюдаемость, локальная рациональность), а второй используйте как язык, честно помечая, что это рамка, а не результат.

Пределы метода

Место, где надо остановиться и не выдавать желаемое за проверенное.

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

Вербализация меняет модель. Заставив человека объяснить свою модель, вы получаете не слепок, а свежепостроенную конструкцию, отредактированную аудиторией и статусом. Отсюда правило: сначала письменно и по возможности анонимно, потом вслух.

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

Аккуратная модель не гарантирует правильного решения. Даже при полном согласии о механизме остаётся неопределённость параметров, а система продолжает меняться. Модель уменьшает класс ошибок «не туда смотрел», а не ошибки вообще; про принципиальные ограничения — моделирование и его пределы.

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

Чеклист

Когда участники описывают одну систему несовместимо:

1. Выложить, кто на какие графики и логи смотрел. Половина расхождений закрывается здесь.
2. Спросить каждого: «что ты ожидал увидеть — в числах?». Ожидание, а не объяснение.
3. Проверить, не спор ли это о границах: обозначает ли слово «система» у всех одно и то же.
4. Проверить горизонт: на каком окне времени каждый оценивает последствия.
5. Задать вопрос-разделитель: «если бы факт был противоположным, изменили бы решение?». Разделить спор о фактах и спор о целях.
6. Для спора о фактах — назначить самый дешёвый эксперимент и дату сверки. Записать предсказания до эксперимента.
7. Для спора о целях — вывести на явное решение владельца и записать в ADR, а не продолжать обмен графиками.
8. Найти участок петли, не попавший ни в одно окно наблюдения. Это и есть задача после инцидента.
9. Проверить артефакты на разрыв с декларациями: пороги, таймауты, лимиты, поля шаблонов.
10. Спросить себя: какое наблюдение опровергло бы мою модель, и собираю ли я его.

Мини-итог

• Ментальная модель — внутренняя причинная схема системы, по которой человек предсказывает последствия действий. Она неполна, нестабильна, переносится без пометки о применимости и экономит усилия, а не стремится к истине.
• Расхождение моделей порождается пятью структурными механизмами: разные границы, разная наблюдаемость, разный горизонт времени, разные целевые функции, разная выборка опыта. Ни один из них не связан с квалификацией или добросовестностью.
• Модель самоподтверждается: она определяет действия и фильтрует наблюдения. Усиливающий контур замыкается, и без специально собранных опровержений модель становится увереннее вне зависимости от правильности.
• Заявленная модель почти всегда отличается от действующей. Действующая читается по артефактам: таймаутам, лимитам, порогам алертов, полям шаблона постмортема.
• Расхождения вскрываются вопросами про ожидание и предсказание, а не про причины. «Что ты ожидал увидеть?» полезнее, чем «почему ты так решил?».
• Спор о фактах и спор о целях требуют разных действий. Тест на различение — один вопрос: изменило бы решение противоположное значение факта.
• Журнал предсказаний с датой сверки — самая дешёвая практика, делающая модели проверяемыми. Счёт Брайера полезен как обратная связь команде и вреден как оценка сотрудника.
• Самая ценная находка разбора — не виновный и не «правильная» модель, а участок петли, который не попал ни в одно окно наблюдения.
• Прочная часть темы — экспериментальные результаты об ошибках в задачах с накоплением и задержкой, хиндсайт и ненадёжность интроспекции. Утверждения вида «общие модели повышают эффективность» — корреляции, а не механизмы, и подавать их надо как гипотезу.
• Если расхождение держится структурой стимулов, работа с моделями его не устранит. Меняйте структуру, а не понимание.

Источники

• K. Craik. The Nature of Explanation. Cambridge University Press, 1943 — исходная формулировка идеи внутренней модели.
• D. Gentner, A. Stevens (eds.). Mental Models. Lawrence Erlbaum, 1983 — сборник, глава Д. Нормана «Some Observations on Mental Models» с перечнем свойств.
• P. Naur. Programming as Theory Building, 1985 — программа как теория в головах команды.
• J. Sterman. Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment. Management Science 35(3), 1989.
• L. Booth Sweeney, J. Sterman. Bathtub Dynamics: Initial Results of a Systems Thinking Inventory. System Dynamics Review 16(4), 2000.
• J. Sterman. Business Dynamics. McGraw-Hill, 2000 — главы о ментальных моделях и границах модели.
• R. Nisbett, T. Wilson. Telling More Than We Can Know: Verbal Reports on Mental Processes. Psychological Review 84(3), 1977.
• B. Fischhoff. Hindsight ≠ Foresight. Journal of Experimental Psychology: Human Perception and Performance 1(3), 1975.
• C. Argyris. Teaching Smart People How to Learn. Harvard Business Review, 1991; C. Argyris, D. Schön. Theory in Practice, 1974 — заявленная и действующая теория, одинарная и двойная петля обучения.
• L. DeChurch, J. Mesmer-Magnus. The Cognitive Underpinnings of Effective Teamwork: A Meta-Analysis. Journal of Applied Psychology 95(1), 2010 — что реально известно про общие модели в командах.
• S. Dekker. The Field Guide to Understanding «Human Error». Ashgate, 2014; D. Woods, S. Dekker, R. Cook et al. Behind Human Error, 2010 — локальная рациональность и разбор аварий.
• R. Cook. How Complex Systems Fail — восемнадцать тезисов, половина из них про модели участников.
• J. Allspaw. Blameless PostMortems and a Just Culture, Etsy, 2012.
• Postmortem Culture: Learning from Failure — Google SRE Book.
• The STELLA Report — SNAFUcatchers, разбор того, как инженеры строят и чинят модели во время инцидентов.
• M. Conway. How Do Committees Invent?, Datamation, 1968.
• P. Tetlock, D. Gardner. Superforecasting. Crown, 2015 — калибровка, счёт Брайера, дисциплина предсказаний.
• D. Meadows. Leverage Points: Places to Intervene in a System, 1999 — уровень «парадигма» как самая сильная и самая труднодоступная точка воздействия.

Что дальше

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

Системные архетипы: повторяющиеся ловушки