Выбор экспериментальной платформы: ретроспектива

Мой подход к выбору между Eppo и Statsig и извлеченные уроки.

Делиться

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

Именно в таком положении мы находились на конференции ManyChat в прошлом году. Мы выбрали Eppo, но это решение — лишь малая часть истории, и ту часть, которую сложнее всего перенести в свою компанию. Вместо этого я хочу поделиться процессом, который я прошел, чтобы прийти к этому решению, своими ошибками на этом пути и тем, что меня удивило по другую сторону контракта (да, врачи меня за этот трюк ненавидят).

Несколько слов о времени. Мы выбрали Eppo в необычайно захватывающий момент для отрасли, когда карта поставщиков менялась прямо на наших глазах в процессе оценки. Сама компания Eppo была приобретена Datadog за несколько месяцев до этого. Statsig недавно была приобретена OpenAI, а затем продана Amplitude. Я не думаю, что что-либо из описанного ниже зависит от конкретного новостного цикла, но хочу отметить, что некоторые из этих событий повлияли на наше настроение во время принятия решения.

Я разделяю последующий процесс на три этапа: до принятия решения, во время его принятия и после.

До

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

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

Я уже видел подобные комнаты раньше. Несколько лет назад в Marktplaats я написал внутренние библиотеки на Python, которые пытаются решить подобные проблемы, и мы наблюдали, как время получения результатов сокращалось с дней до часов, особенно в самых сложных случаях.

Я наблюдал, как аналогичная дискуссия «создавать или покупать» развернулась в Adevinta, уже в глобальном масштабе, и в итоге выбор пал на создание собственной платформы, а не на покупку готовой. К счастью для нас в Manychat, к концу 2025 года предложения платформы достаточно созрели, и для компании нашего размера и на тот момент покупка была очевидным решением.

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

Между нами и выбором стояли две проблемы. Первая была проста: мы обозначили проблему, но пока это были лишь отдельные случаи. Руководство имело (очень хорошее) представление о том, что не работает, и я слышал, как разработчики и менеджеры по продуктам жаловались на текущий стек технологий, когда впервые с ними познакомился. Но ничто из этого не могло сравниться со списком требований поставщика. Пока мы не смогли сопоставить эти два документа, мы не могли определить, какие возможности являются желательными, а какие – действительно необходимыми.

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

Проведение собеседований и снижение рисков при принятии решения.

Я начал с интервью. С менеджерами проектов, аналитиками продуктов, инженерами, маркетологами. Смысл был в том, чтобы превратить отдельные истории в нечто, что мы могли бы сопоставить со списком функций поставщика. История о планировании инженера, «человеческий микросервис» аналитика, менеджер проекта, который отказался от проведения атомарных экспериментов и вместо этого объединял изменения в более крупные релизы, откладывая некоторые из них вовсе: всё это стало описанием работы для инструмента. Я не могу переоценить, насколько это окупилось позже. Каждый раз, когда процесс отклонялся от намеченного пути, а он отклонялся, интервью становились якорем, к которому мы возвращались. Они также придавали всей работе убедительность внутри организации: объяснять моему директору по продуктам, почему мы запускаем прототип, было совсем другим разговором, когда я мог привести ей конкретную причину проблемы.

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

1. Кабинетное исследование. Изучение документации поставщика, составление длинного списка. Большинство платформ отсеялись на этом этапе, еще до того, как мы открыли воронку продаж. На этом этапе также много кода Клода.
2. Демонстрации. Целенаправленная беседа с каждым из отобранных поставщиков. Немного рекламы, конечно, но в основном мы изучали те области, которые, по нашему мнению, имели наибольшее значение.
3. Практическое знакомство с платформами, работа с реальными данными и реальными экспертами — только для двух финалистов.

Каждый последующий этап сужал круг вариантов и предоставлял нам информацию по доступной «цене». К моменту проведения проверки концепции у нас осталось всего два варианта, и выбор сузился до того, что мы могли реально принять. Statsig или Eppo?

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

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

В течение

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

«Как аналитик по продуктам, я был бы очень рад продолжить работу в любой из этих компаний».

Я на мгновение задумался над этим. Сводные баллы совпали с ними: обе платформы получили 4,36 и 4,47 балла по пятибалльной шкале, по более чем двадцати взвешенным критериям. По любой разумной оценке, это была ничья. Я потратил недели на разработку процесса, который четко указывал бы на одну платформу, и этот процесс только что сообщил мне, голосом коллег, которым я больше всего доверял в выявлении значимых различий, что с его места нет никакой значимой разницы.

В тот момент я понял, и не понял бы без участия в дискуссии, что аналитическая строгость стала само собой разумеющимся условием. Ценность выбора одной современной экспериментальной платформы вместо другой не отражается в вашей оценке; она отражается в другом месте. Где именно – вот в чём заключался вопрос, на который мне теперь предстояло ответить.

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

А именно, мы выбирали не между двумя моментальными снимками, а между двумя траекториями. Ставка Eppo была сделана на управляемые, основанные на личном мнении, ориентированные на менеджеров проектов *кхм* доказательства *кхм* рабочие процессы; ставка Statsig — на гибкость для опытных пользователей. Обе ставки, безусловно, были оправданы. Но мы тогда говорили, помните:

Нам нужен был инструмент, который дал бы нам наилучшие шансы на то, чтобы вывести нашу программу экспериментов на желаемый уровень : передовые статистические методы, да, но, что более важно, инструмент, который по умолчанию подталкивает пользователей к проведению убедительных экспериментов (…)

Я заметил то, чего не произошло. План проверки концепции предусматривал тестирование обеих платформ менеджерами проектов и передачу оценок в матрицу. В основном они этого не сделали из-за нехватки ресурсов. Один руководитель отдела маркетинговых операций и один менеджер проектов поделились со мной своими впечатлениями без моего запроса, а остальные данные и отзывы от менеджеров проектов остались скудными. Отсутствие обратной связи от менеджеров проектов привело к парадоксальному результату: в итоге я придал большее значение пользовательскому интерфейсу, рабочим процессам и управлению, ориентированным на менеджеров проектов. Логика асимметрична. Аналитики — это адаптивные, опытные пользователи, если хотите; они освоят любой интерфейс, который вы им предоставите. Адаптация менеджеров проектов не является такой же адаптивной. Если платформа, которую наши аналитики оценили одинаково, также является той, которая снижает барьер для наших менеджеров проектов, это уже решение; обратный вариант, выбор платформы, эквивалентной той, с которой наши менеджеры проектов испытывали бы трудности, был бы тихим самосаботажем.

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

Поэтому мы выбрали Eppo. Решающим фактором стал вопрос о перспективах: в долгосрочной перспективе Eppo лучше соответствовал тому, где мы хотели видеть развитие экспериментов; ближе к командам, занимающимся экспериментами, и выходит за рамки простого аналитика. Управление знаниями как первоклассный объект. Отчетность, для которой не требуется перестраивать презентацию. У Statsig тоже были свои преимущества: CUPED (метод снижения дисперсии) внутри калькулятора мощности, автономный инструмент для исследования метрик, более гибкая аналитическая поверхность; и мы приняли это как пробелы первого года, которые нужно было обойти, пока Eppo перерабатывался в рамках Datadog и приобретал эти функции.

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

После

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

Метафора чистой воды, которую я использовал в предложении, постоянно возвращалась ко мне. Мы проложили трубы; это была интеграция SDK, канализация данных, соединения хранилища. И сама платформа тоже, если хотите. Трубы обеспечивают поток, но не чистую воду. В худшем случае трубы, наоборот, загрязняют её (больше отходов, быстрее). Чистая вода — это то, что выходит из труб, когда остальная часть системы (источник, очистка, люди, которые её обслуживают) выполняет свою работу. Эксперименты работают аналогично: платформа обеспечивает поток, но достоверные результаты получаются благодаря управлению и процессам, людям и тому, насколько серьёзно организация относится к разнице между тестированием идеи и запуском функции.

Инструмент готов; организация пока не готова к его использованию.

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

За несколько недель до подписания соглашения я говорил коллегам, что после запуска Eppo часть аналитической команды постепенно нарастит свои мощности до оптимального уровня. На момент написания этого текста я всё ещё надеюсь, что это произойдёт через квартал-два, но не раньше, чем мы наладим некоторые процессы. Скорость разработки, то есть просто увеличение объёма экспериментов за определённый период, тоже пока откладывается.

Подписание соглашения пока не отмотало время назад и не дало нам возможности сразу же проводить новые эксперименты. Работа, начавшаяся на следующий день после подписания — формирование межфункциональной интеграционной группы, разработка жизненного цикла экспериментов, настройка протоколов Eppo (в рамках его системы управления), сертификация первых показателей успеха и контрольных точек, миграция базы знаний, разработка учебной программы — всё это должно было произойти до того, как платформа смогла бы обеспечить тот потенциал скорости, который мы знали. Короче говоря, впереди нас ждала не проблема инструментов, а проблема управления, процессов и людей.

Три ножки табурета

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

У нас теперь был инструмент и связи. Управление процессами и процессами в основном зависело от команды специалистов по анализу данных: пятиэтапный жизненный цикл эксперимента (Предложение, Проектирование, Запуск, Анализ, Принятие решения); сертифицированный набор показателей успеха и контрольных метрик; всё это было закодировано в собственные шаблоны протоколов платформы, так что эти «контрольные точки» были не страницей Notion, а функцией инструмента. Люди и навыки должны быть материализованы в виде разовых обучающих материалов по использованию инструмента, предоставляемых Eppo, а в долгосрочной перспективе – в виде учебных программ «Экспериментирование 101» и «Экспериментирование 102». Постоянно ведутся споры о модели поэтапной автономии: сначала менеджеры проектов работают в паре с аналитиками, а со временем их независимость возрастает; это точка на горизонте.

И ещё кое-что

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

Заключительные замечания

Если бы мне пришлось всё это сжать, я бы уместил всего в несколько строк следующее:

Убедительное решение — это результат, а не платформа. Платформа — это артефакт. Решение — это то, на чём ваша организация будет жить долгие годы.

В том же духе, трубы — это не вода. Инструмент — это необходимая инфраструктура для проведения достоверных экспериментов, но недостаточная. Работа начинается, а не заканчивается в день подписания контракта.

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

Если вы хотите обсудить детали за чашечкой кофе в онлайн-формате, смело пишите мне в LinkedIn! Я с удовольствием поделюсь с вами идеями.

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

Алехандро Альварес Перес Посмотреть все работы Алехандро Альвареса Переса

Источник: towardsdatascience.com