В игровой индустрии сложилось устойчивое представление, что успех = масштаб. И часто это действительно так — монументальные хиты вроде The Witcher 3 или Red Dead Redemption 2 создаются усилиями тысяч людей и огромных бюджетов.

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

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

Чтобы понять, как это работает на практике, мы поговорили с Иваном Дворяновым, руководителем игрового направления Magnus Tech. В этой статье делимся его экспертизой и выясняем: почему для коммерческого успеха порой достаточно команды из 7–10 человек и как не сломаться под грузом мультизадачности, выбрав этот путь.

Что не так с большими командами?

Сразу спойлер: с ними всё в порядке. Дело в том, что у больших студий и компактных команд принципиально разные весовые категории и задачи. Игры уровня The Elder Scrolls V: Skyrim или God of War создаются усилиями нескольких сотен разработчиков. Это огромные вселенные, создать которые силами маленькой студии физически невозможно. 

Большие студии умеют делать невероятные вещи, и когда их процессы настроены правильно (как, например, у Naughty Dog или в лучшие годы Blizzard), на выходе получаются шедевры. Но масштаб — это всегда палка о двух концах. Как только штат переваливает за сотню, а бюджет — за десятки миллионов, включаются «законы физики», которые могут раздавить проект под собственным весом.

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

Еще одна ловушка ААА-разработки — это инерция. Если в середине цикла разработки выясняется, что ключевая механика не работает или жанр вышел из моды, большая студия часто не может позволить себе смену курса — слишком много ресурсов уже «забетонировано» в ассеты и код.

Яркий и болезненный пример — шутер Concord. Игру разрабатывали восемь лет, вложив в нее, по разным оценкам, более ста миллионов долларов. За это время рынок успел измениться несколько раз, но инерция толкала проект вперед. В итоге, несмотря на колоссальные вложения и опытных специалистов, игру закрыли через две недели после релиза.

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

Таким заложником амбиций стала Dragon Age: The Veilguard. EA ждала от новой части франшизы повторения успеха Inquisition — 12 миллионов копий за несколько лет. Десятилетний цикл разработки, неоднократные изменения концепции и увольнения ключевых лидов раздули бюджет до таких размеров, что игре уже недостаточно было просто стать успешной — ей нужно было стать хитом, чтобы окупить затраты. 

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

Кейсы Ubisoft последних лет, от Skull and Bones до Star Wars Outlaws, тоже подтверждают этот тезис: наличие известной лицензии и огромного штата не страхует от коммерческих неудач, если за масштабом теряется фокус.

И, наконец, самый деликатный аспект — человеческий. В большой системе часто теряется чувство причастности. Разработчики из Rockstar в интервью признаются, что чувствуют себя винтиками в огромном механизме. Ты можешь годами полировать одну анимацию лошади, но так и не увидеть, как она вписывается в финальную картину игры до самого релиза. Это порождает специфический вид выгорания: не только от переработок (печально известные кранчи, которые в некоторых студиях становятся нормой), но и от потери смысла. Когда твой вклад отмечается только строчкой в сорокаминутных титрах, сложно сохранять драйв и «гореть» проектом.

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

Выбор не от безысходности

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

Чтобы подтвердить или опровергнуть это, мы обратились к опыту Ивана Дворянова, продюсера игровой студии Magnus Tech. Его бэкграунд показателен: 12 лет в индустрии, старт карьеры в Playrix, работа над Match-3 проектами уровня Gardenscapes, запуск собственных стартапов с привлечением инвестиций и работа над кастомными режимами для Fortnite. Увидев индустрию с обоих полюсов, он пришел к выводу, что для задач, поставленных перед его командой, а именно разработки мобильных игр, подойдет именно такой размер команды.

Этот формат Иван называет «компактным коммерческим продакшеном».
Это не AAA-разработка, где сотни людей годами полируют один проект. Но это и не инди. Инди-разработка часто строится вокруг авторского видения, смелых экспериментов и принципа «я так чувствую», где коммерческий успех желателен, но вторичен.

В отличие от инди, здесь подход сугубо утилитарный: решения диктуются рынком, аналитикой и потенциалом монетизации. Такая команда — это бизнес-юнит, цель которого — создать прибыльный продукт с минимальными рисками. И размер в 5–10 человек здесь выступает стратегическим преимуществом.

Почему маленькая команда — это не приговор

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

Скорость принятия решений

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

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

То же касается и оперативных правок. В больших компаниях есть инерция: даже если фича работает плохо, её могут не убрать, потому что «уже согласовано» или «слишком сложно откатывать». В компактном юните продюсер может, сидя в редакторе, заметить, что какая-то механика играется скучно, тут же набрать программисту, и через 10 минут решение будет принято.

«Если понимаем, что механику нужно доработать, ставим задачу в приоритет. Часто уже к концу текущего спринта новая версия оказывается в игре. Такая скорость — одно из главных преимуществ небольшой команды» — отмечает Иван.

Гибкость и пивоты

Компактный юнит работает по принципу: увидел тренд — адаптировал. Пока корпорации проводят маркетинговые исследования и оценивают риски, маленькая команда уже выпускает продукт.

Иван вспоминает опыт работы на одном из прошлых мест, где команда создавала кастомные режимы для Fortnite. Это очень динамичный рынок: тренды здесь живут недолго. И вот вышла игра My Perfect Hotel, которая быстро набирала популярность. Команда сразу увидела потенциал ее механик и не стала ждать отчетов аналитиков. В день релиза все поиграли в новинку по часу. Иван тут же набросал короткий дизайн-документ, и уже на следующий день команда начала разработку Hotel Tycoon — аналога My Perfect Hotel, адаптированного под Fortnite.

Это применимо ко всей отрасли в целом. Индустрия знает примеры Backpack Battles или Balatro — игр с уникальными механиками (менеджмент инвентаря, математический покер), которые взлетели в Steam. Крупные мобильные издатели часто слишком долго присматриваются к таким новинкам. Небольшие же команды мгновенно подхватывают механику, адаптируют её под мобильное управление и выпускают хит, часто зарабатывая на тренде больше и быстрее, чем создатели оригинала.

Как подмечает Иван, сравнивая подходы:

«Если речь о марафоне, то большая команда, естественно, сделает всё быстрее [за счет ресурсов]. Но если нужен спринт, то небольшая команда как раз большую опередит».

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

Технологии без бюрократии

Ограниченность ресурсов часто воспринимается как минус, но на деле это мощнейший стимул для инноваций. Когда у тебя нет штата из 50 художников, ты вынужден искать инструменты, которые компенсируют нехватку. И главное преимущество маленькой команды здесь — не просто в использовании того же ИИ, а в скорости его внедрения. То, что в корпорации требует месяцев тестов, проверок службой безопасности и закупки лицензий на год вперед, здесь внедряется за один день.

Для Magnus Tech применение ИИ — это еще один способ оптимизации работы. К примеру, вся 2D-персонажка в текущем проекте сгенерирована Nano Banana. Художник потратит полдня на генерацию вариантов и еще какое-то время на доработку результата. В ручном же режиме отрисовка всех поз и эмоций с нуля заняла бы неделю, а это время и ресурс всегда есть куда направить.

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

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

Прозрачность и вовлеченность

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

Процессы здесь выстроены так, чтобы убрать прослойку менеджеров, которые менеджерят менеджеров. Документация есть, но она не избыточна:  дизайн-документ занимает 2–4 страницы, в нем описывается всё самое главное и актуальное. Да, могут быть закрыты не все вопросы, но в таких командах обычно это и не столь нужно, все и так «в контексте». А если вопросы возникают, то они решаются в мессенджере за пару минут.

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

Иван объясняет разницу подходов на простом примере:

«Когда в большой компании ты говоришь: "Мне нужно, чтобы ты сделал эти кнопки и меню", — он тебе сделает эти кнопки. Но работать они будут так, как ему это видится. Но когда каждый член команды знает, для чего это меню нужно, он подумает: "А будет ли игроку удобно нажать ее именно тут?", — то и результат будет уже другой. 

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

Фокус на главном

Работа в команде из 7–10 человек накладывает жесткий фильтр на амбиции. Это отрезвляет. Как справедливо замечает Иван: «Ты не сделаешь "Ведьмака" впятером или вдесятером». Но это и не требуется. Главная задача не распылять имеющиеся ресурсы на то, что на текущем этапе и не нужно.

В первую очередь это касается выбора самой сущности игры. Лезть в прямую конкуренцию с лидерами рынка — например, делать очередной классический Match-3 и бодаться с Royal Match или Homescapes — самоубийство. У гигантов бюджет на закупку трафика может превышать годовой оборот небольшой студии. Иван называет это «бассейном с пираньями»: тебя просто съедят на этапе привлечения пользователей.

Маленькая команда не может позволить себе и проект, который требует бесконечной генерации ассетов на старте. Поэтому производственный фокус смещается с количества на уникальность игрового опыта. Вместо того чтобы рисовать 50 локаций и 100 персонажей, команда полирует core-механику, которая будет главной фишкой игры. Словом, нужно найти пространство, где гигантов еще нет.

«Когда наша команда выбирала идею для проекта, логика строилась на поиске свободных связок. Есть популярная механика Match-3 Tile. Есть отлично зарабатывающая механика экспедиций. По отдельности эти рынки забиты, но их качественного гибрида в сторах практически нет. 

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

Второй важный аспект — отталкиваться от имеющейся экспертизы. В маленьком коллективе нет времени на масштабное переобучение. Нельзя просто сказать команде, которая специализировалась на мобильных шутерах, что теперь они делают симулятор свиданий на ПК. Рациональнее использовать сильные стороны команды, чем пытаться освоить что-то новое с нуля.

Третий принцип — производство контента «по средствам». Большая студия может позволить себе сделать пачку уровней про запас, еще не зная, дойдет ли до них игрок, или реализовать не самую нужную фичу. Компактная команда такой роскоши не имеет. К примеру, на текущем проекте для этапа софт-лонча подготовили 100 уровней и одну экспедицию. Этого достаточно, чтобы проверить метрики и понять, как быстро игроки осваивают подготовленный контент и заходит ли он им вообще. 

Это касается и найма людей. На этапе пре-продакшена и создания MVP раздувать штат нерационально. К примеру, в Magnus Tech на текущий момент в команде шесть человек: Иван как продюсер, два художника, два программиста и CEO. Всё остальное — аутсорс по необходимости. Не из экономии, а потому что на данной ступени развития нет задач на фулл-тайм для аниматора или 3D-художника. 

Расширение же заложено в стратегию изначально. После софт-лонча, когда станет понятно, что концепция работает, команда вырастет: понадобятся левел-дизайнеры для постоянного потока уровней, специалисты по контенту для экспедиций. Если темпы прохождения окажутся выше ожидаемых и контент придется выпускать чаще, штат расширят еще больше. Предположительно, команду ждёт рост до 20–25 человек, но это произойдет по мере необходимости, а не потому что «так принято». 

Иван резюмирует этот подход формулой: «Рост — это не причина, рост — это следствие». И он происходит только тогда, когда в этом появляется подтвержденная потребность. Это позволяет сохранять фокус на продукте, а не на обслуживании собственных процессов, и не распылять ресурсы на то, что игроку, возможно, даже не понадобится.

Но не всё так радужно

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

Один из основных рисков, от которого никуда не денешься — это так называемый Bus Factor («фактор автобуса»). Для контекста, это метрика, которая показывает, сколько человек должно «попасть под автобус» (aka заболеть, уволиться, уйти в отпуск), чтобы проект остановился. В корпорации на 200 человек уход ведущего программиста — неприятность, но не катастрофа: всегда есть коллеги, легаси-код задокументирован, а задачи подхватит соседний отдел. В команде из шести человек потеря одной боевой единицы может поставить под угрозу весь продакшн. 

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

Отсюда вытекает требование к вынужденной мультиклассовости. Нельзя сказать «это не моя работа» или откреститься от нее, потому что ты вроде как начальник. Иван иногда сам закрывает задачи, которыми в большой студии занимался бы целый отдел из 5–6 человек: от левел-дизайна кора и меты до нарратива и управления бэклогом. Художники же не просто рисуют арт, но и учатся работать в Unity, самостоятельно заливая билды. Это требует от людей колоссальной гибкости и постоянного переключения контекста, что выматывает гораздо сильнее, чем монотонная работа по специальности.

Высокая вовлеченность, о которой мы говорили как о плюсе, в то же время становится фактором риска выгорания. В маленькой команде ты всегда на виду, от твоего вклада напрямую зависит судьба проекта, и этот «котелок» кипит постоянно. Эмоциональная нагрузка здесь выше, чем на стандартном 5/2. 

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

Наконец, есть и объективные ресурсные ограничения. Как уже отмечалось, опция «про запас» закрыта для маленьких команд. Но в контексте проблем, это значит, что в моменты пиковых нагрузок команда не может просто «залить проблему людьми», а вынуждена жертвовать чем-то и справляться имеющимися силами, оптимизируя процессы и расставляя жесткие приоритеты. 

Кому такой формат (не) подходит

В конечном счете, выбор между корпорацией и компактным юнитом — это вопрос не столько профессионализма, сколько психотипа и ожиданий от жизни.

Если для специалиста важен четкий work-life balance, предсказуемость и возможность углубляться в узкую специализацию, не отвлекаясь на смежные задачи, то большая студия будет хорошим выбором. Здесь можно быть отличным профессионалом, качественно выполнять свой блок работ с 9 до 18 и не думать о проекте в выходные (в идеале). С тебя нет спроса по вовлечению, все довольны. Это нормальный, здоровый подход. Но для маленькой команды он не работает.

Здесь нельзя быть просто исполнителем. Этот формат для тех, кому тесно в рамках одной должностной инструкции, кто хочет видеть свой прямой вклад в финальный продукт и готов учиться новому прямо в процессе. Здесь продюсер становится дизайнером, а художник разработчиком. Формально это не их профиль, и в большой студии их к этому, возможно, даже не допустили бы. Здесь же это необходимость. Для одних такая работа — стресс и причина выгорания, для других — драйвер роста.

В таком коллективе на первый план выходят не только hard skills, но и soft skills — намерения человека, его амбиции и  «химия» с остальными участниками. Невозможно спрятаться за спинами коллег или отсидеться в тикетах. Каким бы талантливым ни был человек, если он не хочет быть частью общего дела, он не подходит. 

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

Компактная команда — это не набор процессов и инструментов. Это в первую очередь люди, их отношение к работе и друг к другу. Можно выстроить правильные спринты, внедрить лучшие практики и найти идеальную нишу, но если в комнате сидят десять человек, которые не хотят быть частью общего дела — ничего не сложится. И наоборот: когда каждый понимает, зачем он делает свою задачу, видит результат и готов прикрыть коллегу — успех не заставит себя ждать.

На этом у нас все! Будем рады почитать истории ваших команд и как вы справляетесь с проблемами на пути.