& Magic V). Документ обычно создается в формате таблицы Excel (или Google Tab) и состоит из 4-х листов:
• Tasks – перечень всех известных нам на данный момент задач проекта с оценками по времени и атрибуцией по проектным этапам (прототип, альфа-версия, бета-версия, релиз, апдейты) и направлениям разработки (арт, программирование, дизайн и т. д.).
• Resume – суммированные трудозатраты по этапам, здесь мы видим сколько надо сотрудников на тот или иной этап, а также раскладку по необходимым проектным ролям (таким образом можно спланировать участие определенных специалистов и быть заранее готовыми к моменту, когда они понадобятся).
• Roadmap – тут уже не все, а наиболее важные задачи, разбитые по этапам в более читаемом виде с выделением целей для каждого этапа и ключевых позиций для сдачи версий.
• Staff Plan – состав команды, план вывода новых сотрудников по этапам проекта.
Работа над этим документом коллективная и идет в несколько итераций:
1. Перенести в лист Tasks основные задачи по реализации Feature Set проекта (да, вот тут он нам и понадобился). Просто садитесь и переписывайте все задачи, которые можете себе представить для реализации проекта, исходя из его свойств, описанных в концепт-документе. Чем полнее на этом этапе вы раскроете проект, тем меньше потом будет проблем с укладыванием его в бюджет. По необходимости здесь же производится декомпозиция сложных задач и добавление буфера на R&D (то есть исследовательские задачи, которые пока не очень понятно, как реализовать).
2. Атрибутировать задачи по их категории (арт, программирование, дизайн, продвижение, прочее), наличию на этапе релиза (да/нет), этапу, когда задача должна быть завершена, трудозатратам.
3. Задать в листе Resume коэффициенты – это общий буфер на работы по типам (все оценки будут увеличены на этот буфер). Например, если программирование для проекта подразумевает большое количество тестов и исследовательских задач, можно задать коэффициент 35 %, а если задачи по арту понятны и знакомы команде художников, то коэффициент может быть 10–15 %. Принципиальный момент в том, что буфер (даже небольшой, порядка 10 %) есть всегда, это основа безопасного планирования работ в игровой индустрии.
4. Сбалансировать документ относительно распределения трудозатрат по этапам разработки и соответствию численности команды. Полученные цифры должны соответствовать ограничениям, изначально наложенным на проект в документе Strategic Statement (ведь там вы уже описали и согласовали со всеми, что команда разработки составит, например, не более 15-ти человек).
5. Составить на базе списка задач Roadmap. По каждому проектному этапу выделяется ключевая задача, 2–3 важные подзадачи, а затем выписываются наиболее значимые задачи по категориям, выполнение которых будет проверяться на этом этапе. Также указываются особенности версии игры на данном этапе (технический прототип, играбельная версия, версия пригодная к закрытому тесту и так далее).
6. Заполнить Staff Plan – график подключения сотрудников к проекту. План должен соответствовать потребностям проекта в сотрудниках, формализованным в листе Resume.
В принципе, вы можете делать этот процесс как удобно вам, даже наличие таблицы здесь не является жестким требованием (хотя как без таблицы все это быстро посчитать, я не знаю). Наверное, часть работы по формированию объема задач и его оценке вполне можно провести коллективно на канбан-доске, а уже потом перенести в цифровой формат, но я лично никогда не пробовал так делать, хотя представляется, что это может быть эффективно за счет быстрого обсуждения всеми участниками проекта.
Как вы понимаете, на этапе, когда мы завершили таблицу, мы уже имеем набор документации по проекту, удовлетворяющий большинство потенциально вовлеченных лиц. Руководство сформулировало бизнес-требования, получило в ответ внятный план и сидит в своем кабинете, ждет будущих прибылей. Ключевые сотрудники проекта поняли сверхидею и основные задачи и уже ищут способы их решения, равно как и способы избежать самых сложных задач. Кадровый отдел планирует свою работу, опираясь на ваш Staff Plan, и уже расчехляет аккаунты на сайтах для хедхантеров, а финансисты могут понять, в каком квартале какие затраты будут на разработку вашего проекта. И даже если половины перечисленных специалистов у вас пока нет, вы вполне можете представить, что они есть – будет веселее. Гарантирую, как только вы сделаете первую хорошую игру – они все вмиг появятся, особенно финансисты. В принципе, осталась самая малость – валидация всей этой красоты отделом маркетинга, которая происходит в рамках следующего документа – Business Model.
Business Model (Бизнес-модель)
Очень надеюсь, что с отделом маркетинга вы уже предварительно обговорили свои идеи относительно нового проекта, получили принципиальное подтверждение и даже, возможно, совместно провели какие-то предварительные рыночные исследования. Теперь настала очередь предварительной же бизнес-модели проекта. Она также обычно формируется в виде таблицы и должна выявить набор ключевых метрик, при которых проект является прибыльным в среднесрочной или долгосрочной перспективе (обычно это от 1 до 3 лет). Ключевые параметры, которые нам нужно уточнить:
• способы и стоимость привлечения пользователей;
• количество органических (т. е. бесплатных) установок на привлеченного (т. е. пришедшего по оплаченной рекламе) пользователя;
• базовые значения удержания (т. е. так называемый retention, измеряемый в днях): R1, R7, R28 (числа означают процент игроков, остающихся с вами на соответствующий день после установки игры);
• конверсия активных пользователей в платящих (для проектов на условно-бесплатной модели) либо стоимость игры/подписки (для других моделей);
• сумма, приносимая платящим пользователем в месяц;
• иные способы получения дохода с проекта (если таковые предполагаются).
Необходимо понимать, что предварительная модель является прогнозом и реальные данные будут ощутимо отличаться в силу изменений на рынке за время разработки проекта. При этом назначение таблицы в том, чтобы проект был прибыльным при реалистичных цифрах в табличке. Ситуация, при которой цифры приходится поднимать к значениям сильно выше среднерыночных для того, чтобы сделать модель прибыльной, является маркером того, что с проектом есть какая-то фундаментальная проблема.
One Pager (Презентация проекта)
Этот документ является презентацией проекта, выполненной в формате One Pager – на одну страницу. В формате текст + инфографика сформулированы ключевые мысли о проекте, которые команда разработки хочет донести до лиц, принимающих решение о запуске. Я обычно использую следующую структуру презентации:
• слоган или лаконично сформулированная идея проекта;
• обзор идеи в формате «проблема/решение»;
• базовая концепция проекта;
• ключевые фичи проекта;
• структура игровой сессии;
• команда разработки;
• данные о сроках/стоимости разработки.
Но в целом здесь, конечно же, есть большой простор для творчества, так что презентация у вас может выглядеть по-другому. Если вы уже знаете, кому ее будете показывать, то хорошим тоном будет запросить желаемый формат презентации перед переговорами. Именно в силу этого презентация сокращена до минимального объема – так легче ее переделывать под каждый контакт. Ну и, конечно же, надо помнить, что ключевыми в вопросах переговоров являются люди, делающие проект, а не презентация. Все инвесторы уже давно догадались, что сама по себе презентация проект им не сделает.
На этом по документам, необходимым для принятия решения о запуске разработки проекта, все.
На этом главу можно было бы завершить, так как мы составили и даже описали весь перечень документов, которые должны получить в результате подготовки к производству. Но остается один очень важный момент – как структурировать этот процесс и разделить его на этапы?
Планирование всегда было бичом игровой разработки, и большое количество проектов провалилось именно из-за того, что делалось с сильным превышением бюджета, задержкой по срокам или со значительным люфтом по концепции (о том, как все эти проблемы сказочным образом объединились в одной игре, я рассказывал в комментарии про проект Navy Power). Поэтому будет уместным посвятить еще пару страниц основным этапам разработки игрового проекта.
Истоки именно такой этапности лежат, вероятно, в Nival, а уже в процессе дальнейшей карьеры я ее адаптировал к мобильным проектам, у которых своя специфика. Мобильные игры требуют большей гибкости и более синтетического подхода (то есть элементы игры больше похожи на конструктор для того, чтобы, например, можно было быстро сменить сеттинг или мету проекта). Но в целом и ПК-проекты не станут хуже от большей управляемости. Весь процесс разработки разделен на 5 этапов (у каждого этапа указаны ключевые задачи, которые должны быть реализованы):
1. Preproduction – концепция продукта и команда;
2. First Playable – технология и базовый геймплей;
3. Alpha – экономические циклы и мета;
4. Beta – расширение контента и UI/UX;
5. Release Candidate – полировка и финализация продукта.
Непосредственно к этапу производства относятся 3 стадии: First Playable, Alpha, Beta. Preproduction уже был раскрыт в предыдущем тексте, а Release Candidate относится уже скорее к процессу оперирования, поэтому о нем будет в завершающей части книги.
Повторю еще раз, в чем мы должны удостовериться на каждом из этих этапов:
• First Playable – проект преодолел все возможные технологические риски (то есть он банально стабильно работает на целевой платформе), и проект «играется». То, что мы показываем на этом этапе, должно быть работоспособным и интересным в своем базовом игровом процессе.
• Alpha – на этом этапе добавляются экономика игры и мета-уровень. На этом этапе проект становится кардинально сложнее по своей структуре. Именно поэтому до этого усложнения базовые проблемы с игровым процессом и стабильностью должны быть решены.