На проекте вы постоянно опираетесь на упрощённые представления о системе, процессе и мотивах людей — даже если не называете их так. Ментальные модели (mental models) определяют, что вы заметите в интервью, какую диаграмму построите первой и какие требования сочтёте «очевидными». Эта статья отвечает на вопрос: какие когнитивные рамки полезны аналитику — и бизнес-, и системному, — как осознанно переключаться между ними и не путать модель с реальностью. Граница ролей — в 00.02 Бизнес-анализ vs Системный анализ vs Требования.

1. Суть темы

Ментальная модель (mental model) — внутреннее представление о том, как устроен объект, процесс или роль; через неё вы предсказываете поведение системы и объясняете наблюдаемые эффекты. Модель всегда упрощает реальность: она выделяет важное для текущей задачи и отбрасывает остальное.

Для аналитика ментальные модели — не «мягкий навык», а инфраструктура анализа:

Ментальные модели не заменяют 01.01 Понятие системы и системного подхода — они описывают, как вы применяете системный подход в конкретном контексте. Две команды с одинаковым BPMN-шаблоном могут видеть разные границы системы, потому что у них разные неявные модели.

flowchart TB
    subgraph internal [Внутренний уровень]
        MM[Ментальные модели аналитика и участников]
    end
    subgraph external [Внешний уровень — артефакты]
        D[Диаграммы, глоссарий, SRS]
    end
    subgraph reality [Реальность]
        S[Система и организация]
    end
    MM -->|экстернализация| D
    D -->|согласование и проверка| MM
    S -->|наблюдение, данные, интервью| MM
    D -.->|карта ≠ территория| S

Ключевое различение: модель + метод. Ментальная модель отвечает на «что искать и в какой оптике»; техника анализа — на «как искать». Fishbone (01.03 Техники анализа проблем) без системной модели даст список причин без понимания обратных связей; системное мышление без техники останется абстрактным.

Соседняя тема 01.07 Когнитивные искажения и критическое мышление фокусируется на искажениях восприятия. Здесь акцент на полезных моделях и осознанном переключении между ними. Искажение может маскироваться под «логичную модель» — поэтому обе темы работают в паре: распознав anchoring или confirmation bias, сознательно смените оптику из решётки (см. протокол в §3).

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

ПонятиеСуть для аналитика
Ментальная модельУпрощённая картина «как это работает» в голове участника; основа для прогноза и объяснения (Craik, Johnson-Laird).
Концептуальная модель системыЦелевое согласованное представление команды о поведении продукта — то, как система должна работать по замыслу (Norman).
Модель в артефактеЗафиксированное в [[04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
Карта ≠ территорияЛюбая диаграмма, глоссарий или user story — не реальность; фиксируйте допущения и границы применимости.
Решётка моделей (latticework)Набор моделей из разных дисциплин — системы, экономика, психология, инженерия — вместо одного «любимого» фреймворка.
Системное мышление как модельФокус на границах, обратных связях, задержках, emergent behavior — базовый слой поверх 01.01 Понятие системы и системного подхода; stocks/flows и leverage points здесь не разбираем.
First principles / декомпозицияРазбор до фактов и ограничений без автоматического копирования «как принято в отрасли».
Second-order thinkingВопрос «и что будет после первого эффекта?» — критичен для изменений процессов и IT.
Инверсия (inversion)Формулировка через провал: «что гарантированно сломает решение» — дополняет прямой сбор требований.
Модели стейкholdersУ каждого участника своя картина домена; задача аналитика — выявить, согласовать и зафиксировать общую.
OODA (observe–orient–decide–act)Цикл действий в условиях неопределённости и меняющихся требований.
Модель + методМодель задаёт оптику; техника из 01.03 Техники анализа проблем — процедуру.

Три типа «модели» — не смешивайте

По Norman в HCI различают три уровня, которые на проекте часто называют одним словом «модель»:

  1. Ментальная модель участника — что человек думает, как устроена система (оператор, разработчик, владелец продукта). Она может быть неверной, но определяет поведение и ожидания.
  2. Концептуальная модель (целевая) — согласованное представление команды о том, как продукт должен работать. Это результат анализа, а не «сумма голов».
  3. Модель в артефакте — BPMN, ER, OpenAPI, прототип: экстернализация концептуальной модели для проверки и передачи знаний.

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

Пример (L1, без IT): директор продаж считает, что «успех программы лояльности» — рост среднего чека; маркетинг — удержание и NPS. Оба правы в своей модели успеха, но KPI и граница scope расходятся. Задача аналитика: выявить две модели, зафиксировать критерии успеха (02.01.02 Цели, KPI и критерии успеха (SMART, GQM)) и согласовать, какая модель — рабочая для текущего релиза.

Пример (B2B / internal, L2–L3): оператор колл-центра считает, что «отмена заявки» мгновенно возвращает деньги; разработка моделирует двухэтапный процесс с hold; в OpenAPI поле status не отражает промежуточное состояние. Три разных модели — три источника дефектов на приёмке. Задача SA: выявить расхождение, согласовать концептуальную модель и отразить её в контракте и UI.

Выбор модели из решётки

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

Сигнал в задачеМодель из решёткиКогда не подходит
Спор о приоритетах, скрытые интересы сторон01.04 Теория игр для аналитикаНет конфликта целей — избыточно
Задержки, очереди, «всё упирается в один шаг»01.05 Теория ограничений и бережливое мышлениеПроблема в данных или интеграции, а не в потоке
Сложные обратные связи, побочные эффекты измененийСистемное мышление (01.01 Понятие системы и системного подхода) — без декомпозиции stocks/flows здесьЛокальный баг с известной причиной
«Почему мы вообще так делаем?»First principlesНет времени на переосмысление — нужен тактический фикс
Риск каскадных последствий после релизаSecond-order thinkingТривиальное косметическое изменение
Застряли в оптимизме первого решенияИнверсияУже есть согласованный и проверенный контур
Домен непредсказуем, причинно-следственные связи проявляются постфактумOODA + spike (05.02 Scrum и Kanban (аналитик в Agile))Заказный контур с жёстким контрактом и frozen scope

Базовые переключатели оптики

Один и тот же кейс «отмена заявки» (см. выше) по-разному раскрывается через каждый переключатель:

  • First principles — «какие факты и ограничения обязательны?» (регламент возврата, SLA, наличие hold в платёжном шлюзе). Отсекает «как у конкурента» без проверки.
  • Second-order thinking — «если ускорим отмену в UI, вырастет ли число злоупотреблений? нагрузка на антифрод?» Первый эффект ≠ итоговый.
  • Инверсия — «что гарантированно сломает приёмку?» (расхождение статусов между UI, API и выпиской). Список anti-goals дополняет happy path.
  • OODA — домен ещё не стабилен: фиксируете гипотезу, проверяете spike'ом на стенде, обновляете модель по фактам — а не полируете единственную to-be диаграмму.

В упорядоченном контексте (известные правила, повторяемый процесс) одна to-be модель обычно уместна. В сложном — когда причинно-следственные связи проявляются только после эксперимента — фиксируйте гипотезы и проверяйте spike'ами (01.03 Техники анализа проблем, 02.02.04 Прототипирование и UI-UX-исследования), а не единственную «идеальную» диаграмму на старте. OODA + spike обязательны, когда вы не можете заранее перечислить все сценарии; в заказном контуре с frozen scope — избыточны.

Специализированные модели — подключаемые модули

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

Три слоя модели на типовом проекте

flowchart TB
    L1[Слой 1: Домен и стейкholders — кто, зачем, какие правила]
    L2[Слой 2: Система — границы, потоки, данные, интеграции]
    L3[Слой 3: Решение — паттерны, NFR, компромиссы]
    L1 --> L2 --> L3

На каждом слое допустима своя внешняя форма: stakeholder map и цели — на первом; context diagram, BPMN, ER — на втором; ADR, API-контракты — на третьем. Ошибка — смешивать слои в одной диаграмме «на всё». Модель эволюционирует по SDLC: на discovery достаточно L1–L2, детализация L3 нарастает к реализации — см. 02.05.05 Жизненный цикл требования.

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

Раздел про выбор и переключение оптики, а не про полный процесс анализа. Техники elicitation, нотации и Agile-практики — в соседних ветках базы; здесь — как ментальная модель управляет тем, что вы делаете дальше.

На этапе validate скрытая модель проявляется как расхождение между критериями приёмки и тем, как пользователь ожидает, что система работает — см. 02.04.01 Верификация и валидация (V&V) и 02.04.02 Критерии приёмки (Acceptance Criteria).

Ранние сигналы: какая модель сейчас активна

До конфликта модель часто видна по симптомам — каждый из них запускает шаг 1 протокола переключения (§3, ниже):

  • повторяющиеся споры об одних и тех же терминах без сближения определений;
  • «surprise» на архитектурном ревью — команда видела другую границу системы;
  • один и тот же артефакт читают по-разному («я думал, что API синхронный»);
  • все диаграммы в одной оптике (только процесс или только данные), хотя вопрос уже на другом слое.

Выявление требований: делайте модели явными

На интервью и воркшопах проговаривайте допущения: «Я сейчас считаю, что заявка проходит через оператора, а не напрямую в ядро — верно?» As-is и to-be — согласованные модели, а не только списки требований.

Опоры по техникам (не дублируем процедуры): 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии, 09.01 Техники активного слушания и опросов.

Несовместимые модели стейкholders

Alignment workshop не всегда сближает картины. Если после явной фиксации моделей расхождение остаётся:

  1. Зафиксируйте альтернативы — две (или более) явные модели с последствиями для scope, сроков и рисков.
  2. Определите decision rights — кто принимает решение при несовместимости (спонсор, product owner, архитектурный комитет).
  3. Временная рабочая модель — «пока строим по модели A, модель B проверяем spike'ом к дате X»; не притворяйтесь, что согласие достигнуто.
  4. Эскалация — если ставки высоки и модели взаимоисключающие; фасилитация конфликта — 09.03 Управление конфликтами и переговоры.

Задача аналитика — не «победить» одну модель, а сделать расхождение управляемым и отражённым в scope и ADR.

Экстернализация: оптика → артефакт (индекс, не курс)

Диаграммы и глоссарий — внешнее представление согласованной модели. Выбор нотации — следствие оптики; как рисовать BPMN, ER или C4 — процедура в разделах 03.xx и 06.xx, форматы документов — в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

ОптикаЧто проясняетПримеры артефактов
ПроцессПоследовательность, роли, исключения03.04.01 BPMN 2.0 - введение и основы, 03.04.02 Диаграмма потоков данных (DFD)
Структура системыГраницы, подсистемы, интеграции03.01.02 Моделирование контекста системы (Context Diagram), 06.03.05 C4-модель
ДанныеСущности, связи, жизненный цикл03.03.01 ER-диаграммы (сущность-связь), 10.01.14 Шаблон глоссария и словаря данных
Мотивация акторовЦели, KPI, конфликты02.01.02 Цели, KPI и критерии успеха (SMART, GQM), 02.01.03 Анализ заинтересованных сторон (Stakeholder Map)
ПоведениеСценарии, состояния, события03.02.01 Диаграмма прецедентов (Use Case Diagram), 03.02.04 Диаграмма состояний (State Machine Diagram)

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

На слое решения SA опирается на инженерные оптики — это не чеклист NFR, а рамка, что искать на elicitation. Пример: оптика событийности меняет вопросы на интервью — «что считается событием? кто подписчик? что при повторной доставке?» — и сразу выводит к требованиям идемпотентности и границам сервиса. Детали паттернов — в 01.06 Принципы и паттерны проектирования решений, 03.06.02 Основы Domain-Driven Design, 03.05.06 Event-Driven Architecture, NFR.

Когда модель «достаточна»

Модель всегда упрощает — вопрос не «полная или нет», а достаточна ли для следующего решения. Признаки достаточности:

  • можно сформулировать проверяемую гипотезу (что увидим на стенде, в интервью, в метриках) — см. 08.03 Тестирование требований (статическое тестирование);
  • критические альтернативы перечислены — хотя бы две, с критерием отличия;
  • рискованные допущения явно помечены, для топ-1–2 есть план проверки (spike, прототип);
  • следующий шаг команды не блокируется отсутствием деталей вне текущей границы модели.

Перед стартом разработки сверьте критерий с 10.04 Чеклист аналитика перед стартом разработки.

Если этих признаков нет — уточняйте или проверяйте. Если есть, а команда всё ещё «полирует» диаграмму — это analysis paralysis: переходите к Act (spike, MVP-срез), а не к бесконечному Orient без новых фактов.

First principles на практике: вместо «нужен чат как у конкурента» — «какую задержку ответа оператор допустит? какой канал уже есть? какой SLA в контракте?»; ответы сужают пространство решений до проверяемых ограничений.

OODA, spike и граница с change control

В Agile-контуре требования меняются быстрее, чем «идеальная» модель. Цикл OODA — способ обновлять модель, а не заменять управление изменениями:

  1. Observe — новые факты, метрики, обратная связь со стенда.
  2. Orient — пересмотр допущений и концептуальной модели (double-loop learning — пересмотр предпосылок, а не только выбор тактики). Это глубже, чем правка диаграммы: меняется понимание домена.
  3. Decide — следующий шаг анализа, spike или эскалация в change control (CCB).
  4. Act — прототип, уточнение спецификации, ревью со стейкholders.

Orient ≠ правка артефакта без последствий. Если изменение модели меняет scope, контракт или приоритеты — фиксируйте через процесс изменений и 02.05.03 Управление объёмом (Scope Creep) и ожиданиями, а не только обновлением wiki. Spike (02.02.04 Прототипирование и UI-UX-исследования) — способ обновить модель эмпирически; результат — уточнённая концептуальная модель или отклонённая гипотеза с rationale.

Документирование: какая модель легла в основу решения

ADR (и decision log в том же формате) сохраняют не только «что решили», но какую модель считали верной: контекст → модель/допущения → решение → последствия для требований. Критично при смене аналитика и разборе инцидентов.

Протокол переключения моделей

Когда застряли, спор «на уровне терминов» или распознали искажение из 01.07 Когнитивные искажения и критическое мышление:

  1. Назовите текущую модель — «смотрим только на happy path процесса» (сюда же попадают ранние сигналы из §3).
  2. Перечислите 2–3 альтернативные оптики — из решётки или другого слоя L1–L3; для каждой — что должно отличаться на практике.
  3. Смените оптику — данные, мотивация, ограничения, инверсия, second-order.
  4. Сверьте с эмпирикой — интервью, логи, метрики; модель без проверки — гипотеза.
  5. Обновите артефакт — глоссарий, диаграмму, scope.
  6. Зафиксируйте границу — где модель не претендует на полноту.

Шаг 2 связывает протокол с критерием зрелости из §4 (три альтернативные модели).

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

ОшибкаКак проявляетсяПоследствие
Неявная единственная модель«Все думают как я / как разработка»Пропуск требований, конфликт на приёмке
Путаница типов моделиSRS = «как все понимают»; игнор ментальной модели оператораДефекты UX и интеграций при «формально верной» спецификации
Путаница модели и реальностиЖёсткая привязка к первой диаграмме; игнор новых фактовНеверные решения, scope creep «вслепую»
Overfitting фреймворкаВсё через user stories или только BPMNПотеря системного контекста и NFR
Игнор ограниченийМодель «идального процесса» без узкого местаНеприменимое to-be — см. 01.05 Теория ограничений и бережливое мышление
Локальная оптимизацияУлучшение подсистемы в ущерб end-to-end потокуРост cycle time, разочарование бизнеса
Analysis paralysisУточнение без проверяемой гипотезыЗадержка поставки; см. критерий «достаточности» в §3
Подмена модели жаргономGlossary без общего понимания поведенияКаждый использует термин по-своему
Уверенность вместо моделиAnchoring и confirmation bias под видом «логики»Игнор альтернатив — смените оптику по протоколу §3; см. 01.07 Когнитивные искажения и критическое мышление
«Галлюцинированная» модельАрхитектура или процесс, сгенерированные LLM без эмпирикиПравдоподобный, но ложный каркас — см. 11.03 Промпт-инжиниринг для аналитика

Системные ограничения подхода

Ментальные модели направляют внимание и могут слепить к альтернативам. Они не заменяют эмпирику: интервью, наблюдение, данные эксплуатации, эксперимент на стенде. LLM ускоряет черновик диаграммы или текста требования, но не подтверждает модель — проверка остаётся на вас.

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

Инверсия и second-order thinking не отменяют 02.04.01 Верификация и валидация (V&V) и критерии приёмки: модель должна быть проверяемой через сценарии и метрики.

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

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

Книги и обзорные материалы

  • The Nature of Explanation — Kenneth Craik (ранняя формулировка ментальных моделей как внутренних «малых моделей» реальности)
  • Mental Models: Towards a Cognitive Science of Language, Inference, and Consciousness — Philip Johnson-Laird
  • Thinking in Systems — Donella Meadows (системная ментальная модель; leverage points — см. 01.01 Понятие системы и системного подхода)
  • The Design of Everyday Things — Don Norman (различение ментальной модели пользователя и концептуальной модели системы)
  • Mental Models and User Experience Design — Nielsen Norman Group: https://www.nngroup.com/articles/mental-models/
  • A Guide to the Business Analysis Body of Knowledge (BABOK) — IIBA: https://www.iiba.org/standards-and-resources/babok/ (задачи elicitation, specify, validate как точки проявления скрытых моделей)

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