Геймшторминг. Игры, в которые играет бизнес - читать онлайн книгу. Автор: Дейв Грей, Санни Браун cтр.№ 40

МЕТОДИКА

Упражнение делится на три этапа: вводный этап, процедура создания коробки и ее «продажа».

Этап первый – планирование

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

✔ возможные названия идеи;

✔ возможные потребители, конечные пользователи или покупатели;

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

Это может быть как привычная для группы идея, так и нечто совсем новое. Смыслом данного этапа является получение информации, «достаточной» для начала работы.

Этап второй – создание коробки

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

✔ Как это называется?

✔ Для чего это нужно?

✔ Какова рекламная формула этого?

✔ Каковы самые яркие свойства этого? А выгоды?

✔ Какое изображение сможет выделить это из ряда других продуктов?

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

Этап третий – продажа

Все команды и участники должны получить возможность выступить перед группой и «продать» результаты своего труда. Имеет смысл установить регламент выступлений и учредить приз самой успешной команде.

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

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

Если по результатам игры лучшему «продавцу коробок» полагается приз, определяйте лучших путем голосования. Заранее обеспечьте достаточное количество призов, чтобы хватило всем членам команды-победителя.

СТРАТЕГИЯ

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

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

Это упражнение под разными названиями упоминается в различных источниках. Данная версия представляет собой адаптированное упражнение Product Box из книги Люка Хохмана (Luke Hohmann) Innovation Games: Creating Breakthrough Products Through Collaborative Play. Другие источники указывают в качестве родоначальников концепции Джима Хайсмита (Jim Highsmith) из компании Cutter Consortium и Билла Шекельфорда (Bill Shackelford) из Shackelford & Associates.

ЦЕЛЬ ИГРЫ

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

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

КОЛИЧЕСТВО УЧАСТНИКОВ

Небольшие группы.

ПРОДОЛЖИТЕЛЬНОСТЬ ИГРЫ

Час и более, в зависимости от сложности существующего «наилучшего сценария».

МЕТОДИКА

Наилучший сценарий

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

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

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

✔ Что случится, если этим попытается воспользоваться группа обезьян?

✔ Что случится, если выдернуть вилку из розетки? Как именно подключается устройство?

Наихудший сценарий

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

✔ Сделать – внести изменения в конструкцию или план, избежав таким способом проблем. В результате проблема исчезает.

✔ Переделать – обеспечить средства изменения действий в процессе их выполнения. Это может быть коррекция курса или амортизация воздействия ситуации.

✔ Вернуться назад – обеспечить средства полной отмены действий и возвращения в предшествующее состояние. Это полностью отменяет сценарий.

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