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

Зачем деловой игре сильное ТЗ и чем оно отличается от обычной игры

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

Ключевая связка, которую нужно зафиксировать в техническом задании (ТЗ): бизнес-цель → механика игры → метрики результата. Если цель не сформулирована, ТЗ превращается в набор разрозненных пожеланий: «добавьте уровни», «сделайте рейтинг», «сделайте красиво». В итоге получается игрушка, которая не меняет поведение сотрудников и не влияет на KPI.

Техническое задание на разработку деловой игры принципиально отличается от ТЗ на обычную мобильную или веб-игру:

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

Хорошее ТЗ экономит бюджет и время разработки: меньше доработок «по ощущениям», ниже риск конфликта «мы о таком не договаривались». А главное — игра начинает работать как управляемый инструмент развития, а не как разовая активность для галочки.

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

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

1. Вводная часть и цели проекта

• Формат проекта: мобильное приложение, веб-сервис, десктопное решение или офлайн-игра с цифровой поддержкой. Здесь же — целевые платформы (iOS, Android, веб-браузер, внутренняя сеть).
• Бизнес-цели: снижение времени адаптации новичков, рост конверсии в продажах, повышение NPS, снижение ошибок в документах и т.п. Формулировка должна отвечать на вопрос: «Как поймём, что игра себя окупила?»
• Ключевые показатели успеха: процент завершивших игру, средний балл по компетенциям, изменение KPI до/после, доля менеджеров, вышедших на план. Плохой вариант: «сделать интересную игру». Хороший: «повысить долю сотрудников, набравших >80% в оценке работы с возражениями».

1. Целевая аудитория и контекст использования

• Кто игроки: должность, стаж, цифровая грамотность. Менеджер в колл-центре и руководитель филиала по-разному воспринимают сложность, текст, интерфейс.
• Контекст: проходят ли игру самостоятельно, в группе с тренером, в рамках обязательного обучения или по желанию; используют рабочий ноутбук, личный смартфон или терминалы на производстве.
• Ограничения: доступ к интернету, максимальная длительность сессии (частый запрос — «сессии по 10–15 минут»), возможность ставить игру на паузу. Это критично для проектирования длины уровней и сохранения прогресса.

1. Игровая концепция и сценарий

• Основная метафора: симулятор переговоров, управление виртуальным филиалом, квест по спасению проекта, карточная игра с кейсами клиентов. Метафора должна быть понятна сотрудникам и соответствовать культуре компании.
• Тип геймплея: пошаговый или в реальном времени, линейный или с ветвлениями, одиночный или командный. Это определяет сложность разработки и нагрузку на сервер.
• Структура сценария: уровни, миссии, отдельные кейсы. Например: «5 модулей по 6 ситуаций в каждом, каждая ситуация — 3–5 решений игрока с разными последствиями».
• Примеры решений и последствий. Мини-кейс прямо в ТЗ: «Клиент сомневается в цене. Варианты: а) дать скидку; б) усилить ценность; в) перейти к альтернативному продукту. Для каждого варианта описать реакцию клиента и изменение показателей (прибыль, лояльность)».

1. Требования к контенту

• Типы контента: обучающие тексты, диалоги, озвучка, видеоинструкции, документы (шаблоны КП, чек-листы). Чем подробнее перечень, тем меньше сюрпризов на этапе наполнения.
• Ответственность: кто даёт экспертный материал (заказчик, внутренний методолог, сторонний консультант), кто адаптирует его под игровой формат.
• Реалистичность кейсов и терминология: в банковском, медицинском, промышленном сегменте ошибки в терминах бьют по доверию. В ТЗ стоит закрепить уровень допуска к упрощениям.

1. Функциональные требования

• Регистрация и авторизация: нужна ли интеграция с корпоративным каталогом, SSO, привязка к LMS или CRM.
• Логика прохождения: можно ли перепроходить уровни, предусмотрены ли подсказки, штрафы за неверные действия, ограничения по времени.
• Система оценивания: баллы, уровни, бейджи, рейтинг команд, пороги «зачёт/незачёт». Важно указать, какие действия сколько «весят» в очках.
• Отчётность: какие данные собираются (выборы игрока, длительность, число попыток, типичные ошибки), как выгружаются (CSV, Excel, API), нужны ли агрегированные отчёты по отделам.

1. Нефункциональные требования

• Платформы и устройства: поддерживаемые браузеры, минимальные версии ОС, работа офлайн/онлайн.
• Производительность: максимальное время отклика, одновременная нагрузка (например, до 2000 пользователей в период аттестации).
• Безопасность: работа с персональными данными сотрудников, соответствие внутренним политикам ИБ, уровни доступа для HR, тренеров и руководителей.
• Дизайн: фирменный стиль, язык интерфейса, требования по доступности (крупные шрифты, контрастность, озвучка для слабовидящих при необходимости).

1. Сроки, этапы, критерии приёмки

• Вехи проекта: прототип (пробный сценарий и базовые экраны), альфа-версия (полная механика без всех кейсов), бета (полный контент, тестирование), релиз.
• Для каждой стадии — что именно показывает подрядчик: сценарии, интерактивный прототип, тестовый доступ.
• Критерии приёмки: список сценариев тестирования, чек-листы (корректность подсчёта баллов, стабильность, отображение отчётов). Хорошая практика — приложить к ТЗ отдельный файл с тест-кейсами.

Пример фрагмента: ТЗ на разработку деловой игры для отдела продаж

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

1. Цели проекта (выдержка из ТЗ)

• Повысить долю менеджеров, выполняющих ежемесячный план продаж, с 40% до 60% в течение 6 месяцев после внедрения игры.
• Сократить среднее время вывода нового менеджера до первого подписанного контракта с 3 месяцев до 2.

1. Целевая аудитория

• Менеджеры по продажам в возрасте 22–35 лет, опыт активных продаж от 0 до 3 лет.
• Проходят игру на рабочем ноутбуке, параллельно работе в CRM, с возможностью прерывать сценарий на входящий звонок.

1. Игровая концепция (выдержка)

• Метафора: симулятор переговоров с разными типами B2B-клиентов (покупатель по цене, покупатель по качеству, «вечный сомневающийся», тендерный клиент).
• Каждый уровень — цикл: подготовка к встрече → диалог → работа с возражениями → фиксация договорённостей в CRM.
• Минимум 20 уникальных кейсов, отражающих ключевые сегменты клиентов по отрасли, размеру бизнеса и уровню лояльности.

1. Система оценивания

• Баллы за: корректный анализ потребностей (до 30%), выявление бюджета и лиц, принимающих решение (до 30%), закрытие сделки или получение следующего шага (до 40%).
• Дополнительная метрика за работу в CRM: штрафы за незаполненные поля, бонус за детальные заметки по встрече.
• Итоговый «портрет игрока» с разбивкой по компетенциям: установление контакта, выявление потребностей, работа с ценой, фиксация договорённостей.

1. Отчётность для руководителя отдела продаж

• Онлайн-дашборд: выполнение тренинговых «KPI» по каждому менеджеру, средние значения по командам.
• Выгрузка в Excel для сопоставления с фактическими продажами за период и последующей корреляции.

Обязательные элементы, которые стоит сохранить в любом ТЗ: чёткие цели с цифрами, описание аудитории и контекста, понятная игровая метафора, логика оценивания, требования к отчётности. Детали — типы клиентов, структура уровней, глубина интеграции с CRM или LMS — адаптируются под вашу отрасль и масштаб.

Как согласовать и использовать ТЗ: чек-лист для заказчика и команды

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

• Что проверить до подписания ТЗ
• Цели сформулированы измеримо: есть стартовые и целевые значения показателей.
• Целевая аудитория описана по должности, уровню навыков и реальному контексту использования игры.
• Игровая концепция понятна без жаргона: если убрать «геймификацию», ясно, какие действия будет делать пользователь и зачем.
• Минимальные требования к отчётности и интеграциям (LMS, HR-системы, CRM) перечислены явно, а не «по умолчанию».
• Как использовать ТЗ в процессе разработки
• На каждую новую идею задавать вопрос: «Она приближает нас к целям из ТЗ или просто нравится команде?»
• Все изменения фиксировать в истории версий: дата, суть правки, кто согласовал. Не переписывать разделы тихо, чтобы не потерять договорённости.

Если у компании нет опыта формализации требований к деловой игре, легко потратить бюджет на эффектную, но бесполезную «игрушку». Мы, как команда, которая делает мобильные приложения, веб-сервисы, CRM-системы, игры и интернет-магазины, помогаем перевести бизнес-задачи в рабочее ТЗ и довести проект до результата. Оставьте заявку через форму на сайте — обсудим ваши цели и подготовим структуру технического задания именно под вашу деловую игру.