Обучение в компании — семинар №2 : о ролях в команде и развитии проекта

Игорь Клюкин

Ведущий аналитик

Поделитесь статьей:


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

В этот раз я решил дать некоторое пояснение по нижеследующей части семинара:

Роли в целом зависят от динамики расширения проекта и команды. У вас может быть небольшая команда, где гейм-дизайнер выполняет задачи продюссера, PM’а и аналитика — все в одном. Или у вас может быть команда побольше, в которой эти функции распределены между разными людьми. Главное правильно понимать, какие функции нужны на каждом этапе развития проекта и как они совмещаются или разделяются при масштабировании команды.

Ниже приведено обобщение схожих для нескольких проектных команд Pixonic черт. Посмотрите, а как бы вы сформулировали зоны ответственности внутри своих команд?

Часть [1/2] — Команда и роли в проекте

Роли в проекте

  • Продюсер — отвечает за сроки, бюджет, KPI, команду (найм\увольнение), концепт игры\баланс , организацию работы проекта в целом.
  • Гейм-дизайнер — отвечает за гейм-дизайн, UI, баланс, сюжет, фичи игры, концепт и тд.
  • PM — отвечает за сроки, бюджет и команду (найм\увольнение)

Нужно определить свои сильные и слабые стороны. Слабые стороны закрываются за счет найма профессионалов.

Если PM хочет стать продюсером, ему нужно учиться гейм-дизайну, если гейм-диз хочет стать продюсером, ему нужно учиться управлению.

Состав проектной команды и ответственность

1. Арт — Арт лид\арт директор + исполнители (+UI);

2. Код — тех лид\тех дир + исполнители;

3. QA — QA Lead+ исполнители (входит качество перевода);

4. Support\community\переводы;

5. Все остальное — маркетинг\аналитика предоставляется компанией;

6. Продюсер в ответе за все*!

*Продюсер следит за тем, чтобы все вышеперечисленное функционировало и члены команды правильно взаимодействовали. Он назначает и контролирует контролеров.

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

Как происходит рост проекта

1. Развивающийся проект с переизбытком должен быть обеспечен задачами от гейм-дизайнеров (менеджеров);

2. Если команда разработчиков (+QA) не успевает* выполнять эти задачи, то команду надо увеличить;

3. Если не успевает команда по арту — надо увеличивать ее;

4. Если не хватает задач, то необходимо увеличивать количество** гейм-дизайнеров (менеджеров);

5. Далее пункт 1.

*Речь про сроки. Если команда в принципе не способна выдать необходимое качество (за счет приемлемого увеличения сроков), то ее не расширяют, а “реструктуризируют”. **Качество геймдизайнеров заключается в постановке целесообразных и продуманных задач (с грамотным ТЗ).

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

Часть [2/2] — Постпродакшен: доработка, новые фичи и контент

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

  • Доработка;
  • Введение новых фичей;
  • Добавление контента.

Доработка (Улучшение/Исправление/Изменение)

Исправление, переделка чего-то уже имеющегося в игре. Например, изменение/добавление туториала, упрощение UI, перекройка баланса, фикс багов.

Перед запуском любой игры командой аналитики совместно с продюсером выставляются параметры, которым она должна соответствовать: Retention, ARPU, NPU, LTV и т.д.
Если после запуска показатели плохие — дается время на доработку игры, чтобы достичь требуемых показателей. Новые фичи в игру не вводятся! Если не получается доработать основу — игра закрывается. Ведь если основа проекта не работает, то наслоение на нее чего-то нового вряд ли спасет положение. (Как и не поможет надстройка дополнительного этажа зданию, у которого плохой и разваливающийся фундамент)

Введение новых фичей (Интенсивное развитие)

Внедрение в игру новых механик, функционала. Например, кланы, клановые войны, система событий, рейтинг, механика крафта/рыбалки/прокачки/чего_угодно_нового.

При разработке и вводе каждой фичи совместно с аналитиками определяется, насколько и какой параметр должен быть увеличен. Иногда в качестве KPI ставятся такие показатели как reviews, или кол-во взаимодействия с механикой на игрока в день и т.п.
Если фича не достигает целевого показателя — она дорабатывается, новые фичи в игру не вводятся. Если фича после 2-3 переделок все равно не работает, то либо фича не нужна в игре, либо на проекте плохой гейм-дизайн.

Добавление контента (Экстенсивное развитие)

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

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

Мораль

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

Другие материалы из этой серии:

Семинар 1: о выборе концепта

Семинар 3: принцип free-2-play


Поделитесь статьей: