Карта игры для жизненных ситуаций

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

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

---

Карта игры: пять вопросов вместо чтения мыслей

Для первой версии карты достаточно ответить на пять вопросов:

1. Кто участники?
   Кто в этой ситуации способен принять решение, которое существенно меняет итог?

2. Какие у каждого ходы?
   Что каждый реально может сделать сейчас, а не в идеальном мире?

3. Что для них важно?
   Какие последствия они хотят получить или избежать?

4. В каком порядке принимаются решения?
   Кто действует первым, кто отвечает, а кто выбирает, не зная чужого решения?

5. Что кому известно в момент выбора?
   Какие факты общие, какие видит только одна сторона, а что вообще неизвестно никому?

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

Карта отвечает не на вопрос «кто прав?», а на более полезный вопрос:

При каких вариантах действий у участников возникают именно такие стимулы?

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

---

Сначала задайте границы сцены

Жизненная ситуация обычно слишком велика, чтобы картировать её целиком. Возьмём фразу: «У нас конфликт между командами из-за релиза». Это ещё не игра, а заголовок для десятка разных игр.

Нужно сузить рамку. Например:

В среду команда продукта просит платформенную команду выделить инженера на критичный инцидент до релиза в пятницу.

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

Хорошая граница звучит так: кто принимает какое решение, к какому моменту и в каком контексте.

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

---

1. Участники: ищите право влиять, а не громкую должность

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

В нашей сцене минимальная карта может включать:

• команду продукта, которая запрашивает помощь;
• платформенную команду, которая решает, как ответить;
• руководителя, если он вправе перераспределить людей или изменить приоритет.

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

Полезный тест:

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

Если да — включите в карту. Если нет — отметьте его как условие, ресурс или фон.

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

---

2. Ходы: только реальные и наблюдаемые варианты

После участников выпишите доступные действия. Формулируйте их нейтрально и конкретно.

Плохая запись:

• Команда продукта: «быть ответственной».
• Платформенная команда: «помочь или саботировать».

Это уже моральный вывод, а не описание вариантов.

Лучше:

Участник	Реальные ходы в текущей сцене
Команда продукта	Сформулировать запрос с данными; снизить объём релиза; эскалировать приоритет; отложить релиз
Платформенная команда	Выделить инженера; выделить консультацию на ограниченное время; отказать; предложить другой срок
Руководитель	Подтвердить текущие приоритеты; временно перераспределить ресурс; перенести дедлайн

Ход должен удовлетворять трём условиям:

• его можно сделать в рассматриваемый период;
• участник действительно имеет на него право или ресурс;
• он отличается по последствиям от других ходов.

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

Не надо делать список бесконечным. Для первого разбора обычно хватает двух-четырёх содержательных вариантов у участника. Если вариантов десять, объедините близкие: «дать полную помощь», «дать ограниченную помощь», «не помогать сейчас».

---

3. Интересы: за позицией почти всегда стоит несколько критериев

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

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

Для примера:

Участник	Возможные интересы
Команда продукта	Устранить инцидент; не сорвать релиз; не остаться единственной виноватой; получить предсказуемый срок
Платформенная команда	Не ухудшить надёжность основной системы; не перегрузить инженера; сохранить приоритеты; не поощрять постоянные ложные срочности
Руководитель	Снизить общий риск для бизнеса; справедливо распределить дефицитный ресурс; не создать опасный прецедент

Здесь важно различать факты и гипотезы. Фраза «платформенная команда не хочет помогать» почти ничего не объясняет. Более точная версия:

Предположение: команда опасается, что выделение инженера сорвёт её обязательство по безопасности. Это нужно проверить.

Карта не даёт лицензии говорить за других. Наоборот, она показывает, какой вопрос стоит задать: «Какой риск для вашей команды создаёт помощь сегодня?» или «Что должно быть верно, чтобы вы согласились на два часа консультации?»

---

4. Очередность: видим ли мы чужой ход до своего?

Одни и те же участники и интересы могут образовать совершенно разные игры из-за порядка действий.

В нашем примере возможна последовательная ситуация:

1. Команда продукта формулирует запрос.
2. Платформенная команда видит содержание запроса и отвечает.
3. Руководитель подключается только при эскалации.
4. Команда продукта решает, принять предложенный формат помощи или менять план релиза.

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

Последовательность важна по двум причинам:

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

Однако первый ход не всегда означает власть. Если первый участник обязан действовать вслепую, а второй свободно отвечает, преимущество может оказаться у второго. На этом уроке достаточно аккуратно зафиксировать порядок; разбирать прогнозы чужого ответа мы будем в следующем модуле.

---

5. Информация: что известно, что скрыто и что является догадкой

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

Общее знание

Это то, что известно обеим сторонам и, по возможности, известно, что известно обеим:

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

Частная информация

Это то, что пока известно лишь одному участнику:

• команда продукта знает реальную стоимость задержки для клиента;
• платформенная команда знает, что у её инженера уже идёт серьёзный инцидент;
• руководитель знает, что завтра появится временный подрядчик.

Неопределённость

Это не «секрет другой стороны», а то, чего пока не знает никто достаточно надёжно:

• насколько быстро удастся локализовать проблему;
• сколько пользователей затронуто;
• появится ли обходное решение.

В карте полезно писать такие пункты прямо: «неизвестно». Это часто важнее, чем придумывать мотивы.

---

Дерево и таблица: две формы одной карты

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

На схеме «не атаковать» сразу приводит к результату $(0,0)$. Если первый игрок атакует, ход переходит ко второму. Его ответ определяет один из двух итогов: $(-2,-8)$ при принятии боя или $(3,-3)$ при отступлении.

Пока не нужно решать, какой исход «выберут рациональные игроки». Для карты важнее научиться читать структуру:

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

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

---

Собираем карту целиком: «критический запрос перед релизом»

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

Элемент карты	Черновая запись
Граница ситуации	В среду решается, получит ли команда продукта помощь платформенной команды для устранения инцидента до релиза в пятницу
Участники	Команда продукта; платформенная команда; руководитель при эскалации
Правила и ограничения	Один дежурный инженер; действующий SLA; релиз нельзя переносить без согласования; решение нужно сегодня
Ходы команды продукта	Подать обоснованный запрос; уменьшить scope релиза; эскалировать; перенести релиз
Ходы платформенной команды	Выделить инженера; дать ограниченную консультацию; отказать с обоснованием; предложить более поздний слот
Интересы команды продукта	Стабильный релиз, скорость устранения, снижение риска для клиента, предсказуемость
Интересы платформенной команды	Надёжность платформы, управляемая нагрузка, выполнение собственных обязательств, защита от ложной срочности
Порядок	Сначала запрос, затем ответ платформы; после отказа или спорного ответа возможна эскалация; затем корректировка плана релиза
Общая информация	Дедлайн релиза, доступный ресурс, регламент эскалации
Частная или неясная информация	Реальный ущерб от задержки; текущая загрузка инженера; вероятность быстрого workaround; причины прежних срочных запросов

Обратите внимание на практический эффект. Вместо формулы «платформа опять блокирует релиз» появляется более содержательный разговор:

• Что именно делает запрос критическим?
• Какая минимальная помощь снизит риск?
• Что платформа потеряет при полном выделении инженера?
• Можно ли обменять полный отказ и полную помощь на промежуточный вариант: диагностику, временный обход или уменьшение объёма релиза?

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

---

Карманный шаблон для любой ситуации

Скопируйте этот шаблон в заметки. Одна карта должна помещаться на экран телефона или одну страницу.

Сцена: какое конкретное решение разбираю и до какого момента?
Участники: кто реально выбирает?
Правила: какие ограничения, права и дедлайны заданы?
Ходы: какие два-четыре реальных варианта есть у каждого?
Интересы: что каждый пытается получить, сохранить или избежать?
Порядок: кто действует раньше; кто отвечает; кто выбирает вслепую?
Информация: что известно всем, что известно только некоторым, что неизвестно?
Непроверенные предположения: какие пункты я сейчас лишь предполагаю?

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

---

Итоги

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

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

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

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