Проектная документация и мероприятия

Задачи

Конкретно описанный сценарий "что нужно сделать, чтобы достигнуть цели?" для конкретного специалиста.

Технические задания

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

Отслеживание версионности продукта

Версионность приложений часто идет в формате A.B.C. для игровых продуктов, где
A - основной номер версии
B - дополнительный номер версии
C - номер итерации

Пример: Версия 0.14.2
Может означать, что продукт ещё не готов (0), собран в количестве 14 раз (описан 14 раз), 2 итерация разрабатываемого функционала (2)

Добавлю про Release Notes:

Это специальный документ, который содержит в себе дату релиза версии и прикрепленные выполненные задачи заказчиком. Чаще Release Notes делает только для формата A.B. по той причине, что после финальной итерации, правильно обновить +1 к инкременту B.

Отчетность

Вся отчетность нужна для понимания заказчика о текущем статусе игрового продукта.
Форма отчетности зависит от требований к отчетности от самого заказчика. Кто-то может требовать отчетность каждый день, кто-то неделю. Многие трекеры задач имеют удобный функционал формирования отчетности, такие как Jira.
Небольшой совет от меня, отчетность стоит делать в формате "День to Неделя to Месяц to Квартал", только в том случае, если у менеджера игровых проектов очень много на сопровождении проектов и продуктов или команда разработки превышает более 10 человек. Данная отчетность требуется даже больше для самого менеджера проектов, чтобы он осуществлял максимально эффективный контроллинг этапа.

Митинг

Как правило небольшое по времени (10-15 минут) мероприятие, которое проводят каждый день или неделю. Каждый член команды разработчиков высказывается 1-3 минуты по своим проблемам и планам на текущий день. Главное отследить, чтобы тема не переросла в обсуждение. Достаточно поднять проблему или понять какую задачу будет выполнять конкретный разработчик, далее менеджер проектов сможет решить, нужна ли дополнительная помощь со стороны коллеги по разработке и насколько тема влияет на риски.

Планирование

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

Демо (Демонстрация)

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

Журналы встреч

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

Проектная ретроспетива

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

Пример:

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

Завершение проекта

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

Рекомендуемый мною формат:

1. Наименование проекта
2. Команда
3. Цели (Чек-лист)
4. Полный список задач (Чек-лист)
5. Прогнозируемый срок реализации и затрат
6. Реальный срок реализации и затрат
7. Инциденты и факторы, которые плохо повлияли на проект
8. Анализ событий
9. Достигнутые результаты
10. Финальная оценка заказчика
11. Финальная оценка менеджера проектов
12. Рекомендации и предложения менеджера проектов по улучшению