Лучшая методология управления проектами для разработки игр: Часть 1
Методологий — десятки, а идеальной всё нет. Как понять, какая подойдет именно твоей команде? Об этом размышляет и делится десятилетним опытом в игровой индустрии наш коллега Григорий Кутузов.
Дисклеймер: Любой взгляд на проектное управление субъективен. Все персонажи и события выдуманы, все сходства случайны.
Всем привет!
Проработав более 10 лет в игровой индустрии, я задумался: какую методологию и подходы к планированию я применяю? Поэтому сегодня хочется поговорить про Project Management в геймдев, а именно, про лучшую методологию управления проектами для разработки игр. Такой кликбейтный заголовок получился!
Для начала давайте определимся, кто такой Project Manager? Если вы зайдете на HH и вобьете в поиск вакансии проджектов, то сможете найти много противоречащих друг другу предложений. Я встречал и вакансии секретарей под таким названием, и вакансии менеджеров по организации огромного производства с нуля. На своей практике я видел как людей, которые выполняют типичные проджектовские обязанности, но при этом называются как угодно, только не Project Manager, так и обратные ситуации.
PMBok дает весьма расплывчатое определение: “Project manager - the person assigned by the performing organization to lead the project team that is responsible for achieving the project objectives.” (Это человек, назначенный исполнительной организацией управлять командой проекта для достижения проектных задач). Ключевым я бы выделил здесь команду. Это самый ценный актив в руках Project Manager’а, и без нее достигнуть успеха будет просто невозможно. Для упрощения давайте договоримся, что проджект — это человек, превращающий хаос в порядок.
Вернемся к изначально заявленной теме выбора методологии. Это как раз-таки и есть ответственность проджекта: выбрать методологию управления проектом, по которой будет работать команда. От этого будет зависеть эффективность и скорость работы, а значит и возможность достигать поставленных задач.
В целом из практики все методологии можно разделить на две: Классические (Waterfall во всех его проявлениях) и Agile (Гибкие методологии). На Habr.com есть отличная статья на эту тему: Еще раз про семь основных методологий разработки. Там хорошо показаны основные принципы.
Какая же методология лучшая или как ее выбрать? Вот давайте представим, что у нас есть Project Manager по имени Лестер Геймов. Он руководит командой, которая поставляет готовый 3D контент для различных продуктов компании. Сложность его подразделения состоит в том, что заказчиков много, контент разный, заказчики плохо коммуницируют друг с другом и все хотят свой контент в первую очередь. На Лестера ложится обязанность взаимодействовать со всеми и создать оптимальные условия, при которых команда сможет поставлять ценность и удовлетворять потребности всех заказчиков, соблюдая при этом интересы обеих сторон.
Помните, в определении Project Manager’а я выделил команду? Методология должна помогать команде, а не мешать ей. Если ваша команда не принимает выбранную вами методологию, а вы не можете ей объяснить, в чем ее преимущества, то как бы вы директивно ее не насаждали, работать это, скорее всего, не будет.
Но вернемся к Лестеру. Допустим, каждый из заказчиков составляет свою RoadMap – какой контент в какие сроки необходим на некий обозримый отрезок времени (полгода, год, два). RoadMap составляется совместно с Лестером с учетом возможностей его команды т.к. она не может сделать больше, чем она физически может. Такой каламбур. И это тоже одна из обязанностей проджекта – грамотно доносить до заказчиков, на что способна команда в плане объема работ, т.к. заказчики всегда хотят больше и больше. В итоге у Лестера есть список задач, конечный срок и ресурсы для выполнения этих задач. Думаю, тут становится очевидно, по какой методологии можно работать?
Зная количество необходимого времени на каждую задачу, их приоритеты, конечный срок и количество исполнителей, можно построить классическую каскадную модель. Основным элементом графического отображения которой является Диаграмма Ганта. В этой ситуации команда Лестера просто ей следует, причем можно даже заложить заранее отпуска членов команды, а также к срокам задач добавить некую дельту для компенсации возможных больничных и экстренных отсутствий.
Давайте резюмируем, на что нужно обращать внимание при выборе методологии для долгосрочного планирования:
- Есть ли четкое ТЗ, что нужно сделать? Если вы не совсем маленькая инди студия, то скорее всего у вас есть глобальный план на какой-то обозримый промежуток времени (год-два). Этот план можно использовать как Core составляющую вашего планирования.
- Может ли ТЗ дорабатываться в процессе создания проекта? Если да, то логичным выглядит разбиение большого RoadMap на инкременты (версии). После каждого инкремента можно вносить небольшие доработки в ТЗ и в общий план.
- Знаем ли мы, как точно реализовывать проект? Бывает так, что ключевые требования понятны, но как это должно быть реализовано – нет, тогда можно использовать итерационную модель (не путать с инкрементальной). Задача итерации получить по итогу потенциально рабочий продукт. При этом с каждой итерацией реализация может меняться.
Подводя итог: мы рассмотрели, как классические подходы помогают навести порядок, когда есть четкое ТЗ, понятный RoadMap и стабильные вводные. Но, как показывает практика, такие идеальные условия встречаются нечасто.
Мир геймдева меняется слишком быстро: новые тренды, внезапные задачи — всё это требует большей гибкости и скорости реакции.
Как быть, если RoadMap вдруг перестаёт быть «высеченным в камне», а задачи появляются быстрее, чем успеваешь их закрывать? Об этом — во второй части.