Передача части разработки внешней команде часто вызывает один и тот же вопрос: что произойдёт с проектом, когда кодом, графикой или целым направлением начнут заниматься люди за пределами внутренней команды?
Опасение понятное. Никому не хочется через два месяца обнаружить, что подрядчик движется не туда, сроки разъехались, а оценить реальное состояние проекта можно только по сообщениям менеджера.
Но сама по себе работа на аутсорсе не означает потерю контроля. Проблемы обычно начинаются там, где подрядчику передали задачи, но не передали контекст, не определили точки проверки и не договорились, что вообще считается готовым результатом.
Поэтому вопрос «как передать игровой проект на аутсорс» лучше рассматривать не как передачу работы из одной компании в другую. По сути, нужно встроить внешнюю команду в существующий production так, чтобы заказчик продолжал видеть состояние проекта и принимать ключевые решения.
Сначала определите, что именно вы передаёте
Формулировка «отдаём разработку на аутсорс» слишком широкая.
В одном случае речь идёт о двух разработчиках, которые подключаются к существующему проекту. В другом подрядчик получает целый блок: например, портирование, backend или производство графики. Иногда внешняя команда берёт практически весь production.
От этого напрямую зависит способ управления.
Если внутренней команде просто не хватает ресурсов, можно подключить дополнительных игровых разработчиков и оставить управление внутри проекта.
Если подрядчику передаётся отдельное направление, у него уже может быть собственный lead и внутренний процесс. Тогда заказчику важнее контролировать не каждую задачу, а результат на согласованных точках.
Чем яснее эта граница определена до старта, тем меньше вероятность, что две команды начнут параллельно отвечать за одно и то же.
Передайте контекст, а не только техническое задание
Можно отправить подрядчику репозиторий, документацию и список задач, но этого часто недостаточно.
Внешняя команда должна понимать, что происходит с продуктом в целом. Какой ближайший релиз? Что сейчас является главным риском? Какие системы нельзя серьёзно менять? Где допустим компромисс, а где нет?
Представим, что подрядчику поручили оптимизировать загрузку сцен. Технически можно найти несколько способов решить задачу. Но выбор будет зависеть от того, планируется ли через два месяца полностью менять систему контента или текущая архитектура должна прожить ещё несколько лет.
Такие вещи редко очевидны из task tracker.
Поэтому вместе с техническими материалами стоит передать короткий контекст проекта. Не нужно создавать огромный документ. Иногда достаточно нескольких страниц, где описаны состояние продукта, ближайшие цели и ограничения.
Отдельно NoPanic разбирает этот процесс в материале «Как передать проект подрядчику и не потерять неделю».
У подрядчика должны быть нормальные доступы с первого дня
Очень легко потерять первую неделю на мелочах.
Один человек ждёт приглашение в репозиторий. Второму недоступна документация. Сборка лежит в облаке, к которому никто не выдал права. Потом выясняется, что для запуска проекта требуется внутренняя библиотека.
Со стороны это выглядит как медленное погружение подрядчика. На практике команда просто не может полноценно работать.
Хорошая передача проекта начинается с того, что рабочая среда готова заранее.
У разработчиков должен быть доступ к актуальному репозиторию, task tracker и документации. Также им нужен способ получить рабочую сборку и связаться с человеком, который понимает техническую часть проекта.
Секреты, ключи и production-доступы при этом не нужно раздавать всем подряд. Доступ должен соответствовать роли человека, но его должно хватать для реальной работы.
Не пытайтесь контролировать каждый час
Когда внешняя команда только подключилась, возникает соблазн увеличить количество контроля.
Попросить ежедневные подробные отчёты, подключаться ко всем внутренним обсуждениям подрядчика, проверять каждую мелкую задачу.
Обычно это не делает проект прозрачнее. Скорее заказчик получает много информации, из которой сложно понять главное: движется ли проект к нужному результату.
Рабочая модель выглядит иначе.
У команды есть понятный scope на ближайший период. Заказчик видит актуальный backlog. Через оговоренные промежутки появляется рабочая сборка или другой проверяемый результат. Если оценка меняется или возникает риск, это обсуждается до того, как проблема превращается в сорванный milestone.
То есть контролировать лучше не деятельность, а движение проекта.
Сборка говорит о проекте больше, чем отчёт
Для игровой разработки это особенно важно.
Задача может быть закрыта в tracker. Разработчик может написать, что функция готова. Но пока результат не появился в сборке, сложно понять, как он работает вместе с остальной игрой.
Поэтому одна из самых полезных точек контроля — регулярный playable build.
Не обязательно ждать полностью законченного этапа. Даже промежуточная версия показывает намного больше, чем таблица со статусами.
Если рабочая сборка перестаёт появляться неделями, это уже повод разобраться, что происходит. В статье «Пять признаков того, что проект столкнётся с проблемами через месяц» как раз разбирается ситуация, когда состояние backlog и реального билда начинает расходиться.
Договоритесь о приёмке до того, как появится первая спорная задача
Одна из главных причин конфликтов между заказчиком и подрядчиком — разные представления о готовности.
Допустим, внешняя команда разработала новую систему инвентаря. Для разработчика она готова: механика работает, данные сохраняются, интерфейсы подключены.
Заказчик может ожидать совсем другое: чтобы функция прошла QA, работала на всех целевых устройствах, имела документацию и не создавала новых ошибок в старых сохранениях.
Обе стороны могут быть по-своему правы.
Поэтому критерии лучше определить до разработки, а не во время приёмки.
Для сложных задач полезно заранее зафиксировать, где проверяется результат, какие сценарии должны работать и что именно входит в поставку. В статье о критериях приёмки внешней команды этот принцип разобран подробнее.
Оставьте ключевые решения внутри проекта
Сохранить контроль не означает самостоятельно управлять работой каждого внешнего специалиста.
Гораздо важнее определить решения, которые подрядчик не должен принимать в одиночку.
Например, локальное техническое решение вполне может находиться в зоне ответственности внешнего tech lead. Но изменение ключевой архитектуры, значительное расширение scope или решение, которое влияет на дату релиза, уже должно обсуждаться с заказчиком.
То же самое касается продукта.
Подрядчик может предлагать варианты и предупреждать о рисках. Однако приоритеты продукта, бюджет и принципиальные изменения должны оставаться под контролем владельца проекта.
Так у внешней команды остаётся достаточно свободы для нормальной работы, а заказчик не теряет управление направлением.
Определите одного ответственного с каждой стороны
Когда коммуникация идёт сразу через десять человек, контроль быстро превращается в шум.
Продюсер заказчика написал одно. Разработчик добавил уточнение в личном сообщении. Потом art lead внёс изменения, о которых не знает project manager подрядчика.
Через неделю уже сложно восстановить, какая версия решения была окончательной.
Поэтому для каждого направления полезно иметь понятного владельца с обеих сторон.
Это не означает, что общаться могут только два человека. Разработчики вполне могут обсуждать технические вопросы напрямую. Но кто-то должен принимать итоговое решение и следить, чтобы оно не потерялось между чатами и встречами.
QA лучше не оставлять полностью внутри команды подрядчика
Если подрядчик разработал функцию и сам же её проверил, это ещё не всегда означает независимую приёмку.
На небольшом проекте отдельная QA-команда может быть избыточной. Однако для крупного production полезно иметь второй уровень проверки.
Это может бытьвнутренний QA заказчика или отдельное направление тестирования игровых проектов.
Главное, чтобы на важных этапах результат оценивался не только человеком, который его создавал.
Особенно это касается интеграционных задач, multiplayer, сохранений, миграций данных и изменений, способных повлиять на уже работающие системы.
Не скрывайте изменения scope
Проект почти всегда меняется в процессе разработки.
Появляется новая идея. После первого прототипа становится понятно, что одна система должна работать иначе. Меняются требования платформы или срок релиза.
Проблема не в самом изменении.
Проблема возникает, когда новая работа постепенно добавляется в текущий scope, но ожидания по срокам и бюджету остаются прежними.
Поэтому любое заметное изменение полезно рассматривать через простой вопрос: что оно меняет?
Если добавляется новая функция, возможно, придётся перенести менее важную. Если изменяется архитектура, нужен дополнительный технический этап. Если дата релиза остаётся фиксированной, где-то придётся уменьшить объём.
Это помогает сохранить контроль над проектом намного лучше, чем попытка держаться за первоначальный план любой ценой.
Что делать, если проект уже начал выходить из-под контроля
Иногда внешняя команда подключается не на старте, а когда проблемы уже накопились.
Нет актуальной документации, оценки регулярно меняются, backlog перестал отражать реальность, а часть решений существует только в переписках.
В таком состоянии не стоит сразу добавлять ещё больше задач.
Сначала полезнее восстановить картину проекта: проверить сборку, репозиторий, критичные зависимости и текущие обязательства по релизу.
Для таких ситуаций может подойти формат аудита и улучшения существующей игры.
После этого проще понять, какие проблемы действительно блокируют production, а какие могут подождать.
Как передать игровой проект на аутсорс и не заниматься микроменеджментом
Хорошо организованный аутсорс не должен требовать постоянного контроля каждого исполнителя.
У заказчика остаётся понимание того, что происходит с проектом, но большая часть операционной работы находится внутри внешней команды.
Для этого достаточно нескольких вещей: понятной границы ответственности, актуального backlog, регулярного рабочего результата, заранее определённой приёмки и ответственных людей с обеих сторон.
Тогда контроль строится не на количестве сообщений в чате, а на предсказуемости процесса.
В итоге передать игровой проект на аутсорс без потери контроля вполне реально. Главное — не пытаться контролировать каждого специалиста отдельно. Нужно создать систему, в которой состояние проекта видно без постоянного вмешательства.
Если требуется подключить внешнюю команду к уже работающему production или передать ей отдельное направление, можно обсудить проект с NoPanic Studio и определить формат работы на старте.
Частые вопросы
Нужно ли передавать подрядчику весь репозиторий?
Не всегда. Это зависит от архитектуры и задачи. Если команда работает непосредственно внутри проекта, доступ к репозиторию обычно необходим. Для изолированного направления можно ограничить объём доступных материалов.
Как часто нужно проводить встречи с внешней командой?
Зависит от стадии проекта. В большинстве случаев важнее не количество созвонов, а регулярность проверяемого результата. Для активного production обычно достаточно коротких рабочих синхронизаций и периодического демо сборки.
Кто должен принимать работу подрядчика?
Лучше заранее назначить конкретного человека со стороны заказчика. Для технических задач это может быть tech lead, для art production — art lead, а для крупного блока — producer или владелец направления.
Можно ли подключить аутсорс-команду к уже начатой игре?
Да. Более того, это один из распространённых сценариев. Перед стартом команде понадобится изучить текущую сборку, кодовую базу, документацию и существующий pipeline.
Как понять, что контроля уже недостаточно?
Один из главных признаков — когда невозможно быстро ответить, что сейчас находится в рабочей сборке, над чем команда работает и какие риски влияют на ближайший milestone. В этот момент проблему лучше разбирать до того, как она проявится в сорванном сроке.