Как делать хорошие игры. От идеи до запуска - Петр Прохоренко
1. Идея.
2. Позиционирование.
3. Ключевая команда.
4. Базовый геймплей.
5. Препродакшен.
Ну а в рамках данной книги вы дочитали примерно до середины, и дальше нас ждет самый ответственный этап – производство. А точнее, поскольку у нас не учебник по программированию, управление производством проекта.
Глава 5. Производство игры с точки зрения управления
Если рассматривать основной предмет, которому посвящена книга, с точки зрения управления проектами, то мы увидим, что принципиально игра не сильно отличается от любого другого высокотехнологичного проекта. И это действительно так, управление производством игр вполне под силу любому подготовленному менеджеру. Но, к сожалению, довести проект до запуска и сделать хорошую игру это совершенно разные вещи. Именно поэтому делать хорошие игры так непросто.
Сам процесс управления игровым производством не таит в себе каких-то тайн. Это все те же планы, контроль за выполнением задач, трекинг прогресса проекта и постоянная ревизия планирования. Наверное, это можно сравнить с прохождением атомоходом Северного Морского пути (движение вперед с постоянными замерами толщины льда, погодной обстановки, координат и мониторинга всех корабельных систем), и так же, как атомоход, крупный игровой проект крайне сложно остановить или развернуть на полном ходу, поэтому этому процессу далее будет даже посвящена отдельная глава.
В идеальном мире производство игрового проекта может выглядеть так, как описано дальше. Разработка проекта ведется по этапам согласно принятому на этапе препродакшена Roadmap, и на каждом этапе производится следующий цикл действий (в скобках – кто делает):
• формирование плана на этап (команда разработки и продюсер);
• приоритизация задач по времени и формирование спринтов/версий (команда разработки);
• формирование и утверждение чек-листа для сдачи этапа (продюсер);
• контроль за ходом разработки спринтов (менеджер проекта);
• приемка финального спринта (менеджер проекта сдает продюсеру);
° в случае отрицательного результата обсуждается дополнительный спринт для доработки;
• актуализация чек-листа для топ-менеджмента (менеджер проекта и продюсер);
• внутренняя приемка этапа (менеджер проекта и продюсер сдают этап своему начальству);
° в случае отрицательного результата обсуждается изменение масштаба работ / планирования этапа;
• опционально создание отчета о ходе разработки для высших контролирующих органов (продюсер и руководство);
° отчет включает в себя статус выполнения проектных целей, комплектность выполненных задач, выполнение бюджета;
• внешняя приемка этапа (продюсер и руководство сдают этап высшим контролирующим органам);
° в случае отрицательного результата обсуждается дофинансирование или прекращение разработки / изменение плана разработки.
Парадоксально, но основные риски в производстве игровых проектов находятся за рамками собственно производства и сосредоточены на участках подготовки концепции (об этом мы уже говорили) и после завершения основных работ. Вероятность, что вы сделаете игру как некое функционирующее программное обеспечение при наличии даже средней команды, составляет более 80 %. Но если вы придумали не то, что нужно рынку, и если рынок за время разработки вашего программного обеспечения поменялся (а этот процесс изменений не останавливается никогда), то шансы на успех снижаются до стандартных 10 %.
Именно поэтому основная специфика в разработке игр заключается в изменении курса проекта по ходу его разработки. Поменялся рынок, появился новый конкурент, старые конкуренты придумали новые фичи, изменились условия платформ, пользовательская база начала мигрировать в другой жанр – все это приводит к тому, что вам нужно переделывать и модернизировать ваш атомоход прямо на ходу, при этом не останавливаясь и продолжая ломать лед.
Может показаться, что этот процесс не очень сложный, и в принципе так оно и есть, но лишь до тех пор, пока у вас маленькая и гибкая высокопрофессиональная команда. Та самая core team, о которой мы говорили в предыдущих главах. Как только производственная команда разрастается до десятков сотрудников, ни о какой гибкости уже речи не идет. Эффективность большинства команд радикально снижается при их масштабировании. Именно поэтому плавный рост команды от core team до полноценной рабочей группы в 10–15 человек представляет ключевое значение для всего проекта.
Как сделать хорошую игру, Способ № 15: Не растите слишком быстро! Помните, что критичные участки роста производственной команды находятся в зонах «нас уже около 15-ти человек» и «ух ты, нас более 50-ти человек». Первая ваша задача – это вырасти до 15-ти сотрудников, сохранив ту же эффективность и гибкость, которая у вас была, когда вас было 5. И ваша вторая задача – постараться не раздувать команду до состояния ее неуправляемости. Помните, что даже деревья не растут до небес…
Эмпирически есть некие границы где-то в районе 5–50–100 человек, и при каждом пересечении границы правила управления немного меняются. Скажу честно, я никогда не управлял проектной командой больше 100 человек и вообще сомневаюсь, что это возможно в терминах эффективности. Даже в очень крупных компаниях, где над разработкой одного проекта трудятся 200–300 человек, они обычно разделены на подкоманды, которые достаточно автономны и живут по понятным правилам. В моем опыте также, даже если были ресурсы раздувать команду до бесконечности, я старался придерживаться этого «правила 50», структурируя команду на крупные блоки. Когда мы в условиях цейтнота и почти неограниченного бюджета делали платформу Series (2021 год), то команда разработки состояла из 40–50 человек, часть технической команды была на аутсорсе (еще 10–15 человек в другой локации), а основные контентные работы были разделены на пять внешних студий (и сколько там было задействовано сотрудников, подсчитать сложно). Таким образом, общее количество работающих над проектом сотрудников было точно больше 150, но непосредственно ключевая команда разработки никогда не превышала 50 рабочих единиц.
Поэтому можно считать, что все изложенное в этой главе относится к управлению командами от 5 (то есть за рамками делавшей препродакшен ключевой команды) и до 50 (поскольку дальше требуется более сложная структура). Полагаю, что это затронет проблематику, интересную 90 % читателей.
Если предыдущие этапы игрового проекта были вотчиной маркетологов, продюсеров, гейм-дизайнеров и даже программистов, то теперь наступает очередь проектного менеджера. Это рабочие лошадки всего игрового бизнеса, которые вытаскивают на себе большую часть самой нудной и самой неинтересной работы.
Проектный менеджер занимается управлением разработкой вашей игры, то есть управлением проектом.
Управление проектами – область деятельности, в ходе которой определяются и достигаются четкие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками.
Таким образом, из каких сущностей состоит проект? Мы имеем следующие составляющие:
• ресурсы (сюда входят деньги, люди, время, технологии и прочие важные элементы);
• объем работ (заданный на
