Как в планировании подружить творчество и управление, — кейс Натальи Поповой из Overmobile
О том, как не допустить бардака при планировании новых фич, — специально для App2Top рассказала Наталья Попова, менеджер игровой команды Overmobile, также ведущая курс «Управление игровыми проектами» на WN Academy.
Это статья вышла при поддержке образовательного сервиса WN Academy, который активно привлекает для своих курсов и корпоративного обучения ведущих экспертов.
Наталья Попова
Меня зовут Наталья Попова, и я уже больше 15 лет управляю разработкой игр, в основном мобильных. В этой статье — мои наблюдения о том, как подружить творчество и управление. Без бюрократии, но не в анархии.
В геймдеве остро стоит конфликт между творческим хаосом и структурой. Оба важны, но перекос в любую сторону опасен. С чем сталкиваются многие команды:
RnD без релизов
Креатив, который длится годами, не приводит к результату, но пожирает ресурсы. «Мы не влезли в большой проект с неизвестной окупаемостью», — утешение, которое не заменит результата.
Контент-фабрика без искры
Расширяющаяся команда, забетонированные процессы, регулярные отчеты — и творческий импульс в минусе. Состояние «нет творчества» вдруг становится сопутствующим эффектом успеха игры.
Хаос под маской свободы
На поверхности — творческая свобода (команда генерит небанальные идеи, релизы есть), но внутри постоянные переработки, истощение лидов, потерянное на пустом месте время и куча мисскоммуникаций. Это не творчество, а отсутствие процессов.
Часто такой подход романтизируют: «мы гибкие», «у нас живой процесс», «мы не хотим бюрократии». Но на деле это бардак, в котором люди подвержены выгоранию, а продукт — факапам.
Настоящая творческая среда — это не анархия, а место, в котором идея может родиться и пройти путь до реализации без надрыва.
Задача менеджера не столько контролировать, сколько управляться с событиями и идеями, которые постоянно происходят на проекте. Именно об управлении идеями мы и поговорим.
Для работы с идеями я предлагаю следующую цепочку: хранилище идей -> бэклог -> итеративная разработка.
Думаю, что любой менеджер проекта пытался создать бэклог, изучая Agile, однако очень быстро такой бэклог становился свалкой, а затем — кладбищем идей и заметок.
За годы управления в геймдеве я пришла к следующему решению это проблемы: до того, как заниматься бэклогом, следует внедрить в процесс элемент, который я называю хранилищем идей.
Хранилище идей — это доска с карточками, разделенными по следующим столбцам:
Inbox / Need to think / Approved / Approved small / Отменено-Приостановлено
- Inbox — в этот столбик записываются все идеи, звучащие от команды.
- Need to think — сюда идут идеи, по которым есть вопросы и сомнения. Например, видны технические риски или нужен рисеч, есть вопросы о том, как ввести фичу для старых игроков или, возможно, есть подозрения, что сломается общий баланс. Я вношу в этот столбик и те идеи, которые выглядят слишком трудоемкими. Иными словами, это пул для идей, от которых вы не готовы отказаться, но и взять в проработку невозможно без предварительных размышлений.
- Approved / Approved small — те предложения, которые можно переводить в ТЗ. Я предпочитаю чередовать большие и небольшие идеи. По графику работ программистов часто бывает так, что между крупными фичами, нужны небольшие «задачи-перебивки».
- Отменено-Приостановлено — часто команде сложно отказаться от идеи, когда явных противопоказаний к идее нет, но из квартала в квартал, а то и из года в год идея остается в хранилище. Это означает, что целый год находились идеи выше приоритетом. Такое логично удалять. Подобный столбик помогает содержать хранилище идей незахламленным, но и не заставлять гейм-дизайнеров вот так сразу удалять идею. С идеей, находящейся в столбике год, всем сильно легче с ней расстаться, чем сразу.
От команды и проекта зависит горизонт подробного планирования. Как правило, он составляет три-четыре месяца. На мобильном рынке довольно часто появляются тренды среди фич. Дорожная карта длиной в полгода к моменту реализации может устареть. По этой причине я выступаю за квартальное планирование. Чуть ниже мы поговорим о том, что делать, если издательство требует заполнить роадмап на год.
В хранилище идей добавляем столбики по количеству планируемых релизов за квартал (или за полгода, если команда планирует все-таки полугодиями). Как правило, в мобильных играх релизы происходят раз в один-два месяца. Таким образом, добавляем три столбика на квартал, я добавляю их слева от всех вышеописанных.
И далее совместно с ГД/продюсером заполняем три релизных столбика карточками из Approved и Small Approved. В некоторых случаях в «дальние» релизы можно добавить карточки из Need to think. Тогда точно видно, к какому сроку нужно прояснить вопросы и риски по таким карточкам.
Такой способ работы с карточками позволяет в одном визуальном пространстве держать:
- верхнеуровневый план по фичам;
- список идей, по которым можно писать ТЗ;
- список идей на обдумывание;
- список всех входящих.
С годами я пришла к выводу, что очень важно держать такие вещи перед глазами одновременно.
Может возникнуть вопрос о том, как можно распределять карточки идей по релизам без оценки сроков?
Обычно с опытом PM вполне способен давать оценку сверху большинству фич. Маловероятно, что фича занимает квартал, а PM оценит ее в один месяц.
В любом случае задача этого плана — определить последовательность приоритетов работы для команды. Это и есть продуктовый план.
Если издательство требует план на год, то таким же образом распределяются карточки из хранилища идей на год: однако, как показывает опыт, через квартал в любом случае стоит план пересмотреть.
Какие еще действия с таким плано-хранилищем полезно проделать?
В хороших инструментах для организации таблиц с карточками есть возможность проставить эмодзи на карточки. Например, я использую:
- эмодзи с деньгами/долларами — для фич, которые напрямую влияют на монетизацию (хотя бы в наших представлениях);
- стрелочка — для фич, которые должны повлиять на ретеншен;
- бантик — для фич, которые участвую в общем product value, но напрямую ни на что не влияют (например, «Реплаи в чате» или «Отображать ранг игрока в таком-то лидерборде»).
Расставив эмодзи на карточках, проверяем себя на то, чтобы релиз не состоял из одних бантиков. Такими задачами очень легко увлечься — и хотя product value, безусловно, важен, но кардинальным образом такие задачи показатели проекта не изменяют.
Второй аспект, под которым стоит взглянуть на столбики-релизы — соотношение фич для новых игроков и старых.
Как правило, в этом конфликте интересов чаще «забывают» о новичках и о работе с воронкой входа.
В целом работать с ретеншеном первых дней, как и с конверсией первых дней, сложнее и скучнее, чем с монетизацией и ивентами для старых игроков.
Старые игроки уже существуют, они уже пишут в поддержку или сообщество запросы. На эмоциональном уровне гейм-дизайнеры больше вовлечены во взаимодействие с ними, чем с тем процентом игроков, которые прибавятся, когда мы улучшим ретеншен 1-го дня.
Реже случается ситуация, когда забывают о старых игроках, но и такое бывает. Поэтому обязательно смотрите на свои столбики-релизы глазами платящего игрока, который в игре уже год: даст ли игра новые вызовы и новый дофамин?
Обычно обе проверки приводят к тому, что выясняется дисбаланс в запланированных фичах: в этом случае мы снова обращаем внимание на столбики Approved и Need To Think, чтобы «перебалансировать» релизы.
Почему так важно организовать процесс работы с идеями, когда они еще не продуманы?
Хочу упомянуть яркую концепцию, которую дает один из основателей Pixar Эд Кэтмелл в книге «Корпорация гениев. Как управлять командой творческих идей».
Со временем в компании появляется Зверь: «под этим словом я понимаю любую крупную группу, для функционирования которой необходим непрерывный поток новых материалов и ресурсов… Он неумолим, он голоден и всегда требует следующего большого проекта».
Кажется, с тем же самым сталкиваются команды выстреливших проектов: рост компании и кризис роста похожи на рождения Зверя, в этот момент менеджеры только и успевают, что кормить Зверя, занимая всех людей задачами.
Ждать пока у гейм-дизайнера появится идея новой фичи, какой еще нет в других играх? Некогда! 30 художников и 10 программистов ждут задач!
Щупать идею? Выкидывать неудачные попытки фич? И хотя мы не автомобильные заводы с линией сборок, частая ловушка — бояться простоев команды и начинать планировать «от людей», а не «от идей».
А вот как Эд Кэтмелл описывает идею, когда она у команды только появляется: сырая, неуклюжая, будто неприглядный ребенок. В этот момент идея особенно уязвима: ее можно отвергнуть, недооценить, сломать или заморозить. Именно поэтому ее нужно защищать, дать время и пространство на рост.
Мне нравится яркость этих образов, и они применимы к тому, что происходит при разработке/поддержке игры. Менеджеру проекта стоит задуматься о том, как защищать «неприглядных детей» от зубов Зверя. Иначе проект может превратиться в конвейер, который живет только за счет старых игроков, постепенно угасая. А еще больше проектов даже не доживают до стадии ядра лояльных платящих игроков.
Хорошая идея легко погибает. Иногда — под зубами Зверя, иногда — в бэклоге, который никто не открывает. Берегите, организуйте и управляйте идеями команды даже когда они еще не красивые, не понятные и не оправданные таблицами — во многом создание такой среды и есть настоящая управленческая работа.