Лучшая методология управления проектами для разработки игр: Часть 2
В первой части мы разобрали классические методологии и поговорили о том, как использовать каскадный подход для долгосрочного планирования. Однако у реальности разработки игр часто свои планы.
RoadMap редко остается неизменным — приоритеты могут меняться, появляются новые фичи, срочные задачи и рыночные вызовы. Поэтому важно уметь адаптироваться и выстраивать процессы так, чтобы команда оставалась эффективной даже в условиях постоянных изменений.
Именно здесь на сцену выходят гибкие методологии.
В целом, ситуация, когда у вас есть четкий и неоспоримый RoadMap слишком утопичная. В реальности так не бывает. Мы живем в быстро меняющемся мире, и, если вы не разрабатываете что-то для полета на Марс, где ТЗ определяется один раз и не меняется, то такой метод вам не подойдет. А в разработке игр так тем более, нужно успевать следовать трендам, особенно, если речь идет об онлайн-играх.
Что, если приоритеты не определены? Или могут появляться внезапно всплывающие приоритетные задачи для удовлетворения потребностей рынка? А еще заказчики хотят, чтобы процесс производства 3D-контента улучшался, а значит, становился быстрее и качественнее? Значит также нужна система для кратко- и среднесрочного планирования, которая ко всему еще способна адаптироваться под быстро меняющиеся условия.
Получается, у нас есть Core проекта в виде RoadMap, в котором есть какие-то крупные фичи, контентные добавления и прочее. Это крупные столпы, которые, как правило, не двигаются и распределены по RoadMap равномерно, а вот то, что происходит между ними может создавать много хаоса. Для этого нам и нужно кратко- и среднесрочное планирование и адаптация к изменениям.
Лестер останавливается на идее гибких методологий. Он предлагает разбить крупные контентные задачи на мелкие составляющие и организовать их производство в коротких итерациях. А по итогу итерации проводить встречи с командой и заказчиками и менять входные данные для следующей итерации, если это необходимо. Так мы приходим к идее Scrum-команды.
Но вот незадача, у одного из продуктов, который заказывает контент у команды Лестера, внезапно появляется очень крутая идея, которая должна сильно продвинуть позиции проекта на рынке. Для этого требуется большое количество контента. Для достижения этой цели принимается решение нанять в штат еще одну команду, точнее даже обучить стажеров и передать их в подразделение Лестера.
Какую проблему тут можно увидеть? Команда стажеров — это неслаженный коллектив, который должен решить приоритетную задачу в короткие сроки. Получить от них такую же производительность, как от опытной команды практически нереально.
Логичным решением выглядит работа нового подразделения по такой же методологии, что и основная команда, но сработает ли это в новых условиях? Старая система хорошо себя зарекомендовала на дроблении крупных задач на более мелкие подзадачи. Их легче оценивать, легче планировать, а главное, легче находить способы их ускорения.
Тогда Лестер принимает решение соединить каскадную модель со Scrum на коротком отрезке времени. Большие задачи дробятся на еще более мелкие, чтобы над одной контентной задачей могло одновременно работать несколько художников. Также они распределяются по итерациям заранее. Так как у команды есть точный дедлайн, то можно посчитать и количество итераций на поставку всего контента. Команда получает возможность отслеживать прогресс в реальном времени, на сколько они опережают или отстают при выполнении задачи. А главное, они могут вовремя вносить коррективы в процесс работы.
Что в итоге получилось? Для планирования какого-то глобального видения Лестер использовал элементы каскадной модели. Для оперативного реагирования на изменяющийся мир задействовал Scrum. Для мягкого вхождения свежего подразделения в процесс работы - гибридизировал каскадную и гибкую модели.
На что стоит обратить внимание при выборе гибких методологий:
- Есть ли заранее список задач или они просто льются потоком, как из рога изобилия? Казалось бы, а какая разница? Дело в том, что готовый список можно приоритизировать, следовать ему, добавлять новые задачи и менять приоритеты. Тогда команда, работая итерациями, постепенно закрывает задачи из потенциально бесконечного бэклога. Кстати, составлен он может быть на основе RoadMap. Если задачи льются постоянно, особенно это актуально для проектов, которые активно следуют трендам, то нужно придумывать систему очереди и приоритезации задач на ходу.
- Есть ли ситуации внезапно прилетающих задач сверх планирования? Это немаловажный момент. На моей практике такое есть всегда и даже чаще, чем всегда. Отличный пример — это флешмоб с постерами игр в стиле анонса GTA VI.
- Это только кажется, что просто взяли и нарисовали. На самом деле, подобная работа задействует большое количество людей и подразделений. Art Owner должен утвердить концепт, художник по концепту нарисовать постер, после он утверждается Арт директором, отдел, отвечающий за позиционирование, должен запостить. А теперь представьте, в какие сжатые сроки все это должно быть сделано, подвинув основные задачи.
Что я хотел всем этим показать? У каждой методологии есть свои стандарты, и это хорошо, им нужно следовать. Они помогают работать в сложных условиях, особенно при отсутствии большого количества опыта. Они – стержень вашей разработки. Но ключевая обязанность менеджера – это умелая комбинация методологий, подходов и инструментов, исходя из контекста проекта. Ведь самое главное – это достижение целей и задач проекта.
В японских боевых искусствах есть концепция обучения, когда ученик проходит через три стадии: Сюхари. На стадии «Сю» ученик беспрекословно повторяет все, что говорит учитель. На стадии «Ха» он уже начинает понимать правила и может учить других, тем самым получая новый опыт. На стадии «Ри» он сам становится правилом, правил больше нет. Так Project Manager и его команда проходят через эти три стадии.
Ответ на вопрос, какая же методология лучшая для разработки игр: та, которую вы изобрели сами. Соберите своего Франкенштейна, хорошенько шарахните его током и во весь голос закричите: He’s Alive!