Главное отличие деловых или серьезных игр (serious games) от других игр состоит в том, что деловые игры ставят на первое место решение конкретной задачи, в то время как развлечение, которое связано со всеми играми, является второстепенным. Это не значит, что деловая игра должна быть скучной. Вовсе нет, без должной толики «фана» такая игра не вовлечет игрока, не создаст нужный уровень азарта, драйва, концентрации, желания победить, — всего того, что позволяет сделать игру сильным инструментом, в том числе и для решения задач.
И вот тут в полной мере показывает свою силу высказывание, что грамотно поставленная задача — это 50% решения. Периодически наблюдаю пренебрежение к этапу постановки задачи как со стороны заказчика, так и со стороны разработчиков. Смею предположить, что это одна из причин появления откровенно слабых игровых решений. В своей практике разработки деловых игр я пришел к определенному алгоритму постановки подобных задач. Этим алгоритмом и хочу поделиться в данной статье.
Если кратко, то последовательность выглядит следующим образом:
- Озвучивание задачи заказчиком;
- Постановка задачи разработчиком;
- Предложение гипотезы решения;
- Разработка концепции игрового решения;
- Заключение договора на разработку и реализацию решения;
- Разработка игрового решения;
- Реализация игрового решения.
Наблюдаемая мною ошибка заключается в том, что в стремлении как можно быстрее получить результат, 2 и 3 шаги пропускаются или им уделяется крайне мало внимания. Чаще всего это связано с довольно простыми причинами: сжатые сроки, желание поскорее получить договор, привычка работать со знакомыми концепциями.
Однако если не пожалеть сил на эти два важных шага, то качество игровых решений возрастает многократно. Ниже я попробую прояснить суть этих шагов.
На первом шаге заказчик озвучивает нам задачу так, как сам ее понимает. Это похоже на постановку задачи клиентом автосервиса: “У меня машина сломалась”. Прежде чем бросаться на автомобиль с гаечным ключем, опытный механик расспросит клиента в чем суть поломки, что не так в поведении автомобиля. Прежде чем сообщать о сроках и стоимости ремонта, он внимательно осмотрит состояние механизмов, проведет диагностику и предложит один или несколько вариантов устранения неполадки.Так же, на мой взгляд, должен поступать профессиональный разработчик деловых игр.
Поэтому на втором шаге важно посмотреть на задачу глазами разработчика. Причем, важно это делать совместно с заказчиком, поскольку в процессе формулирования задачи потребуется выяснение дополнительной информации и нюансов, о которых заказчик, возможно, даже не задумывался. А мы, как разработчики, часто имеем дело с объектами и связями, которые без заказчика никак не можем “пощупать” и оценить.
Какие задачи решают деловые игры?
Для начала разберемся с какими задачами способны справляться деловые игры. Условно можно разделить эти задачи на три большие группы:
- Передача информации игрокам;
- Получение информации от игроков;
- Исследование реальной ситуации на игровой модели.
Чуть более пристально посмотрим какие задачи входят в каждую из групп.
Передача информации игрокам
В эту группу входят все задачи, которые связаны с информированием и обучением участников, а также изменением их поведения.
В случае информирования, нам достаточно того, что информация, передаваемая игрой была запоминающейся, отложилась в голове у участников. Это может быть демонстрация новой корпоративной культуры или новых стандартов; презентация нового продукта; объяснение организационной структуры или бизнес-процессов или даже игра для знакомства сотрудников между собой.
В случае обучения нам важно, чтобы участник не только получил информацию, но и выработал или попрактиковал в процессе игры некоторые умения, которые в будущем можно перевести в навыки. Это наиболее распространенные задачи в данной группе, связанные с обучением конкретным вещам: управление финансами; организация производства; коммуникация; выявление потребностей; стратегическое планирование; системное мышление и многое другое.
В случае изменения поведения задача связана с убеждением участника изменить свое текущее поведение или стратегию. Сюда относятся такие задачи как: улучшение взаимодействия между отделами; переход на новые стандарты взаимодействия; вовлечение в проектную деятельность; содействие изменениям или реорганизации. Это довольно сложные, но от того интересные задачи, в которых в полной мере раскрывается сила игр как инструмента.
Получение информации от игроков
В эту группу входят все задачи, связанные с оценкой персонала или соискателей, диагностикой организации.
В случае оценки персонала или соискателей, необходимо получить информацию об умениях, навыках, установках, характере, стратегии поведения и других качествах одного или нескольких участников. Это могут быть задачи на оценку кандидатов на групповом собеседовании, оценку кадрового резерва для составления плана развития и т.д.
В случае диагностики организации, необходимо выявить общие характерные черты в стратегии поведения, реакции на события, внутреннего и внешнего взаимодействия у некоторой репрезентативной группы участников. Такие игры часто используются в начале консалтинговых проектов, для быстрого определения слабых и сильных мест организации, поиска точек роста.
Исследование реальности с помощью игровой модели
В эту группу входят задачи, которые помогают в сжатой форме получить информацию о достаточно крупной системе, проверить стратегические решения или бизнес-процессы. Это самая сложная группа задач, требующая от разработчика глубокого изучения моделируемой области. Однако пользу игр при решении данных задач сложно переоценить, поскольку именно в этом случае возможно получение в игре опыта, который в реальности весьма дорогостоящ или сопряжен с высоким риском.
В случае тестирования процессов и решений, внимание сосредотачивается на нюансах самих процессов, возможных сбоях, столкновениях интересов, узких местах, других штатных и внештатных ситуациях. Такие игры используются при разработке и внедрении изменений в компании, проверки разработанных бизнес-процессов.
В случае изучения реальности, главным становится наиболее адекватное моделирование той области реальности, законы и ответы на действия которой нам интересно изучить. Такие игры полезны в качестве составляющей для форсайтов, стратегических сессий, процесса поиска решений в сложных и неоднозначных ситуациях.
И, как разработчику, на первом этапе постановки задачи нужно понять к какому типу задачи относится поступивший от заказчика запрос. Однако одного понимания типа задачи совершенно недостаточно.
Как игры решают задачи?
Вне зависимости от типа задачи, можно представить работу, которую нужно совершить с помощью игры, как перевод ситуации или участника из некоего исходного состояния в некоторое желаемое состояние. Далее я буду объяснять подход на примере решения задачи по изменению поведения участников, что не умаляет его применимости для решения всех остальных описанных выше задач.
Пример исходного состояния из практики
Одна крупная производственная компания поставила задачу: нужно изменить поведение руководителей отделов относительно внедрения изменений, которые затрагивают сразу несколько подразделений.
Ситуация такова, что есть проектная группа, перед которой поставлена задача ввести в эксплуатацию новую установку и начать производство нового типа продукции. Осуществление этого проекта затрагивает интересы множества подразделений и отделов, так или иначе возникают проблемные места и задачи, которые нужно решать совместными усилиями, через договоренности между отделами. Однако текущее поведение руководителей отделов таково, что они не хотят решать эти задачи между собой и идти на уступки. Предпочитаемая стратегия в спорных ситуациях — твердо занимать свою позицию и перекладывать решение на вышестоящее начальство, апеллируя к нему как к защитнику своих интересов.
Пример желаемого состояния из практики.
Заказчик хочет, чтобы руководители отделов начали больше коммуницировать между собой по подобным проблемам, самостоятельно искать решения и компромиссы, обращаться к вышестоящему начальству только в случаях, когда действительно требуется вмешательство и внутренними ресурсами проблема никак не решается.
Как же игры помогают переходу из исходного состояния к желаемому?
В книге Jesse Schell “The Art of Game Design” дано хорошее определение игре, как инструменту, который позволяет формировать опыт.
Задача разработчика деловой игры состоит в том, чтобы сделать игру, играя в которую участник получит или проявит определенный опыт. Этот опыт в свою очередь и позволит перейти от исходного состояния к желаемому.
Но для этого мало просто столкнуться с определенным опытом в игре, нужно его присвоить, понять. И в этом помогает фасилитация или иная другая форма работы с полученным при помощи игры опытом. Поэтому деловые игры зачастую неотделимы от тренера или фасилитатора, который помогает осознать все то, что произошло с участником в процессе игры.
Комплекс действий, применяемых для решения поставленной задачи, который содержит в себе игру или в основе которого лежит игра, я называю игровым решением.
Для разработки игрового решения нужно понимать:
- Какой опыт должен получить участник во время игры?
- Как и в какой форме будет происходить присвоение опыта участниками?
Если второй вопрос — зона ответственности тренера или ведущего игры, то первый — это главный вопрос для разработчика, на нем и сосредоточимся.
В случае задачи по изменению поведения, нам необходимо через игровой опыт показать участнику преимущества желаемого поведения над исходным. Только в этом случае участник действительно захочет изменить свое поведение. А для этого нам нужно самим разобраться в плюсах и минусах того или иного поведения.
Первый вопрос, на который мы должны дать ответ: В чем причина исходного состояния?
В случае с поведением руководителей из приведенного примера, нам нужно понять почему они предпочитают текущее поведение? В чем его выгода для них?
После продолжительной беседы с заказчиком удалось понять, что текущее поведение мотивировано опасениями за свой участок должностных обязанностей. У каждого подразделения, а соответственно и у руководителя этого подразделения, есть зона ответственности и KPI за который с него спросит вышестоящие руководство. Подавляющее большинство проблем, возникающих в рамках проекта по установке нового оборудования проблем, связаны со снижением этого KPI.
Например, поставку сырья для нового оборудования со склада невозможно организовать по существующему маршруту. Для организации поставок придется перебросить часть сотрудников на новый участок работ, что, соответственно, снизит текущую производительность, которая и фигурирует как KPI подразделения. Не желая снижения эффективности, руководитель отдела обращается к начальнику по персоналу и требует нанять в его подразделение дополнительных людей. В свою очередь, KPI начальника по персоналу завязан на численность персонала и фонд оплаты труда. Если будут наняты новые сотрудники, то ему придется отвечать за это перед вышестоящим начальством. На лицо противоречие, попав в которое оба руководителя перекладывают решение вопроса на плечи начальства, при этом каждый настаивает на том решении, которое не приведет к снижению его KPI.
Иногда понять детали и причины исходного состояния удается на первой же встрече с заказчиком в течении десятка минут. Однако порой на это уходит гораздо больше времени.
Второй важный вопрос, на который нам нужно ответить: Возможно ли желаемое состояние?
К сожалению, иногда желание заказчика бывает неосуществимо по объективным причинам. И в таких случаях лучше отказаться от проекта, чем надеяться на чудо при высоких репутационных рисках.
Если говорить о задачах по изменению поведения, то можно грубо разделить их на три ситуации:
Первая ситуация состоит в том, что люди придерживаются текущего поведения по той причине, что они не знают о возможности вести себя иначе. Это самая простая ситуация и для ее разрешения достаточно с помощью игры показать им иную модель поведения. Увидя преимущества новой модели поведения люди сами с удовольствием перейдут на нее.
Вторая ситуация гораздо сложнее и связана с тем, что даже если участники знают о существовании альтернативной модели поведения, она оказывается проигрышной в ситуации, когда остальные участники взаимодействия придерживаются прежнего поведения.
Третья ситуация — это ситуация в которой желаемое поведение в любом случае будет невыгодно участнику ввиду внешних обстоятельств. Как бы не хотелось заказчику, крайне сложно заставить человека поступать в ущерб своим интересам.
Если описанный выше пример рассмотреть через призму теории игр, то получаем почти классическую ситуацию.
Есть несколько “игроков”, которые имеют некоторый ресурс — свое текущее значение KPI. Чем больше этого ресурса у игрока, тем выше его сиюминутный выигрыш (премии, поощрения). Чем меньше — тем выше шансы на проигрыш (штраф, увольнение). Так же есть некий общий для всех проект, в случае выполнения которого всех ждет выигрыш (предприятие станет увереннее чувствовать себя на рынке). Если же проект не состоится, то всех ждет поражение (в долгосрочной перспективе предприятие окажется под угрозой закрытия из-за нерентабельности). Для того, чтобы проект состоялся, в него нужно вложить некоторое количество ресурсов от игроков.
Текущая стратегия поведения игроков — сохранять и приумножать свой ресурс, не подвергая себя риску проиграть из-за вложений в проект.
Желаемая стратегия поведения игроков — совместные вложения ресурсов в проект ради достижения отдаленного выигрыша.
Взглянув на ситуацию, становиться понятно, что это как раз второй случай, когда изменение поведения только одним участником приведет к его поражению. Если меньшинство выберет стратегию вложения в проект, а другие предпочтут сохранять свои ресурсы, то высока вероятность, что даже если проект состоится, в конечном счете выиграют от этого те, кто предпочел в него не вкладываться.
На этапе разработки это условие важно понимать. Если мы предложим в игре некоторую стратегию поведения, люди в нее поверят, прибегнут к ней, а в результате пострадают, то они потеряют доверие не только к вам, как к ведущему или разработчику, но и к играм в целом, как к полезному источнику информации.
В общении с заказчиком узнаем, что небольшие потери в KPI всех участников процесса вполне допустимо, если без этого невозможно осуществить проект. При этом важно, чтобы это падение было более-менее равномерно распределено по подразделениям, а не сосредоточилось на одном или двух.
Предыдущие два вопроса помогают нам найти ответ на третий: какой опыт нужен для перехода из исходного состояния в желаемое?
В нашем случае это опыт совместного поиска возможностей минимизировать потери в KPI и равномерно распределить эти потери по участникам. Опыт того, что такие решения возможны и они, в дальней перспективе, выгодны всем участникам. Однако если кто-то из участников процесса сохраняет прежнюю стратегию, то он, несмотря на краткосрочный выигрыш, создает в долгосрочной перспективе проблему всем, и себе в том числе.
После того, как становится понятным, какой опыт участники должны получить в игре, задачу можно считать поставленной.
Алгоритм постановки задачи на разработку деловой игры
Кратко опишем полученный алгоритм в виде вопросов, на которые нужно дать ответ:
- Каково исходное состояние?
- Каково желаемое состояние?
- Какова причина исходного состояния? В чем его выгода?
- Возможно ли желаемое состояние?
- Какой опыт спровоцирует переход от исходного состояния к желаемому?
Задача для разработчика формулируется в виде опыта, который он должен передать участникам с помощью деловой игры
Задача поставлена, что дальше?
Следующим этапом идет разработка гипотезы игрового решения, которая должна ответить на вопрос: Каким образом можно передать требуемый опыт?
Возможность ответить на данный вопрос напрямую зависит от опыта и кругозора разработчика. Необходимо представить ситуацию, пережив которую, игроки получат требуемый опыт. Важно отметить, что гипотеза игрового решения — это в большой степени предположение о том, что пройдя через определенную игровую ситуацию, мозг участников, с учетом всех особенностей восприятия и их текущей картины мира, сформирует и усвоит интересующий нас опыт.
По мере возможности, заказчику озвучивается несколько гипотез, из которых совместными усилиями выбирается та, что сработает с наибольшей вероятностью. Присутствие заказчика при выборе рабочей гипотезы важно, поскольку он гораздо лучше знает свои участников и особенности их восприятия.
В случае описанного ранее примера, была выбрана гипотеза о том, что игрокам нужно пережить в форме симуляции ситуацию, максимально приближенную к реальности. Т.е. фактически проиграть за несколько часов все этапы внедрения изменений, сталкиваясь при этом с возможными трудностями и необходимостью находить компромисс. В игре должна оставаться возможность действовать привычным методом, однако такое поведение с высокой долей вероятности приведет к поражению. При этом нужно позволить игрокам, в случае неудачи, возвращаться назад во времени и менять свои решения.
Получение рабочей гипотезы позволяет обозначит общие черты игры и перейти созданию концепции игрового решения, которая ответит на вопрос: Как будет происходить игра?
Ответ на этот вопрос уже конкретизирует условия по площадке, количеству участников, доступности материальных и временных ресурсов, сроках, бюджете, реквизите, роли тренера и фасилитатора, программе мероприятия и т.д.
Концепция игрового решения уже является относительно конкретным предложением по решению задачи, поставленной заказчиком. Ну а далее следует заключение договора, разработка и реализация решения.
Надеюсь, я убедил Вас в важности подробного изучения ситуации перед предложением концепции решения. Поскольку, в противном случае, высок риск оказаться в ситуации механика, который в качестве решения проблем с автомобилем всегда предлагает поменять колеса или перебрать коробку передач.
Юрий «Tordenson» Исаев
2017.06.15
