Техника безопасности при запуске крупной фичи: баланс между быстрыми метриками и прыжком веры
Практически любой зрелый ИТ-продукт отчасти напоминает неповоротливый механизм, в который сложно вносить глобальные изменения, а предсказать реакцию пользователей на них еще сложнее. Но даже с учетом этого внесение новых крупных фич нередко является единственным вариантом развития продукта. В результате компании вынуждены идти на риски.
Меня зовут Алексей Сенников. Я директор по направлению контента и AI технологий в ОК. В этой статье я хочу поделиться правилами безопасного внедрения крупных фич в большие продукты, которые мы с командой выработали в процессе масштабного редизайна Ленты в ОК.
ОК сейчас
ОК — одна из самых популярных социальных сетей в рунете, в которой зарегистрированы семь из десяти россиян, пользующихся соцсетями. Ежемесячная аудитория ОК в России составляет более 34 млн пользователей из РФ.
ОК имеет четыре платформы, и главная из них — Android. Ядро аудитории формируют пользователи в возрасте от 35 до 55 лет (женщин в два раза больше, чем мужчин). Причем аудитория в ОК довольно активная. Например, ежедневно в соцсети создаются несколько миллионов единиц контента, на которые ставят до 17 млрд классов в месяц и тратят на просмотр более 800 млн минут в день. Для понимания — на просмотр всех 2137 серий самого «долгоиграющего» сериала «Санта Барбара» нужно всего 1600 минут. Соответственно, время, проводимое пользователями ОК за просмотром контента в течение всего одного дня, эквивалентно 500 тысячам просмотров «Санта Барбары».
Важно, что ОК — продукт с длительной историей и своими продуктовыми артефактами.
Наши изменения: варианты обновления соцсети
В 2024 году ОК исполнилось 18 лет. И на протяжении всего этого времени мы планомерно и последовательно работаем над улучшением всех аспектов соцсети — от оптимизации требований к ресурсам до улучшения механик взаимодействия с внутренними сервисами.
Но каждый зрелый продукт со временем приходит к состоянию, когда небольших обновлений для роста уже недостаточно. Нужны масштабные изменения. В рамках нашей соцсети было три способа внести в продукт что‑то глобально новое:
провести радикальный редизайн интерфейсов;
обновить устаревшие core‑сценарии;
внедрить новые глобальные фичи и механики.
Нюанс в том, что за 18 лет мы получили консервативную аудиторию, часть из которой чувствительно реагирует даже на изменение цвета кнопок в интерфейсе. При этом другая часть пользователей неизменно хочет заметных перемен. То есть важно было «угодить всем».
Более того, нам были нужны не «изменения ради изменений», а обновления, которые могли бы улучшить опеределенные ключевые продуктовые метрики нашей сети — Timespent и прибыль от рекламы. И такой эффект в нашем случае возможно получить, только если «затронуть» какой‑либо из основных сервисов — например, Ленту.
Лента — ключевой сервис по использованию в ОК по времени, с которым ежедневно взаимодействует 80% аудитории. Таким образом, глобальные изменения в Ленте пользователи увидят сразу. А изменения на такой аудитории дадут значимый эффект на ключевые метрики.
Поэтому для глобального обновления ОК мы решили провести масштабный редизайн Ленты.
Исходные условия и требования к подготовке обновлений
В ОК довольно много продуктового legacy, которое любое масштабное изменение в сервисах не могло не затронуть. Поэтому еще на этапе планирования обновления было критически важно ответить на ряд вопросов, среди которых:
Как запуститься не за 2–3 года, а быстрее?
Как спроектировать и оценить эксперименты?
Как понять, что из глобальных изменений повлияло на поведение пользователей?
Сколько держать эксперимент, чтобы выработать у пользователя новые привычки?
Что сделать, чтобы релиз на всю аудиторию был выверенным и прогнозируемым, а не «прыжком веры»?
После этого нам предстояло выбрать формат проведения редизайна. В общем случае можно выделить три сценариях.
Долго и аккуратно. Берем большую команду продакт‑менеджеров и исследователей, тратим полгода на исследования. После этого начинаем разработку и выкатываем фичи по мере их готовности через множество А/Б‑экспериментов. По мере релизов занимаемся доработкой уже раскатанных фич.
Быстро и кое‑как. Исключаем этап исследований, рисуем макеты на свой вкус и пытаемся все сделать, как можно быстрее. При этом, не обращаем внимание на баги и сразу катим новые фичи на всю аудиторию.
Быстро, но максимально аккуратно. Компромиссный вариант, который предполагает уход от лишней бюрократии, но без ущерба качеству продукта и с сохранением всех тестов и исследований.
Второй вариант очевидно неоптимальный. А первый не подошел нам из‑за сжатых сроков — на редизайн у нас было всего 4 месяца. Соответственно, мы пошли по третьему пути, стремясь провести все обновления быстро, но предельно аккуратно.
И на этом пути мы выработали для себя ряд универсальных правил «техники безопасности» для прогнозируемого и безболезненного запуска новых масштабных изменений в продукте, которые будут справедливы практически для любого запуска, независимо от профиля и особенностей продукта и обновлений.
Правило №1. Учитывайте специфику своего продукта
У каждого продукта есть свои специфики. Да, это очевидно многим, кто читает этот материал. Но вы не поверите, сколько людей забывает об этом при изменениях и делает что‑то без учета специфика продукта.
Для определения подобной специфики ОК достаточно подробно изучить графики DAU. По ним видно, что начиная с нового года, активность аудитории начинает падать вплоть до начала отпусков. Все это прерывается праздниками, когда часть аудитории ненадолго возвращается. С сентября, наоборот, — всё больше людей начинает сидеть в соцсети. В ОК это называется восходящим трендом.
Мы понимали, что в период отпусков люди будут плохо воспринимать изменения, а в начале года мы просто физически не успеем сделать что‑либо масштабное. Поэтому в нашем случае наилучшим временем для внесения глобальных изменений в интерфейс ОК является именно период восходящего тренда — с сентября по декабрь. При этом важно понимать, что для каждого продукта «лучшее время» отличается, поэтому важно изучать паттерны пользователей и на их основе принимать решения.
Правило №2. Создавайте картинку «ожидание-реальность»
Перед началом любых изменений важно понимать «целевое состояние» продукта после раскатки обновлений. Поэтому любым крупным запускам должен предшествовать этап подробной проработки, что именно изменится в продукте, как изменится и как это повлияет на смежные сервисы. И чтобы зафиксировать ожидания, в идеале сразу графически изобразить желаемый результат.
Мы были ограничены 4 месяцами и понимали, что после завершения работы разработчиков придется быстро проверять все изменения и оперативно вносить правки. При этом, в нашем случае задача редизайна предполагала более 100 изменений, причем сразу на 4 платформах — Android/iOS/web/mobweb. Довольно очевидно, что удержать в голове все обновления физически невозможно. Поэтому до начала разработки мы для каждой платформы сделали в Figma сетку с дизайном текущего прод состояния и вариантом от дизайнера.
Этот макет решал две задачи:
использовался дизайнерами в качестве подсказки в процессе отрисовки нового интерфейса;
использовался на этапе проверки в качестве референса — продакт‑менеджер фиксировал итоговое состояние и, если находил критические несоответствия, возвращал фичи на доработку.
Здесь стоит отметить, что обычно упомянутая проверка выполняется тестировщиками и дизайнерами на стадии тестирования и дизайн ревью. И она есть. Но необходимость дополнительного контроля тоже обоснована.
Во‑первых, продакт‑менеджер отвечает за конечный вид продукта, то есть должен сам проверить и посмотреть изменения, которые сделаны и убедиться, что старые фичи не забыли перенести.
Во‑вторых, из‑за сжатых сроков возрастает риск ошибок, связанных с человеческим фактором. И дополнительная проверка — возможность убедиться, что таких проблем нет.
В‑третьих, при недостатке времени разработчики и дизайнеры могут не успеть внести все изменения. Соответственно, перед запуском А/Б‑экспериментов и последующим релизом важно понимать итоговое состояние продукта и то, насколько реализация отличается от макета. Например, у нас в макете интерфейса на Android была кнопка отметки друзей, но в итоговый вариант ее добавить забыли.
Правило №3. Если нужно быстро запуститься — группируйте!
Подготовка разрабатываемой фичи подразумевает проектирование, проработку всех деталей, определение зависимостей и мозговые штурмы с разработчиками. И чем сложнее фича, тем больше ресурсов нужно на ее подготовку.
В ситуациях, когда планируется одновременно подготовить и выкатить сотни обновлений, нагрузка повышается в геометрической прогрессии. Соответственно, времени на такие релизы нужно в разы больше.
Но способ сокращения времени есть — группировка. То есть, разделение фич на группы (а групп на подгруппы) с последующим разделением этих групп между продакт‑менеджерами. В итоге продакты могут работать, запускать А/Б‑эксперименты и общаться с разработчиками независимо и параллельно, и объединять результаты уже после подготовки фич в рамках своих зон ответственности. То есть группировка позволяет готовить фичи в многопоточном режиме без ущерба качеству.
Например, мы еще на этапе дискавери разделили весь запуск между 4 продакт‑менеджерами. При этом у каждого продакта фичи так же были сгруппированы таким образом, чтобы их можно было запускать независимо по А/Б, и независимо оценивать влияние фичи или группы фичей на метрики.
Такой подход дает двойной профит:
В сжатые сроки фичи приезжают на продакшен неравномерно, а группировка позволяет не ждать всех фичей, а запускать их по мере готовности, экономя время.
Возможность запуска фич частями (по одной или группами) позволяет оценивать эффект на метрики каждого обновления, а не всего глобального релиза. То есть, легче отследить, какое нововведение аудитория воспринимает плохо, и быстро его доработать.
Правило №4. Составляйте план запуска
Составление плана запуска — обязательный этап при подготовке любого релиза. Вместе с тем, в ситуациях, когда запустить крупную фичу или группу фичей надо быстро, значение правильно составленного плана кратко возрастает. Особенно, если фичи разрабатываются и тестируются параллельно (как в случае с упомянутой выше группировкой).
Причина в том, что в потоке одновременно подготовленных задач важно отслеживать, что нужно разработать в первую очередь, как фичи связаны между собой, как они влияют на другие сервисы (или элементы интерфейса) и метрики.
При этом важно использовать план не только как чек‑лист, но и для формирования отчета — то есть вносить в документ с планом все результаты разработки и тестов. Например, какие именно фичи проверили, какие метрики получили, какие выводы сделали, что из core‑сервисов «затрагивали» в процессе внедрения. В дальнейшем эту информацию можно использовать при расследовании инцидентов или оценке результатов релиза.
Например, мы запускали 4 группы изменений на стартовой странице ОК. Они касались сервисов
После обновления «Красного линка» мы увидели, что эксперимент «серый», дарение подарков не упало, а изменений в продуктовых метриках нет. То есть можно безопасно катить на всю аудиторию.
После этого мы запустили отдельно блоки, которые были точками входа в Увлечения, Моменты и фильтры. Получили на запуск +0,6% Timespent в Ленте.
Однако после того, как мы скомпоновали обновления («Красного линка» + Хобби + Моменты), то увидели -0,6% Timespent в Ленте, то есть время нахождения пользователей в Ленте упало.
Если бы мы не проводили отдельные эксперименты для каждой из фичи, могли бы подумать, что все обновления дают исключительно негативный эффект (что ошибочно) и вернули бы их в доработку. Но последовательный запуск экспериментов, их группировка и фиксация результатов позволили нам отловить момент, когда мы выходили в плюс. То есть, мы понимали, что с обновленными фичами всё нормально, но надо искать проблему.
В нашем случае оказалось, что проблема была в логировании — часть элементов логирования не доехало. После исправления мы перезапустили эксперимент и получили положительный эффект.
Правило №5. Делайте пробные прогоны
Чтобы обезопасить себя и убедиться, что при раскатке обновлений на всю аудиторию не возникнет проблем (даже там, где уже были тесты), важно делать тестовые прогоны на части пользователей. Причем алгоритм запуска и действий должен четко повторять то, что будет при реальном релизе на всю аудиторию.
В нашем случае запуск фичей проводится по согласованному чек‑листу:
проверка на ботах, что всё хорошо и не разваливается;
включение фичи на себя и коллег;
проверка логирования;
включение на 0,1% пользователей;
включение на часть пользователей;
создание чата со всеми участниками и саппортом.
В случае с редизайном Ленты на подобный тестовый прогон у нас ушел целый день. Но подобные затраты ресурсов оправданы, поскольку позволили нам исключить попадание в прод ошибок и багов.
По итогам итогового А/Б‑эксперимента мы получили показатели, которые нас вполне устроили.
Более того, мы получили оптимальный эффект на ключевые метрики:
+0,6% Timespent в Ленте.
-59% Timespent в Моментах.
-7% дарение подарков.
+1% денег от рекламы в Ленте.
Стоит отметить, что время пользователей в Ленте и выручка от рекламы для нас при запуске были приоритетнее, чем показатель Timespent в Моментах и дарение подарков. Поэтому по итогам общего прогона мы решили катить релиз на всех пользователей, а устранением полученного проседания второстепенных метрик заняться в следующих релизных циклах.
Правило №6. Будьте готовы к шоку пользователей
Любое нововведение — шок для пользователей. В связи с этим перед любым глобальным релизом важно отработать два момента.
Во‑первых, нельзя оставлять пользователей «наедине» с обновлениями, поскольку человек может ошибочно подумать, что конкретно у него «что‑то сломалось» и пойдет с запросом в техподдержку. Возможен и вариант, что часть пользователей не сможет самостоятельно разобраться с новой версией продукта. Поэтому пользователей важно информировать о любых крупных обновления. В ОК мы это реализовали с помощью «антишоковой шторки», в которой разместили соответствующее уведомление о новых возможностях социальной сети.
Во-вторых, донести информацию и «попасть» обновлениями во всех пользователей не получится. Соответственно, часть людей неизбежно будет приходить в техподдержку с вопросами и просьбами «вернуть всё, как было». Поэтому перед запуском важно сформировать группу, которая будет мониторить пользовательский фидбэк по обращению в саппорт и в оценках в сторах, а также увеличить штат техподдержки. Нам это помогло выдержать и стабильно обрабатывать возросший поток обращений, который уже через две недели пошел на спад.
Вместе с тем, надо понимать, что полностью игнорировать реакцию пользователей в надежде на то, что «со временем всё наладится» нельзя. В нашем случае на «оценку реакции» мы отвели две недели — если бы пользователи не смогли адаптироваться к новому интерфейсу, нам пришлось бы постепенно и точечно отключать и дорабатывать те фичи, которые пользователи оценивают негативно.
Например, мы хотели убрать аватарку с главной страницы ОК на web — на других платформах на стартовом экране ее тоже нет.
Но пользователи негативно восприняли это изменение, поэтому нам пришлось откатить фичу и вернуть фотографию.
Правило №7. Делайте квартальные фризы для фиксации изменений за длительный период
При последовательном запуске А/Б‑экспериментов можно достоверно оценить только первичный эффект от запуска — дальше эффект новизны теряется и приходят новые пользователи. Следовательно, метрики могут как расти, так и ухудшаться. То есть, если последовательно выпустить две фичи, каждая из которых дает прирост в метриках на 1%, совсем не обязательно, что суммарный прирост составит 2%.
Соответственно, понять, какое влияние на метрики продукта оказывает внедрение той или иной фичи (или целой группы) со временем становится проблематично.
Чтобы получить объективную картину влияния обновлений, мы в ОК решили раз в квартал замораживать часть партиций. То есть, в течение квартала пользователи на этих партициях не получают никаких новых фичей, а в конце квартала мы их размораживаем и раскатываем на них не часть фичей, а сразу все обновления за этот период.
Например, за отдельный период мы провели 8 экспериментов, но только 3 обновления раскатили на всех пользователей. Соответственно, после разморозки аудитории пользователи получили обновления сразу от 3 экспериментов.
Такой подход полезен как продакт‑менеджерам, так и аналитикам. Так, продакты получают:
понятные цифры для отчетности «наверх»;
возможность отслеживания движения к нужному уровню KPI;
возможность оценки синергии запусков.
В свою очередь, аналитикам и ML‑специалистам практика с фризом позволяет получить:
чистые статистически значимые цифры.
возможность отслеживания эффекта там, где он ниже MDE;
возможность оценки изменения метрик от сезонности и внешних событий;
возможность оценки «эластичности» метрик в продукте.
Примечание: Фриз — общепринятый подход для оценки суммарного влияния нововведений. Например, этой методикой пользуется Spotify и Disney Streaming.
Одновременно с этим, квартальный фриз позволяет получить достоверную оценку влияния. Например, мы активно качали модели ранжирования Ленты, заводя новые таргеты и фичи ранжирования. Каждый из экспериментов нам давал прирост в метриках. Без квартального фриза, мы могли оценивать суммарный эффект от внедряемых фич только математически, то есть, просто складывая полученные цифры без учета других факторов. Так, в упомянутой ситуации с прокачкой модели ранжирования Ленты у нас было 4 эксперимента, каждый из которых влиял на Timespent:
Е1 — Новые таргеты модели ранжирования +2% Timespent ОК.
Е2 — Добавление новых фичей по времени в ранжирование +3% Timespent ОК.
Е3 — Добавление в ранжирование скоров контента +1% Timespent ОК.
Е4 — Дополнительные коэффициент ранжирования +2% Timespent ОК.
Математически мы оценивали эффект на уровне +8% к общему времени нахождения пользователей в соцсети. При этом мы не могли учитывать, как фичи влияют друг на друга. С фризом это стало возможно и А/Б‑эксперименты после квартального фриза показали нам, что запуски дали мультикативный эффект, а Timespent в ОК вырос не на 7%, а на 10%.
Итоги редизайна
Описанные правила — не теоретические советы из интернета, а рекомендации, которые мы выработали на своем опыте в процессе глобального обновления Ленты ОК. Следование приведенным «правилам безопасности» позволило нам провести редизайн Ленты максимально прозрачно и мягко для пользователей, а также предельно контролируемо с точки зрения влияния на ключевые метрики ОК.
Одновременно с этим, решая задачу упрощения потребления контента в ОК, мы получили заметный эффект от редизайна:
+20% минут Timespent в Ленте Android + iOS YoY (год к году, то есть по сравнению с 2022 годом);
+4,1% потребляемый контент;
+3,5% рост рекламной выручки в Ленте.
Надо отметить, что после редизайна мы делали ML‑запуски, что также повлияло на полученный эффект. Но без редизайна эффект на ключевые метрики, безусловно, мог быть значительно меньше.
Наш опыт показывает, что бояться запуска крупных фичей или глобальных изменений продукта не стоит — если следовать простым рекомендациям, релиз непременно будет успешным.
