Что такое техническое задание на деловую игру и зачем оно нужно
Техническое задание (ТЗ) на разработку корпоративной деловой игры — это формализованный документ, который описывает требования заказчика к будущему продукту: его цели, содержание, формат, методологическую основу, технические параметры и ожидаемые результаты. По сути, ТЗ выступает мостом между бизнес-задачей компании и творческо-методической работой разработчиков.
Качественно составленное техническое задание решает сразу несколько практических задач. Во-первых, оно фиксирует единое понимание проекта всеми сторонами и снимает риск «додумывания» требований. Во-вторых, служит юридической основой договора и точкой опоры при приёмке работ. В-третьих, позволяет адекватно оценить бюджет и сроки, а также сравнить предложения разных подрядчиков на сопоставимых условиях.
В отличие от ТЗ на ИТ-продукт, документ на деловую игру требует особого внимания к педагогическому дизайну, психологическим и групповым процессам, бизнес-контексту и эмоциональной составляющей участников. Это гибрид методического, организационного и продюсерского документа.
Кто участвует в разработке техзадания
На стороне заказчика в подготовке ТЗ обычно задействована проектная группа из нескольких ролей. Заказчик-инициатор (руководитель направления, для которого создаётся игра) формулирует бизнес-задачу и определяет ожидаемый эффект. HR- или T&D-специалист отвечает за связь игры с компетенциями, программами обучения и оценочными процедурами. Внутренний эксперт (носитель предметной экспертизы — продаж, производства, безопасности, финансов) обеспечивает достоверность содержания. Представитель бизнес-подразделения подтверждает реалистичность кейсов, а закупщик или юрист отвечают за корректность формулировок в коммерческой части.
Со стороны разработчика к диалогу по ТЗ обычно подключаются методолог, сценарист, гейм-дизайнер и продюсер. Их задача — задавать заказчику уточняющие вопросы, помогать переводить размытые пожелания в измеримые требования и предупреждать о методологических рисках на ранней стадии.
Подготовительный этап: сбор исходных данных
До того как сесть писать текст ТЗ, необходимо собрать фактуру. Опыт показывает, что чем тщательнее проведён диагностический этап, тем меньше итераций потребуется на стадии разработки. Минимальный объём исходных данных включает описание бизнес-ситуации, которая стала поводом для запуска игры, актуальные данные о целевой аудитории (численность, должности, опыт, средний возраст, география), внутренние документы по компетенциям и стандартам, а также примеры реальных рабочих кейсов и типичных ошибок сотрудников.
Параллельно полезно зафиксировать ограничения: корпоративные ценности и культуру (что точно нельзя транслировать в игре), требования к визуальному стилю, конфиденциальные данные, которые нельзя выносить во внешние материалы, и ранее проведённые обучающие мероприятия по теме. Если игра встраивается в более масштабную программу развития, нужно понимать её место в общей логике: где она стоит — перед обучением, после него или в роли аттестационного инструмента.
Структура технического задания
Универсального шаблона ТЗ не существует, но устойчивая практика выработала достаточно стабильный набор разделов. Документ обычно включает: общие сведения о проекте, цели и задачи, описание целевой аудитории, формат и продолжительность, методологическую концепцию, требования к сценарию и игровой механике, контенту и материалам, технические и организационные требования, требования к фасилитации и дебрифингу, критерии оценки результатов обучения, требования к отчётности, состав поставляемых артефактов, сроки и этапы работ, порядок приёмки и коммерческие условия.
Полезно сразу разделять обязательные требования и пожелания (must have и nice to have). Это позволяет подрядчику предложить оптимальные решения внутри бюджета и при необходимости честно сообщить, какие из «пожеланий» придётся вынести во вторую очередь.
Формулирование целей и задач игры
Это самый важный и одновременно самый часто провальный раздел ТЗ. Формулировки уровня «развить лидерские качества» или «улучшить коммуникацию» не работают — они слишком абстрактны и не позволяют проверить результат. Цель должна быть привязана к измеримому бизнес-эффекту или поведенческому изменению.
Грамотный подход — формулировать цели по принципу «после игры участники смогут / будут делать / перестанут делать». Например: «после игры руководители среднего звена смогут проводить встречи по обратной связи по модели SBI без избегания неприятных тем», «участники будут учитывать показатель оборачиваемости запасов при принятии решений о закупках», «менеджеры по продажам перестанут предлагать скидку как первый аргумент в переговорах». Такие формулировки сразу задают и сценарные ситуации, и критерии оценки.
Помимо обучающих целей, имеет смысл фиксировать сопутствующие — диагностические (выявить уровень компетенций), мотивационные (вовлечь в новую стратегию), интеграционные (познакомить сотрудников после слияния подразделений) или имиджевые (продемонстрировать ценности компании). Их явное указание помогает разработчику расставить акценты.
Описание целевой аудитории
Качество игры напрямую зависит от того, насколько точно разработчик представляет себе игроков. В ТЗ нужно описать аудиторию по нескольким срезам. Демографические и должностные характеристики: уровни должностей, функциональные роли, опыт работы, средний возраст. Профессиональный контекст: какие задачи решают ежедневно, какие инструменты используют, с каким уровнем стресса и автономии работают.
Не менее важны установки и психологический портрет: насколько участники привыкли к игровому формату, как относятся к обучению вообще, есть ли «уставшая» от тренингов аудитория или, наоборот, новички. Стоит указать количество участников за одну сессию, минимальный и максимальный размер группы, возможность смешанных групп (по уровням, подразделениям, городам). Если планируется тиражирование игры на десятки или сотни групп, это нужно отметить сразу — масштабируемость влияет на архитектуру решения.
Формат и игровая механика
В разделе о формате описывается верхнеуровневая «оболочка» игры. Прежде всего — тип: настольная, павильонная, выездная, цифровая (онлайн или мобильное приложение), гибридная, симуляция в формате роль-плей, бизнес-симуляция с расчётной моделью, квест, стратегическая или штабная игра. Каждый формат имеет свои сильные стороны и ограничения, и заказчику полезно описать своё видение, но оставить разработчику пространство предложить альтернативу с обоснованием.
Далее фиксируется длительность одной сессии (с разбивкой на раунды, перерывы, дебрифинг), требования к ведущему (один фасилитатор или команда), а также общая логика игровой механики на уровне принципов: командная или индивидуальная конкуренция, наличие экономической модели, элементы случайности, прогрессия сложности, система обратной связи внутри игры. Если у заказчика есть референсы — игры или симуляции, которые понравились или, наоборот, не подошли, — их обязательно стоит указать с пояснением «что именно зацепило» или «что не сработало».
Требования к сценарию и контенту
Сценарная часть — это смысловое ядро игры. В ТЗ важно зафиксировать, в каком сеттинге будет разворачиваться действие: реалистичный (компания-аналог заказчика), метафорический (космическая станция, средневековое княжество, остров), исторический или фантастический. Метафорический сеттинг хорошо работает, когда нужно снизить защитные реакции участников и дать возможность взглянуть на привычные ситуации со стороны.
Следует указать обязательные содержательные блоки: какие темы, модели, инструменты должны быть отработаны в ходе игры (например, конкретная модель переговоров, алгоритм принятия решений, методика расчёта unit-экономики). Параллельно — стоп-лист: темы, формулировки, ситуации, которые недопустимы (политика, религия, конкуренты, чувствительные внутренние конфликты). Также важно описать тональность: серьёзная деловая или с элементами юмора, динамичная или вдумчивая, соревновательная или кооперативная.
Отдельным пунктом идут требования к локализации и адаптивности: возможность проведения на разных языках, замена кейсов под разные подразделения, версии для разных уровней опыта.
Методологическое обоснование
Серьёзный заказчик ожидает от разработчика не просто «красивой игры», а методологически обоснованного продукта. В ТЗ стоит прописать требование к описанию педагогического дизайна: на каких теоретических моделях строится обучение (цикл Колба, таксономия Блума, теория опыта, поведенческие модели), как обеспечивается перенос навыков в реальную деятельность, какие инструменты пост-игровой поддержки предусмотрены.
Также важно описать требования к структуре дебрифинга — этапу разбора игрового опыта, на котором формируется большая часть образовательного эффекта. Должны быть указаны его минимальная длительность, обязательные вопросы или модели разбора, формат раздаточных материалов для участников и методические рекомендации для ведущих.
Технические и организационные требования
В этой части собираются все «физические» параметры решения. Для офлайн-игр: размеры и состав комплекта, материалы изготовления, износостойкость, требования к упаковке, тиражность, удобство логистики и хранения. Для цифровых игр: поддерживаемые устройства и браузеры, требования к скорости интернета, интеграция с корпоративным LMS, SSO, требования к информационной безопасности и обработке персональных данных, нагрузочные характеристики (сколько одновременных пользователей выдерживает платформа).
Отдельно фиксируются требования к помещениям и оборудованию (площадь, рассадка, проектор, флипчарты, звук), к численности и квалификации фасилитаторов, к программе обучения внутренних тренеров заказчика (train the trainer), к технической и методической поддержке после внедрения. Если предполагается передача прав на использование игры — указываются модель лицензирования (бессрочная, по числу запусков, по числу пользователей), территория и состав передаваемых исходников.
Критерии оценки результатов
ТЗ должно отвечать на вопрос: как мы поймём, что игра удалась. Здесь полезно опираться на многоуровневые модели оценки обучения (например, модель Киркпатрика). На первом уровне — реакция участников (NPS, CSI, открытые комментарии). На втором — усвоение знаний и моделей (тесты до и после, контрольные кейсы внутри игры). На третьем — изменение поведения в работе (наблюдение, обратная связь от руководителей, оценка 360). На четвёртом — бизнес-результаты (динамика конкретных метрик подразделения).
Для каждого уровня в ТЗ фиксируются ожидаемые значения, методы измерения и зона ответственности (что замеряет разработчик, что — внутренняя служба заказчика). Не менее важны критерии приёмки самого продукта: визуальное качество, соответствие сценария согласованной концепции, корректность методологии, успешное прохождение пилотных сессий, отсутствие критических багов в цифровой части.
Бюджет, сроки и этапы работ
Разработка корпоративной деловой игры — итеративный процесс, и попытка втиснуть его в один монолитный срок почти всегда приводит к проблемам. Корректнее разбивать проект на этапы с промежуточной приёмкой: концепция и сценарная заявка, детальный сценарий и методическая записка, прототип (бумажный или цифровой), внутреннее тестирование, пилотная сессия с целевой аудиторией, доработка по итогам пилота, финальное производство и обучение фасилитаторов.
По каждому этапу в ТЗ фиксируются срок, состав поставляемых артефактов, форма приёмки и условия оплаты. Бюджет полезно структурировать по статьям: методическая разработка, дизайн и иллюстрации, производство комплектов, разработка цифровых компонентов, лицензии на сторонние материалы (шрифты, музыка, изображения), пилотные мероприятия, обучение внутренних тренеров, авторский надзор и поддержка. Такая разбивка позволяет управлять расходами и видеть, где можно гибко двигаться по объёму, а где экономия приведёт к падению качества.
Типичные ошибки при составлении ТЗ
Первая и самая распространённая ошибка — подмена бизнес-цели формой решения. Заказчик сразу пишет «нам нужна настольная игра про лидерство», ещё до того как сформулировал, какое именно поведение должно измениться. В результате подрядчик вынужден угадывать смысл, а заказчик — переделывать концепцию после первой демонстрации.
Вторая ошибка — отсутствие критериев успеха. Если ТЗ не содержит ответа на вопрос «как мы поймём, что игра работает», на приёмке начинаются субъективные споры о вкусе. Третья — избыточная детализация механики при отсутствии содержательных требований: заказчик подробно описывает количество карточек и цвет жетонов, но не объясняет, какие управленческие решения должны принимать игроки.
Часто встречаются также игнорирование особенностей фасилитации (игра «без ведущего» в корпоративном контексте редко даёт нужный эффект), недооценка пилотной стадии, отсутствие чёткой модели передачи прав и поддержки после внедрения, а также завышенные ожидания по срокам — желание получить готовый продукт за две-три недели почти всегда оборачивается компромиссом по качеству.
Чек-лист готовности технического задания
Прежде чем отправлять ТЗ подрядчикам, полезно прогнать его по короткому чек-листу. Сформулирована ли бизнес-задача, ради которой создаётся игра, и измеримый эффект от её решения. Описаны ли цели на уровне поведения участников, а не общих компетенций. Описана ли целевая аудитория с точки зрения должностей, опыта, установок и численности. Указаны ли формат, длительность, размер группы, ограничения по логистике и помещениям. Прописаны ли обязательные содержательные блоки и стоп-лист тем.
Зафиксированы ли требования к методологии, дебрифингу и переносу навыков в работу. Описаны ли технические требования (для цифровых игр — отдельно по безопасности и интеграциям). Заданы ли критерии оценки результата на нескольких уровнях. Разбит ли проект на этапы с промежуточной приёмкой и привязаны ли к ним сроки и оплаты. Описаны ли условия передачи прав, гарантийной и методической поддержки. Если на все эти вопросы ТЗ отвечает однозначно, документ готов к выходу на рынок — и шансы получить сопоставимые, реалистичные предложения от разработчиков существенно повышаются.