Scaled Agile Framework® в международной GameDev-компании
Xsolla — международная компания со штаб-квартирой в Лос-Анджелесе и офисами в Перми и Сеуле, предоставляющая разработчикам игр продукты и сервисы, которые помогают им строить и развивать бизнес: привлекать трафик, монетизировать игры и заниматься дистрибуцией. Компания берёт на себя все бизнес-технологии и даёт разработчикам игр возможность сосредоточиться на креативном процессе.
В августе 2017 года компания решила перейти к гибким методам управлениями проектами. О причинах, ходе и результатах этой Agile-трансформации мы поговорили с Константином Голубицким, CTO компании, и Александром Сайфурановым, вице-президентом по R&D.
Константин Голубицкий (слева) и Александр Сайфуранов
Почему вы решили перейти к Agile? Какие цели вы ставили перед этой трансформацией? Какие проблемы вы хотели решить?
Александр Сайфуранов: В 2017 году у нас было шесть функциональных команд: бэкенд, фронтенд, QA, дизайн, технические писатели и команда по кредитным картам и антифроду. Классическая IT-структура.
Основная сложность, которая вырастала из этой структуры, — длительность цикла разработки, из-за которой мы регулярно не удовлетворяли ожидания стейкхолдеров. То есть мы составляли план на месяц или квартал, шли по плану, придерживались ТЗ, реализовывали план и сдавали продукт, — и в этот момент оказывалось, что продукт уже утратил актуальность. Получалось, что мы сделали не совсем то и в любом случае поздно.
Разумеется, мы всеми силами пытались сократить time-to-market, но ни одно из придуманных нами решений не сработало.
Другой фактор — в тот момент топ-менеджмент поставил перед нами амбициозную задачу: за год расширить линейку продуктов с одного до семи. Мы поняли, что со старым подходом мы с поставленной задачей не справимся.
После этого мы обратились к Agile как к самому логичному для нас варианту: у нас высококонкурентный рынок, нам нужно делать короткие итерации и как можно быстрее поставлять продукт на рынок и получать обратную связь.
Константин Голубицкий: Хотел бы отметить ещё одну проблему, связанную с тем, что раньше у нас были монофункциональные команды. В реализации любой задачи разработки должны были принимать участие несколько функциональных команд, а в некоторых случаях и все функциональные команды.. Соответственно был единый бэклог задач и единый план. И чтобы внести хоть какое-то изменение в этот план, нужно было пересматривать задачи для всей группы разработки.
Перед внедрением Agile мы попробовали другой подход — проектное управление: сделали ещё один уровень управления и выделили проекты, но проблема с приоритезацией всего бэклога целиком никогда не ушла.
Как начинался ваш переход на Agile? Как он проходил? Можно ли сказать, что эта трансформация уже закончилась?
К.Г.: Сначала мы создали независимые кросс-функциональные продуктовые команды, чтобы каждая команда могла самостоятельно развивать свой продукт. Мы сформировали отдельные бэклоги по каждому из продуктов и разделили архитектуру, чтобы минимизировать зависимости между командами. На этом этапе мы перешли к продуктовой разработке: для каждого продукта — своя команда. Эта трансформация за год дала нам возможность доделать и успешно запустить 6 новых продуктов.
Дальше по инициативе нашего CEO в компании были созданы бизнес-лайны: структуры, которые отвечают за развитие прибыльного бизнеса в каждом из бизнес направлений, в которых мы работаем. У каждого бизнес-лайна свои цели, задачи, продукты и т.д.
С начала этого года мы пошли дальше и перешли на SAFe®, который очень хорошо вписался в существующую структуру: в каждом бизнес-лайне есть ряд команд, которые на предыдущем этапе работали независимо, а теперь их объединяют общие процессы и они создают ценность для всего бизнес-лайна.
Кроме того, решение перейти на SAFe было продиктовано и тем, что на этом этапе, — когда у нас уже 12 продуктовых и несколько сервисных команд — только Scrum и Kanban уже недостаточно. Нужен был дополнительный слой для координации команд между собой, их коммуникации с бизнесом и интеграции продуктов.
Пока мы используем только первые два уровня SAFe (команды и поезда), которых с запасом хватает для координации и эффективной работы наших 20+ команд, состоящих из более чем 200 сотрудников, и смотрим на перспективу на два другие уровня: large solution и portfolio.
А.С.: Ну и, разумеется, Agile-трансформация никогда не заканчивается, она продолжается непрерывно: мы всё время учимся, меняемся, совершенствуемся.
Можно ли подвести промежуточные итоги Agile-трансформации? Какие положительные изменения произошли за эти два года?
К.Г.: Совершенно точно повысилась прозрачность процессов. Коллеги в штаб-квартире в Лос-Анджелесе, где базируется топ-менеджмент, руководители бизнес-лайнов, маркетинг и бизнес-девелопмент, — то есть ключевые стейкхолдеры — существенно лучше стали понимать, что происходит в разработке тех или иных продуктов, и получили возможность влиять на эти процессы.
Другое важнейшее достижение Agile-трансформации вытекает из первого — это более тесная связка бизнеса и разработки: бизнес видит текущие процессы, участвует в планировании и системных демонстрациях, даёт обратную связь и вносит своевременные корректировки. Благодаря этой синхронизации бизнеса и разработки реже меняются приоритеты, поэтому улучшилась точность и качество доставки продукта.
А.С.: Да, мы стали гораздо лучше работать с ожиданиями стейкхолдеров. Теперь мы не просто ставим задачи, а определяем цели на квартал по доставке ценностей. Поэтому команды понимают, что они делают, а бизнес понимает, когда это будет сделано. Кроме того, мы проводим ретроспективный анализ: смотрим, что получилось, а что нет.
То есть проблему поставки не того и не в те сроки, о которой я говорил в начале, мы решили.
Как команда восприняла изменения? Как долго проходила адаптация?
А.С.: Команда, включая меня, была сначала настроена скептически. Разумеется, почти всегда любые изменения воспринимаются поначалу негативно. Задача руководства в такой ситуации — уважать мнение людей, но проводить изменения достаточно решительно, особенно если руководство считает, что эти перемены помогут компании завоевать лидирующие позиции на рынке. Мне кажется, мы с этой задачей успешно справились.
Мы приглашали консультантов, которые рассказывали нам о методологии Agile, об её плюсах, о том, как нужно поменять свое сознание, и о том как работать в Scrum-фреймворке.
Где-то через три месяца мы собрались с руководителями разработки, оценили наши текущие компетенции и прикинули, какие компетенции потребуются нам для создания тех или иных продуктов. Затем проконсультировались с тимлидами и разделили людей по командам.
Дальше уже говорили с отдельными командами и отдельными людьми. Разумеется, все равно оставались недовольные — с ними мы продолжали диалог индивидуально, стараясь ответить на вопросы и снять опасения. Не могу сказать, что все приняли эту идею, но подавляющее большинство нам поверило.
Оглядываясь назад, оценивая текущие достижения, глядя на то, насколько самоорганизованными стали команды и насколько они ценят доверие и творчество каждого человека, я понимаю, что мы тогда всё сделали правильно.
Какие у вас дальнейшие планы?
К.Г.: Наша текущая цель — итеративно улучшать все процессы в продуктовых командах и в разработке, максимально вовлекать коллег из других департаментов в наши процессы и делать эти процессы более прозрачными внутри компании.
А.С.: Кроме того, мы планируем поработать над визуализацией и прозрачностью. Например, у нас уже есть идеи по визуализации и публикации квартальных дорожных карт: это поможет нашим партнёрам лучше понимать, чем мы занимаемся и над чем мы сейчас работаем. Возможно, это также поможет снизить риски того, что внезапно будут приходить какие-то срочные задачи.
Помимо этого, мы совершенствуем метрики и работаем над тем, чтобы процессы разработки были более понятны и прозрачны для остальной компании.
Какую помощь вам оказали сотрудники ScrumTrek?
К.Г.: ScrumTrek оказал серьёзную помощь, потому что на начальном этапе очень важно было задействовать экспертов, которые на опыте других компаний могли рассказать, как и почему это всё работает.
Сначала Сергей Баранов провёл двухдневный тренинг по Scrum и Kanban для всех тимлидов и проектных менеджеров, которые в дальнейшем стали владельцами продуктов. На следующем этапе, когда мы переходили на SAFe, в аналогичном воркшопе Сергея Рогачева участвовали не только люди из разработки и продуктовых команд, но и руководители бизнес-подразделений, которые специально прилетели из Лос-Анджелеса.
Такое совместное обучение придает большую уверенность и синхронизирует ожидания от предстоящей трансформации для ее основных участников, стейкхолдеров и менеджмента компании. За это хотел бы сказать ScrumTrek большое спасибо.
А.С.: Да, на начальном этапе, когда в обсуждении участвовало очень много людей, высказывалось очень много мнений о целесообразности Agile-трансформации, договориться друг с другом нам помогли внешние эксперты, которые выступили в роли третейских судей.
Впоследствии ScrumTrek помогал оценить, насколько успешно работают Scrum-команды: какие процессы идут внутри, как команды взаимодействуют друг с другом и как — с бизнесом. И вот тогда-то мы провели сессию Value Stream Mapping и поняли, что таких коммуникаций сильно не хватает. После этого стало очевидно, что нужно внедрять SAFe, в чём нам тоже помогали консультанты ScrumTrek — Сергей Рогачев и Иван Селеверстов.
Как вы пришли к тому, чтобы обратиться именно в ScrumTrek?
А.С.: Со ScrumTrek мы знакомы довольно давно, с первых дней нашего образовательного пространства «Чердак Xsolla» в пермском офисе, где мы устраиваем митапы, хакатоны, обсуждения, лекции, тренинги. Один из таких тренингов — по бизнес-архитектуре — для нас провёл как раз Сергей Баранов. Нам тренинг очень понравился, с тех пор мы и подружились со ScrumTrek.
Как вы считаете, что лучше: работать с приглашенным консультантом или же иметь собственного Scrum-мастера?
А.С.: Я бы сказал, что на начальном этапе нужен внешний консультант — это ключ к успеху. Это профессионал, который действует не по наитию, а точно знает, что нужно делать. Он не только всё правильно организует, но и научит этому всю вашу команду: не только Scrum-мастера, а всех сотрудников. Очень важно, чтобы вся команда делала всё осознанно: все ритуалы, которые есть в Scrum, имеют большое значение — ни один из них нельзя просто взять и выбросить или провести как-то иначе. Ну и помимо прочего, хороший консультант должен быть и хорошим фасилитатором с лидерскими навыками.
В дальнейшем, разумеется, когда ваш Scrum-мастер поймет, что и как нужно делать, то он должен быть частью команды: команда должна видеть его каждый день и работать с ним в непосредственном контакте, потому что именно так рождается доверие. Это очень важно в Scrum-команде.
Что бы вы могли порекомендовать компаниям, которые только задумываются о переходе на Agile?
А.С.: Если вы решили, что необходимо проводить Agile-трансформацию, потому что текущие подходы и практики не работают или работают недостаточно эффективно, решительно претворяйте эти изменения в жизнь. Не останавливайтесь, будьте решительными и проявляйте лидерство — только так вы сможете добиться успеха.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.