Когда Дарья пришла в PlayFlock в начале 2021 года, студия уже была серьезным игроком: 80 сотрудников, 60 миллионов игроков в 165 странах, портфель free-to-play (бесплатных) игр для iOS, Android и нескольких веб-платформ.
«Я пришла без опыта в геймдеве. И именно это, как мне кажется, стало преимуществом — я видела процессы свежим взглядом и не знала, что "так принято"», — говорит Дарья.
Уже через несколько недель она выявила важную область для улучшений. Релизный процесс был устроен так, что любая задача на деплой превращалась в многочасовое приключение: подготовка сборки занимала 8 часов, цикл от билда до тестирования — ещё 8 часов. По словам Дарьи, проблема была не техническая, а скорее организационная. Команда работала на 10+ платформах одновременно (iOS, Android, несколько веб и социальных сетей), каждый день команда генерировала около 100 изменений. Но инфраструктура для релизов оставалась ручной и завязанной на одного человека.
«Я начала с простого: задала вопрос "а почему именно так?" — и не получила ответа, который меня бы убедил. Это был сигнал, что здесь есть что менять», – рассказывает Акульшина.
Все задачи требовали аппрувов единственного человека: тимлида, без которого не мог выпуститься ни один релиз. Тимлид был сильным экспертом и руководителем, который не только согласовывал релизы и проверял их технически, но еще и управлял командой, которая активно разрабатывала новые фичи или фиксила баги. Кроме того, разработка действовала по принципу «move fast, break things» (перевод: двигайся быстро, ломай все подряд), так как на рынке игр продолжался послепандемийный бум и нужно было максимально быстро реализовывать новые идеи и доставлять их пользователям.
Как именно выглядел процесс в деталях? Предположим, компания хочет выпустить новую фичу или тематическое обновление игры к Новому году. Сначала нужно собрать билд с этим изменением для iOS (приоритетная для бизнеса платформа), а потом сделать еще десяток веток для других платформ. Менеджер проекта (PM) ставит задачу: нужен обновленный контент для новогоднего билда. Для этого нужно собрать иллюстрации от отдела 2D-художников, обновленные 3D-ассеты от отдела 3D-моделирования, новые звуки, новый сторителлинг от отдела нарративного дизайна, новую карту местности и так далее — а затем передать эти задачи в разработку. Если PM не сильно подкован технически, то декомпозировать задачу на подзадачи для команды разработки будет тимлид. После этого PM приходит к тимлиду с вопросом, когда будет готов билд. Тимлиду приходится держать в голове всех сотрудников и их задачи и отслеживать статус: кто что делает, на какой стадии pipeline разработки.
После окончания сборки тимлид ставит задачу кому-то из команды разработки собрать билд под нужную платформу. При этом эта задача ставится не в том проекте, где PM-ы контролируют общую подготовку новогоднего билда, а в подпроектах — например, в GitHub, Slack или в таск-трекере конкретной команды разработки. Разработчик собирает тестовую версию билда (DevBuild), PM передает ее на проверку в QA-отдел.
Команда тестирования проверяет билд и, как правило, находит баги, которые попадают на исправление в отдел разработки. Этот цикл может повторяться несколько раз: правки, пересборка, снова тестирование. Затем все то же самое повторяется для Production Build, после чего готовый билд готовится к релизу. При этом важно следить за версионностью, и всем этим приходится заниматься кому-то одному из команды разработки, держа в памяти весь контекст — иначе можно легко перепутать версии. А теперь представьте, что у вас больше десяти платформ, и каждый билд нужно каждый раз пересобирать для каждой из платформ.
«При этом процессом вроде бы управляет PM, но одновременно есть огромное количество точек, когда PM утрачивает контроль — например, когда кто-то из команды разработки пересобирает очередную версию билда с исправлениями. Если вся команда разработки занята, тимлиду придется самостоятельно собирать билды. Все это очень сильно тормозило процессы, учитывая, что у нас могло собираться и обновляться четыре проекта одновременно. Ценное и очень дорогое время команды разработки уходило на рутинные задачи, которые повторялись каждый день по десять раз. При этом сборка билда — процесс небыстрый, но весьма рутинный, который реально автоматизировать с помощью скриптов», — поясняет Дарья.
Автоматизация без программирования: как это работало
Первым шагом стал аудит пайплайна вместе с DevOps-командой, который подтвердил: значительная часть времени уходила на рутинные операции, которые при правильной автоматизации не требовали участия человека вообще.
Дарья выстроила систему из двух ключевых элементов. Первый — шаблоны задач для релизных веток. Вместо того чтобы каждый раз вручную настраивать задачи в трекере, команда получила автоматические шаблоны: менеджер открывал новую ветку в GitHub — и всё необходимое для сопровождения релиза создавалось само. Время подготовки упало с 8 часов до 1 часа.
Второй элемент — перераспределение прав на деплой. Раньше только тимлид мог запустить сборку и отправить её в продакшн. После изменений любой менеджер мог самостоятельно триггерить билд из GitHub-ветки и релизить на все платформы.
«Это звучит как мелочь, но это убирает целый класс блокеров. Тимлид в отпуске? Нет проблем. Тимлид занят критическим багом? Релиз все равно идет по расписанию», – обращает внимание Дарья.
Еще одно решение, которое Дарья предложила и реализовала вместе с командой, звучит тоже очень интересно.
«Обычно разработкой управляют разработчики. А мы сделали так, чтобы разработкой могли управлять PM-ы — через групповой чат в Slack. Я сама как PM была идеальным пользователем продукта, который мы разрабатывали, поэтому я активно привносила ключевые инсайты для построения этого внутреннего продукта и автоматизации релизов», – рассказывает Дарья Акульшина.
Конкретно это означало следующее: менеджеры получили возможность самостоятельно собирать версию приложения, отправлять ее в тест и релизить на все платформы — без единой строчки кода и без участия тимлида. Весь процесс запускался прямо из Slack.
Новый подход пришелся по вкусу и остальной команде, особенно шаблоны на любые рутинные задачи в компании, которые теперь можно было самостоятельно разрабатывать во внутреннем таск-трекере команды.
«Мы начали со slash-команд с аргументами (например, /build android prod hotfix-1.2), потом доросли до интерактивных кнопок и модалок с выбором атрибутов. Команды через webhook уходили в небольшой бэкенд, тот через GitHub API запускал workflow_dispatch и слушал события через webhooks от GitHub, чтобы постить статус обратно в Slack», – поясняет Дарья.
Работа с DevOps-командой над оптимизацией CI/CD дала ещё один впечатляющий результат: цикл от сборки до тестирования сократился с 8 часов до 30 минут — в 16 раз.
«У нас не было выделенного DevOps — задачу взял на себя бэкендер, у которого был интерес к инфраструктурным задачам. Я как PM отвечала за постановку задач и приоритеты. Первым делом — кэширование зависимостей, параллельный запуск джобов, разнесённые стадии (быстрые smoke-тесты на каждый PR, тяжёлая регрессия — отдельным ночным прогоном). Это базовая гигиена, без неё дальше двигаться было бессмысленно. Но настоящий сдвиг был не в самом конвейере, а в том, кто и как им управляет. Мы вынесли управление сборками и деплоями в Slack. Технически связка простая: Slack — пульт, GitHub — двигатель. В Slack-бот зашиты команды, под капотом — GitHub Actions. Менеджер открывает форму в чате, выбирает, что именно собрать и с какими атрибутами, и в том же треде получает ссылку на готовый билд. Разработанный бот покрывал почти весь спектр сценариев: AAB для Google Play и IPA для App Store, отдельные сборки для QA с выбором конфигурации (окружение, фича-флаги, версия), полную пересборку нативного бинаря или быстрый OTA-апдейт без перевыкладки в сторы, отдельный ускоренный пайплайн для хотфиксов. Параллельно мы научили всех PM-ов работать с версионированием — кто за что отвечает в номерах версий, как читать changelog, когда мажорный релиз, когда патч. И сделали визуализацию веток: менеджер мог в один клик посмотреть, что сейчас в dev, что в release, что в prod, не обращаясь к git», – делится опытом Дарья Акульшина.
В сумме эти изменения и дали эффект ускорения в 16 раз:
- Релиз перестал быть событием, требующим разработчика,
- Менеджер сам видит состояние веток, сам собирает нужный билд, сам катит хотфикс,
- А тимлид перестал быть единственной точкой контроля, перестал заниматься рутиной и смог сосредоточиться на управлении сложной разработкой и помощи PM-ам со сложными экспертными вопросами.
Цифры, которые говорят сами за себя
«Важно понимать: мы не просто ускорили процесс. Мы сделали его устойчивым. Раньше выпадение одного человека могло остановить релизы на весь день. После — нет», – объясняет Акульшина.
Частота релизов выросла кратно. Если на старте релиз был событием раз в неделю-две, то после всех изменений деплои стали рутиной: несколько в день между всеми платформами. Менеджеры выкатывали обновления контента, маркетинг — A/B-тесты, мобильщики — фиксы, и все обновления стало возможным выполнять через одну и ту же кнопку.
Время от готовой фичи до прода сократилось радикально. По подсчетам Дарьи, build-to-test цикл сократился с 8 часов до 30 минут — это то самое 16-кратное ускорение. Setup новой задачи в пайплайне тоже ускорился с 8 часов до 1 часа за счёт шаблонов веток. Иными словами, фича, готовая к выкатке утром, могла быть в проде уже до обеда, а не через пару дней.
Хотфиксы перестали быть кризисом. До перестройки выкатить фикс на проде было отдельным проектом — собрать команду, выпросить тимлида, дождаться окна. После — PM сам жал кнопку Hotfix в Slack, и через 30 минут патч был в сторе (или OTA-апдейтом — за минуты). Это снизило стоимость ошибки: команда стала смелее экспериментировать, потому что цена отката больше не была заградительной.
Кроме того, снизился процент вынужденных откатов изменений: если раньше любая регрессия приводила к откату всего релиза, потому что чинить было дольше, чем катить старое, то сейчас стало намного проще пересобрать и выкатить фикс через тот же бот, чем разворачивать релиз назад. Полные откаты остались только для критичных ошибок, без которых не обходится ни один процесс разработки (краши, потеря данных), и стали единичными случаями за квартал.
Почему это должен делать PM, а не тимлид
Здесь Дарья формулирует позицию, с которой согласятся не все, но которую сложно оспорить фактами. Обычный аргумент звучит так: разработчики должны контролировать релизы, потому что они лучше понимают технику. Дарья переворачивает эту логику:
«В большинстве компаний релизный процесс — территория разработчиков. PM приходит с задачей, а дальше ждет. Я убеждена, что это не всегда правильно. PM — это тот, кто несет ответственность за скорость доставки ценности пользователю. Кроме того, менеджеры зачастую могут принимать эти решения быстрее, потому что у них контекста продукта больше. Значит, менеджер вполне может владеть инфраструктурой, которая эту ценность доставляет», – поясняет Дарья Акульшина.
По ее словам, тимлид знал код, но именно менеджер понимал, какая фича нужна к завтрашнему утру, какой сегмент игроков она затрагивает и что произойдёт, если релиз сдвинется на день. Когда решение о деплое перешло к тому, кто держит в голове продуктовый контекст, скорость выросла не только за счёт автоматизации, но и за счёт качества самих решений.
Как преодолеть сопротивление изменениям
В данном случае основное сопротивление, с которым столкнулась Дарья, было от команды разработки.
«Прямо в лоб переубедить не получалось — на любой аргумент в духе "это сэкономит время" звучало "ты не понимаешь, как устроена разработка"», – поясняет Дарья Акульшина.
Это понятно: разработчики опасались, что PM-ы «все сломают», развалят то, что пусть медленно, но работало. Что сработало у Дарьи: не попытки переубедить на словах, а маленький эксперимент с цифрами. Договорились попробовать новый процесс на одной команде и одном продукте в течение 2 недель. Замерили до и после: время сборки, количество деплоев, сколько раз тимлид был реально нужен. Когда стало видно, что без него релизы не разваливаются, а ускоряются, а сам он перестал быть дежурным по пожарам — позиция поменялась сама.
Главный урок: с инженерами не работают аргументы «будет лучше», работают только данные и результаты экспериментов, в идеале с их же кодовой базы.
Интересно, что случаи, когда PM-ы принимали неверные решения о деплое — были. По словам Дарьи, самыми распространенными были следующие проколы: менеджер выбирал не то окружение (думал, что катит на стейдж — а уехало в прод), путал версии после хотфикса, или жал релиз вечером в пятницу, чего делать не стоило. Однако цена ошибок оказалась низкой именно потому, что система к ним готовилась. Откат — такая же кнопка, как и деплой; rollback занимал ровно столько же времени, сколько обычный билд. Перед запуском бот показывал, что именно поедет (ветка, окружение, версия) и просил подтверждение — это отлавливало половину промахов до того, как они уходили.
«Все запуски летели в публичный Slack-канал, поэтому если менеджер делал что-то странное, в течение минуты приходил кто-то из инженеров со словами "ты уверен?". И, пожалуй, главное — мы изначально договорились, что ошибки тут не наказываются, а становятся поводом улучшить guardrails. После каждого инцидента не было разбора "кто виноват", а был апдейт бота: добавили подтверждение для прода, заблокировали пятничные релизы после 17:00, сделали diff-превью изменений. Так система умнела сама собой», – вспоминает Дарья.
Три полезных вывода
По итогам разговора мы сформулировали три подхода, которые сработали в PlayFlock и, по убеждению Дарьи, применимы практически в любой продуктовой команде.
1. Сначала — анализ: соберите данные и найдите, где замедление или бутылочное горлышко
Не нужно оптимизировать то, что уже работает нормально. Начните с аудита: где люди ждут дольше всего, кто является единственным источником решения. Обычно это становится видно за несколько дней наблюдения.
«Сядьте рядом с человеком, через которого сейчас идут все релизы — обычно это тимлид, иногда DevOps — и попросите показать вам один полный цикл деплоя от начала до конца. Не предлагайте ничего менять, просто смотрите и записывайте: где он ждёт, где переключается, что проверяет руками, где злится. Через пару таких прогонов у вас на руках будет карта реальных болевых точек, а не теоретических гипотез — и, что важнее, человек-bottleneck скорее всего станет вашим союзником! Если же вы поймете, что определенные задачи действительно требуют ручного, вдумчивого, экспертного труда, не нужно их автоматизировать — начните с рутины, которой обычно в любом проекте хватает», – рекомендует Дарья Акульшина.
2. Автоматизировать постепенно и с умом
Помните, что вам нужны реальные улучшения, а не автоматизация во имя автоматизации. А главное, следуйте стратегии маленьких шагов.
«Не пытайтесь сразу перестроить весь pipeline. Найдите один самый болезненный шаг (у нас это была подготовка сборки на 8 часов) и почините его. Маленькая победа, измеренная и показанная команде, откроет вам двери (и сердца команды) для следующих изменений. Большой план в начале пути обычно умирает в первом же спринте, а пошаговые улучшения часто дают неожиданно сильные результаты», – советует Дарья.
3. Не стоит недооценивать способности других
PM-ы легко научились читать логи и разбираться в build logs достаточно, чтобы локализовать проблему и передать её нужному инженеру с конкретным описанием, а не размытым «что-то сломалось».
«В PlayFlock я поняла главное: зависимость от разработчиков в рутинных операциях — это не особенность геймдева. Это универсальная боль. И она решается не наймом ещё одного инженера, а перестройкой системы», – отмечает в заключение Дарья.
Дарья Акульшина — project manager. С 2021 года она работает в PlayFlock, где перестроила релизный процесс для портфеля free-to-play игр с 60 миллионами пользователей.