Как подготовить ТЗ на разработку игры для аутсорс-команды

Начните не с механик, а с общей картины проекта

Разработчику важно сначала понять, что за продукт перед ним.

Фраза «нужна стратегия для мобильных устройств» почти ничего не говорит о реальном объёме работы. Это может быть небольшая single-player игра на несколько часов или большой live-service проект с серверной частью, экономикой и постоянными событиями.

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

Если игра уже существует, стоит сразу сказать, что готово. Например, есть ли репозиторий, рабочий prototype, art, backend или только концепция.

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

Референсы нужны, но они не заменяют описание

Почти в любом игровом ТЗ появляются названия других игр.

Это нормально. Референс иногда объясняет идею быстрее нескольких абзацев текста.

Проблема возникает, когда написано только: «бой как в игре A, интерфейс как в B, прогрессия как в C».

Подрядчик не знает, какую именно часть системы вы имеете в виду.

Например, «бой как в Dark Souls» может означать управление, stamina, темп, lock-on, анимационные окна или просто ощущение тяжёлых ударов.

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

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

Опишите основной игровой цикл

Если подрядчик не понимает core loop, ему сложно оценить почти всё остальное.

Достаточно простого описания того, что игрок делает большую часть времени.

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

Уже из этой короткой схемы начинают появляться вопросы к системам прогрессии, сохранениям, UI и контенту.

Для сложного проекта можно дополнительно показать несколько типичных игровых сценариев. Но делать полноценное описание каждого возможного действия на этом этапе необязательно.

Главное — чтобы внешняя команда понимала, вокруг чего строится игра.

Механики лучше описывать через поведение

Техническое задание становится значительно полезнее, если вместо названия функции объясняет, как она должна работать.

Допустим, в документе есть пункт «инвентарь».

Само слово ничего не говорит о сложности.

У одного проекта это список из двадцати предметов. У другого — сетка, drag-and-drop, категории, stack, durability, экипировка, сортировка, фильтры и синхронизация с сервером.

Поэтому каждую важную систему лучше описывать с позиции игрока.

Что он может сделать? Какие существуют ограничения? Что происходит после действия? Где сохраняется состояние?

Не нужно сразу определять архитектуру. Это уже задача разработчиков. От заказчика прежде всего требуется понятное продуктовое поведение.

Отдельно зафиксируйте платформы и технические ограничения

Функционально одинаковая игра может потребовать совершенно разной работы на PC, смартфоне и консоли.

Поэтому целевые платформы нужно указывать сразу.

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

То же касается движка.

Если технология уже выбрана, это стоит зафиксировать. NoPanic, например, отдельно работает с разработкой игр на Unityи Unreal Engine.

Но если движок ещё не определён, необязательно выбирать его только ради ТЗ. Лучше описать требования продукта, а технологическое решение принять после технического анализа.

Multiplayer нужно описывать подробнее, чем кажется

Фраза «будет мультиплеер» способна изменить оценку проекта в несколько раз.

Поэтому сетевую часть лучше не оставлять одним пунктом.

Подрядчику нужно понимать хотя бы формат игры. Сколько участников находится в сессии? Есть ли matchmaking? Можно ли создавать приватные комнаты? Что происходит при разрыве соединения? Нужен ли dedicated server?

На первой версии документа не обязательно иметь готовую сетевую архитектуру.

Но бизнес-требования к multiplayer должны быть понятны. Иначе две команды могут оценивать под одним названием совершенно разные системы.

Не забудьте про контент

Частая ошибка игрового ТЗ — подробно описать функции и почти ничего не написать о количестве контента.

При этом именно контент способен стать одной из крупнейших частей бюджета.

Нужно понимать хотя бы порядок цифр: это пять персонажей или пятьдесят, три уровня или тридцать, десять видов оружия или несколько сотен предметов.

Необязательно фиксировать окончательные числа на годы вперёд.

Но подрядчик должен понимать масштаб первой версии.

Если значительную часть составит визуальный production, его можно передать отдельной команде игровых художников, однако и ей потребуется понимать объём и требования к ассетам.

Что писать про графику

Фразы «красивая 3D-графика» недостаточно.

Гораздо полезнее приложить несколько референсов и объяснить желаемый уровень качества.

Реалистичный персонаж для крупного плана и стилизованный герой мобильной игры могут оба называться «3D-персонажем», но production у них совершенно разный.

Важно также указать, что уже существует.

Если есть concept art, UI-kit, готовые модели или style guide, подрядчик должен увидеть их до оценки.

Если визуальное направление ещё предстоит разработать, это также должно быть частью scope, а не неожиданностью после старта.

Обязательно отделите первую версию от идей «на потом»

Игровое ТЗ очень быстро разрастается.

В процессе обсуждения появляется ещё один режим, система кланов, achievements, редактор персонажа и несколько дополнительных платформ.

Если всё это оказывается в одном документе без приоритетов, подрядчик вынужден считать максимальный объём.

Гораздо удобнее разделить обязательный scope первой версии и возможные дальнейшие функции.

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

Этот подход особенно полезен для prototype и MVP. В статье об объёме игрового прототипа подробно разобрано, почему ранняя версия должна прежде всего проверять гипотезу, а не пытаться имитировать весь будущий продукт.

Зафиксируйте не только задачу, но и результат

Подрядчику важно понимать, что он должен передать в конце этапа.

Формулировка «разработать систему боя» оставляет слишком много вопросов.

Нужно ли только реализовать механику? Должна ли она быть встроена в основную игру? Входит ли UI? Нужно ли тестирование? Какая документация требуется?

Эти условия лучше согласовать заранее.

Необязательно описывать Definition of Done на несколько страниц. Но момент завершения задачи должен быть понятным обеим сторонам.

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

Нужно ли указывать бюджет в ТЗ

Если есть реальный диапазон бюджета, скрывать его не всегда полезно.

Он помогает подрядчику понять ограничения проекта и предложить подходящий scope.

Например, одну идею можно реализовать как небольшой prototype, MVP или полноценный production. Без финансового ориентира студия может потратить время на оценку варианта, который изначально не подходит заказчику.

При этом бюджет не должен заменять декомпозицию.

Фраза «у нас есть пять миллионов, скажите, какую игру можно сделать» — это уже скорее запрос на discovery и product development, а не обычное техническое задание.

Срок релиза тоже влияет на решение

Если у проекта есть жёсткая дата, её необходимо назвать до оценки.

Например, игра должна быть готова к выставке, маркетинговой кампании или запуску на конкретной платформе.

В таком случае команда будет строить scope с учётом дедлайна.

Иногда правильным решением становится уменьшение первой версии, а не попытка ускорить весь production за счёт увеличения команды.

Чем раньше подрядчик узнает о реальном ограничении, тем меньше шанс, что этот разговор произойдёт уже за месяц до релиза.

ТЗ не обязано отвечать на все вопросы

Это, пожалуй, самое важное правило.

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

Лучше прямо обозначить вопрос как открытый.

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

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

В каком виде передавать ТЗ аутсорс-команде

Формат документа вторичен.

Это может быть Notion, Google Docs, Confluence или другой инструмент, с которым удобно работать обеим сторонам.

Гораздо важнее, чтобы существовала одна актуальная версия.

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

После старта документацию всё равно придётся обновлять.

Поэтому ТЗ лучше воспринимать не как документ, который подписали и забыли, а как начальную точку для production.

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

Что в итоге должно дать хорошее ТЗ на разработку игры

Хорошее ТЗ на разработку игры не отвечает на каждый технический вопрос заранее.

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

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

Открытые вопросы можно вынести в discovery. Будущие идеи — оставить за пределами первой версии.

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

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