Процессы под контролем менеджера игровых проектов

Посмотрим на пример ключевых процессов в итеративном подходе, которые контролирует менеджер проектов

Анализ и планирование

Ниже представлена декомпозиция анализ и планирование
Рассмотрим подробно:

Риски проекта

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

Игровая архитектура

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

Затраты/Затраты на готовые решения

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

Bus Factor

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

Планирование задач

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

Roadmap

Карта Project Life Cycle активно используется в описании проектов с конкретными датами между этапами (или кварталами). У вас должно быть понимание, что это приблизительные запланированные даты, а не точное обещание выполнения к этому сроку или регламент. Если менеджер игровых проектов правильно оценил риски и запланировал задачи, то дата этапов жизненного цикла разработки игрового проекта не должна смещаться. Ничего страшного нет, если сроки будут смещаться, главное обновлять Roadmap и согласовать его с заказчиком.

Простой пример Roadmap

Защита рисков игрового проекта/решения

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

Контроллинг проектирования

Что же такое контроллинг? Это комплексное сопровождение этапа со стороны менеджера проекта. Нужно не только контролировать, чтобы к определенным срокам было закончено проектирование, но и четко понимать эффективность каждого члена команды исполнителя. Контроллинг включает в себя управление рисками, оценку качества работы (систему расчета эффективности) и постоянного планирования.

Контроллинг разработки

Менеджер игровых проектов продолжает процесс контроллинга разработки. Должно быть понимание и заказчика о общем статусе готовности игрового проекта.

Документирование игрового проекта

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

Контроллинг тестирования

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

Ретроспектива/закрытие игрового проекта

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

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