На проекте результат вашего решения зависит не только от логики требований, но и от того, как поступят другие участники — заказчик, команды, регулятор, вендор. Теория игр (game theory) даёт формальный язык для таких ситуаций: кто принимает решения, какие у них интересы, какая информация доступна и к какому исходу это ведёт. Статья отвечает на вопрос: как моделировать конфликты и кооперацию между стейкхолдерами без тяжёлой математики и не подменить анализ манипуляцией. Это фундаментальная рамка раздела 01 — для бизнес- и системного аналитика; тактика переговоров — в 09.03 Управление конфликтами и переговоры, детали governance и паттернов решений — в 01.06 Принципы и паттерны проектирования решений.

1. Суть темы

Теория игр — рамка для описания ситуаций, где исход зависит от совместных решений нескольких игроков с разными интересами, ограниченной информацией и ожиданиями относительно поведения других. «Игра» здесь — не развлечение, а формальная модель: игроки, возможные ходы (стратегии), информация и выигрыши (payoffs) по исходам.

Для аналитика теория игр — не математика ради математики, а инструмент моделирования стратегического взаимодействия:

  • кто выигрывает и проигрывает при вариантах scope, архитектуры, приоритетов;
  • какой рациональный ответ у другой стороны, если вы зафиксируете решение X;
  • можно ли сдвинуть исход, изменив правила (процесс согласования, прозрачность данных), а не убеждая сильнее.

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

flowchart LR
    A[Игроки и интересы] --> B[Стратегии / опции]
    B --> C[Payoffs по исходам]
    C --> D[Равновесия и Парето-набор]
    D --> E[Изменение правил или информации]
    E --> F[Артефакты: decision log, governance]
    F -.->|следующий раунд| A

Ключевое различение для практики:

Диагностика проблемыИгровая модель
ВопросЧто не так и почему?Кто что выберет и к чему это приведёт?
ФокусПричины, gap, симптомыСтратегии, выигрыши, равновесия
Типичный контекст«Пользователи не могут закрыть кейс»«Две команды блокируют интеграцию — каждая выигрывает локально»
Соседняя тема01.03 Техники анализа проблемэта статья

Отличие от соседних тем раздела:

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

ПонятиеСуть для аналитика
ИграФормальное описание: игроки, стратегии, информация, payoffs по исходам
Стратегия (strategy)План действий игрока. Смешанная стратегия (вероятностный выбор ходов) в проектных моделях почти не нужна — достаточно знать термин: иногда команды чередуют приоритеты, чтобы скрыть истинный payoff («bluffing»); для прогноза обычно хватает чистых стратегий
Payoff (выигрыш)Ценность исхода для игрока: KPI, риск, политический капитал, time-to-market — см. 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)
Доминирующая стратегия (dominant strategy)Лучший ход независимо от действий других; если есть у всех — исход предсказуем. В большинстве проектных 2×2 доминирования нет — тогда ищите равновесие Нэша
Равновесие Нэша (Nash equilibrium)Профиль стратегий, где никто не выигрывает от одностороннего изменения своего выбора. Равновесий может быть несколько — выбор зависит от норм, истории и focal point
Парето-оптимальность (Pareto efficiency)Нельзя улучшить положение одного без ухудшения другого; база для поиска win-win в структуре стимулов (тактика переговоров — 09.03 Управление конфликтами и переговоры)
Кооперативная vs некооперативная играПереговоры с обязательными договорами vs самостоятельный выбор без принуждения к договору
Полная vs неполная информацияВсе знают структуру игры (common knowledge) vs скрытые типы, сигналы, асимметрия знаний
Повторяющаяся игра (repeated game)Серия взаимодействий; появляются репутация, санкции, долгосрочная кооперация — shadow of the future
Проектирование механизмов (mechanism design)Изменение правил игры под желаемый исход. Паттерны governance и форма решений — в 01.06 Принципы и паттерны проектирования решений; здесь — только вопрос «как сдвинуть равновесие правилами»

Соответствия в аналитической работе

Элемент моделиВ проекте аналитика
ИгрокиСтейкхолдеры, команды, регулятор, вендор, конкурент — см. 03.01.02 Моделирование контекста системы (Context Diagram) («игроки на границе системы»)
PayoffsKPI, риски, стоимость изменений, карьерные и политические последствия
ИнформацияПрозрачность backlog, оценок, зависимостей; асимметрия — частый источник провала согласований
Правила игрыRACI, Definition of Ready/Done, контрактные SLA, процесс эскалации и 02.05.02 Управление изменениями (Change Control Board)

Классические модели — якоря для интуиции

Дилемма заключённого (prisoner's dilemma). Индивидуально рациональный выбор каждого ведёт к худшему групповому исходу. На проекте — silo-метрики, локальная оптимизация, отказ от риска интеграции: каждая команда «выигрывает» по своему KPI, система проигрывает.

«Курицы» (chicken game). Взаимное «не уступлю» с риском взаимного проигрыша. Типично для публичных конфликтов стейкхолдеров и эскалации сроков релиза:

Сторона B: уступаетСторона B: не уступает
Сторона A: уступает(0, 0) — компромисс с потерями(+1, −2) — A проигрывает лицом
Сторона A: не уступает(−2, +1)(−3, −3) — срыв релиза, эскалация

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

Игра с нулевой суммой vs положительной суммой. «Делим пирог» vs «пирог можно увеличить». На проекте интеграция, автоматизация и снижение операционных затрат часто расширяют ценность, а не перераспределяют фиксированный бюджет — это структура стимулов, не переговорный приём; framing для заказчика — 09.07 Управление ожиданиями заказчика.

Аукционы и механизмы. Порядок ходов и видимость информации меняют исход — аналог процессов согласования: кто approves первым, что видно в roadmap, как эскалируется спор.

Коалиции (на уровне идей). Несколько продуктов или команд на одной платформе — вопрос, хватит ли каждому видимой выгоды, чтобы не сорвать объединение. При n > 2 игроках сначала найдите минимальную пару или тройку pivotal players — без кого сделка не живёт; моделируйте их 2×2, остальных выведите в контекст или veto. Академические Shapley value и core здесь — только интуиция «справедливого» распределения; расчёты не нужны, нужен явный разбор вкладов и выгод в decision log.

Мини-пример: дилемма интеграции

Две команды решают, вкладываться ли в общую интеграцию API. Упрощённая таблица payoffs (чем выше — тем лучше для команды):

Команда B: интегрируетсяКоманда B: не интегрируется
Команда A: интегрируется(+1, +1) — системная ценность(−1, +2) — A несёт cost, B free-rider
Команда A: не интегрируется(+2, −1)(0, 0) — status quo, технический долг растёт

Одношаговая игра. Рациональный выбор каждой стороны — не интегрироваться (0, 0): это равновесие Нэша, хотя (+1, +1) Парето-лучше для системы. Это не «плохие люди», а структура стимулов.

Повторяющаяся игра. Проект — серия релизов; «shadow of the future»: если сегодня free-rider, завтра вторая команда откажет в зависимости. Санкции (блокировка зависимостей, публичный статус интеграции) и репутация сдвигают рациональный расчёт: односторонний дефект становится дороже, кооперация — устойчивее.

Изменение правил. Общий KPI на сквозную метрику, поэтапная поставка с видимым win для обеих сторон, штраф за shadow IT — меняют payoffs так, что (+1, +1) становится равновесием или focal point. Провести смену governance — через 02.02.02 Воркшопы, фасилитация и совместные сессии; технический контекст интеграции — 09.06 Ведение переговоров с техническими командами.

Неполная информация — короткий кейс

Product owner заявляет «must have к релизу», но roadmap и capacity скрыты от смежной команды. Команда B трактует это как сигнал (signaling) высокого приоритета и уступает в споре по scope. После релиза выясняется, что фича была «nice to have». Модель: у PO два типа — срочный / несрочный запрос; публичное заявление — cheap talk: без costly signal или verifiable disclosure (видимый backlog, оценка, commit в roadmap) аналитик не должен обещать, что «раскрыли backlog — игра решена». Выход — изменить информационную структуру: общий видимый backlog, Definition of Ready с оценкой, а не спор о содержании при скрытых payoffs.

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

Где модель осмысленна

  1. Стратегический слой поверх stakeholder map — из 02.01.03 Анализ заинтересованных сторон (Stakeholder Map) берёте power/interest/influence, но сужаете до одной развилки и 2–3 игроков с payoffs; остальные — в veto, контекст или «фон» без строк в таблице. Поверх выбранных игроков строите матрицу исходов: что каждый получает при вариантах A/B/C; ищете равновесия и ловушки локального оптимума.
  2. Приоритизация и trade-offs — пакеты требований как переговорные позиции; поиск Парето-улучшений вместо победы одной стороны — см. 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) и динамику при смене правил — 02.05.02 Управление приоритетами в условиях изменчивости.
  3. Разрешение конфликтов требований — двух- или n-сторонняя игра; проверка: «если зафиксируем X, какой рациональный ответ другой стороны?» Тактика ведения переговоров — 09.03 Управление конфликтами и переговоры; здесь — структура стимулов.
  4. Governance и incentive design — изменение правил (кто approves, что видно в roadmap, как эскалируется) часто эффективнее убеждения; детали паттернов — 01.06 Принципы и паттерны проектирования решений, цепочки approval — 02.05.02 Управление изменениями (Change Control Board).
  5. Кросс-функциональные зависимости — повторяющаяся игра: сегодняшняя «победа» в споре снижает кооперацию завтра; учитывайте shadow of the future — срок проекта, серия релизов — 02.05.01 Управление зависимостями между требованиями.
  6. Системный и архитектурный контекст (SA) — platform team vs product team (кто платит за общую платформу), build vs integrate с вендором, согласование breaking change в API-контракте: игроки на границе системы — 03.01.02 Моделирование контекста системы (Context Diagram), правила версионирования и lifecycle — 03.05.07 Управление версионированием API и жизненным циклом. Продуктовая стратегия — 02.01.01 Определение бизнес-проблем и возможностей.
  7. Риски саботажа процесса — если процесс выгодно обходить, рациональный агент будет обходить; проверяйте совместимость incentives с желаемым поведением — 08.05 Управление рисками на этапе анализа.

Практический мини-процесс (без тяжёлой математики)

  1. Назовите игроков (≤ 5 для читаемости модели) — из stakeholder map; отдельно отметьте veto-holder (директор, архитектурный комитет). Для них payoffs «сверху» часто — mandate и risk appetite, а не KPI; таблица 2×2 — вводная для эскалации, а не замена решения сверху.
  2. Выписите стратегии/опции — не только «да/нет», но и отложить, эскалировать, урезать scope, обойти через shadow IT, наложить veto.
  3. Оцените payoffs — см. чеклист ниже; шкала −2…+2 уже полезна; помечайте уровень уверенности.
  4. Постройте таблицу 2×2 или дерево решений для ключевой развилки. При n > 2 — сначала выделите pivotal players (минимальная коалиция, без которой сделка не состоится).
  5. Найдите доминирующие стратегии (если есть), равновесия Нэша, Парето-набор. Если равновесий несколько, модель без focal point, истории и норм не даёт единственного прогноза — зафиксируйте сценарии или предложите координацию.
  6. Сформулируйте изменение правил или информации — прозрачность, общий KPI, поэтапная поставка — сдвигающее равновесие к системной цели.
  7. Выровняйте модель с участниками на воркшопе (common knowledge): все видят одну таблицу и допущения — 02.02.02 Воркшопы, фасилитация и совместные сессии. Shared model — профессиональная норма; weaponized framing (скрытая односторонняя модель для давления) — граница с 09.03 Управление конфликтами и переговоры.
  8. Зафиксируйте в артефактах: допущения, чувствительность («если payoff заказчика выше, исход …»); framing для steering — 09.07 Управление ожиданиями заказчика.

Мини-чеклист выявления payoffs (гипотезы → проверка через 02.02.01 Интервьюирование и анкетирование и 02.04.01 Верификация и валидация (V&V)):

  • Какой официальный KPI у игрока при каждом исходе?
  • Есть ли скрытые выгоды/риски: карьера, контроль budget, страх потери автономии?
  • Что игрок теряет при кооперации в краткосроке, даже если система выигрывает?
  • Меняется ли payoff, если игра повторяется (следующий релиз, следующий проект)?
  • Какая информация скрыта и как это меняет его выбор?
flowchart TD
    S1[1. Игроки + veto] --> S2[2. Стратегии]
    S2 --> S3[3. Payoffs]
    S3 --> S4[4. Таблица / дерево]
    S4 --> S5[5. Равновесия и Парето]
    S5 --> S6{Системная цель достигнута?}
    S6 -->|нет| S7[6. Изменить правила или информацию]
    S7 --> S4
    S6 -->|да| S8[7. Воркшоп + decision log]

Артефакты аналитика

АртефактСодержание
Таблица payoffs + сценарииДопущения и уровень уверенности — в decision log или раздел «Alternatives / Context» 10.01.13 Шаблон архитектурного решения (ADR)
One-pager «стратегическое взаимодействие»Для steering committee: игроки, ключевое равновесие, предложение по правилам
Incentive-compatible workflowПредложения по изменению процесса согласования — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями
Матрица исходов по scopeСвязка с 02.01.04 Определение границ решения (Scope Modelling); трассировка допущений к требованиям — 10.01.15 Шаблон матрицы трассировки

Комбинация с теорией ограничений

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

Граница применимости

Теория игр не заменяет elicitation, данные и пилоты — 02.02.01 Интервьюирование и анкетирование, 02.04.01 Верификация и валидация (V&V). Она структурирует гипотезы о поведении до и после сбора фактов.

Модель не нужна, если:

  • единственный ЛПР без оппозиции — нет стратегического взаимодействия;
  • чисто технический trade-off без разнесённых incentives (один владелец решения, общая метрика);
  • конфликт уже закрыт полномочиями — тогда таблица только для коммуникации, не для прогноза;
  • payoffs нельзя даже качественно оценить — модель остаётся иллюстрацией; зафиксируйте это явно.

В таких случаях достаточно 01.03 Техники анализа проблем или прямого согласования без формализации.

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

Ограничения метода

ОграничениеСледствие для практики
Упрощение реальностиЛюди не всегда рациональны; эмоции и давление не в таблице payoffs
Иерархия и vetoРешение «сверху» обходит таблицу; для veto-holder моделируйте mandate/risk appetite, а не KPI
Калибровка выигрышейБез данных модель — гипотеза, не прогноз; помечайте уровень уверенности
Много игроковСужайте до pivotal players и ключевой развилки
Неполная информацияCheap talk без verifiable disclosure не меняет равновесие; проверяйте сигналы данными
Common knowledgeНа реальном проекте не все знают одну модель — выравнивайте на воркшопе, иначе прогноз бесполезен
ЭтикаShared model с участниками — норма; скрытое одностороннее использование модели для давления — за пределами профессиональной практики

Типичные ошибки аналитика

  1. Считать игру нулевой суммой, когда можно расширить scope ценности — интеграция, автоматизация, снижение операционных затрат; framing — 09.07 Управление ожиданиями заказчика.
  2. Моделировать только одношаговую игру, когда взаимодействие повторяется — оптимизация под один релиз ломает долгосрочное сотрудничество между командами.
  3. Приписывать другим «свои» payoffs (projection bias) — см. 01.07 Когнитивные искажения и критическое мышление; проверяйте мотивы интервью и данными.
  4. Фиксировать стратегии слишком грубо — пропуск скрытых опций: эскалация, политическое veto, обход через shadow IT.
  5. Одно равновесие Нэша как «истина» — часто равновесий несколько; выбор зависит от focal point, норм, истории взаимодействий.
  6. Спор о содержании вместо redesign процесса — если структура стимулов токсична, убеждение не сработает; паттерны изменения правил — 01.06 Принципы и паттерны проектирования решений.
  7. Переусложнение — формальная модель без решения для backlog; для большинства кейсов достаточно таблицы 2×2 и явных допущений.

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

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

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

Книги и стандарты

  • Dixit A., Nalebuff B. The Art of Strategy — прикладное введение в игровое мышление для бизнеса и политики (обновлённая версия Thinking Strategically)
  • Brandenburger A., Nalebuff B. Co-opetition — кооперация и конкуренция одновременно; silo-KPI, платформенные коалиции
  • Osborne M. J. An Introduction to Game Theory — учебник с акцентом на intuition и примеры
  • Game Theory — Stanford Encyclopedia of Philosophy: https://plato.stanford.edu/entries/game-theory/

Статьи и справочные материалы

Курсы и учебные материалы