Техническое задание на разработку деловой игры: пошаговое руководство

Зачем деловой игре продуманное техническое задание

Деловая игра в IT-формате — это не только «игрушка», а цифровой продукт: мобильное приложение, веб-сервис, модуль для LMS или гибридное решение, которое поддерживает очные сессии. Внутри одной системы сходятся обучение, геймификация, бизнес-логика, интеграции с HR‑ и CRM‑системами. Любая неточность в описании быстро превращается в дорогое недопонимание между заказчиком, методологом и разработчиком.

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

Чем ТЗ на деловую игру отличается от обычного ТЗ

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

Значимая часть документа посвящается целям и ожидаемому эффекту. Формулировка «повысить мотивацию продавцов» для ТЗ бесполезна. Рабочий вариант: «сократить среднюю длительность цикла сделки на 10 % за 6 месяцев за счёт тренировки обработки возражений на этапе сравнения с конкурентами». То же с целевой аудиторией: важно указать роли (линейные сотрудники, руководители, резерв), опыт, доступное время на обучение, уровень цифровой зрелости.

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

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

Подготовительный этап: что решить до написания ТЗ

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

Сначала — формулировка целей. Удобный набор вопросов:

• «Какую управленческую реальность мы моделируем?» (рынок, внутренний проект, работу отдела);
• «Какие решения участники должны научиться принимать?» (ценовые, ресурсные, коммуникационные);
• «По каким цифрам поймём, что игра сработала?» (NPS клиентов, конверсия, скорость внедрения изменений).

Пример доработки цели. Сырой вариант: «научить руководителей быть гибкими». Рабочий вариант для ТЗ: «оттренировать у руководителей среднего звена выбор управленческого стиля в ситуациях сопротивления изменениям, измеряем по доле команд, выполнивших проектные KPI после игры».

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

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

Отдельно фиксируются ограничения и условия:

• сколько людей в одной сессии и сколько параллельных групп;
• длительность партии (например, 60–90 минут) и всей программы;
• платформы: только веб, мобильное приложение под iOS/Android, модуль для корпоративной LMS;
• работа с данными: используются ли реальные показатели бизнеса, нужна ли анонимизация;
• диапазон бюджета и приоритеты: что входит в «обязательный минимум», а что в «вторую очередь».

Результат подготовительного этапа — короткий черновик на 1–2 страницы с ответами на эти вопросы. Его полезно показать HR, методологу, IT и владельцу бизнес-процесса, чтобы убрать противоречия ещё до выхода к подрядчикам. Из такого брифа уже можно разворачивать полноценное ТЗ.

Структура технического задания на разработку деловой игры

Ниже — базовая структура ТЗ с рабочими формулировками, которую удобно использовать как шаблон.

Раздел «Общие сведения и цели проекта»

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

• Неудачно: «Сделать интересную деловую игру по продажам».
• Лучше: «Создать деловую игру‑симуляцию работы отдела продаж для обучения менеджеров обработке возражений на этапе “сравнение с конкурентами”, с возможностью анализа типичных ошибок по итогам сессии».

Раздел «Целевая аудитория и сценарии использования»

Опишите роли (менеджеры, руководители, стажёры), их опыт и ограничения по времени. Дополнительно зафиксируйте сценарии использования:

• корпоративный тренинг на 20–30 человек с фасилитатором;
• самостоятельное прохождение в формате онлайн‑курса в LMS;
• часть программы кадрового резерва с обязательным отчётом в HR‑системе.

Важно указать, какие устройства у участников есть гарантированно (ПК, планшеты, смартфоны), есть ли стабильный интернет, можно ли устанавливать приложения.

Раздел «Игровая механика и сюжет»

Здесь фиксируется тип игры и базовая «игровая петля»: что делает участник, как видит результат, как получает обратную связь.

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

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

Раздел «Учебные результаты и метрики»

Задача — связать действие в игре с навыком и измеримым результатом. Пример формата:

• «Навык: работа с ценовыми возражениями. Игровое действие: выбор формулировки ответа клиенту в диалоге. Метрика: доля “успешных” ответов, рекомендованных методологом, и её связь с ростом конверсии в сделку через 3 месяца».

Сразу закладывайте два уровня показателей: внутриигровые (очки, уровни, рейтинги) и бизнес‑метрики, которые можно сопоставить с реальностью.

Раздел «Технические требования»

• платформы и устройства (десктоп, мобильные браузеры, нативные приложения);
• поддерживаемые браузеры и минимальные версии ОС;
• интеграции: CRM, ERP, HRM, LMS, BI‑системы для выгрузки аналитики;
• нагрузка: максимальное число одновременных пользователей, частота запусков в год;
• требования к безопасности и хранению персональных данных, место размещения серверов.

Раздел «Требования к интерфейсу и контенту»

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

• контент полностью со стороны заказчика;
• совместная разработка с методологом подрядчика;
• контент «под ключ» на основе ваших материалов.

Раздел «Этапы разработки, тестирование и приёмка»

Разбейте проект на этапы: прототип (игровая петля и один сценарий), пилот (игра на ограниченную группу), доработка, релиз. Для каждого этапа пропишите критерии готовности.

• Пример: «Игровая механика “переговоры по цене” считается принятой, если реализованы три уровня сложности, работает подсчёт баллов, есть расшифровка ошибок для участника и выгрузка статистики в Excel».

Проверка и доработка ТЗ: чек‑лист и взаимодействие с подрядчиком

Перед отправкой подрядчику пройдитесь по короткому чек‑листу. В ТЗ должно быть понятно:

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

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

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

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