Превращение аналитики в командный вид спорта в WeWork

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

За исключением того, что они часто это делают. Многие аналитики данных работают незаметно, зная, что они являются частью команды, но чувствуя себя командой данных, состоящей из одного человека.

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

Таким образом, хотя продуктовая аналитика звучит как командный вид спорта, она не всегда так выглядит. Я думаю, что проблема начинается с фразы «разработка продукта на основе данных».

Проблема с разработкой продукта на основе данных

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

Но данные о продуктах и ​​идеи не материализуются из воздуха — всегда чья-то работа состоит в том, чтобы собрать все воедино. В WeWork это выглядит примерно так:

• Инструментарий : кто-то решает, о чем мы хотим собирать данные, и документирует их, что дает нам основу для начала работы. (В моем случае это обычно активность пользователя переднего плана.)
• Реализация: кто-то пишет код для реализации этого отслеживания активности.
• QA: Кто-то (действительно невоспетый герой) подтверждает, что реализация генерирует данные, как и ожидалось.
• Управление: кто-то управляет управлением данными, гарантируя, что мы отправляем максимально чистые данные и обрабатываем их надлежащим образом.
• Моделирование : Кто-то создает модель данных нашего хранилища данных, от приема данных до проектирования масштабируемой структуры, которая будет соответствовать потребностям бизнеса.
• Мониторинг производительности: кто-то использует собранные данные для мониторинга производительности продукта, ответов на основные вопросы и предоставления конкретных цифр заинтересованным сторонам, помещая их в контекст, который кристаллизует, что является значимым, а что нет.
• Проверка гипотез: кто-то выявляет значимые гипотезы и проводит эксперименты и анализ, чтобы (надеюсь) принимать решения о продукте и определять будущее нашего продукта.

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

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

Преодоление запугивания данных с помощью обучения 1:1

Наша мечта в WeWork заключалась в том, чтобы привлечь больше людей в «команду» по работе с данными, но нам было трудно внедрить инструменты аналитики, включая Looker и Tableau. Это каноническая проблема — я думаю, что большинство специалистов по данным создали по крайней мере одну панель мониторинга, которая полностью не использовалась или игнорировалась. Несмотря на то, что аналитика самообслуживания не нова, мы никогда не пользовались большим успехом, но мы достигаем этого с помощью Amplitude Analytics.

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

Моя миссия состояла в том, чтобы создать «моменты озарения», когда люди узнают, как приятно задавать вопрос и быстро отвечать на него, используя инструменты самообслуживания. Я знал, что запугивание — это форма страха, поэтому я начал со встречи с призраком.

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

Вначале это началось с большого количества индивидуальных занятий, посвященных основам: как работает отслеживание, как мы идентифицируем пользователей и что такое поток событий. Затем мы прошлись по платформе и обсудили, как думать о наших данных и как задавать вопросы, на которые можно найти ответы в Amplitude. Я научил своих пользователей (заинтересованных сторон моего продукта), как проявлять любопытство к данным и как делать диаграммы, чтобы удовлетворить это любопытство.

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

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

Медленный путь к изменению культуры данных

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

Мне самому тоже пришлось это сделать. Я предположил, что как только люди познакомятся с Analytics, они разработают свои собственные ритуалы просмотра и использования информационных панелей на платформе. И все же я продолжал отвечать на вопросы, на которые уже были даны четкие ответы, на существующих диаграммах и информационных панелях. Было очевидно, что моя команда не использовала платформу так часто, как я надеялся.

Итак, я знал, что мне нужно помочь нарастить мышцу привычки. С этой целью я настроил еженедельный обзор панели инструментов, в ходе которого мы с продакт-менеджерами тщательно изучаем наши основные показатели, используя панели инструментов Amplitude. Эти регулярные обзоры неизбежно выявляют другие вопросы, которые мы можем исследовать вместе в Google Analytics. Таким образом, мы не только взяли за привычку начинать неделю с согласования метрик, но тем самым настраивали себя на большее количество «моментов лампочки».

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

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

Цель: разработка продукта на основе данных

Забудьте об управлении данными . Мы стремимся к разработке продуктов на основе данных — разработке продуктов, которая управляется командой разработчиков, но подпитывается партнерством с группой данных. Просто не имеет смысла, чтобы все исследования данных, поиск информации и анализ ограничивались людьми со словом «данные» в их названии. Amplitude Analytics создана для того, чтобы вся команда разработчиков могла исследовать свои данные; в некотором смысле, любой член команды продукта должен быть членом «команды данных». И чем больше «команда данных», тем больше «топлива данных» вы добавляете к разработке продукта.