Планируя Game Design курс, столкнулся с актуальной ролью в современной игровой индустрии Game Designer / Feature Owner. Я несколько раз уже внедрял эту роль и сталкивался с примерами внедрения в других компаниях разного размера: от стартапа на 20 человек до корпорации Wargaming, где работает больше 5000 спецов. Про мой опыт, а также видение коллег читайте тут, в заметке. 

Привет, как и обещал — продолжаю писать. Говорим про гейм дизов сегодня. Актуально? Да. Спорно? Вероятно. Полезно? 100%. Для написания этой заметки я связался с коллегами, которые разбираются в вопросе GDFO, так что их цитаты вы тоже найдете в тексте.

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

GDFO 2023: Актуально и востребовано

Если раньше, 3-4 года назад я сталкивался с институтом фичеовнерства лишь в исключительных кейсах, то начиная с середины прошлого года все чаще стал замечать вакансии с этой формулировкой. Даже если вы сейчас загуглите эту роль, то наверняка найдете открытые вакансии с вполне конкретными требованиями:

• Анализ конкурентов, гипотезы и предложения.
• Разработка игрового дизайна, сопровождение: написание документации, постановка задач, приемка фичи;
• Расчёт и балансировка;
• Взаимодействие со всей командой, понимание технических аспектов работы проекта;
• Планирование и анализ метрик проекта, a/b тесты;

Feature owner в БОЛЬШИХ компаниях

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

Суть подхода в том, что в компании есть человек, который от «А до Я» знает все про фичу или несколько фичей (Да, ФО может овнить несколько фичей в компании). Например: Фича «Боевой пропуск» фича системно используется в проекте, эволюционирует согласно рынку, базируясь на метриках проекта. У компании портфель похожих проектов, где используется один общий Battle Pass, и внедряет ее тот самый Feature Owner, работая с командой каждого из проектов. Таким образом все проекты портфеля получают актуальный формат механики сезонного пропуска и не заморачиваются над тем, как его делать. У них бай дизайн лучшая версия фичи, так как за нее отвечает специально обученный человек.

Feature owner в маленьких проектах

В стартапах и небольших студиях роль Project Manager практически не работает. Ее забирает себе Feature Owner той или иной фичи, и делает весь проектный менеджмент для нее. Соответственно, при таком подходе у всего, что делает студия есть feature owner’ы. Они покрывают весь спектр работ и у классического ПМа нет ни работы, ни ответственности. Так как общее планирование забирает себе Product owner, то Project Manager в таких проектах — рудиментарная роль. Соответсвенно, компании ставят себе за цель нанимать спецов, которые умеют в фиче овнерство и тем самым экономят на проектном менеджменте. По крайней мере на первых порах, пока не начнут его эффективно монетизировать.

Who is Feature Owner?

Перед тем, как ответить на этот вопрос, хочется сказать, что владельцем фичи может быть не только Game Designer. Овнер фичи выбирается (лидом или командой) исходя из самой фичи. Все зависит от опыта в той или иной доменной области. Например, внедряя локальные пуши, фиче овнером может быть клиентский разработчик, который уже имеет опыт работы с этой историей. А гейм диз ему просто напишет тексты к пушам и выставить триггеры — т.е. закроет таску в джире. 

Feature Owner — это специалист высокого уровня синьорити, который забирает ответственность за конкретное решение/решения в продукте и покрывает ее реализацию на всех этапах производства и использования.

Если по простому, то Фича Овнер — это продукт овнер фичи, где фича — один продукт или сервис внутри структуры бизнеса.

Работа Фича овнера включает в себя все аспекты создания и управления фичей в бизнесе компании:

1. Требования и измеримые бизнес цели
2. Исследование и деконстракшен
3. Продуктовая концепция и документация
4. Техническое задание и брифинги
5. Проектный менеджмент
   1. менджмент задачи в трекерах
   2. декомпозиция и оценка задач по созданию и интеграции решения в портфель компании или продукт
6. WIP сопровождение
7. Приемка и Релиз менеджмент
8. Аналитика и Оперирование 
9. Обновление и Актуализация
10. Масштабирование на уровне портфеля компании

«Камон, Саша», — скажете вы — «Это и Produсer, и GD, и PM и LiveOps с Аналитиком вместе взятые?». Да, это кажется нереальным для одного человека по экспертизе. Но когда мы говорим про эти роли не в рамках всего проекта, а в рамках одной фичи — условной «Пиньяты» или «Колеса фортуны», «Таптика» или «Пушей», «GDPR» или «Rate us с прогревом» — фичеовнерство не кажется чем-то невозможным. Если у вас в бэкграунде уже лежит успешный кейс внедрения какого-то сервиса или фичи, и ты понимаешь что там было на каждом этапе — то скорее всего ты потянешь. 

Теория и примеры применения

Вы же помните заметку про Хороших Гейм дизайнеров Игоря Светикова (Creative producer at World of Tanks, но работал как Game Designer Feature Owner в WG)? Если нет, то советую прочитать.

Он тогда анонсировал 2ю часть заметки, которую вы сможете прочитать на ProGameDev. Так вот, пока она еще не вышла, я хочу вставить ее фрагмент, который касается как раз работы и задач позиции Feature Owner. Привет, Игорь, спасибо за такую возможность =)

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

FO ↔️ Stakeholders
Сбор требований, определение критериев продуктового качества, определение продуктовых рисков, организация "гринлайтов", подготовка презентаций либо показов, согласование дизайна и его изменений, согласование сроков, приоритетов и т.д.

FO ↔️ Design Team
Организация обсуждений и брейнштормов, генерация и отбор жизнеспособных вариантов, принятие дизайнерских решений, создание прототипов для их проверки, превращение высокоуровневой задачи в концепт конкретной фичи, разработка и поддержка документации, и т.д.

FO ↔️ Project Manager
Формирование беклога фичи (набора необходимых задач), определение приоритетов разработки, формирование MVP-скоупа (без чего фича не может выйти), определение основных этапов разработки и их сроков, подбор команды и привлечение необходимых специалистов, гибкая настройка производственных процессов и т.д.

FO ↔️ Development
Презентация фичи и её целей, ознакомление команды с дизайном и дальнейшие консультации в этом направлении, участие в эстимациях задач (определение объёмов и сроков разработки), подготовка необходимых данных и т.д.

FO ↔️ QA
Контроль продуктового качества, определение ожидаемого поведения, приоритезация багов, участие в тестировании, формирование опросников и т.д.

FO ↔️ Publishing
Определение необходимых активностей по поддержке фичи на выходе в релиз и при дальнейшем оперировании,  согласование влияния на другие активности, формирование позитивного отклика аудитории, ответы на основные вопросы игроков по фиче и т.д.

FO ↔️ Departments
Формирование и донесение общего видения фичи, постановка ТЗ на контент, определение необходимых объёмов контента, контроль его продуктового качества и т.д.

Как видите, ФО — это скорее про ответственность. Работа же может быть делегирована специалисту. Например декомпозицию задач делает ПМ, а не ФО ручками в Асане. Но для ПМа декомпозиця — это одна из задач, от одного из фичаовнеров в проекте. ПМ — тут исполнитель, он — руки. А ответственность на Аркадие. 

Слава Торик, руководил отделом GD, которые росли в Product owners :

Фичаовнер - это тот человек, который полностью отвечает за фичу с того момента, как были зафиксированы ее бизнес-цели, и запланированы работы по ней.

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

Интересно, что отвечать за фичу - не означает делать все самому, единого стандарта "ответственности" не существует. Хорошей практикой считается, когда геймдизайнер сам предлагает видение фичи и аргументацию в ответ на запрос продюсера о необходимости решить ту или иную проблему проекта, или воспользоваться какой-то новой возможностью. Получив одобрение, геймдизайнер становится фичаовнером, и теперь его задача - довести фичу до релиза, собрать пострелизные метрики и зафиксировать в постмортеме, указав возможные векторы развития фичи в дальнейшем.

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

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

Почему Feature owner’ом ставновится Game Designer?

Для работы ФО тебе понадобятся не только опыт, но и развитые Soft Skills. ГеймДиз же коммуникативные скиллы, которые в обычной жизни мы называем софт скиллами, иcпользует как Hard Skills. То есть навыки презентации, обратной связи, брифингов и QnA он использует и без дополнительной ответственности FO. Потому ему зачастую на уровнях middle+ не сложно подхватить ответственность и заовнить фичу. Такие попытки стимулируют его рост в продакта, дают релевантный опыт.

Евгений Судак тут хорошо прокоментировал:

В тех компаниях, где мы применяли такую практику, фичеовнерство использовалось как проба для ГД, который думает, куда ему расти. А компания выявляла потенциальных продюсеров. При том, что всё происходит под руководством продюсера, это, тем не менее, позволяет сотруднику проверить свои силы, и попробовать продюсерского хлеба в относительно безопасных условиях, без риска для работы.

Summary

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

Чтобы Гейм Дизу стать Feature Ownerом достаточно быть внимательным, получать опыт и изучать его. Развивая софт скиллы, анализируя что делают коллеги с твоим гейм дизайном (проджект менеджмент, аналитика, тюнинг…) ты сможешь претендовать на эту роль для тех фичей, с которыми ты разобрался.

P.S. И да, вчерашние успешные Фиче Овнеры, сегодня еще не новые Продакт Овнеры. Все таки сколько бы фичей ты не овнил, овнить продукт — это другое. Приходи ко мне на курс по Продюсированию — расскажу.