Ольга Абашова о том, как выстроены процессы создания игр в G5 Entertainment

Александр Семенов, выпускающий редактор App2Top: Привет! Чуть больше года назад у G5 появилась новая студия в Калининграде. Ее запуском занималась ты, сегодня ты ее возглавляешь. И я как раз хочу с тобой поговорить о процессах разработки в команде. Но давай начнем с рассказа о G5. Это все-таки российская или шведская компания?

Ольга Абашова, руководитель калининградского офиса G5 Entertainment: Привет! Мы публичная шведская компания, акции размещены на площадке Nasdaq Stockholm, и штаб-квартира компании находится в Стокгольме. Основана компания была в Москве много лет назад, и Влад Суглобов и Алик Табунов, основатели компании, продолжают ей руководить.

Я знаю, что у компании есть офисы в Москве, Стокгольме и Калининграде. А где еще?

Управляющий офис у нас на Мальте. Маркетинг – в Сан-Франциско. Самый крупный офис разработки находится в Харькове, самый новый – в Калининграде. В общей сложности у нас более 300 сотрудников по всем офисам.

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

Оля, ты сама основатель и глава калининградского офиса. Расскажи про него.

В Калининграде у нас 2 большие проектные команды, в каждой более 15 человек. Мы развиваем уже выпущенные проекты, каждый из которых требует достаточно затратных по контенту обновлений. Плюс, конечно, идет оптимизация. То есть, мы не только выпускаем новый контент, но и дорабатываем качество старого, улучшаем техническую часть, добавляем новые функциональные возможности, новые игровые механики.

Как работает твой офис и, в целом, офисы G5?

В основе каждого офиса разработки – проектные команды. Менеджмент распределён между всеми офисами, по факту, управление у нас частично удаленное. Административная часть и функциональные отделы сосредоточены в одном офисе.

Мы постоянно ездим, курсируем между офисами, плотно общаемся друг с другом. Нет никакого затруднения или проблем в плане коммуникации, нехватки информации и так далее.

В центральном офисе (на Мальте) у нас находится часть топ-менеджмента и команда лицензирования. И здесь же мы собираемся для проведения внутренних конференций и тимбилдинга. На период конференций съезжаются целые проектные команды. Прежде всего, конечно, позагорать, пообщаться, и, между делом, обсудить текущие вопросы и планы.

Как при таком количестве офисов и удаленном управлении всё это контролируется? Как вы избегаете бардака?

Бизнес-процессы и никакой магии. Собственно, во многом благодаря отлаженной системе бизнес-процессов мы быстро и ­«бесшовно» запустили и настроили работу студии разработки в Калининграде, обеспечив её эффективное взаимодействие с другими офисами. Очень позитивный опыт. И это при том, что у калининградской команды изначально был другой опыт в плане корпоративной культуры, другие стандарты (основной костяк – сотрудники закрывшей Realore, – прим.редакции). Я думаю, такое вливание новых кадров не каждая компания смогла бы вынести настолько безболезненно. Ну и ещё нужно отметить в целом самостоятельность наших проектных команд.

Это общий ответ. Раскрой, пожалуйста.

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

Можешь привести пример такой регламентации для наглядности? Как это работает на деле?

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

И кто занимается написанием этих шагов, всей этой документации? Это сверху спускается или внутри проектных команд всё делается?

Гуру процессов у нас операционный директор и директор по разработке. Они прорабатывают первую версию нового процесса, когда в нем возникает необходимость. А в целом, все процессы постоянно рефакторятся и оптимизируются и снизу, и сверху. Разумеется, бывают сбои. Бывает, что что-то идет не так. Тогда мы анализируем возникшую проблему, корректируем процесс, адаптируем под новые задачи и ситуации.

Если говорить непосредственно о разработке, то за видение проекта и разработку документации по дизайну игры отвечает руководитель проекта – «Executive Producer». Он может вести несколько проектов. А вот непосредственной работой с командой занимается «Producer», который полностью погружен в проект. При запуске нового проекта «Executive Producer» и «Producer» формируют команду, и процесс начинается.

Затем стартует разработка. Но, хочу сделать акцент на том, что уже перед стартом прописано то, чем кто будет заниматься, на каком этапе, описаны шаги, описаны конкретные взаимодействия, расписана система контроля, система отчетности. В процессе работы всё это мониторится, есть чекпойнты. В случае каких-то изменений в сроках, расписании, бюджетах – все отражается в документации, все прозрачно. И работает это в том числе между офисами. У нас редко случаются большие факапы, когда что-то где-то потерялось или было не сделано. Но, конечно, всякое бывает, мы же не машины. И потом, следование процессу не самоцель. Есть ситуации, когда нужно принимать именно оптимальные решения, а не как написано.

То есть, главное ваше правило – обо всем договариваться на берегу?

Ну не обо всём, конечно. Разработка игр не очень предсказуемая вещь, фан-фактор не формализуешь. Но вот синхронизировать видение игры по результатам этапа можно и нужно, как и договориться о необходимых изменениях. Главное, перед началом работ иметь чёткое представление о том, что ты делаешь и зачем. Понятные проектные цели и план действий очень с этим помогают. А ещё мы огромное внимание уделяем коммуникации. Чтобы она проходила между нужными людьми, чтобы информация доносилась до всей группы. Совместные обсуждения, совместное принятие решений.

Mahjong Journey: Путешествие (один из калининградских проектов G5)

Сейчас шажок в сторону: а где тут место творчеству, когда у тебя все так расписано и так все строго регламентировано? Или творчество «на местах» у вас не очень приветствуется?

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

Но не ломает ли внедрение предложений всю структуру работы?

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

Сейчас хочу уточнить один момент. Чем конкретно занимается «Executive Producer», кроме написания дока до разработки?

В нашем случае «Executive Producer» отвечает прежде всего за выработку единого направления развития продукта, аккумулируя и обобщая мнения проектной команды.

Получается, он не завхоз?

Совсем нет, «Executive Producer» – это отчасти геймдизайнер, отчасти менеджер, который несёт полную ответственность за все аспекты проекта. Он отвечает и за дизайн, и за монетизацию, за организацию работы, за бюджет проекта. «Executive Producer» оценивает риски, смотрит, какие конкуренты есть у продукта, думает, как их догнать и перегнать, предлагает решения, чтобы сделать продукт лучше и так далее. Он также оценивает качество, как это сделано, какой уровень качества ему предоставили, отсматривает и графику, и сам геймплей, и так на каждом этапе (в том числе после вывода проекта в релиз, когда начинает следить уже за обновлениями игры). Кроме того он смотрит за тем, чтобы максимально качественно были реализованы те решения, которые были приняты по продукту.

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

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

Хорошо, а линейный чем занимается?

Линейный продюсер занимается непосредственным управлением командой проекта. Он регулирует процесс на уровне задач, их декомпозиции, распределения нагрузки, управления ресурсами. Функции нашего продюсера приближены к функциям «Project Manager».

Грубо говоря, «Executive Producer» у вас говорит, что хочет такое-то солнце, а линейный продюсер видит, какие у него есть возможности, прикидывает и распределяет задачи, чтобы это солнце загорелось?

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

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

У нас совсем не так. Продюсер координирует работу проектной команды и помогает проектным лидам (ведущий программист, ведущий художник, ведущий дизайнер проекта, ведущий QA проекта). Лиды проектов – это эксперты в своей области, которые руководят соответствующими специалистам в рамках проектной команды, на основе их оценок принимаются решения. Они участвуют в обсуждениях всех ключевых моментов по развитию игры. Мы хотим, чтобы лиды были полностью вовлечены в проект, понимали, насколько успех проекта зависит от них. Именно поэтому сейчас мы развиваем систему опционов для проектных команд: когда сотрудник чувствует значимость своего вклада в успех проекта и компании и получает соответствующие бонусы.

А перед кем «Executive Producer» отвечает?

«Executive Producer» несет ответственность за достижение проектных целей перед топ менеджментом.

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

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

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

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

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

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

А в чем вы строите roadmap, каким инструментарием пользуетесь?

В основном используем стандартные виды Jira. Все сейчас, наверное, с ней работают. Распределение нагрузки в проекте отлично показывает Диаграмма Ганта. По всем другим аспектам используем инструменты от Google. Конечно, есть своя Wiki, в которой мы занимаемся описанием всей нашей бурной деятельности.

Я слышал два мнения по поводу вики. Я знаю, что, к примеру, студии внутри Mail.Ru Group ведут свою базу знаний, что они считают ее важным инструментом, поскольку она позволяет быстро разобраться в проекте новым сотрудникам и напомнить старым что-то, если они о каком-либо аспекте забыли. Но я сталкивался и с мнением, согласно которому, это лишняя трата времени, поскольку вносить все в Wiki — очень долго, очень много времени на это тратится, которое, например, можно было бы потратить на код. Что ты об этом думаешь?

Мы не ведём именно проектную Wiki, вся необходимая информация есть у проектных лидов, которые и доносят её до всех остальных членов команды. Wiki – это общекорпоративная база знания, где мы описываем полиси и процессы, принятые в компании. То есть, процессы, относящиеся в целом к разработке проектов, а не к отдельным проектам. Так что, специалисты тратят своё время на проект, а не на заполнение вики.

Ведение Wiki действительно затратно по времени, особенно если поддерживать в актуальном состоянии постоянно меняющуюся базу знаний по проекту (чего мы не делаем). Хотя аналоги тоже не намного лучше. Я, например, ранее использовала Confluence. Там немного другой интерфейс, немного другой функционал, но в целом одно и то же. Создавать, наполнять и вносить статьи и там, и там – весьма кропотливый труд.

Именно для написания, для создания статьи – в Wiki есть очень удобное «дерево», в ней также есть очень удобный поиск. В Confluence – сложнее, хотя форматирование и внесение правок, наоборот, лучше построено. Wiki-разметка хранит много сюрпризов. Иногда для работы с ней требуется ангельское терпение и смирение.

С другой стороны, с точки зрения пользователя, Wiki действительно очень хороша. Любому сотруднику очень просто найти любую информацию, потому что там алфавитный порядок, поиск по ключевым словам, там все удобно, хотя и есть нюансы с форматированием, но, в целом, это эффективнее, чем Confluence и, конечно, лучше, чем отсутствие ее совсем.

Понятно, спасибо большое за интервью.