Комьюнити-менеджер (Community Manager)

Работает с комьюнити. Постит в фейсбучек. Зачитывает тосты, проводит конкурсы. Может трактоваться как своеобразный подвид PR-менеджера.

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

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

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

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

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

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

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

Причин тут несколько, но основная заключается в том, что, если отпускать развитие компании на самотек, концепция будет формироваться «как придется». И на момент открытия юридического лица это будет делаться исходя из сугубо внешних факторов. Что практически всегда не на руку разработчику.

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

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

1. Хобби-разработка.

2. Индустриально-ориентированная продуктовая разработка.

3. Бизнес-ориентированная продуктовая разработка.

4. Это отдельный тип компаний (вне основного списка) – сервисно-ориентированный бизнес, связанный с разработкой полного цикла. Он не лежит в фокусе нашей темы, но его невозможно обойти и не обсудить хотя бы вкратце.

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

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

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

Характеризуется следующими ключевыми факторами.

› Зачастую один или максимум два автора-разработчика. Может быть, что-то на аутсорсе.

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

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

› Логичным образом из предыдущего пункта вытекает, что это зачастую маленькие, в разной степени профессиональные или не очень игры. С точки зрения продукта – в первую очередь для ПК.

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

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