Шість правил ефективної LiveOps-команди: досвід Mech Arena

Привіт, мене звати Аня, я Team Lead LiveOps-команди на проєкті Mech Arena. Це динамічний PvP-шутер із бойовими роботами, орієнтовний на командну взаємодію. У грі — різні режими, десятки мехів, пілотів, видів зброї та понад 50 мап для боїв з особливим ігровим процесом на кожній.

Наша команда відповідає за те, щоб гра залишалася цікавою та динамічною для гравців. Що це означає на практиці? Ми плануємо й запускаємо внутрішньоігрові активності, як-от спеціальні тимчасові події (івенти), завдання, пропозиції та турніри, які мотивують користувачів повертатися в гру частіше, грати довше або випробовувати новий контент.

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

У цій статті я поділюся практиками, які можуть стати в пригоді й командам, що тільки стартують, і тим, хто вже давно в процесі роботи. Якби я зараз формувала LiveOps-команду з нуля, орієнтувалася б саме на ці правила.

1. Мати гнучкий роадмап проєкту на рік та регулярно його переглядати

Команди LiveOps мають цільові КРІ, які є індикатором того, наскільки гра цікава для користувачів. Це допомагає визначити її майбутнє та можливості розвитку. Ключовим інструментом нашого планування є роадмап — структурований план того, що ми будемо додавати до проєкту протягом року. Така стратегія допомагає забезпечити чітке бачення та досягнення цілей, синхронізуватися з іншими командами, передбачити, які ресурси потрібні, а також ефективно розподіляти час. Усе це ми зазначаємо у звичайних Google Sheets.

За допомогою роадмапу планується не тільки наша робота. LiveOps-активності безпосередньо впливають і на інших фахівців, як-от арткоманда, геймдизайнери, клієнтські й серверні розробники, UI/UХ-спеціалісти, тестувальники, аналітики, ком’юніті та команди, що розробляють внутрішні інструменти для оперування. Адже їм також потрібно виконати свою частину завдань заздалегідь.

Щоб забезпечити ефективну координацію між усіма залученими сторонами, ми визначили оптимальний горизонт планування — на рік уперед. Такий підхід дає змогу ефективно розподіляти навантаження й запускати контент стабільно, якісно та вчасно.

Який вигляд має процес створення роадмапу для нас

Ми розпочинаємо з того, що разом із командою аналітиків визначаємо, на яких показниках фокусуватимемося надалі. Це можуть бути Retention D1, D7, D30, Conversion певних днів або інші — саме вони формують базу та цілі.

Далі проводимо брейншторм, де обговорюємо, як досягатимемо поставлених цілей через уже наявні активності або допрацювавши їх, і генеруємо ідеї LiveOps-фічей, як-от нові типи оферів або подій. Про те, як саме відбувається такий брейншторм, поділилася нижче в правилі 5.

Також у Mech Arena регулярно з’являється новий контент, який доставляється гравцям. Цей делівері флоу теж треба спланувати й зробити частиною роадмапу. Зазвичай передбачені такі етапи:

• планування списку потрібного контенту;
• планування івентів (у нас це сезони), у межах яких у гру доставлятиметься цей контент;
• спільне планування роботи з командами Game Design, LiveOps, Development, Art тощо, щоб усе це стало можливим.

Отже, наш фінальний роадмап на рік містить:

• нові LiveOps-фічі;
• імпруви до поточних LiveOps-фічей;
• перегляди балансів наявних активностей;
• інструменти для оперування — дашборди, інтерфейси для запуску. Адже від команди LiveOps потрібно завчасно сформувати запит із детальним описом того, що саме це має бути й для чого використовуватиметься;
• активності в грі, за допомогою яких новий контент з’являтиметься в гравців.

Приблизно через пів року настає момент, коли ми актуалізуємо поточний роадмап і продумуємо ідеї, які реалізовуватимемо вже після окресленого періоду. Чому саме такий термін? Це оптимальна кількість часу для нас, щоб визначити основні фокуси, провести брейншторми, зібрати список ідей та передати його всім залученим командам.

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

Формат роадмапу має залишатися достатньо гнучким, щоб його можна було адаптувати до змін пріоритетів, зовнішніх чинників або результатів аналізу. Вибирайте такі інструменти й підходи, завдяки яким можна оперативно оновлювати плани без втрати загальної структури та фокусу.

2. Підлаштовувати командні інструменти й процеси під цілі та в разі потреби їх актуалізувати

Роботу LiveOps-команди бачать усі: гравці одразу помічають запущені турніри, знижки, івенти тощо. Але те, як саме це реалізується, скільки часу йде на налаштування кожного елемента й аналіз загалом і, як наслідок, на коригування балансу, відомо лише нам. Щоб ефективно використовувати ресурси й оптимізувати рутинні дії, ми намагаємося максимально автоматизовувати процеси. Є два принципи, що економлять наш час.

2.1. Підтримувати та створювати внутрішні інструменти

Ідеться про інтерфейси, які полегшують і пришвидшують роботу LiveOps-фахівця, зокрема автоматизують налаштування оферів та активностей. Під час розроблення нової фічі ми завжди плануємо не лише її ігрову цінність та мету, але й спосіб запуску.

Навіть якщо вже на старті зрозуміло, що елемент потрібно буде допрацьовувати чи змінювати, паралельно з його дизайном має створюватися й відповідний інтерфейс для запуску. Щоб це зробити, ми формуємо технічні вимоги та передаємо їх команді, яка займається розробленням внутрішніх інструментів.

Як ми до цього прийшли

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

Шлях до цього рішення був довгим. Один із показових прикладів — активність «Гонитва за скринями». На етапі концепції ми розуміли, що її функціональність ще буде розширюватися, тому свідомо вирішили не створювати інтерфейс запуску одразу, а повернутися до нього вже після фіналізації фічі. Як наслідок, реалізація інструменту затягнулася більш ніж на рік.

Упродовж цього періоду ми й надалі запускали активність уручну. Згодом провели оцінювання та зрозуміли, що таких івентів стало суттєво більше, тому й на налаштування тепер витрачається значно більше ресурсу, ніж хотілося б. З огляду на потенційну економію часу після автоматизації, ми вирішили підвищити пріоритет розроблення відповідного інтерфейсу, а також ще кількох внутрішніх інструментів, що мали оптимізувати наші процеси.

Раніше ми фокусувалися тільки на досягненні цілей гри, відкладаючи технічне вдосконалення. Цей кейс навчив нас: зручний і стабільний процес запуску — така сама ціль, як і будь-який КРІ.

Tip. Коли розробляєте нову фічу, одразу плануйте, як вона буде запускатися. Якщо можливо, автоматизуйте процес або закладайте розроблення інструментів, які мінімізують мануальну роботу.

2.2. Оптимізувати процес аналізу

Аналіз результативності — невіддільна частина підготовки будь-якої внутрішньоігрової події, тож цей етап також потребує ефективної оптимізації. Щоб оперативно оцінювати результати без постійного залучення команди аналітиків, ми використовуємо дашборди. Це один із ключових інструментів для самостійного моніторингу показників. Дошки мають бути максимально актуальними й охоплювати типові запити команди, щоб забезпечити швидкий доступ до даних у щоденній роботі.

Якщо ми розуміємо, що аналітики отримують від нас якийсь запит регулярно, то просимо їх створити дашборд або додати потрібні дані в наявний. Команда аналітики не витрачатиме час та зусилля на стандартизовані запити, а в нас будуть актуалізовані дані в будь-який час.

3. Завжди мати план Б: ураховувати ризики й готуватися до будь-якого сценарію

Під час розроблення концепції фічі ми очікуємо позитивного впливу на KPI проєкту. Але завжди є ймовірність, що щось може спрацювати не так, як прогнозували. Що ретельніше все продумано та протестовано, то меншим є ризик, хоча повністю мінімізувати його неможливо.

Як це працює в нашій команді

Ще до старту розроблення фічі ми обговорюємо потенційні ризики із залученими командами та формуємо відповіді на пʼять запитань, наведених далі.

1. Що будемо робити, якщо запуск не підвищить очікуваний KPI?
2. А якщо спричинить негативні наслідки: зменшить KPI чи розчарує гравців?
3. Які ризики ми бачимо вже зараз? Чи можемо їх зменшити на етапі дизайну або підготуватися до них заздалегідь?
4. Чи будемо вимикати фічу в екстреному порядку?
5. Якою буде наша комунікація до, під час і після запуску?

Tip. Коли плануєте запуск фічі, ураховуйте всі можливі сценарії розвитку подій, особливо негативні. Завчасно обговоріть із залученими командами план дій на випадок, якщо щось піде не так. Наприклад, команди, що відповідають за комунікацію з гравцями, мають знати про всі потенційні ситуації, щоб підготуватися до кожної з них.

4. Забезпечити чітку комунікацію та зрозумілі процеси між командами

Робота LiveOps-спеціаліста неможлива без тісної взаємодії з іншими командами й департаментами. Від створення нових фіч до запуску A/B-тестів для перевірки гіпотез — майже до кожного процесу залучені фахівці з аналітики, геймдизайну, розроблення, арту тощо. Комунікація з ними й планування спільної роботи над завданнями є невіддільною частиною діяльності нашої команди.

Як ми налаштували цю взаємодію

Щоб уникнути зайвої комунікації та оперативно трекати прогрес, у роботу інтегрували Slack-бот. Він автоматично сповіщає учасників про зміну статусу завдань, призначення відповідальних осіб або появу необхідних даних. А після завершення завдання надсилає фінальне повідомлення. Завдяки цьому кожен знає, хто за що відповідає, на якому етапі робота і які подальші кроки.

Навіть якщо процес добре працює тривалий час, буває так, що в когось із команди можуть виникнути сумніви: чи коректно розподілені ролі, чи логічно, що саме цей спеціаліст виконує конкретне завдання, чи ефективно побудований сам процес? У такому разі ми виносимо питання на спільне обговорення.

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

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

5. Помічати зони розвитку наявної функціональності й покращувати її не менш важливо, ніж розробляти нову

Виявлення проблеми — уже половина шляху до її розв’язання. Наші гравці щодня отримують новий ігровий досвід, розвиваються та змінюються. Тому важливо постійно переглядати та покращувати пропозиції, удосконалювати активності, а також знаходити зони розвитку. Однак для цього потрібно створити певні умови. Бо коли все стабільно, можна пропустити момент, у який щось почне працювати не так ефективно, як раніше.

Саме тому ми регулярно повертаємося до вже налагоджених процесів, щоб подивитися на них інакше та вчасно виявити, що потребує змін. Це допомагає по-новому сприймати наявні інструменти та, як результат, мінімальними зусиллями покращувати КРІ.

Як такі умови створюються в нашій команді

Раз на два тижні ми проводимо командні міти, щось на кшталт ретроспективи, де кожен ділиться чимось цікавим зі своєї зони відповідальності. Формулювання «щось цікаве» використовуємо навмисно, щоб не обмежувати LiveOps-спеціалістів у виборі теми. Це може бути як результат запуску нового промо, так і спостереження за перебігом сталих активностей. Кожен самостійно вирішує, що варте уваги колег.

Під час обговорення вся команда максимально залучена в процес, будь-які коментарі та пропозиції цінні для нас.

Що ми зробили завдяки цим мітингам

• Провели численні тести для перевірки гіпотез, які виникли під час обговорень.
• Змінили баланси на ті, що краще працюють.
• Запустили нові комбінації активностей.
• Змінили частоту запуску різних типів оферів.

Нижче скріни дошки, на якій проводиться цей міт. Ми трохи допрацювали під свої потреби MIRO-template Quick Retrospective.

А ось так ми фіксуємо результати:

У нас є напрацьований шаблон, за яким ми регулярно проводимо організовані брейншторми, щоб генерувати ідеї для розвитку наявної функціональності. Наприклад, у найближчому майбутньому плануємо дві зустрічі, які спрямовані на оновлення підходу до поточних активностей та промо, а також визначення їхніх цілей і шляхів використання інструментів.

Шаблон брейншторм-мітів

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

Tip. Для себе ми визначили оптимальну кількість таких мітингів: ретроспектива проводиться раз на два тижні, а брейншторми — коли є запит, як-от актуалізувати підхід до запуску поточних активностей, або в разі планування роадмапу, щоб згенерувати ідеї.

6. Розвивати себе як спеціаліста

Last but not least. Цілі команди, департаменту, компанії, досягнення місячних КРІ, планування та правки до поточних планів тощо — за всім цим можна загубити власні бажання та шляхи розвитку. Саме тому для LiveOps-спеціаліста, як і для будь-якого іншого фахівця, важливо не втратити фокус на власних цілях, які допомагають зростати.

Що ми робимо для цього

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

Такий підхід допомагає краще розподіляти завдання, адже враховуються сильні сторони, інтереси й потенціал кожного. Якщо спеціаліст працює з тим, що йому дійсно цікаво або цінно з погляду розвитку, це напряму впливає на якість виконання: зростає залученість, ініціативність і відповідальність. Ситуація win-win і для фахівця, і для команди.

Також ми підтримуємо періодичний перегляд зон відповідальності. Це допомагає уникнути рутини, забезпечити обмін знаннями всередині команди та сприяти постійному зростанню кожного учасника.

Ми розвиваємося й у суміжних напрямах, зокрема в аналітиці та геймдизайні, адже вони тісно пов’язані з нашою щоденною роботою. Наприклад, коли аналізуємо перші результати запуску промо чи нової фічі, потрібно розуміти, які дані й метрики переглядати та як їх інтерпретувати. А під час створення нових LiveOps-активностей важливо мати геймдизайнерське мислення, щоб розуміти, як фіча буде працювати в грі та впливати на поведінку гравців. Тому ми постійно прокачуємо потрібні навички — це корисно як для команди, так і для особистого розвитку.

Відвідуємо воркшопи, майстер-класи, після цього обовʼязково обговорюємо результатами та думками одне з одним, пробуємо застосовувати набуті знання в роботі. Ми намагаємося пам’ятати, що треба не тільки виконувати поставлені КРІ (це, безумовно, важливо), але й продовжувати розвиватися та цікавитися галуззю. Я також заохочую кожного співробітника ділитися новими знаннями, проводити внутрішні лекції та дискусії.

Tip. Не забувайте відзначати, що з робочих завдань вам подобається найбільше, і проговорюйте це зі своїм керівником. Такий простий крок допоможе менеджеру краще розуміти ваші цілі й очікування в розвитку та враховувати їх під час формування навантаження команди, а також підсилювати вашу експертизу через релевантні завдання.

ВИСНОВОК

Ці правила, поступово сформовані на основі спроб, помилок і спостережень, допомагають нам працювати структуровано, не втрачати фокус, підтримувати ефективність на дистанції та зберігати командну енергію. Завдяки їм ми не просто виконуємо завдання, а постійно вдосконалюємо як підходи, так і себе в професійному плані.

Буду рада, якщо щось із цього стане в пригоді вам і вашій команді. Маєте власні практики? Діліться в коментарях, буде цікаво порівняти досвід.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини