Bukalapak - Fireside Chat with the Data Science team
Юджин Ян делится опытом выступления на fireside chat с командой data science индонезийского e-commerce-единорога Bukalapak. Он рассуждает о том, является ли Data центром прибыли или затрат, и почему в e-commerce данные напрямую влияют на GMV через поиск, рекомендации и маркетинг. Описывает практики выстраивания отношений со стейкхолдерами в Lazada: внутренние рассылки, роадшоу, пятничные happy hour и принцип «white-glove service» для бизнеса. На примере с Fulfilled by Lazada показывает, как через многократное «Почему?» можно переформулировать задачу ранжирования товаров в задачу прогноза доставки. Также рассказывает, как меняется роль с переходом на senior/lead-позицию: фокус смещается на бизнес-результаты, менторство и доверие команде вместо погружения в детали. В завершение отмечает, что культура работы с данными зависит не от региона, а от конкретной организации.
Bukalapak — Fireside Chat с командой Data Science
[ datascience leadership ] · 10 мин чтения
Меня недавно пригласили выступить на fireside chat с Bukalapak — e-commerce-единорогом из Индонезии. Это была интересная дискуссия с командой data science и инженерии, где я поделился опытом построения и управления командами данных в Юго-Восточной Азии и ответил на вопросы аудитории. Мне сказали, что мои ответы помогли им переосмыслить подход к управлению командами данных и взаимодействию со стейкхолдерами. Возможно, они будут полезны и вам.
• • •
Каково ваше видение роли команды Data в компаниях, где данные не являются основным продуктом? Должна ли Data играть ведущую или поддерживающую роль?
Я думаю, это зависит от того, в какой части организации находится Data. Один из способов взглянуть на это — определить, является ли Data центром затрат или центром прибыли. Я считаю, что в случае Bukalapak data — это центр прибыли. В e-commerce-компаниях Data двигает Gross Merchandise Value (GMV) через поиск, рекомендации, маркетинг, привлечение клиентов и т. д.
Если Data — часть центра затрат, например, занимается противодействием отмыванию денег из-за государственных требований или автоматизацией процессов, то объём денег, который данные могут сэкономить, ограничен. Максимальная ценность, которую могут принести данные, — 100% от вовлечённых затрат. И даже этого никогда не достичь, потому что инфраструктура и люди, обслуживающие эти системы (data и machine learning), сами стоят денег.
С другой стороны, если data — часть центра прибыли, максимальная ценность, которую она может принести, бесконечна. Возьмём, например, рекламные системы Google. С тех пор как Google начал продавать рекламу, доход от рекламы продолжает расти и расти. В целом, команды данных в центрах прибыли пользуются большим уважением и влиянием, потому что, ну, они приносят деньги. Команды данных в центрах затрат, как правило, играют поддерживающую роль (и их с большей вероятностью отдадут на аутсорс).
Тем не менее, есть исключения. Одно из них основано на уровне доверия, которое лидеры Data имеют в организации. Я видел Data-лидеров, которые, независимо от их функции (т. е. центра прибыли или затрат), имеют большое влияние в организации. С ними советуются исполнительный комитет и старшее руководство, потому что они заработали доверие и продемонстрировали, что данные могут приносить ценность. В таких случаях Data играет ведущую роль.
С другой стороны, если Data-лидер потерял доверие организации — либо из-за плохих решений, либо из-за плохого взаимодействия с другими функциями или командами — он может лишиться доверия и оказаться в положении, где сможет играть только поддерживающую роль.
Как вы повышаете уровень сотрудничества между data-командой и остальной организацией? Как поощряете стейкхолдеров быть более data-подкованными, помимо того, чтобы они просто смотрели на дашборды?
Размышляя о своём предыдущем опыте, я думаю, есть три основных механизма, которые мои команды делали хорошо.
Первый подход — более формальный. В Lazada мы начали рассылать внутреннюю рассылку по data science, в которой делились с организацией результатами нашего сотрудничества с различными стейкхолдерами. Это помогало повысить осведомлённость о том, чем занимается data-команда, и приводило новые «заказы». После рассылки стейкхолдеры обращались к нам и говорили: «Знаешь то, что ты сделал для них? Не мог бы ты сделать то же для нас?»
Мы также проводили роадшоу — я ездил по нескольким нашим маркетплейсам (т. е. странам), чтобы рассказать о работе data-команды через презентации, а также проконсультироваться с каждой страной по их ключевым потребностям. В одном из предыдущих стартапов наша tech-команда устраивала демо каждую пятницу. Эти демо были открыты для всех (<20 человек), и это помогало командам business development и маркетинга узнавать о нашей работе, чтобы они могли лучше её продавать.
Второе, что сильно повлияло, — это пятничный happy hour (т. е. более неформальный формат). В Lazada каждую пятницу вечером мы с VP of Data Engineering запускали пятничный happy hour. У нас была еда и напитки — по сути, это был повод для команды собраться вместе и расслабиться. Но время от времени к нам присоединялся кто-то из старших функциональных руководителей. Ну, бесплатная еда и напитки! — к нам приходило много людей со всей организации, и за время happy hour мы узнавали о различных функциях больше, чем за всю неделю.
После нескольких напитков я аккуратно вворачивал вопрос: «Что не даёт тебе спать по ночам? Чем data может помочь?» Иногда они делились проблемами, в которых data могла бы помочь — например, автоматическим обнаружением спама в отзывах или улучшением прогнозов доставки. Затем команда брала это в работу и доводила до результата. Это колоссально помогало в завоевании доверия организации. И этот человек становился евангелистом data.
Также иногда, когда я получаю запрос или информацию, которую не понимаю, я люблю просто пройтись по офису и попросить у стейкхолдеров «2 минуты». Обычно это означает 10–15 минут. Но за эту короткую встречу всё проясняется, и улучшается взаимопонимание между командами. Я также говорю им, что они могут делать то же самое со мной, и я рад, что некоторые действительно обращаются ко мне на «2 минуты».
Наконец, и это, вероятно, более актуально для вашего второго вопроса, я стараюсь обеспечить стейкхолдерам сервис «по высшему разряду», когда они проявляют интерес к данным. Например, если стейкхолдер спрашивает о каких-то данных, я сажусь рядом с ним, настраиваю SQL-клиент на его ноутбуке, проверяю, что у него есть доступ к БД, и делюсь простым запросом, чтобы он мог получить нужные данные. Затем я также трачу время, чтобы вместе с ним подстроить запрос под его задачи.
Чаще всего это разовый запрос (они, вероятно, понимают, что просить помощи с данными у Eugene слишком трудозатратно и требует от них усилий, ха-ха). Но иногда некоторые стейкхолдеры заинтересовываются настолько, что начинают сами играть с базой данных. Это случается примерно один раз из пяти.
Как вы работаете с бизнесом над тем, чтобы определять правильные задачи и приоритизировать их решение? Можете привести конкретные примеры?
Это хороший вопрос. Обычно я делаю это, просто проявляя любопытство и наращивая толстую кожу, чтобы спрашивать «Почему?». Вот пример, когда команда логистики обратилась с таким запросом:
«Можете ли вы повысить ранг товаров, которые Fulfilled by Lazada (FBL)?» Я подумал, что запрос имеет смысл. Мы хотим, чтобы товары, использующие наши сервисы, ранжировались выше, и стимулировать продавцов использовать FBL. Тем не менее, я решил спросить «Почему?».
«Потому что товары, которые fulfilled by Lazada, доставляются быстрее.» Опять же, очень разумный ответ. Мы хотим, чтобы клиенты получали свои товары быстрее. Тем не менее, рискуя показаться глупым, я решил снова спросить «Почему?».
«Потому что, когда товар доставляется быстрее, мы получаем меньше жалоб на задержки доставки.» Ага, теперь проступает корневая причина. Они хотят ранжировать товары fulfilled by Lazada выше, чтобы уменьшить количество жалоб клиентов на задержки доставки.
Но, на мой взгляд, это была не задача ранжирования товаров; это была задача прогнозирования доставки. Наши прогнозы недооценивали время доставки, когда продавцы сами выбирали отправку товара (например, через стороннего перевозчика или дропшиппинг). В этом случае мы решили заняться этой проблемой, улучшая алгоритм прогноза доставки, а не подкручивая систему ранжирования товаров.
Вот так определяется правильная задача. Затем — как мы приоритизируем, какие проблемы решать? Так уж получилось, что я как раз сейчас пишу пост об этом, но суть его в том, что… (Пожалуйста, обратитесь к этому посту на прошлой неделе.)
Как senior/lead в команде, обладая знаниями о работе всей компании, как вы находите баланс и не позволяете такому объёму вас перегружать?
Я считаю, что чем более старшая у вас позиция, тем неизбежнее вы теряете контакт с некоторыми деталями, которыми владели в предыдущей роли. Например, если вы в Bukalapak, вы можете попытаться выучить всё, что происходит в Bukalapak, прочитать все документы, изучить все данные, и к моменту, когда закончите, то, что вы выучили, уже устареет.
Я думаю, что как senior вы не должны ожидать от себя, что будете знать, делать и доставлять всё, особенно если вы на лидерской позиции. От вас этого не ожидают, и если бы вы так делали, то, я считаю, вы плохо бы лидировали. Вместо этого ваша роль — давать команде направление и интуицию, менторить и растить их, и доверять им принимать правильные решения. И поскольку команда напрямую работает с проблемой или системой, у них будет более глубокое понимание и более актуальный контекст, чем у вас.
Кроме того, как senior или lead, вы должны быть больше сфокусированы на бизнес-результатах. Как вы определяете наиболее насущные проблемы, которые требуют вашего внимания? Как вы структурируете проблему и решение и помогаете команде эффективно его выполнить? Как вы нанимаете, обучаете и мотивируете команду доставлять результат? Всё это требует много энергии. Маловероятно, что вы сможете оставаться в курсе деталей — как может IC — параллельно занимаясь этим.
Тем не менее, иногда вам может понадобиться погрузиться в детали — возможно, когда проблема особенно туманна, или когда это критическая, чувствительная ко времени ситуация. В таком случае вам нужно применить just-in-time learning, чтобы быстро войти в курс дела, проконсультироваться с командой и довериться своему опыту и интуиции, чтобы принять правильные решения.
Что вы думаете об использовании данных из Excel-таблиц? Обычно они приходят от команд ops/admin и business/product, которые хотят, чтобы данные были доступны через мониторинг.
Я думаю, это боль. Тем не менее, это терпимо, если процесс автоматизирован. Я раньше работал с командами, которые предоставляли данные в формате CSV, и долгое время это не было автоматизировано. Это означало, что иногда названия колонок менялись или пропадали, или кодировка могла меняться с UTF-8 на ASCII или Latin ISO.
Если бы это зависело от меня, я бы не принимал никакие данные, поступающие из неавтоматизированного процесса. Это означает, что CSV, Excel и текстовые файлы — нормально, при условии, что они автоматизированы и имеют постоянную схему и формат. Когда процесс автоматизирован, я не думаю, что слишком сложно экспортировать CSV или Excel-файлы в S3-бакет. Data-команда затем может построить ETL-пайплайн, чтобы прочитать и сохранить эти данные в базе.
Альтернативно, data-команда может напрямую запрашивать данные из их базы данных. Они ведь откуда-то получают свои данные, верно? Спросите их, как они запрашивают данные, и получайте их из их базы напрямую.
У вас есть опыт в США и Сингапуре. Как вы сравниваете культуру работы с данными между Юго-Восточной Азией и США?
Я не думаю, что регион играет большую роль в плане культуры работы с данными. В Юго-Восточной Азии у нас тоже есть tech-единороги, занимающиеся отличной работой с данными и machine learning, такие как Grab, GoJek, Traveloka, Tokopedia, Sea, Bukalapak и т. д.
Я думаю, что разницу делает организация. Например, в США тоже можно найти более старые, более зрелые компании, где работа с данными и machine learning не так развита, как у наших чемпионов в Юго-Восточной Азии.
У меня был fireside chat с командой data science и инженерии @Bukalapak, где мы обсудили: • Data как центр прибыли vs. центр затрат • Внутренние рассылки и пятничный happy hour для работы со стейкхолдерами • Как меняется ваша роль, когда вы становитесь senior/lead • И многое другое... https://t.co/XRSXGIpKnc — Eugene Yan (@eugeneyan) 31 марта 2021
Если вы нашли это полезным, пожалуйста, цитируйте эту статью так:
Yan, Ziyou. (Mar 2021). Bukalapak - Fireside Chat with the Data Science team. eugeneyan.com. https://eugeneyan.com/speaking/bukalapak-fireside/.
или
@article{yan2021bukalapak, title = {Bukalapak - Fireside Chat with the Data Science team}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Mar}, url = {https://eugeneyan.com/speaking/bukalapak-fireside/} }
К 11 800+ читателям, получающим обновления о machine learning, RecSys, LLM и инженерии.