Game Insight, Playrix и Zeptolab об устройстве игровых компаний.
26 мая вышел 185 выпуск подкаста «Как Делают Игры». На этот раз ведущие Сергей Галёнкин и Михаил Кузьмин поговорили с представителями трёх студий о структуре команд, их автономности и мотивации.
Гости выпуска:
- Максим Вознюк, Development Director московской студии Game Insight;
- Антон Пензар, Senior Project Manager, Playrix;
- Майк Свиблов, Head of Publishing, Zeptolab.
DTF публикует избранные фрагменты.
О гостях
Максим Вознюк: Я в индустрии с 2003 года. Мой друг устроился в зеленоградскую студию Mistland и позвал меня тестировать игру. Скоро должна была выйти «Власть Закона», и он попросил помочь. Я начинал как тестер, потом был геймдизайнером, руководителем проекта. С 2007 года работал продюсером в 1C:Мультимедиа. А с 2012 года — в Game Insight. Вначале был руководителем проекта, выпустил «Транспортную Империю», сейчас занимаюсь организацией разработки всей московской студии. Недавно мы запустили мобильный шутер Guns of Boom.
Антон Пензар: В геймдеве я чуть больше пяти лет. Как и Максим начинал с тестировщика, но в компании Playrix в Вологде. Работал где-то полтора года, потом перешёл на позицию менеджера портирования премиум-игр на Mac и iOS. Затем довёл два ПК-проекта до релиза и после этого стал менеджером free-to-play проектов. Руководил двумя играми параллельно, одна вышла в релиз, другую мы закрыли по результатам софт-лонча. После этого я уже перешёл на позицию проджект-менеджера в оперирование. Долгое время занимался Township, в этом году начал подключаться к другим играм на позиции старшего менеджера проекта, чтобы помочь другим ПМ-ам.
Майк Свиблов: Мой стаж в игровой индустрии — около 10 лет. Я начинал с компании IT Territory, где занимался браузерной игрой «Легенда: Наследие Драконов» сначала как младший геймдизайнер, потом как старший, а затем — руководитель проекта.
Открыл собственную компанию, делал браузерную игру «Пароград», занявшей в 2013 году первое место на КРИ. Потом чуть-чуть позанимался социальными играми в компании Playflock, ушёл в Zeptolab на позицию продуктового менеджера всей линейки Cut the Rope где провёл около года. Перешёл на издательское направление Zeptolab и возглавил его.
Об организации процессов
Майк Свиблов: У нас идеи для игр придумывают не только геймдизайнеры и менеджеры по продукту. Есть специальное место в Jira, куда любой сотрудник — специалист техподдержки, художник, программист — может закинуть небольшой двустраничный питч игры, которую хочет сделать. Потом вся компания голосует за каждый из этих проектов (голос геймдизайнера «весит» чуть больше, чем голос программиста). Если игра набирает достаточно голосов — на неё выделяются ресурсы. За месяц генерируется порядка ста идей. Большая часть, конечно, не проходит.
Кроме того, у нас есть «дни автономии» — если сотрудники компании не заняты задачами, они самоорганизуются в небольшие команды и делают что-то полезное. Например, прототип игры, внутреннего софта или что-то такое. Так они работают один-два дня, потом презентуют проект, он проходит через голосование, победителей награждают. Многие наши игры, в частности — King of Thieves, родились как раз во время этих дней автономии.
Появляется идея. Сначала над ней работает очень небольшая команда — обычно это геймдизайнер, продуктовый менеджер (иногда даже в одном лице) и программист с художником. Они делают прототип в жёсткие сроки — по-моему, за три месяца. Его показывают в компании, после чего следует второй этап одобрения. Потом презентуют друзьям и семьям, понимают, есть ли в нём потенциал.
Если всем всё нравится — запускается вторая итерация, тоже примерно на три месяца. Цель — проверить все возникшие гипотезы. Более-менее играбельный прототип выкладывается в магазин с другого аккаунта и мы смотрим, как пользователи оценивают игру. Если цифры нам нравятся, мы запускаем полноценную работу над продуктом.
Михаил Кузьмин: А зачем выкладывать под другим аккаунтом?
Майк Свиблов: Мы закрываем очень много таких продуктов, и не хотим, чтобы игроки и участники индустрии видели, над чем мы работаем, пока не уверены, что это хорошо.
Ещё одна интересная история — проверка гипотезы до начала работы над игрой. У нас возникает идея какой-то механики и визуального стиля. Мы рисуем несколько псевдо-скриншотов, как будто игра есть. Закидываем их в фальшивый магазин вроде Splitmetrics, нагоняем туда чуть-чуть трафика и смотрим на конверсию, интересен ли людям проект. Это тоже помогает принимать решения ещё до начала разработки и позволяет сэкономить много денег.
Антон Пензар: У нас все процессы построены на двух главных тезисах — делать только хитовые продукты и максимально качественно. Поэтому мы не работаем одновременно на многих играх, а фокусируемся на том, в чём уверены и редко создаём новые проекты. Новые идеи обсуждаются узким составом. Мы постоянно смотрим на рынок, видим появление новых ниш, следим за новыми механиками — как их можно соединить, чтобы удивить игроков. Это первый этап разработки: узкая команда продюсеров пишет документ с кратким описанием игры и долго его обсуждает.
Если документ всем нравится — наступает второй этап. Мы набираем команду геймдизайнеров и художников, рисуем концепт-арты, скетчи, просто чтобы посмотреть, как идея будет выглядеть на мобильных устройствах. Если всех устраивает результат — начинается разработка первого прототипа. Подключается команда программистов (сначала довольно небольшая). Первые прототипы создаются от нескольких месяцев до полугода.
Дальше мы изучаем прототип, находим слабые места и начинаем итерационно «полировать». Это самый долгий этап, так как уже к софт-лончу мы хотим сделать продукт, который считаем хитом. В итоге игра может довольно радикально измениться — с теми же усилиями можно было бы сделать три разных проекта. Но мы всё стараемся довести до идеала.
Когда в компании понимают, что всё получается — проверяем игру на пользователях софт-лончем в отдельной стране. Если всё устраивает — готовим к мировому релизу. Не устраивают метрики — изучаем, почему так получилось. Когда исправить не получается — закрываем проект, у нас были такие прецеденты. Либо не закрываем, но очень сильно модифицируем. Показателен пример Gardenscapes — игра была в софтлонче, показала дикие метрики по удержанию, но невысокую монетизацию. Тогда мы решили проверить, что будет, если изменить жанр проекта на «три-в-ряд».
Максим Вознюк: У нас много общего с Zeptolab и Playrix. Изначально мы проверяем идеи в компании, начиная с концептов и презентации стилистических набросков. Дальше препродакшен, корректировка, просмотры, оценка аудитории, запуски. Ту же Survival Arena очень долго улучшали. Guns of Boom была в софт-лонче приблизительно полгода — мы докручивали стриминг, одновременную игру в одной комнате и так далее.
Формирование команды
Максим Вознюк: Исторически в Game Insight несколько студий, собранных на базе лидов. Сейчас это уже устоявшиеся коллективы, внутри формируются команды проектов. Есть идея — выбираются специалисты, которые лучше для неё подходят. Всё начинается с лидов, занимающихся препродакшном, плюс пара человек — геймдизайнер с описательной частью, лид-программист, выбирающий технологические решения и арт-директор — стилистику.
По мере развития проекта команда расширяется, появляются ресурсы — большой арт-отдел для производства контента, серверные разработчики и так далее. У всех наших студий есть общий запас ресурсов — часть арта делается не внутри студий, как и серверная экспертиза.
Майк Свиблов: В компаниях, где я работал, чаще всего не было выделенных людей с ролями геймдизайнера и менеджеров проекта и продукта. Все эти роли играл продюсер, который одновременно был лидом-геймдизайнером, контролировал сроки, бюджеты и метрики продукта. И так было практически везде, кроме Zeptolab.
В Zeptolab есть чёткий триумвират. Геймдизайнер — отдельный человек (чаще всего он же — «product owner»), отвечающий за то, чтобы игра была интересной. Проджект-менеджер контролирует сроки, задачи, бюджеты и организовывает рабочий процесс. Менеджер по продукту следит за монетизационными показателями, цифрами по ретеншну, фичами, не касающимися геймплея.
Сергей Галёнкин: У нас роли обычно разделены. Есть человек, который занимается именно финансовыми показателями, есть тот, кто контролирует «видение» продукта, геймдизайнер, и отдельно — продюсер, занимающийся управлением. В Epic так исторически сложилось (как и в Riot), что продюссер просто напоминает всем о том, что нужно выполнять те или иные задачи.
Максим Вознюк: Было бы идеально, если бы все ипостаси сходились в одном человеке — гениальным восьмируким лидом проекта с машиной времени. Но объём работы по каждому направлению очень велик. Хорошо, когда человек может совмещать хотя бы две позиции.
Если у лида проекта не хватает экспертизы или возможностей по какому-то из направлений — мы даём ему человека в усиление. Например, он классный лид-геймдизайнер, держит в голове видение проекта, понимает, что и для чего мы делаем, думает про метрики, но у него нет времени на планирование, постановку задач, контроль программистов. Мы просто ищем человека, который возьмёт на себя эту обязанность.
Иногда хороший лид-геймдизайнер справляется с задачами, всё планирует, контролирует, но у него не хватает продуктового видения. Тогда мы подключаем продюсера, который привносит свежие идеи, взгляд на проект извне, продумывает его позиционирование и место на рынке.
Антон Пензар: У нас обычно на проекте есть один менеджер, выполняющий организационные задачи и может участвовать в принятии решений по продукту, метрикам. Он как раз такой «восьмирукий» специалист (во всяком случае, к нему предъявляются достаточно высокие требования). Вместе с ним у проекта есть продюсер, следящий за направлением движения игры, отвечающий за её качество и геймдизайн.
В команде три основных подразделения с лидами. В арте это тимлид и арт-продюсер. Арт тим-лид отвечает за организационные вопросы, сроки, планы, ресурсы. Арт-продюсер — за соблюдение стилистики проекта. Он всматривается в задачи художников, даёт обратную связь, помогает получить нужный результат.
Часто бывает, что в команде арта может быть несколько таких лидов — один арт-продюсер и лид-художники по направлениям (интерфейс будет оценивать тот, кто в нём разбирается).
У программистов свой менеджер, участвующий в решении технических задач, но в основном отвечающий за организационную часть. В его команде есть техлид, концентрирующийся на архитектуре и технологии.
И у геймдизайнеров есть ответственный за всё менеджер и люди по направлениям. Лид по балансу, лид по дизайну нарратива, лид по техническому дизайну.
Про автономность
Майк Свиблов: Мы стараемся делать команду максимально автономной: она отчитывается о действиях и результатах только на контрольных точках. Несмотря на то, что основатели компании имеют профильное образование — один программист, а второй геймдизайнер — они никогда не влезают, не говорят, что делать в игре.
Антон Пензар: У нас для каждого проекта есть внешние продюсеры. Они подключаются на каких-то определённых этапах — при согласовании важных вопросов, отсмотре прототипов. Это эксперты со свежим, незамыленным взглядом. Они часто подмечают критические моменты, могут дать обратную связь по развитию продукта.
Они приходят не как «авторитарные» специалисты, но представляют ещё одну позицию во время обсуждения, выбора и поиска наиболее правильного направления для игры. Можно сказать, что команды автономные, то есть большинство решений принимается внутри коллективов, но и внешних продюсеров мы используем часто.
Максим Вознюк: Похожая ситуация — внешние продюсеры, рекомендательный характер, плюс есть по всем проектам срезы, важные точки, на которых проект презентуют расширенному кругу людей. Запрос на это может исходить и из самой команды, если она столкнулась с какой-то проблемой или вынуждена принимать сложное решение. Происходит вертикальный обмен опытом между проектами — команды показывают друг другу версии, обсуждают, придумывают выходы. Технологические решения тоже «скалируются» вверх.
Такой подход мы выбрали намеренно. Изначально команды были изолированы, варились в собственном соку, и это было нужно, чтобы все проблемы озвучивались на уровне всей компании — это эффективнее.
Антон Пензар: Добавлю, что кросспроектные решения у нас принимаются по геймдизайнерским вопросам, а технические отданы на откуп командам. То же и с артом — для согласования стилистики и отдельных важных технических элементов изредка подключаются внешние продюсеры. Мы стараемся наладить процессы так, чтобы эффективнее распространять кросспроектный опыт. Выделили, например, команду по движку, которая также занимается и SDK-сервисами — так мы можем перенести единообразные решения на все наши проекты. По арту тоже стараемся наладить процесс обмена опытом и получается интересно.
Про планирование
Максим Вознюк: Прежде чем начать бежать, нужно узнать куда, зачем и есть ли такая возможность. Мы меняем подход в зависимости от задач и команд. Первое, что стоит сделать — описать желаемое. Если это игра — подготовить дизайн-документ, расписать основные фичи, технологическую базу, примерно описать контент «в штуках». После чего грубо всё оценить — это даст хотя бы какую-то приблизительную картину. Если получается, что при вашей команде и ресурсах вы сделаете игру за полтора года — скорее всего, быстрее не получится. Тогда надо задумываться о расширении команды или переосмыслить желаемое. Первая оценка очень груба, но это всегда преуменьшение, а не преувеличение срока.
Дорожная карта — это грубый план, который мы собираем на большой срок, полгода-год. Он описан крупными мазками, это обычно фичи и технические решения, какие-то крупные проблемы или запланированные обновления движка. Мы разбиваем работу на более мелкие этапы (обычно сроком в месяц). Дальше мы уже подробнее расписываем, что конкретно и как будем делать, разбиваем процесс на задачи и недельными «спринтами» идём к результату.
Сергей Галёнкин: А что происходит, когда вы не укладываетесь в сроки и начинает смещаться вся стройная структура?
Максим Вознюк: Дорожная карта настолько примерна, что нет задачи досконально в неё уложиться. Она даёт вектор развития проекта и общее понимание.
Чтобы минимально смещались месячные планы — раз в неделю мы проводим общее собрание и понимаем, что успели сделать, что нет, что планируем, насколько отстаём от графика. Но исключать задачи и менять сроки нужно на ранних этапах, ни в коем случае не тянуть до последнего.
Михаил Кузьмин: Как происходит синхронизация между отделами?
Максим Вознюк: У нас есть ежемесячная встреча для расширенной команды. В ней участвуют все — тестирование, маркетинг и другие отделы. Мы озвучиваем два ближайших этапа, подробно рассказываем, что на них будем делать, в какие сроки, какие ивенты будем запускать, какие фичи добавлять. И у нас есть обновляющийся документ, который даёт представление о том, что происходит.
Михаил Кузьмин: Насколько подробной вы делаете документацию?
Максим Вознюк: Зависит от подразделения. У программистов и геймдизайнеров чуть лучше, у художников чуть хуже. Это сильно зависит от проекта. У старых документация давно неактуальна, у самых новых — её ещё нет. Могу сказать только, что программисты в этом плане дисциплинированнее всех.
Майк Свиблов: Мы начинаем планирование с изучения рынка. Где-то раз в три месяца инициируем глобальное совещание. Каждый человек берёт конкретный жанр, играет в его игры, выделяет в них сходства и различия и потом мы это собираем в один документ. Он даёт понять, что сейчас в тренде, что может быть будет в тренде, какие инструменты монетизации или долгосрочного удержания используются в играх. И это не совсем про планирование, но помогает всей команде быть в курсе того, что можно использовать и куда мы хотим двигаться.
Антон Пензар: Небольшие отличия, поскольку в основном всё сходится. У нас тоже есть дорожная карта на достаточно длительный срок, ближайшие месяцы описываются подробно, чем дальше — тем менее подробно и менее точно по срокам. И мы работаем не по «спринтам», а все крупные фичи разбиваем на рубежи и примерно закладываем даты их преодоления. Если не успеваем — обсуждаем, что делать.
По документации тоже всё зависит от команды. Но мы стараемся ставить задачу напрямую— ты реализовал фичу, ты и напиши документацию. Сотруднику выделяют на это отдельное время, так как это критически важно для QA, маркетинга, поддержки — эти отделы не смогут работать без документа.
Про коммуникацию
Максим Вознюк: Обычно есть крайности — коммуникации слишком много и она не формализована, или её вообще нет.
В первом случае два программиста могут решить в курилке переписать половину движка, и удалить «отжирающий» память SDK, который оказывается главным инструментом отдела маркетинга. Во втором случае — программисту приходит задача «приделать к танку приделать хвост кота» — он ни у кого ничего не спрашивает и выполняет.
Антон Пензар: Кроме ежедневных встреч программистов и еженедельных у других отделов есть и просто общение в ходе работы. Например, на каждую фичу у нас выделяется набор специалистов — геймдизайнеры, художники, программисты, которые решают большинство вопросов сами. Они могут собраться в переговорке, обсудить всё, постоянно держат руку на пульсе.
Майк Свиблов: Интересно, как вы к этому шли при вашем-то количестве удалённых сотрудников.
Антон Пензар: Наш центральный офис находится в Вологде, а туда готовы переехать не так много специалистов. На определённом этапе роста пришлось открывать новые офисы или искать удалённых сотрудников. Мы решили попробовать и сформировали жёсткие правила.
Во-первых, мы набираем тех, кто может работать как удалённые сотрудники — не всем это подходит. После тестового периода мы активно сигнализируем во всех каналах в Slack, что нужно эффективно взаимодействовать с людьми. Рассылаются небольшие напоминания. Во время совещаний мы делаем общие звонки в Skype, показываем свой экран, чтобы люди понимали, что с ними общаются так же, как и в одном офисе. Мы проводим конференции как по всему проекту, так и по подразделению. Специалисты из одного проекта могут съехаться, поработать вместе, обсудить идеи и дальше им будет уже куда легче найти общий язык, даже находясь в семи часовых поясах друг от друга.
Про мотивацию
Максим Вознюк: Самое главное — понятные и интересные задачи. Человек должен знать, что от него требуется, как будет оцениваться результат, как его работа развивает и двигает вперёд весь проект, какой он вносит вклад. Плюс он должен ощущать ответственность и вовлечённость в процесс.
Второй аспект — коллектив. Дружелюбный, открытый. Часто очень хорошие специалисты в негативном коллективе выдают плохие результаты. Вместо рабочих задач они начинают заниматься подковёрными интригами, сварами, максимально непродуктивными действиями.
Третий пункт — комфортное рабочее место. Если у вас в офисе не работает туалет, сорокаградусная жара и с потолка капает — работнику сложно сосредоточиться на главном.
Михаил Кузьмин: Поручик, а деньги?
Антон Пензар: Необходимое, но недостаточное условие. Все мы, к сожалению, не справимся без них — у нас семьи, хобби, ипотеки и так далее. Но только деньгами замотивировать человека нельзя. Либо можно, но только на старте — долго поддерживать «запал» не получится.
Майк Свиблов: У нас есть индивидуальный план развития. Раз в год любой сотрудник составляет вместе с коллегами или начальником план: что он научится делать лучше в этом году. Задача не обязательно относится к рабочим обязанностям — возможно, ему не хватает английского языка, софт-скиллов или знания программных пакетов. HR, начальники и коллеги помогают ему выявить слабые стороны. А в конце года работник проверяет, выполнил ли свой план.
Каждый год сотрудник чувствует, как становится лучше. У нас есть отдельный бюджет на обучение и сотрудник может тратить его на поездки на конференции, литературу — всё это замечательно работает.
Деньги тоже важны, у нас есть бонусы, которые делятся между всей командой. Аналитики на старте проекта говорят, сколько будет зарабатывать проект, если его не развивать. Проходит полгода, мы смотрим, сколько игра действительно заработала, и процент от разницы распределяется по команде. Какой вклад в результат внёс отдельный работник определяет менеджер проекта.
Какие инструменты использовать при переходе от соло-разработки к команде
Максим Вознюк: Для начала Google-документов вполне достаточно.
Майк Свиблов: Сложный вопрос. Slack, Trello и Asana вполне масштабируются от трёх человек и до 30. Если больше 30 — наверное, следует использовать Jira.
Антон Пензар: У нас команды по 60-70 человек на некоторых проектах и мы до сих пор используем Asana. Главное — уметь её правильно готовить.
Источник: DTF
