Менеджмент игровых проектов: от идеи до релиза

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

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

***

Разработка игр – процесс сложный, но увлекательный. Многие игровые продукты не увидели свет (и не заработала ни гроша) только потому, что не смогли грамотно организовать рабочий процесс и результативно завершить проект. На днях в Высшей школе бизнес-информатики НИУ ВШЭ на лекционном вечере о разработке игр прошла открытая лекция Сергея Голубкина, экс-продюсера Ubisoft и Nival.

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

Стратегии управления проектом

Геймдев – это во многом про счастье сотрудников. Игровые компании на Западе давно не используют директивные методы работы. Сначала создаётся обстановка и атмосфера, в которой комфортно работать, в ответ на эти шаги люди работают эффективно и выпускают качественный продукт. В геймдеве используется два основных подхода управления проектом и командой: Agile и Waterfall (каскадная модель).

Waterfall

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

Вариант формулировки этапов работы над проектом по каскадной модели:

  1. Определение требований, создание концепта.
  2. Запуск и организация работ (документация).
  3. Аналитика и сбор информации по рынку.
  4. Дизайн.
  5. Программирование.
  6. Тестирование и отладка.
  7. Поддержка.

Модели Waterfall отдают предпочтение в крупных проектах, с участием свыше 100 человек.

Agile

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

Ценности Agile:

  • Индивидуальность и итеративность всегда важнее процессов и инструментов.
  • Работающая программа важнее документации. Но не отменяет её.
  • Постоянная работа в контакте с заказчиком/пользователем.
  • Внесение изменений «на лету» важнее следования плану.

SCRUM

SCRUM – один из методов практического внедрения философии Agile в IT-командах, предложенный в 1993 г. Джеффом Сазерлендом. SCRUM определяет следующие «церемонии» в команде:

  • Планирование спринта.
  • Ежедневный стенд-ап.
  • Демо-приложение по итогам спринта.
  • Ретроспектива по итогам спринта.

Модель также описывает роли и обязанности в команде:

  • Product Owner – определяет виденье продукта.
  • SCRUM Master – поддерживает процессы и церемонии в команде.
  • SCRUM Team – команда из 5-7 работающих вместе людей.

Пошаговое внедрение SCRUM:

  1. Назначаем Product Owner – человека, который лучше всех знает, что за продукт вы делаете. Обычно это автор основной идеи.
  2. Собираем SCRUM Team.
  3. Выбираем Scrum Master. Человек, который будет следить за эффективностью работы остальных участников. Необязательно, чтобы он был управленцем, главное – отдать роль самому ответственному члену команды. Им не должен быть Product Owner, иначе случится конфликт интересов.
  4. Создаём бэклог – хранилище идей, связанных с проектом для последующего обсуждения с командой.
  5. Уточняем и оцениваем бэклог. Оцените сложность задач, определите хотя бы два параметра: трудоёмкость и риски.
  6. Планируем спринт. Определяем, сможем ли уложиться в сроки, учитывая длительность каждой задачи. Собираемся командой, планируем пул задач на неделю. Далее члены команды разбирают задачи, кому что интереснее.
  7. Проводим регулярные стенд-апы. Минимум шуток, краткое резюме о статусе текущих задач и планах на день (на созвоне или с мест в офисе).
  8. Проводим ретроспективу или представление демо. Обычно команда собирается в пятницу обсудить прошедшую неделю и выполненные задачи, а также новые идеи улучшения проекта.
  9. Начинаем следующий спринт. Недельная итерация завершилась, возвращаемся к пункту 6.

Этапы разработки

1. Подготовка

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

Формируем документацию: концепт, art-style doc, бюджет, бизнес-план, проектный план. Некоторое время понадобится для адаптации и «срабатывания» команды, построения процессов взаимодействия.

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

  • Целевая аудитория, размер и структура рынка.
  • Модель поведения (психотипы Бартла, типизация Маржевского, модель BrianHex).
  • Казуальность, сеттинг.
  • Конкуренты (в том числе потенциальные), показатели конкурентов.
  • Что будет представлять собой релиз.

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

  • Монетизация и бизнес модель.
  • Кто платит? Что продаём? Каковы риски?
  • Список основных конкурентов, степень опасности.
  • Стратегия риск-менеджмента.
  • SWOT-анализ.

2. Предпроизводство

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

Пример перечня задач (feature list)

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

Пример плана проекта (project plan)

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

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

Чем отличается бюджет от бизнес-плана:

  • Бюджет – фактический документ, по которому живет проект/команда.
  • Бизнес-план – документ с планами и прогнозами по проекту/команде.

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

3. Производство

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

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

Jira. Главный инструмент менеджера, но с одним большим недостатком. Jira лучше всего работает с плагинами, а почти все они – платные. Если команда маленькая, можно обойтись Trello.

Интерфейс Jira

Trello. Отличный треккер для небольших команд: простой и бесплатный. Классическая модель предполагает три колонки: to do (запланированные задачи), in progress (задачи, над которыми сейчас кто-то работает) и done (выполненные задачи). Если у вас небольшая команда до 7-8 человек, можно вести бэклог в Trello.

Интерфейс Trello

Confluence – это хранилище документов для совместного доступа к файлам. Если вы используете Jira, то Confluence станет для вас удобным инструментом – всё интегрировано.

Интерфейс Confluence

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

Интерфейс Slack

4. Релиз

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

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

Заключение

На практике перечисленные процессы могут показаться слишком сложными. Поэтому Сергей решил поделиться опытом в игровой форме, выпустив настольную игру-симулятор геймдев-студии – Game Dev Sim.

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

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

admin
15 апреля 2019

13 главных ошибок, мешающих разрабатывать игры

13 самых злых ошибок для тех, кто мечтает разрабатывать игры или уже успел ...
Библиотека программиста
23 июня 2017

Разработка игр – это просто: 12 этапов изучения геймдева

Разработка игр на плаву, она перспективна и набирает популярность. Мы подго...