Как делать хорошие игры. От идеи до запуска - Петр Прохоренко
• 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 – на одну страницу. В формате текст + инфографика сформулированы ключевые мысли о проекте, которые команда разработки хочет донести до лиц, принимающих решение о запуске. Я обычно использую следующую структуру презентации:
• слоган или лаконично сформулированная идея проекта;
• обзор идеи в формате «проблема/решение»;
• базовая концепция проекта;
• ключевые фичи проекта;
• структура игровой сессии;
• команда разработки;
• данные о сроках/стоимости разработки.
Но в целом здесь, конечно же, есть большой простор для творчества, так что презентация у вас может выглядеть по-другому. Если вы уже знаете, кому ее будете показывать, то хорошим тоном будет запросить желаемый формат презентации перед переговорами. Именно в силу этого презентация сокращена до минимального объема – так легче ее переделывать под каждый контакт. Ну и, конечно же, надо помнить, что ключевыми в вопросах переговоров являются люди, делающие проект, а не презентация. Все инвесторы уже давно догадались, что сама по себе презентация проект им не сделает.
На этом по документам, необходимым для принятия решения о запуске разработки проекта, все.
На этом главу можно было бы завершить, так как мы составили и даже описали весь перечень документов, которые должны получить в результате подготовки к производству. Но остается один очень важный момент – как структурировать этот процесс и разделить его на этапы?
Планирование всегда было бичом игровой разработки, и большое количество проектов провалилось именно из-за того, что делалось с сильным превышением бюджета,
