Автор Дима Coder 
Заказ технического задания (ТЗ) для гейм-аутсорса не просто набор требований, это ваш контракт с внешней командой, который определяет, во что вы инвестируете, какие риски принимаете и какой результат получите.
В индустрии Hi‑Tech, где игры часто становятся сложными программными продуктами с интеграциями, аналитикой и требованиями к облачной инфраструктуре, грамотное ТЗ - залог сохранения бюджета и сроков.
Я дам пошаговый гид по созданию ТЗ для гейм-аутсорса: от концепта и документирования механик до описания инфраструктуры, тестирования и передачи контента.
Всё написано живым языком, с конкретными примерами и практическими советами, которые помогут вам избежать типичных промахов и получить предсказуемый результат.
Цель и общий концепт проекта
Первое, с чего всегда нужно начать: чётко сформулируйте цель проекта. Это не "сделать игру", а конкретный бизнес-результат - привлечь N пользователей, получить LTV X, протестировать гибридную механику, запустить прототип для инвесторов и т.п.
Без ясной цели подрядчики не будут понимать приоритеты и баланс между качеством и скоростью.
Опишите целевую аудиторию, ключевые платформы (iOS, Android, PC, веб, консоли), жанр, уровень графики (2D пиксель-арт, 3D реализм), ориентировочную продолжительность разработки и желаемую модель монетизации (краш-модели: F2P + IAP, premium, подписка, ad-based).
Приведите примеры референсов - 2–3 игры, визуальные и геймплейные маяки, которые вы считаете близкими по духу. Например: "core RPG с элементами карточной боёвки, как Slay the Spire, но с мобильной камерой и микротранзакциями по модели Gacha".
Важно прописать KPI: DAU, ARPU, Retention D1/D7/D30, CPI, время до MVP, бюджетные лимиты. Аутсорс не просто "сделайте красиво", а "сделайте так, чтобы через 3 месяца после релиза ARPU был не меньше X". Чем точнее вы опишите метрики успеха, тем меньше недопониманий по результатам.
Функциональные требования! Механики и геймплей
Здесь детализируйте все ключевые игровые механики. Начните с ядра геймплея - что игрок делает каждую игровую сессию? Затем опишите вторичные системы: прокачка, экономика, крафт, PvP, PvE, социальные функции, достижения, челленджи.
Для каждой механики укажите примерный сценарий использования и ожидаемое поведение системы в крайних случаях.
Примеры формата: "Инвентарь: лимит 50 слотов, предметы имеют свойства { rarity, level, durability }. При попытке добавить предмета, если инвентарь полон - показывать окно с сортировкой и возможностью разрушить предметы. Предметы с rarity = legendary не могут быть авто‑удалены".
Опишите прогрессию (XP curve), экономику валют (золото, премиум‑валюта), источники дохода и sink'и (куда игрок тратит валюту). Приведите модель расчёта баланса: формулы награды за миссию, стоимость улучшений, вероятность выпадения редких предметов.
Например: "Уровень сложности 1 даёт 100±20 монет; стоимость улучшения оружия на +1 - 200*(1.15^уровень) монет".
Технические требования- движок, архитектура, интеграции
Техническая часть ТЗ - одна из самых важных. Укажите желаемый или обязательный движок (Unity, Unreal Engine, Godot), версии (Unity 2021 LTS и новее) и ограничения по используемым плагинам.
Если движок свободен, пропишите критерии выбора: мультиплатформенность, поддержка DOTS/ЕCS, наличие SRP, возможности для build‑серверов и CI/CD.
Опишите архитектуру клиента и сервера: нужно ли авторитетное серверное решение для боёв, синхронизация прогресса, облачные сохранения, масштабируемость, поддержка многопоточности.
Укажите требования по использованию облачных провайдеров (AWS/GCP/Azure), контейнеризации (Docker, Kubernetes) и требованиям к latency. Для Hi‑Tech проекта важно прописать требования к аналитике: интеграция с Firebase/Amplitude/Adjust/Segment, события, параметры и схема аналитики.
Не забудьте про CI/CD: автоматические сборки для тестеров, бета‑каналов, автотесты.
Пропишите требования к формату артефактов, подписыванию (iOS), автоматическому деплою на TestFlight/Google Play Internal. Также опишите требования к кросс‑платформенным сохранениям и методам миграции данных при апдейтах.
Архитектура данных, бэкэнд и безопасность
Если ваша игра использует серверную логику, онлайн‑режимы или хранит пользовательские данные, обязательно опишите требования к бэкенду: REST/GraphQL, WebSockets, RPC, авторизация (OAuth2, JWT), хранение состояния матчей, дедупликация транзакций.
Укажите требования к отказоустойчивости, резервному копированию и восстановлению данных (RTO/RPO).
Определите требования к безопасности: защита от читов (anti‑cheat), валидация на сервере, хранение персональных данных в соответствии с GDPR/CCPA, шифрование трафика (TLS 1.2+), защита секретов и ключей.
Для Hi‑Tech проектов часто необходима интеграция с SIEM или лог‑агрегатором (ELK/Datadog), чтобы иметь трассировку инцидентов.
Также важно прописать требования к нагрузочному тестированию: сценарии нагрузки (10k/100k/1M concurrent), целевая latency, RPS, способы масштабирования (horizontal autoscaling) и метрики мониторинга (CPU, memory, error rate, p95 latency).
Поставьте конкретные threshold'ы облегчит оценку подрядчиков и выбор архитектурных решений.
Графика, анимация и технические ограничения
Опишите артефакты, которые требуется создать: концепты, спрайты, 3D‑модели, шейдеры, анимации, VFX, UI/UX. Для каждого типа контента укажите технические требования: полигональность, размер текстур, формат (PNG, TGA, FBX), LOD‑система, наборы анимаций (idle, run, attack, death), требования по риггингу и экспорту.
Например: "Персонаж 3D: до 15k треугольников, текстуры 2048×2048 base+normal+ORM, skinned mesh с 30 костями".
Добавьте требования к стилю и гайдлайнам: палитра, типографика, сетки UI, адаптивность под разные разрешения, поведение элементов при локализации. Пропишите, что должны быть предоставлены исходники (PSD/Illustrator/Blender), экспортные пресеты и инструкции по интеграции в движок.
Не забудьте оптимизацию: требования по draw calls, batching, occlusion culling, правила использования шейдеров и пост‑эффектов. Для мобильных проектов укажите целевые девайсы и минимальные фреймрейты (например 30 FPS на low‑end, 60 FPS на high‑end), а также допустимые пики по памяти.
Контент-план, локализация и управление ресурсами
Контент не только арт и уровни, но и текст, озвучка, музыка и маркетинговые материалы. В ТЗ перечислите весь контент по пакетам и этапам: базовый (MVP), сезонный контент, бонусные наборы.
Для каждого блока укажите объёмы: количество уровней, количество диалогов, длительность саундтрека, число уникальных врагов и т. п.
Опишите требования к локализации: список языков, обязательные версии (английский, упрощённый китайский, японский, испанский), формат передачи текстов (XLIFF, CSV), система управления переводами (Crowdin/Localize).
Укажите требования к качеству перевода (native speakers, адаптация под культуру) и к озвучке (таймкоды, формат WAV 48kHz, нормированная громкость, согласование с NDA).
Также обязательно опишите требования к системе управления артефактами: репозиторий (Git LFS), менеджмент ассетов, naming conventions, CI‑скрипты для импорта ассетов в проект. Для Hi‑Tech проектов часто используют таблицы с метаданными (Excel/Google Sheets) и API для импорта/экспорта локализации и контента.
UX/UI и прототипирование
UX/UI - один из ключевых элементов, который определяет удержание пользователей.
В ТЗ укажите задачу по созданию интерактивных прототипов (Figma/Adobe XD) и сценариев использования для ключевых флоу: регистрация, первый уровень, магазин, система доната, настройки.
Опишите, какие элементы интерфейса должны быть кликабельны в прототипе и какие пользовательские тесты провести на ранних этапах.
Дайте требования по доступности: масштабирование шрифтов, контрастность, поддержка экранных читалок (если релевантно), удобство управления для разных типов устройств (тач, мышь+клавиатура, геймпад). Укажите требования к аналитике интерфейсов: трекинг кликов, funnel conversion, heatmaps для выявления узких мест.
Проработайте onboarding: сколько интерактивных туториалов, их длительность и уровень интерактивности. Включите требования к инструментам A/B‑тестирования интерфейсов и балансных изменений, чтобы можно было быстро тестировать гипотезы без перекомпиляции клиента.
Тестирование, QA и поддержка после релиза
Опишите план QA: виды тестов (юнит, интеграционные, e2e, автоматизированные, ручные), процессы приёмки задач, чек‑листы и критерии выхода на релиз. Для игр важны регресс‑тесты механик и производительности: укажите порог допустимых багов, blocking‑issues и policy по багфиксам.
Пропишите, как оформлять баги (Jira/YouTrack) и какие метаданные должны быть в репортах (лог, скриншот, шаги воспроизведения, приоритет).
Не забудьте про тестирование на разных устройствах и сетевых условиях: эмуляция плохого соединения, режимы оффлайн, тесты на переключение между сетями. В Hi‑Tech среде важны тесты безопасности, pentest и code review, особенно если игра интегрируется с финансовыми системами.
Опишите условия пострелизной поддержки: SLA на критические баги (например фикс в 48 часов), расписание патчей, hotfix‑процедуры и коммуникация с сообществом.
Часто аутсорсеры предоставляют fixed‑cost поддержку на первые 3 месяца - укажите это в ТЗ и требования к передаче знаний: документация, воркшопы, код‑ревью, обучение in‑house команде.
Управление проектом, сроки и договорные условия
Опишите модель взаимодействия: fixed‑price, time & material, milestone‑based. Укажите требования к регулярности отчётности: ежедневные стендапы, еженедельные демо, спринт‑ревью.
Установите критерии приёмки промежуточных этапов и описание артефактов, которые должны быть переданы на каждом mile‑stone (build, design docs, source files).
Пропишите сроки и промежуточные дедлайны с допустимыми отклонениями, а также штрафы/бонусы за срыв/раннюю сдачу. Договор должен включать пункты по интеллектуальной собственности (все права переходят заказчику), NDA, ответственность за утечку данных и условия расторжения.
Также не забудьте про бюджет: разбейте оплату по этапам, укажите валюту, условия выставления счетов, платежные гарантии и требования к учёту трудозатрат (timesheets). Пропишите обязательные документы, которые подрядчик должен предоставить: страхование ответственности, список ключевых сотрудников и их резюме, план замены специалистов.
Шаблоны, примеры и контроль качества ТЗ
Хорошее ТЗ должно быть не только полным, но и проверяемым. Приложите шаблоны артефактов: формат JSON/CSV для экспорта контента, примеры event‑треков для аналитики, шаблон баг‑репорта. Приведите чек‑лист приемки для каждого типа работ: код, графика, анимация, звук, бэкенд.
Проставьте критерии качества в терминах measurable outcomes: "FPS ≥30 на device X, memory ≤400 MB, p95 latency сервера ≤150 ms при 10k concurrent", "D1 retention ≥40% на бета‑тесте". Такие числовые цели позволят подрядчикам оценить риск и предложить архитектуру, а вам - объективно принимать работу.
В ТЗ полезно добавить примеры неудачных кейсов и lessons learned: например, "проект провалился из‑за неправильной экономики: валюта генерировалась быстрее, чем игроки её тратили, что привело к падению IAP".
Попросите у подрядчика план рисков и mitigations: замены ключевых людей, баги блокирующие релиз, срыв интеграций с партнёрами.
Советы по выбору подрядчика и оценке предложений
При выборе подрядчика не ориентируйтесь только на цену. Проверьте портфолио, оцените релевантные кейсы (жанр, масштаб проекта), попросите демо‑сборку или запись игрового процесса, уточните процессы разработки и политики QA.
Проверьте отзывы клиентов и запросите контакты для референсов.
Сравнивайте предложения по одинаковым критериям: сроки, состав команды, объем работ, риски, SLA.
Полезно провести short‑listing и технико‑коммерческое интервью: задавайте вопросы про архитектурные решения, опыт в оптимизации под платформы и пример проблем, которые подрядчик уже решал.
Если у вас несколько предложений, поставьте их в матрицу риска/выгоды: low‑cost/high‑risk vs mid‑cost/medium‑risk vs high‑cost/low‑risk.
Для фазы MVP часто выгоднее выбрать mid‑cost команду с сильным portfolio в конкретном жанре. А для Live Ops лучше брать подрядчиков с опытом поддержки и масштабирования проектов после релиза.
Готовые шаблоны и checklist для внедрения ТЗ
Ниже - минимальный набор документов и шаблонов, которые должны сопровождать ваше ТЗ: 1) Summary sheet - цель, KPI, основные сроки; 2) Feature list с приоритетами; 3) Tech stack и infra diagram; 4) Asset list с техническими требованиями; 5) QA checklist и acceptance criteria; 6) Соглашение по SLA и support plan.
Рекомендую приложить пример одной "фичи" в полном объёме: описание, user story, acceptance criteria, дизайн, данные для аналитики и тест кейсы. Это поможет подрядчику показать реальное понимание задания и сэкономит цикл согласований.
Формулируйте задачи по принципу "Given/When/Then" (acceptance tests), это даёт ясность и уменьшает scope creep. Например: "Given игрок находится на уровне 3, When он нажимает кнопку "Upgrade", Then валюта списывается, уровень предмета повышается и появляется визуальный эффект + звук".
Такие тест‑кейсы экономят время на QA и ускоряют оценку задач.
Наконец, держите ТЗ живым: редактируйте его на основе обратной связи, фиксируйте изменения через change requests и вносите поправки в сметы и сроки. Это уменьшит количество споров и позволит гибко реагировать на новые данные.
Если кратко: ТЗ для гейм‑аутсорса должно быть максимально конкретным в бизнес‑целях и KPI, достаточно детализированным в игровых и технических требованиях, и при этом предусматривать процедуры контроля качества, коммуникации и пострелизной поддержки.
Чем больше вы пропишите заранее - тем меньше сюрпризов и перерасхода бюджета.
Вопросы и ответы (опционально)
В: Сколько времени обычно уходит на подготовку такого ТЗ? О: В зависимости от масштаба - от 2 недель для простого мобильного прототипа до 2‑3 месяцев для крупной мультиплатформенной игры с онлайн‑инфраструктурой.
Лучше вложить пару недель на проработку, чем терять месяцы в согласованиях с подрядчиком.
В: Как оценивать стоимость разработки по такому ТЗ? О: Попросите несколько моделей оценки: high‑level T-shirt sizing, детализированные оценки спринтов, а также риск‑резервы. Сравнивайте не только сумму, но и coverage: что входит в цену и что требует доплаты.
В: Нужен ли собственный продюсер/PM при работе с аутсорсом? О: Да, обязательного. Without internal PM вы теряете контроль над приоритетами и рисками. PM нужен для коммуникации цели бизнеса, приоритизации фич и принятия решений по компромиссам.
В: Какие самые частые ошибки при составлении ТЗ? О: 1) Нечёткие цели и KPI; 2) Отсутствие требований по аналитике и мониторингу; 3) Недооценка инфраструктурных затрат; 4) Отсутствие плана поддержки после релиза.