Гибкие методологии для быстрого роста в геймдеве

Участники проекта в NX Studio — о том, как Scrum поддерживает быстрый рост компании-разработчика игр.

Дмитрий Цуканов

Продюсер Hero Wars Mobile, NX Studio.

Александр Иванов

Генеральный продюсер, NX Studio.

NX Studio — студия разработки социальных и мобильных игр. Компания работает с крупнейшим разработчиком популярных игр в качестве подрядчика. В том числе, сотрудники студии участвовали в разработке игры Hero Wars («Хроники Хаоса»), которая в конце 2019 года стала самой кассовой в России.

В 2020 году команда разработчиков увеличилась в несколько раз, и специалисты NX Studio обратились в ScrumTrek, чтобы совместно внедрить новые методы управления на этапе роста. На тот момент Дмитрий Цуканов работал в NX Studio как продюсер Hero Wars Mobile, а Александр Иванов участвовал в проекте в роли генерального продюсера NX Studio. В интервью они вместе поделились результатами проекта.

Как работа над игрой была организована до начала проекта?

Дмитрий Цуканов: Изначально нас было меньше 10 человек. Мы хорошо умели действовать как дружная команда: все вместе фокусировались на одной задаче и решали ее. Но весной 2020 года мы выросли вдвое и благодаря успеху игры продолжили расти. Нас стало слишком много, чтобы наваливаться на одну задачу «всем миром». Нужны были новые способы решать несколько задач одновременно и не терять в качестве работы.

В рамках внутреннего эксперимента мы разделились на две команды, и сохранили эффективность в параллельной работе. И тогда мы задумались: можем ли мы решать еще больше задач одновременно? Собственно, тогда мы позвали ScrumTrek.

Почему решили внедрять гибкие методологии с участием консультантов?

Александр Иванов: Сначала мы экспериментировали со Scrum самостоятельно. Еще до этапа роста единая команда из 10 человек работала по Scrum или его вариациям. Мы не стремились к особой чистоте методологии, чтобы все было как по учебнику. Скорее, деление процесса на спринты было для нас достаточно естественным, поэтому не нужно было ничего придумывать.

Затем несколько человек из команды отправились на учебу в ScrumTrek. Когда ребята отучились, завязался контакт. Мы подумали, что можно попробовать поработать с тренерами в другом формате.

Дмитрий: К моменту совместного проекта со ScrumTrek мы уже находились в динамике: у нас были выстроены команды, было понимание подхода. Я думаю, что мы на 90% работали по Scrum и шли в правильном направлении. Однако с привлечением специалистов мы надеялись быстрее получить нужный результат. ScrumTrek могли помочь нам ускориться, осознать неправильно понятые моменты в методологии, решить конкретные задачи, для которых еще не было решения.

Как шел сам процесс внедрения изменений?

Александр: В апреле мы встретились с Иваном Селеверстовым и Русланом Юсуповым и совместно запустили пилотный проект — перестроили процессы в нескольких командах.

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

Дмитрий: Чтобы внедрить это решение, в мае мы провели сессию самодизайна. Другими словами, предложили сотрудникам самостоятельно спроектировать новую структуру. Команда на сессии сама решала, как поделиться на группы по-другому.

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

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

В процессе работы и коучинга стало понятно, что у нас подкованная команда: ребята знали ритуалы, знали термины, понимали, как все работает. Так что нам даже не потребовался отдельный тренинг по Scrum. Несколько человек отправились на обучение прикладным навыкам. Мы проходили школу Product Owner, ребята из команды проходили Scrum-мастера. Это помогло обогатить инструментарий, даже если в остальном вроде все работает.

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

Какие были сложности на этом пути? Как решали возникающие трудности?

Дмитрий: В первую очередь, изначально были сложности в коммуникации. Мы все привыкли работать сами с собой, самостоятельно решать, как выстраивать свою работу. И тут пришли какие-то люди со своим опытом и начали рассказывать, как нам правильно работать. Соответственно, был этап притирки. Мы собрали обратную связь, поделились с Русланом. Тренеры адекватно это восприняли, скорректировали работу и впоследствии такой проблемы больше не возникало. Сотрудники отмечали, что стало лучше.

Александр: Да, у нас люди любят действовать обстоятельно, последовательно, чтобы было время подумать, без «быстрее-быстрее-давай». Иван и Руслан подстроились под наш ритм и стиль работы. Если первой реакцией команды было сопротивление чужим людям, то со временем удалось сформировать доверие к процессу изменений.

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

Сколько времени потребовалось на изменения?

Дмитрий: Я бы оценил весь процесс в три месяца, хотя «чистого времени» мы потратили гораздо меньше. Важно, что изменения со временем «докатываются». Например, мы проводим самодизайн, потом команда первое время осмысляет этот опыт.

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

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

Как оценивали итоги проекта?

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

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

Александр: К измеримым результатам можно отнести, например, time to market. В ходе проекта он сначала снизился, потом слегка увеличился. Это помогло найти новые ограничения в нашем процессе. С новыми навыками мы смогли проработать эти ограничения, и по результатам всего проекта показатель сократили и продолжаем сокращать самостоятельно. Для нас было важно, что некоторые проблемы мы увидели по-новому, не так как делали раньше. Мы уже были оснащены инструментарием для их решения, так что было интересно.

Какие качественные результаты получили?

Александр: Психологически команда очень сильно изменилась, и это заметно со стороны. Я работаю с тимлидами и вижу, что люди получили новые инсайты в понимании Agile. Это такое «Хоба! Так вот как это работает!».

Вовлеченность в работу с продуктом сильно выросла. Один из наших запросов был про ответственность. Мы не понимали, как это измерить, и даже не пытались подсчитать количественно. Но по ощущениям, люди в команде стали относиться к работе по-хозяйски в хорошем смысле: «это мое, я за это отвечаю и хочу, чтобы здесь все было хорошо».

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

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

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

Как ситуация развивается сейчас? Планируете масштабировать эти практики на всю компанию?

Александр: Какие-то инструменты и элементы методологии уже распространяются по другим подразделениям.

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

Раньше, конечно, была такая аргументация: ой, ну, в gamedev Agile не работает, в играх так нельзя. Оказалось, что можно.

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