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

Повторюсь: как бы мы ни казались иногда далеки друг от друга, но работа и отношения с командой разработки – одна из важнейших составляющих успешного КМ-подразделения.

Вполне объяснимо, что оно не хочет заниматься только мемасиками и комментариями в стиле «ваше мнение услышано, обязательно передадим (но это не точно)».

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

Почему работать по-настоящему вместе с разработчиками так важно? Да потому, что эти люди создают игру! Без них и общаться-то не о чем. Вам именно с их продуктом работать 100 % времени. И, что характерно, они будут создавать эту самую игру что с вами, что без вас. Но без вас, скорее всего, в какой-то степени хуже.

Если, конечно, вы не только про мемасики.

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

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

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

А тот, как положено человеку из разработки, полез в статистику. Оттуда выяснилось, что на самом деле проблема с точки зрения частоты не касается значимого числа игроков: процент гибели танков от авиации в этом режиме незначителен в сравнении с другими причинами гибели.

Логично. И продюсер закономерно посчитал, что мы пришли терять его время, потому что эти данные могли получить и сами, благо доступ имелся. Кто тут прав? Сложно сказать. На самом деле, проблема существовала. Но, во-первых, – больше в эмоциональном поле, чем на поле реальных цифр (это очень частое явление при работе с игроками). А во-вторых, ее причины были несколько иными, нежели озвучивалось в записке, поскольку симптом и причина заболевания, как известно, могут быть весьма неочевидно связаны.

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

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

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

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

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

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

В игре War Thunder было более 3000 моделей различной военной техники, сотни улучшений и модулей, часто специфичных для каждой из них. И тут не обойтись пониманием, чем танк отличается от БТР или даже чем гладкоствольный танк отличается от такого же, но с нарезным орудием. Нужно углубляться в детали. И часто придется искать понимающих сотрудников изнутри самого комьюнити игроков, потому что они уже инвестировали свое время в понимание игры и им эта тема интересна. Но и у такого подхода есть подводные камни: игроки со сложившимся мнением, попав в команду, тяжело «переучиваются» на реальное восприятие продукта. И общаться их чаще всего никто специально не учил.

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

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

Теоретически можно сказать, что это обязанность разработчиков и, конечно, QA. Так и есть: разработчик, не играющий в свою игру, – это тоже не очень хороший разработчик. А уж QA ее вообще должны знать досконально. Но по факту большинство из них проводят время на дев- или тестовых контурах, т. е. играют не в конечный продукт, а в его тестовые внутренние версии во время разработки, когда игроков-то всего десяток-другой и они – прочие сотрудники. А до продакшена (т. е. до публичной версии игры, где сидят живые игроки) добираются сильно реже и не все. Разве что самые ответственные не забудут регулярно играть на проде. Но, скажу честно, таких немного. У людей не хватает сил и замыливается глаз.

Хотя есть компании – например, знаменитый Riot Games (League of Legends, LoL), – которые знамениты тем, что все их сотрудники играют в обязательном порядке. Даже на собеседования на любые вакансии надо сообщать свой игровой ник, чтобы они проверили статистику кандидата в игре, насколько он ею увлечен и понимает ее. Я когда-то давно подавался на одну вакансию в Riot Games. В то время аккаунта внутри LoL она еще не требовала, но все равно первый этап собеседования состоял именно из подробного обсуждения личного игрового опыта в играх разных жанров. И это верная практика.

В Gaijin раньше, когда еще все работали в офисе, прямо в столовой висело огромное табло, куда выводилась игровая статистика сотрудников по отделам. И все радостно обсуждали: «Что-то наш Х последнее время совсем плохо играет, потому у него и косяки в настройках потом. А вот Y – молодец: почти всех гейм-дизайнеров уделал, профи!» Прекрасный подход к описанной практике заставлять сотрудников играть в свой продукт.

В любом случае от КМ ожидают игры́ на проде. И поэтому КМ часто чувствует живую игру лучше – видит не только баги и проблемы баланса, но и общие нюансы массового геймплея (для многопользовательских игр), который труднее понять, играя короткие тестовые сессии с небольшим количеством сотрудников. Тем КМ и ценен. Кроме того, он неизбежно лучше понимает эмоциональный фон продакшена, потому что КМ питает животворная энергия игроков. Ладно, о «животворной» я пошутил, но энергия часто мощная – это правда.

КМ – как последняя линия обороны от ошибок. На эту тему у меня с разработчиками было много разных бесед. Но суммировать их можно фразой Кирилла Юдинцева (сооснователь и креативный директор Gaijin) о том, что КМ должен знать игру, видеть проблемы и, когда необходимо, стоять внутри компании насмерть за их решение. То есть быть еще одним уровнем условного QA, способным вцепиться зубами в вилку деплой-машины – системы, на которой осуществляется сборка игры в финальный программный продукт перед выпуском его на общий продакшен-контур игрокам. И не дать выкатить очередное обновление в мир, если игроков там ждет какая-нибудь засада.

Так что реально, кроме пресловутых мемасиков, приходится иметь в кармане еще и гранату, тельняшку (чтобы было что порвать) и каску. Хотя был случай, когда сам Кирилл нас с этим и отфутболил на эмоциях. Помню, к выпуску готовилась функция улучшения физики гусениц танков в War Thunder. К счастью, не на продакшен, а на открытый тестовый контур, доступный игрокам перед крупными обновлениями. Все бы ничего, но она подразумевала, что траки начнут чаще скользить на склонах, особенно боком. Это выглядело бы реалистично, мы же за честную физику. Но не подумали, что в левел-дизайне игры танкам приходилось бы скользить слишком часто.

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

В общем, мы попробовали встать грудью на оборону. Но так как функция казалась «математически верной», были жестко отодвинуты, и она ушла на открытый контур. Минут через тридцать посыпались жалобы и ругань игроков. Кирилл вступил с ними в спор и через некоторое время был аргументированно побежден. Функцию откатили и убрали на долгую доработку.

Выходит, что даже формальное правило «стойте насмерть» не означает, что ваша смерть не даст ошибке произойти. Но стараться надо.

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

Только в реальности разработчики действительно заняты и информация часто приходит в последний момент, а то и вовсе в таком формате: «Сообщаем, что сейчас на прод поедет одна фича…» Или еще смешнее: «Мы тут выпустили – напишите игрокам…» Это, конечно, неконструктивно. Но неизбежно, если вы сами не предпринимаете шаги, чтобы быть в курсе.

Общайтесь в условных курилках, читайте чаты разработчиков и т. п. За вас никто этого не сделает. И помните: нельзя быть попугаем. Разберитесь в теме!

Проиллюстрирую байкой из собственного опыта в другой индустрии. Я курю трубку. А фишка трубки в том (кроме прекрасного вкуса настоящего табака, а не этого всего со «взорванной жилкой»), что курить ее довольно долго, 30–40 минут минимум. И на довольно раннем этапе моей карьеры это меня сильно выручило. Пока я пару раз в неделю стоял в зоне курения на парковке у офиса и дымил, мимо успевала пройти пара десятков курильщиков сигарет со своими нервными и быстрыми затяжками.

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

Конечно, тут не просто трубка помогла (зато образ красивый – запоминается).

Резюмирую. Как сказал старый КМ War Thunder Евгений Моисеев (Squier), пока мы с ним беседовали по другой теме, «разработчики должны давать информацию, а КМ – превращать ее в публикации и активности. На это нужно время. А то часто приходят и говорят без должной формулировки: „Опубликуйте вот это!“ – не думая о том, чтобы хватило времени на исправление ошибок и планирование контента, не думая о том, как он зайдет. В таких случаях получится неэффективная ерунда».

К сожалению, чтобы разработчики понимали ценность своевременной и качественной подачи информации от них к КМ, а от КМ – вовне, им нужно уметь объяснять разницу на цифрах. Например – сравнивая продажи после качественно продуманной и после второпях поданной новости о товаре. Или сравнивая цифры участия и удержания игроков в событии, которое смогли описать хорошо и красиво и которое описать так не смогли. Ну или количество негативных отзывов на Steam после необдуманно выкаченного на продакшен изменения без соответствующей информационной подготовки. Об этом мы поговорим позже.

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

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

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