«Часть команды либо сидит без работы, либо овертаймит без остановки»: 7 главных ошибок менеджера при разработке игр

AB Games — студия разработки с украинскими корнями, которая создает игры в жанре free-to-play Hidden Object. В разработанную компанией игру Hidden City каждый день играют более миллиона людей из всех стран мира. 

Меня зовут Ольга Онищенко, я — Game Producer Hidden City. Сегодня я  поделюсь лайфхаками, как настроить процесс разработки игры, чтобы минимизировать простои, укладываться в дедлайны и организовать команду для наилучшей продуктивности.

Как минимизировать простои?

Сразу оговорюсь: если команда больше нескольких человек, накладки/простои будут в любом случае. Это нормально. Основная задача менеджмента — свести их к минимуму.

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

Допустим, QA Engineer Сигизмунд каждый день задерживается на три часа после работы. Как выяснить, почему это происходит? Он не успевает? У него слишком много задач? Он недостаточно компетентен для текущих задач? Ему слишком поздно выдали артефакты для тестирования? Или просто он ждет, когда у ребенка закончится тренировка в школе через дорогу, чтобы забрать его домой?

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

Тут отмечу: для более-менее большого проекта (20+ человек, не говоря уже про проекты на 200+, на 1000+ человек) нужно выделить хотя бы одного менеджера на полный день, чтобы разобраться, что не так с планированием, и как устранить проблему.

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

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

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

История про самоорганизующиеся высокоуровневые команды из скрама — прекрасна, но что делать, если у нас бόльшую часть команды составляют специалисты уровня junior и trainee?

Не нанимать джунов — не вариант, иначе откуда будут появляться новые специалисты в индустрии? 

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

Я бесконечно благодарна команде проджект-менеджеров Hidden City за те изменения, которые они имплементируют последние полгода на проекте, и которые помогли нам честно оценить свою текущую ситуацию в разработке и сдвинуться в направлении снижения энтропии.

Вот что привело к качественному улучшению планирования в нашем случае:

• введение нового подхода к эстимации задач (отдельно командой и тимлидом);
  
• введение практики трекать все процессные задачи;
• переэстимация стандартных задач и отказ от тех, которые не добавляли ценности конечному продукту;
Онлайн-інтенсив "Як створити рекомендаційну модель за 2 дні" від robot_dreams.
Ви пройдете етапи вибору, навчання, оцінки рекомендаційної моделі для електронної бібліотеки та отримаєте індивідуальний фідбек від лекторки.
Приєднатись до інтенсиву
• общее планирование работы исходя из постулата, что в течение дня эффективно тратится не больше шести часов.

Главные ошибки при настройке производства апдейтов

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

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

В этом процессе можно допустить несколько ошибок.

1Неправильно оценить скорость потребления контента

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

2Неверно оценить работоспособность команды

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

3Забыть учесть какую-то функцию в организационной структуре

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

4Не заложить возможности инфраструктуры на поддержку постоянных апдейтов

Или не предусмотреть возможность быстро эту инфраструктуру дописать/дорастить/арендовать.

Неоднократно слышала, что есть множество проектов с прекрасной архитектурой, про которые никто не слышал, кроме ближайших родственников разработчиков, и, наоборот, проекты с мировым именем и ужасной архитектурой/инфраструктурой. Я лично не думаю, что есть 100% корреляция между позицией в топ-гроссинг (продукты, приносящие наибольший доход — прим.) и красивостью «внутренностей» проекта, но, без сомнения, как только проект показывает свою жизнеспособность, следует озаботиться вопросом инфраструктуры. К слову, проблемой Hidden City долгое время была ручная сборка билдов (которой занимался ни много ни мало сам CTO). В текущем году мы наконец-то решили и этот вопрос.

5Неправильно оценить уровень самоорганизованности команды

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

6Завести аккаунт в сторе на почту, которую никто не просматривает

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

7Отложить на потом вопросы соблюдения лицензии

Last but not least — отложить на потом вопросы соблюдения лицензионных условий использования и IP третьих сторон, и работа с личными данными пользователей.

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

Чего точно не стоит делать — занижать сроки в надежде, что как-нибудь получится сделать побыстрее.

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

Читайте также: Как казуальные игры стали мегапопулярными и что делать, чтобы люди за них платили