Распределенная разработка. Опыт MS-1 (Wargaming)

Как построена распределенная работа над проектом в мобильной студии разработки MS-1 (Wargaming), — в своей колонке на App2Top.ru рассказал Вадим Гильварг, программ-менеджер World of Tanks Blitz.

World of Tanks Blitz

О себе

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

Вадим Гильварг

До MS-1 я занимался казуальными играми, а также работал в аутсорсинговой компании, где разрабатывал проекты под нужды заказчиков (мобильные приложения, веб-сайты и другое). В команду World of Tanks Blitz я изначально пришел на должность проджект-менеджера, скрам-мастера. Здесь занимался разработкой камуфляжей для танков, игровых режимов, внутриигровых ивентов и другого функционала.

О команде

Сегодня в студии MS-1 работает более 360 человек. Мы занимаемся разработкой World of Tanks Blitz, а также мобильного корабельного онлайн-экшена World of Warships Blitz. Кроме того, на сегодняшний день в разработке у нас находится два проекта на движке Unreal Engine в жанрах шутер и экшен.

Наша команда распределена между 5 офисами — в Минске, Москве (здесь в основном ведется разработка мобильных «Танков»), Шанхае (здесь работают над World of Warships Blitz), Берлине, и совсем недавно мы открыли новый офис в Вильнюсе, в котором преимущественно ведется разработка новых проектов.

Роадмап как живой инструмент

Итак, распределенная разработка. Еще до пандемии мы смогли опробовать кое-какие практики и внедрить их в свою работу.

Так, в нашей команде не формируется и не утверждается детальный роадмап, которому мы слепо следуем в течение года. У нас роадмап — это живой инструмент, который может меняться буквально каждый день. Мы практикуем Agile-подход и считаем, что планировать на год вперед в стремительно развивающейся индустрии как минимум нецелесообразно: это влечет за собой большое количество упущенных возможностей и несвоевременную реакцию на изменения рынка. Также это не дает гибкости в плане реакции на положительный или отрицательный фидбэк на какие-то выпущенные ранее фичи.

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

Бэклог как основа

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

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

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

Наш инструментарий

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

Естественно, когда мы вводили Slack, такого большого набора каналов не было, мы нарабатывали их постепенно — какие-то убирали, какие-то добавляли. Сегодня же мы имеем некий набор каналов, который позволяет нашей команде коммуницировать эффективно, поэтому новый сотрудник сможет довольно быстро понять, в какой из каналов можно задать тот или иной вопрос, чтобы получить необходимую информацию.

Межкомандное распределение

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

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

Наш кастомный фреймворк

Мы разделяем ценности Agile и за многие годы сформировали понимание того, что Scrum — очень удобная и полезная штука. Однако, будучи отличным инструментом для одной команды, он слабо подходил для координации работы 15-20 команд.

Мы начали думать, как адаптировать этот достаточно удобный и эффективный, на наш взгляд, фреймворк под собственные нужды. Получилось так, что параллельно с нами с этой же проблемой начали сталкиваться и другие компании по всему миру, и в итоге стали появляться фреймворки масштабированного Scrum: LeSS, SAFe, Nexus и тому подобные.

В ходе работы над собственным решением какие-то практики мы придумывали самостоятельно, какие-то заимствовали из существующих фреймворков. В итоге получился собственный фреймворк масштабированного Agile. К тому времени, когда мы сформировали его и начали по нему работать, команда Джеффа Сазерленда (Jeffrey Sutherland), одного из авторов Agile-манифеста и Scrum, выпустила свой фреймворк Scrum@Scale, который оказался очень похож на то, что мы создали самостоятельно.

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

Мы считаем основные церемонии Scrum — очень правильными инструментами, так как они позволяют всей команде смотреть в одну сторону. Daily Stand-Up, Sprint Planning, Sprint Review и Sprint Retrospective — это четыре основные церемонии Scrum, масштабированные на уровень разработки каждой новой версии нашей игры.

У нас есть планирование каждой версии, во время которой продукт-оунеры каждой команды заявляют какой-то набор фич на версию и обязуются его доставить по окончании разработки этой версии. Также у нас проходят Version Demo — это аналог Sprint Review, во время которого команды демонстрируют функционал, показывают разработанные фичи и принимают обратную связь. На этом мероприятии оценивается целостность того, что было сделано, а также высказываются мнения, будет ли это интересно нашим пользователям.

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

Таким образом, у нас есть Scrum-церемонии на уровне feature-команд и масштабированные скрам-церемонии на уровне команды проекта. Это позволяет не терять фокус, не забывать, что мы работаем не каждый над своей фичей, а делаем одну большую игру.

Язык коммуникации

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

И наоборот, человек, не знающий английский, также может работать в MS-1, просто мы будем стараться подобрать ему команду, в которой английский язык не сильно востребован и где пересечение с англоговорящими не существенное. Но в то же время мы постараемся максимально быстро обучить его, для чего предусмотрено посещение языковых курсов. Как правило, даже люди, слабо знающие английский язык, приходя к нам в команду, постепенно подтягивают свой уровень.

Общение прежде всего

Мы регулярно проводим так называемые teams health checks, во время которых менеджеры команд мониторят состояние команды, ее мотивацию, удобство инструментария и т. д. На удаленке они стали особенно полезны. Одним из критериев в данном мониторинге является фан. К сожалению, приходится констатировать, что показатели фана сейчас просели, ощущение единства команды также снизилось.

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

Мы пользуемся голосовыми чатами, что позволяет эмулировать ситуацию пребывания в комнате. Это не обмен технической информацией или пересылка рабочих материалов, а исключительно повторение момента, в котором ты, сидя за столом в офисе, можешь поднять голову и сказать: «О, ребята, хотите расскажу прикольный случай, который вчера со мной произошел?» или «А кто-нибудь сталкивался с такой проблемой?» Это не требует открытия Slack, поиска соответствующего канала, описания проблемы. Ты просто поднимаешь голову и спрашиваешь: «А кто-нибудь такое уже делал?» А в ответ ему: «Да, у меня был такой кейс, иди покажу». Благодаря использованию таких инструментов нам удалось не потерять дух коллективного творчества, позволяющего нашим командам вместе проводить мозговые штурмы, дорабатывать свои фичи.

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