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

Начинайте не с портфолио, а со своей задачи

Одна из частых ошибок — искать «хорошую игровую студию» вообще.

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

Допустим, вы делаете сетевой action на Unreal Engine. Наличие у подрядчика десяти выпущенных мобильных puzzle-игр говорит о том, что команда умеет доводить проекты до релиза. Но почти ничего не говорит о её способности построить multiplayer, работать с репликацией и оптимизировать игру под большое количество одновременно существующих объектов.

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

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

Смотрите на релевантность опыта, а не на количество проектов

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

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

Фраза «мы участвовали в разработке проекта» может означать что угодно: от создания нескольких моделей до полной разработки клиентской части.

Нормальный подрядчик способен довольно конкретно объяснить свою роль. Что было сделано с нуля? Что уже существовало до подключения команды? С какими проблемами столкнулись? За какие решения отвечали разработчики подрядчика?

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

Хорошая команда задаёт много вопросов ещё до оценки

Разработка игры почти никогда не оценивается нормально по одному предложению вроде «нужна мобильная RPG».

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

Перед адекватной оценкой обычно появляются вопросы. Какая платформа? Есть ли готовый дизайн? Нужен ли backend? Как устроена экономика? Сколько персонажей и уровней? Есть ли multiplayer? Кто делает art? Какая часть проекта уже существует?

По этим вопросам хорошо видно, как команда думает.

Опытный подрядчик обычно пытается сначала найти неопределённость и самые дорогие риски. Только потом появляется оценка.

Это не означает, что до старта нужны сотни страниц документации. Иногда достаточно короткого discovery или прототипа. Но оценка должна опираться хотя бы на понятные вводные.

Попросите объяснить, как будет устроена работа после старта

Продажа проекта и его разработка — две разные вещи.

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

Спросите, кто станет вашим постоянным контактом. Будете ли вы общаться непосредственно с разработчиками или только с менеджером? Как часто появляются сборки? Где ведётся backlog? Кто принимает технические решения? Как заказчик узнаёт, что задача начала выходить за первоначальную оценку?

Хороший процесс не обязательно должен быть сложным. Для небольшого проекта может хватить одного общего tracker, регулярного созвона и рабочей сборки раз в неделю.

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

Проверьте команду, которая действительно будет работать над игрой

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

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

Если проект технически сложный, имеет смысл познакомиться с tech lead. Если большая часть бюджета приходится на контент — с art lead. Если команда небольшая, можно провести короткий технический разговор непосредственно с разработчиком.

Это не должно превращаться в полноценное собеседование каждого человека.

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

Обсудите критерии готовности до начала разработки

Фраза «механика готова» для заказчика и подрядчика может означать совершенно разное.

Для одной стороны это рабочая функция в тестовой сцене. Для другой — полностью интегрированная система, проверенная QA, работающая на всех целевых устройствах и переданная вместе с документацией.

Чем крупнее проект, тем дороже становятся такие расхождения.

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

В NoPanic Studio этатема отдельно разобрана в материале про критерии приёмки работы внешней команды.

Не оценивайте подрядчика только по стоимости часа

Ставку удобно сравнивать, потому что это конкретное число. Но итоговая стоимость разработки зависит не только от неё.

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

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

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

Начните с ограниченного этапа

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

Безопаснее начать с этапа, у которого есть понятный результат. Например, с технического исследования, прототипа, vertical slice или отдельной системы.

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

Вы увидите, насколько реалистичны оценки, как команда сообщает о проблемах, как оформляет код, что происходит с дедлайнами и насколько легко принимать результат.

Если после первого этапа сотрудничество работает нормально, масштабировать его значительно проще.

Уточните, как передаются код и знания

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

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

До старта полезно договориться и о процессе передачи проекта.

Что произойдёт, если через полгода вы решите продолжать разработку своими силами? Какие доступы, инструкции и исходники получите? Потребуется ли отдельный период handover?

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

Обратите внимание на то, как команда говорит о рисках

Не каждый сложный вопрос имеет приятный ответ.

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

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

Напротив, полезно, когда команда заранее говорит: «Здесь есть риск», «Этот вариант увеличит сроки», «Мы бы сначала проверили это прототипом».

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

Отдельно проверьте подход к тестированию

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

До старта стоит понять, как устроен QA. Когда начинается тестирование? Кто проверяет новые функции? Есть ли регрессия? На каких устройствах запускаются сборки?

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

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

Важно не конкретное количество тестировщиков, а то, чтобы проверка результата вообще была частью процесса, а не появлялась за несколько дней до релиза.

Красные флаги при выборе подрядчика

Обычно проблемы становятся заметны ещё до подписания договора.

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

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

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

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

После нескольких встреч решение обычно становится проще, если не пытаться свести его к одной таблице со ставками.

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

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

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

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