Надгробья современного геймдева. Поддержка пользователей

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

Давайте попробуем сегодня "сыграть наоборот": я докажу вам, что "саппорт не нужен". Без удивительных историй из моей практики (и жизни) в аргументах. Только здравый смысл, логика и беспристрастность.

Сегодня в прицеле - поддержка пользователей. А с ней то что не так? И что у "саппорта" общего с сектантами?


Чохочу?

Давайте попробуем вспомнить, что ожидается от Службы Поддержки Пользователей:

  1. Консультирование по особо мутным внутриигровым вопросам.

  2. Решение технических проблем.

  3. Урегулирование финансовых трудностей.

  4. Эскалирование баг-репортов.

  5. Аггрегирование обратной связи.

  6. Отсев мусора (спам, "когдапатч", "dead game" и прочий хлам).

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

1. Консультирование по внутриигровым вопросам

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

Нет, встречаются исключения типа

  • Path of Exile, Dark Souls и соулсоидов в целом, где необходимость методом научного тыка учиться играть правильно (или пересматривать видеогайды сутками) - это фича;

  • Oxygen Not Included, Craft the World и аналогичных "симуляторов неудобства", где собственно вся суть геймплея в креативной борьбе с неудобством, как на тактическом уровне, так и на стратегическом;

  • ADOM, Dwarf Fortress и иных игр "эпического" жанра, где физически невозможно уместить всё необходимое во внутриигровой мануал и распланировать интерфейс на абсолютно все возможности и потребности;

  • да мало ли...

Но в 99% (ну ладно, пусть будет в 50%) случаев разработчики разрабатывают отнюдь не нишевый продукт.

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

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

И каждая более-менее обоснованная заявка от пользователя на тему "а как вообще тут играть?" - это жирнющее пятно на репутацию создателя того функционала, который вызвал такой вопрос.

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

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

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

А как же Служба Поддержки Пользователей?

Беда в том, что для того, чтобы Служба Поддержки Пользователей могла адекватно консультировать игроков, такой же всеобъемлющий мануал нужен им. То есть, его всё равно придётся писать(хотя у трезвых людей он уже написан и откорректирован в ходе работы над дизайн-документом и над непосредственно игрой - но хто ж его нынче адекватно пишет в 202X году то).

Нет мануала - нет адекватных консультаций - есть рост недовольства у пользователей и лишние траты на сопровождение проекта...

...но вам не придётся писать мануал и содержать сотрудников поддержки, если у вас нет службы поддержки.

Недовольство то же - а затраты ниже.

2. Технические проблемы

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

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

Две проблемы в этой категории вижу я.

Проблема первая: если у игрока сколь-либо попсовая, ожидаемая конфигурация оборудования и сопутствующего программного обеспечения, - игра обязана работать у него без закидонов.

Если же что-то внезапно не подошло - игра обязана уведомить об этом игрока, явно и недвусмысленно: "не знаю, что Вы себе навертели, но мне не хватает оперативки / SSE2 / чорта лысого. Вы же ознакомились с Минимальными Системными Требованиями перед покупкой? Извиняйте, тут эта игра не заработает".

Или хотя бы крэшнуться, хотя бы и молча, но сразу при запуске.

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

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

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

Так зачем пытаться?

3. Урегулирование финансовых трудностей

Два слова: платёжный аггрегатор.

Пусть отрабатывают свою комиссию. Всё равно нужны будут данные по платежу, так чего гонять клиента туда-сюда?

4. Эскалирование баг-репортов

Начнём с того, что сама идея делать из игрока внештатного сотрудника QA - крайне порочна по своей сути.

Да, сейчас модно выбрасывать недоваренный пельмень продукта в Early Access и надеяться, что "пронесёт".

Нет, это не сэкономит никому денег. Особенно если игра давно в релизе, но по уровню качества всё ещё Early Access (76, 77).

Как и муть в игровой механике, баги отвлекают игрока от мыслей о том, как бы принести разработчику прибыль. А это очень, очень, очень, очень плохо (и не менее грустно).

Более того. Если у разработчика хоть немного адекватно поставлен процесс контроля качества - 99% входящих баг-репортов от пользователей БУДУТ бесполезными дубликатами.
А оставшийся 1% - лютой дичью, воспроизводящейся строго в ночь на Ивана Купала и строго если в штанах у игрока спрятан хомяк.

И то, рано или поздно QA и такую дичь поймает (скорее всего, уже поймали, только никому не скажут, чтобы не опухал бэклог).

Далее.

У разработчика уже есть профессиональный отдел QA.

Если встаёт потреба дополнить его непрофессиональными QA в виде игроков - что-то пошло ооооочень сильно не так.

Ведь тем бедолагам из поддержки пользователей, которые будут перерабатывать информацию от игроков, всё равно придётся попеременно дёргать "настоящих" QA (мануала то нет, см. пункт 1) и своего шефа (ведь вместо этой бесполезной работы можно было заняться своими основными обязанностями).

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

Да и самим игрокам не мешало бы подкинуть чего-нибудь эдакого за неудобства... но не принято, да-с...

Так к чему лишние траты?

5. Аггрегирование обратной связи

Ох, сколько всего неожиданно плохого с этим пунктом...

Тут и вредность мнения большинства.

И необходимость мирить ёжика с ужиком, повседневный AGILE с необходимостью держать резерв времени на доработки сообразно обратной связи от игроков.

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

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

Десять шагов вперёд, девять шагов назад.

Чья это работа - решать, что лучше для игрока и как это принесёт больше прибыли, собирать данные и делать из них адекватные выводы?

Вот то-то же.

Если "царю" понадобится "пройтись среди народа", послушать, что хорошо, что плохо, да идей понабраться на будущее, - он это может и сам сделать.

Совершенно без помощи не владеющих нужными навыками сотрудников не заинтересованного в этой работе отдела.

Достаточно поддерживать в перманентно бурлящем состоянии "котёл" с идеями где-нибудь, где можно легко и быстро поискать эти самые идеи. Например, на форуме. И не забыть туда дорогу (и правила повседневной вежливости, если пропрёт на пообщаться с народом).

6. Отсев мусора

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

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

Повторю парадокс:

  • на обеспечение качественного обслуживания у компании денег нет, ведь все эти мануалы и тесты и прочее кто-то должен написать и/или запрограммировать,

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

Так, может, пора направить эти деньги туда, где они реально принесут пользу?


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

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

За последние десять лет мне пришлось пережить массу удивительнейших разборок:

  • от затяжной ругани из-за купленной во внутрилаунчерном магазине делюксовой версии, в которой не оказалось делюксового контента (больше года "грязного" времени потрачено, спасибо, Ubisoft!),

  • и до довольно трогательной беседы о доначислении акционного имущества (как ни странно, Bethesda, вы себя реабилитировали в моих глазах).

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

Я как бы пытаюсь подвести черту и под тем, и под этим.

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

Тренды неутешительные.

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

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

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

А вот надежда, что я снова застану времена, когда в Amazon Games можно было, помимо прочего, посоревноваться с сотрудником в витиеватости пожелания доброго здравия, а в Paradox - вместе мило поиронизировать над очередным удивительным багом, - уже угасла.

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

Может, пора "вернуться к корням"?

Источник: https://habr.com/ru/post/662780/


Интересные статьи

Интересные статьи

"Сесюрности мало не бывает!" (с) Джейсон СтетсонЧем больше мер безопасности, тем реже у пользователей что-то пропадает, тем меньше техподдержка тратит время на рутину, тем спокойнее проходят внутриигр...
Всем привет! Я Дима, начинающий разработчик. В статье расскажу о своем первом опыте работы в крупной продуктовой IT-компании.Я пришел в ЮMoney полгода назад, когда мне бы...
В этой статье расскажу, как с помощью Git я управляю файлами в своём домашнем каталоге и синхронизирую их на других устройствах. У меня несколько устройств: лэптоп на работе, стацион...
Привет, Хабр! На прошедшем 28 января Luxoft TechFest, Михаил Занкович, Senior Team Lead в Luxoft, рассказывал про приложения с тяжелой наследственностью. Сегодня он делится дополнител...
В этой инструкции показывается как настроить пользователей только для чтения в PostgreSQL для Redash. Читать дальше →