Групповая ошибка планирования

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

«Я понятия не имею, пойдет дождь или нет, – говорит она. – Как бы то ни было, мы не можем знать наверняка».

Теперь выходит Уверенный Боб. Он недолго смотрит вверх, улыбается, словно наслаждаясь шуткой, понятной только ограниченному кругу людей. Он поворачивается к группе и уверенно объявляет: «Дождя не будет. Не беспокойтесь».

Группа естественным образом выбирает Боба. Боб получает последователей, одобрение и социальный статус. Алису называют слабой, глупой, нерешительной или ленивой, хотя ее ответ и был более точным.

Это групповая ошибка планирования. Люди естественным образом тянутся к лидерам, которые, как им кажется, уверенно смотрят в будущее, даже если это ви́дение будущего не соответствует реальности.

Чтобы не попадаться на эту удочку, достаточно поймать Боба на том, что он оказался неправ. Как только это случится несколько раз, люди перестанут его слушать. Но такие выводы в геймдизайне не так очевидны, как в прогнозе погоды. В геймдизайне трудно сразу связать причину и следствие, результаты могут проявляться годами, и за это время происходит так много, что мы забываем о своих прогнозах. В обычной жизни, когда мы можем оценить результат такого «предсказателя» практически сразу, наши инстинкты в конечном итоге заставляют нас не доверять Уверенному Бобу. Но в современных задачах дизайна происходит иначе. У нас нет такой подушки безопасности. Таким образом, стереотипы относительно Уверенных Бобов остаются, а подушка безопасности (проверка результатов) – нет. Стереотипы не сбалансированы.

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

Эффект хиндсайта

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

В 1972 году исследователь Барух Фишофф спросил людей, что может произойти во время предстоящей дипломатической поездки президента Никсона в Китай. Будет ли Никсон встречаться с Мао Цзэдуном? Произойдет ли значительный дипломатический прогресс? Он спросил о вероятности этих событий, а также о 13 других.

Когда Никсон вернулся, Фишофф снова попросил тех же людей сказать, с какой вероятностью событие будет иметь определенный исход. Эффект хиндсайта был очевиден. Если чей-то прогноз оказывался верным, человек говорил, что был увереннее в своем ответе, чем это было на самом деле. Если же прогноз оказывался неверным, то он преуменьшал степень своей уверенности. Они скорректировали свои воспоминания, преувеличивая свою способность предвидеть, как все произойдет. Постфактум процесс разработки игр всегда выглядит более логичным и контролируемым, чем это было на самом деле. Наш мозг автоматически редактирует хаос процесса разработки, превращая его в нашей памяти в чистую историю. Когда мы рассказываем о нем другим, мы еще сильнее осуществляем упрощение. Бесплодная трата времени время на тангенсы, бездумные ошибки, ужасные недопонимания и монотонные дни оттачивания работы – все это отпадает, а история становится детской сказкой. На самом деле я описал подобные истории в этой книге.

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

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

Протокол тестирования

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

Цель плейтестинга состоит не в том, чтобы выявить технические проблемы или собрать данные о маркетинге, а в том, чтобы понять, как работает геймдизайн в действии. Это значит, что нужно дать поиграть в игру обычным людям и посмотреть, где дизайн работает, а где – нет. Где игроки в замешательстве? Где слишком легко или слишком сложно? Достаточно ли сбалансирована игра? Есть ли вырожденные стратегии? Понимают ли игроки нарратив?

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

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

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

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