На недавней конференции IT Spring 2016 директор департамента разработки СООО «Гейм Стрим», минского центра разработки Wargaming, Александр Деркач поведал о трансформации создателя World of Tanks из компании одного продукта в распределённую мультипродуктовую компанию, остановившись на вопросах методологии и управления командами, которые находятся в разных городах и регионах.
Предпосылки
— Когда к разным частям тела слона подвели шесть мудрецов с завязанными глазами, то кому-то слон показался деревом, кому-то — верёвкой, а кому-то — стеной. Никто не понял, что перед ними слон, и, соответственно, не смог получить от него пользу как от слона. Вывод очень прост: чтобы многоуровневая система работала слаженно и эффективно, её нужно сначала увидеть целиком, а затем уже взаимодействовать с каждым из её компонентов.
Команда — это не набор составляющих, а единый живой организм. Когда структура, состоящая из команд оперирования, игровых студий, продуктовых команд распределена по ряду локаций, будь то разные города, страны или континенты, она всё равно должна функционировать как единое целое.
Между командами в такой структуре формируются связи и определённая зависимость друг от друга, но это не предполагает возникновения синергии автоматически. Важно выстраивать процессы, которые будут стимулировать эволюцию команд и поддерживать синхронную работу в распределённой среде.
Локальная команда VS распределённая
Когда команда находится в одном здании, ею проще управлять и легче контролировать процесс разработки. Проще внедрять методологии и процессы, удерживать все усилия команды в рамках единого вижена.
В то же время такая команда замыкается в рамках своей локации и теряет связь с остальными точками на глобальной карте Wargaming. Продукты, которые она создаёт без учёта специфики других подразделений, становятся менее ценными. Постепенно она начинает смещаться в функциональную структуру: ценность функций, таких как код или дизайн, становится выше ценности продукта, что тоже не лучшим образом отражается на итоговом результате.
Распределённость, напротив, заставляет команду эволюционировать быстрее. Такая команда лучше понимает культурные особенности регионов и претворяет в жизнь более технологичные решения. В результате продукт получается качественней, чем у локальной команды.
Уровни распределённой разработки
В основе производства сложного продукта лежит целый «батальон» креативных, управленческих и технологических компетенций. Вокруг этого ядра строятся самодостаточные подкоманды полного цикла, которые предлагают свои идеи и доводят их до реализации. В рамках управления продуктом и формирования видения выстраивается взаимодействие с игровыми студиями и командами оперирования по всему миру.
Идея не нова, но, как всегда, значение имеет реализация. Чтобы обеспечить эффективную работу этой структуры, необходимо придерживаться ряда принципов как в разработке, так и в продуктовом управлении.
Нужно перестать строить «космические корабли» и сместить фокус на компактные, понятные, измеримые фичи, которые быстро попадают в продакшн. В геймдев-индустрии, если идея пришла вчера, а сегодня её не начали реализовывать, завтра можно не начинать.
Необходимо выстроить каналы быстрой обратной связи с игровыми студиями и пользователями. Важно глубоко понимать как цели каждой конкретной игры, так и потребности игроков, внимание и любовь которых весьма переменчивы. Команда должна понимать место каждой фичи в общем продукте и знать, как повысить конкретные показатели, то есть видеть большую картинку, а не отдельные её фрагменты.
Проблемы коммуникации и бизнес-идея
Одна из основных трудностей в распределённой разработке — коммуникация. Она неизбежно усложняется, и появляется информационный дефицит. Всё сложнее становится поддерживать информационное поле.
В такой ситуации сохранить единый вектор поможет простая, лаконичная бизнес-идея, вокруг которой строится стратегия подразделения. Задавая себе «философский» вопрос «Зачем?», каждая из команд в распределённой структуре может провалидировать свои активности относительно общей стратегии. К примеру, бизнес-идея нашего отдела достаточно проста — это вовлечение игроков через социализацию и соревновательные элементы. Любую фичу можно проверить на соответствие этому требованию.
Для детального обоснования бизнес-идеи в игровой разработке существует два полярных подхода: экспертное мнение и аналитическая модель. Первый подход основывается на глубокой убеждённости, что если в одном помещении собрать экспертов в функциональных областях и фанатов определённого игрового жанра, то за пару лет они создадут хит, который сразит всех. Второй полярный подход — это замена геймдизайна аналитикой. Создание модели поведения игрока, вокруг которой уже строится реализация игры.
Игра World of Tanks запускалась на основании экспертного мнения, однако сейчас больше внимания уделяется сбору данных и аналитике. В целом, культура принятия решений выстраивается на основании экспертного мнения, подтверждённого данными.
Креатив нельзя создать по навязанной методологии
Налаженные в компании процессы — это скорее поддержка, нежели обязательство. Их функция — объяснять, как из одной точки в процессе производства попасть в другую, но команда сама решает, какая методология ей подходит в каждом конкретном случае. Главное — ничего не навязывать, так как жесткие ограничения убивают креатив. К примеру, игровых дизайнеров вообще трудно заставить работать по какой-либо методологии.
Начиная крупный проект, нужно заранее продумывать, будет он распределённым или нет. Необходимо обращать внимание на инфраструктуру, распределённое проектное планирование, наличие небюрократичной документации, разработку руководящих принципов, соответствие продукта образу мыслей пользователя. Важно наладить коммуникацию между сотрудниками и peer-to-peer связи между распределёнными командами на исполнительном уровне. А наличие централизованного плана поможет снизить объём передаваемой информации.
Региональная кастомизация
Полностью уникальные решения стоят дорого. Однако, если у нас будет одно решение и одинаковые игры для всех регионов, это не даст бизнесу нужного результата. Необходимо создавать кастомные решения, но выделять из них общую часть как с продуктовой, так и с технической точки зрения. Это приводит нас к топологии платформенного ядра, которое подключается к играм через плагины специфичной для каждой игры бизнес-логики. Задачка нетривиальная, но решаемая.
В современном геймдеве недостаточно иметь идеальную игровую механику. Чтобы игра долгое время оставалась по-настоящему успешной на рынке, вокруг неё должен быть выстроен целый набор сервисов и расширений метагеймплей. Нужна чёткая синхронизация между продуктовыми командами, работающими над игрой.
Одно и то же решение, запускаемое в разных регионах, должно учитывать культурные особенности, сегментацию рынка, конкуренцию в той или иной его нише, популярность решения в регионе в целом. Поэтому важно оперативно собирать обратную связь от пользователей, но если этот процесс затягивается, скажем, на полгода, то становится никому не нужным, так как люди к этому времени уже играют в другую игру.
Процесс региональной кастомизации построен вокруг двух команд. Reliability хорошо понимает, как устроена игра технически, и отвечает за то, чтобы технические решения были удачно применены в каждом из регионов. Live Operations отвечает за быстрый сбор информации. Это жизненно необходимо, так как всегда нужно понимать, какие требования существуют со стороны игроков в конкретном регионе, что нужно дорабатывать и т. д.
Построить захватывающую и одновременно хорошо масштабируемую и кастомизируемую игру — задача нетривиальная. И здесь очень большой вклад вносят сами команды, которые предлагают как свои решения, так и подходы к их реализации, настаивают на внедрении тех или иных функций, если они нужны пользователям.
В принципе, путём проб и ошибок распределённую разработку может выстроить любая компания. Нам удалось сделать этот процесс управляемым и предсказуемым по времени, учитывая предыдущие ошибки и накопленный опыт.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.