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

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

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

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

Первый этап проектной деятельности. Инициация разработки и/или издания проекта в компании среднего размера

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

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

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

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

Экспертная группа для оценки потенциала проекта чаще всего состоит из тех сотрудников, которые неплохо разбираются в рынке. Под «неплохо» подразумевается достаточный опыт работы с рынком с точки зрения оценки качества и потенциала проектов. Такие люди обычно могут сравнить предлагаемый на разработку/издание проект с текущими трендами рынка – как затухающими, так и развивающимися, с реальным запросом аудитории, с конкурентными проектами, которые уже вышли или планируются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй этап проектной деятельности. Планирование проекта в компании среднего размера

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

1. Создание проектной команды.

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

Классический состав любой операционной группы по запуску проекта в компании среднего размера:

• продюсер проекта (опционально, в идеале желательно) обеспечивает общий контроль на проекте, особенно соответствия хода разработки тем целям, которые поставлены перед проектом, и доходно-расходной части проекта;

• менеджер проекта осуществляет операционную работу по общему контролю над всем проектом;

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

• руководитель проектной группы разработки/издательства или релевантного департамента решает общие организационные вопросы по запросу менеджеров проекта;

• ведущий разработчик проекта и аффилированные члены его команды – в том случае, если проект – это разработка;

• маркетолог проекта – обычно это аккаунт-менеджер из команды маркетинга, который согласовывает задачи оперирования/разработки проекта с маркетинговой командой и с командой подготовки маркетинговых материалов. Аккаунт-менеджером он явлется с точки зрения функционала, реальное название позиции может быть очень разным, чаще всего это бренд-менеджер. Если в компании нет PR-специалиста, маркетинговый менеджер может отвечать за PR-поддержку, участие компании в мероприятиях и т. д. Помимо этого, опять же, если в компании нет специалиста по коллаборациям/партнерским проектам с другими брендами, то это обычно становится задачей выделенного на проект маркетолога;

• технический специалист обеспечивает развертывание серверов, контроль над подключением платежных систем и т. д.;

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

• юрист на проекте – если в компании несколько юристов (часто в компании среднего размера два-три юриста), то проект и договоры по всему, что связано с проектом, закрепляются за определенным юристом;

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

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

2. Детальная разработка всей документации, требующейся для разворачивания разработки / издания проекта.

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

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

При этом доступы к конкретным документам в такой папке ранжируются в зависимости от уровня их важности и коммерческой ценности.

3. Подготовка потребностей проекта с точки зрения software (движки, аналитика, аккаунты для работы и т. д.) и hardware (оценка ресурсов и согласование бюджетов на их закупку).

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

4. Создание детального таймлайна проекта.

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

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

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

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

5. Маркетинговая кампания в деталях.

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

Для подготовки маркетингового плана предварительно обычно готовится маркетинговый паспорт проекта. В маркетинговый паспорт проекта вносятся основное USP (unique selling point – уникальное торговое предложение) проекта, его аудитория, жанр, сеттинг, ключевые персонажи и их наиболее вдохновляющие особенности с точки зрения маркетинга. А также проводится оценка проекта с учетом ситуации на рынке, включая анализ имеющихся похожих игровых проектов (уже вышедших или выходящих в ближайшее время) и маркетинговой активности конкурентных проектов.

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

• оценка необходимых объемов трафика для выполнения показателей по доходности проекта;

• закупка прямой рекламы в медиа (кроме закупки трафика);

• PR-поддержка проекта;

• план активностей с блогерами;

• участие в различных мероприятиях (выставки, конференции и т. д.);

• партнерские коллаборации.

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

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

Разработкой плана маркетингового продвижения проекта и списком требуемых материалов по маркетинговым активностям обычно занимается маркетинговый менеджер / бренд-менеджер проекта. При необходимости он привлекает других сотрудников команды маркетинга.

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

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

6. Подготовка договоров с подрядчиками, контрагентами, владельцами IP, сотрудниками на контракте.

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

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

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

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

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

Также с юристами обсуждаются и готовятся к согласованию документы на работу команд-подрядчиков по любым видам работ на проекте.

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

Тендеры бывают разными государственными и коммерческими, открытыми и закрытыми. Мы сейчас говорим о коммерческом тендере. Коммерческий тендер – это достаточно произвольное мероприятие с точки зрения его условий. Главное, чтобы они находились в правовом поле.

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

Задача HR-команды с точки зрения подготовки договоров – обеспечить подготовку всех документов, связанных с наймом дополнительных сотрудников, которых набирают на проект. Компании, помимо прямого найма в штат, также могут нанимать людей/команды на договоры гражданско-правового характера (договоры ГПХ) и договоры подряда.

Чаще всего детали таких договоров – это работа кадровой команды. После подготовки таких документов HR-команда согласовывает их с юристами. В целом количество найма дополнительных сотрудников и его способы (штат / ГПХ / договор подряда) зависят от решения CEO и топ-менеджмента. Эти решения принимаются с учетом оценки требуемых ресурсов и способов их привлечения. Например, договор ГПХ стоит использовать, если вы планируете нанимать людей только на определенный срок работы на конкретные задачи. Если же сотрудники нанимаются по ГПХ, но при этом делают относительно стандартный набор задач за достаточно долгий срок, то их стоит перевести в штатный состав команды.

7. Бюджет с учетом таймлайна, потребностей в маркетинге/команд и потребностей в инвестиции (с учетом их возврата).

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

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

В любом случае бюджет проекта воедино обычно собирается продюсером проекта или его ведущим менеджером, обсуждается с финансистами и после этого финально согласовывается с CEO. А при необходимости – и с советом директоров.

8. Оценка потребностей в инвестициях и способов их получения.

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

Решения о поиске инвестиций обычно принимает CEO и/или совет директоров (если он существует в компании) с учетом мнения финансового директора / ведущего финансиста и продюсера проекта / ключевого проектного менеджера.

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

Третий и четвертый этапы проектной деятельности. Исполнение и контроль исполнения проекта

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

1. Работа проектной команды на стадии разработки перед запуском проекта на издательские платформы, работа на самом запуске, оценка показателей проекта и их корректировка.

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

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

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

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

2. Разработка проекта.

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

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

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

3. Старт маркетинговой кампании проекта. После того как все планы согласованы, включая маркетинговый, начинается работа по продвижению проекта во всех запланированных маркетинговых направлениях. За выполнение маркетингового плана отвечает все тот же бренд-менеджер / маркетинговый менеджер проекта с привлечением директора по маркетингу.

Маркетинг стартует обычно с момента получения первых материалов по игре, а PR-поддержка – с момента согласования проекта в принципе. А перед стартом запуска материалов по маркетингу и PR нужно, конечно, подготовить посадочную страницу проекта желательно со скидками и другими предложениями к запуску проекта. Это первичная монетизация проекта для тех, кто уже готов платить, чтобы получить определенные бонусы к старту игры.

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

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

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

4. Работа с комьюнити.

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

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

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

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

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

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

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

5. Тестирование проекта.

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

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

6. Подготовка и выгрузка проекта на издательские платформы.

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

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

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

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

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

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

Руководством по запуску проекта на различных платформах занимаются операционные менеджеры проекта с подключением всей проектной команды.

7. Техническая поддержка проекта.

Как только проект будет запущен в публичное поле, его начнут покупать и даже играть в него. Почему я делаю разницу между «покупать» и «играть» – потому что сам, как игрок, покупаю много игр, но далеко не во все из них играю.

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

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

Техническая поддержка уже должна быть готова к первому, обычно очень объемному, потоку вопросов, начиная с классического «я все скачал, а игра не запускается» и т. д. Именно техподдержка – те, кто поможет игрокам ворваться на просторы выбранного ими проекта без потери драгоценного времени на изучение игрового мира и/или прокачку своих персонажей.

Если у вас ММО-проект или игра подразумевает онлайн-подключение, то у техподдержки будет много работы: сложности со скачиванием, совместимость с конкретными устройствами, сбои при подключении, падение серверов, технические вопросы.

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

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

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

8. Аналитика проекта.

С момента старта и до окончания оперирования выпущенным проектом все данные по нему собирает, обрабатывает и оценивает команда аналитики.

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

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

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

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

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

9. Юридическое сопровождение проекта.

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

10. Движение денежных средств по проекту.

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

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

11. Оценка исполнения бюджета.

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

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

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

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

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

Пятый этап проектной деятельности. Завершение проекта. Предпосылки к принятию решения о завершении проекта. Формализация результатов проекта и его фактическое закрытие

Проект в компании среднего размера обычно готовят к закрытию в следующих случаях:

• если проект не выполняет плановые показатели по аудитории – например, аудиторные показатели на проекте начинают плавно или резко снижаться;

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

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

• если по ряду причин команда разработки не может оперативно готовить обновления проекта (например, в компании идут структурные изменения и часть разработки перевели на другую игру);

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

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

• технологическое устаревание проекта – качество графики, устаревший движок, влекущие за собой снижение интереса аудитории;

• запуски и активности конкурентных проектов, имеющих больший потенциал и перетекание вашей аудитории в эти проекты;

• снижение интереса инвесторов к рынку в целом и, как следствие, к инвестициям в конкретный проект/команду/компанию;

• в целом снижение возможностей финансирования для того, чтобы развивать проект/проекты.

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

Если компания понимает, что интерес аудитории к проекту снижается, она обычно сначала снижает количество участников проектной группы, задействованных в его поддержке, а затем в принципе перестает поддерживать проект. Это в первую очередь касается игр-сервисов (онлайн-игры с развитым комьюнити, основные жанры – ММОРПГ, онлайн-шутеры и battle royale).

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

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

А если мы говорим об играх-сервисах типа ММОРПГ, то здесь закрытие проекта проходит в несколько шагов.

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

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

3. Уведомление игроков. Команда маркетинга, PR и комьюнити готовят материалы, в которых рассказывается о будущем закрытии проекта. Эти материалы обычно размещаются в игровых сообществах, посвященных проекту, и в СМИ. А также иногда осуществляется рассылка о будущем закрытии всем, кто подписался на новости от компании по выбранному проекту. Чаще всего такие материалы включают в себя предложение перейти на другие проекты компании и подарок за такой переход.

4. Отключение проекта от серверов. В определенный день проект отключают от выбранных серверов (а иногда от всех серверов). За отключение отвечает руководитель IT-службы или руководитель группы системного администрирования. Новость об отключении обязательно размещается во всех игровых сообществах, посвященных проекту. За этим обычно следит руководитель команды комьюнити-менеджеров.

5. Отключение проекта от аналитики. Проект отключается от аналитики на тех территориях, на которых происходит отключение серверов. За отключение проекта от аналитических серверов отвечает ведущий аналитик проекта.

6. Подготовка финансовой документации по проекту. Команда финансистов после получения последней документации по доходности проекта фиксирует прибыль за отчетный период оперирования проектом и производит распределение полученных средств с учетом договоренностей с партнерами. Руководит процессом финансовый директор.

7. Закрытие договоренностей с партнерами. Команда юристов под управлением операционного менеджера и продюсеров готовит все требуемые соглашения в связи с закрытием проекта и фиксирует получение и подписание договоров с партнерами и подрядчиками. При этом учитываются все обязательные действия каждого участника договора.

8. Постмортем по проекту (как минимум внутренний).

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

Обычно такие материалы, если они включают в себя детали под NDA типа финансов и нюансы договоренностей с партнерами, доступны топ-менеджменту и ключевым сотрудникам компании.

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

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

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

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

Этим темам я посвятил следующую главу.

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