Как эффективно использовать данные: советы по работе с командой аналитики
Продуктовые аналитики позволяют бизнесу понимать, как и на что влияют разные изменения в продукте. Но эти данные не существуют сами по себе — важно, как другие команды взаимодействуют с командой аналитики. Делюсь опытом, как сделать этот процесс эффективным.
Кто работает с данными
Уже в 2021 году 92% представителей крупного бизнеса рассказывали, что в их компании принимают решения, основываясь на данных. За то, как эти данные интерпретировать и какие выводы делать на их основе, отвечают аналитики — они помогают принимать решения, ориентируясь не только на интуицию и опыт команды, но и на объективные исследования. Аналитика, как клей, связывает разные части бизнес‑процессов и команд: указывает на слабые стороны и направляет продукт и бизнес по нужному пути. Например, аналитики могут:
- помогать с принятием решений (о запуске продукта, введении новой функциональности и так далее);
- находить точки роста для бизнеса (предлагать, как оптимизировать ту или иную проблему, закрывать потребность пользователя);
- создавать инструменты для других аналитиков (строить инфраструктуру для будущих исследований).
Но чтобы аналитики приносили максимум пользы, недостаточно просто задать им вопрос и вернуться за решением через неделю — нужно налаживать совместную работу. Вот несколько наблюдений, которые в этом помогут.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Делайте аналитиков частью команды
Зачастую в компании создается разделение на заказчиков (продуктовых менеджеров, разработчиков) и исполнителей (аналитиков). В этом случае все идеи по продукту обсуждаются изолированно, а аналитиков используют как удобный интерфейс к данным — не погружают в общий контекст, проблематику и целеполагание. На первый взгляд продуктовому менеджеру это даже может показаться хорошим решением: команда получает исполнительного сотрудника, который отвечает на конкретные вопросы и приносит конкретные данные. Но на самом деле в этот момент команда теряет в продуктивности.
Дело в том, что при таком раскладе аналитик не использует свои сильные стороны — умение формализовать бизнес‑проблему в аналитических терминах, свести задачу к набору гипотез и метрик, а также придумать методологию того как эти гипотезы быстрее всего проверить. В негативном сценарии «заказчик» замыкает эту деятельность на себя и может неправильно задать вопросы или недостаточно точно поставить задачу — просто потому, что это не его специальность.
Как это решать. Считать аналитика частью своей команды. Нужно не просто давать ему готовый набор задач, а включать в процессы — от этапа обсуждения проблем и брейншторма до внедрения и оценки результатов.
Нередко это поможет сэкономить время. Например, продуктовая команда может просто не знать о новых инструментах в аналитике и отказаться от задачи, думая, что её просчет займет слишком много времени — хотя аналитики готовы решить её довольно быстро. Такого не будет, если не относиться к аналитикам, как к аутсорсу.
Пример. В одном из сервисов запустили детский раздел и была цель — растить количество пользователей. Для этого менеджер поставил аналитикам задачу: нужно было научиться предсказывать, кто из пользователей воспользуется им. Команда планировала показывать уведомление с информацией про новый раздел. Но эффекта от этого уведомления не было. Дело в том, что аналитики выделяли именно тех пользователей, которые в ближайшее время воспользуется им — они действительно выбирали новую функцию, а дополнительная коммуникация была лишней и мешала.
Все дело в неправильной формализации задачи. Произошла подмена понятия: вместо поиска тех пользователей, которым нужно показать уведомление и рассказать про новый раздел и которые под его воздействием воспользуются им, аналитики искали тех, кто это сделает и без уведомления и не получали эффекта. Уже после менеджер вовлёк аналитиков в изначальную проблематику и бизнес‑контекст, и это помогло успешно завершить проект. Аналитики построили модель для поиска тех пользователей, которые только после дополнительного уведомления начинают применять новую функцию. Таким образом от коммуникации была польза — она давала инкрементальные заказы в детском разделе.
Собирайте данные
Звучит банально, но для аналитики данных в первую очередь нужны данные. Нередко бывает, что в попытке успеть в дедлайн продуктовые менеджеры спешат и запускают новую функциональность, не продумав её логирование (то есть сохранение и структурирование данных) и не начав эксперимент. После этого они приходят к команде аналитики с просьбой оценить результат от внедрения и, разумеется, уходят с пустыми руками. В итоге недовольны все: и менеджер, который не получил результат, и аналитики, которых попросили о невыполнимом.
Как это решать. Проблема с недостатком данных может возникнуть, даже если аналитика уже сделали частью команды и на раннем этапе подключили к обсуждению концепций. Аналитику важно не только взаимодействовать с продуктовой командой, но и погружаться в технологическую реализацию фичей. Так аналитик сможет проконтролировать, что данные, необходимые для оценки результатов, будут собраны в нужном объеме и формате.
Пример. С подобной проблемой мы столкнулись при обновлении одного сервиса. Тогда команда спешила и не продумала этап логирования данных. В результате данные, которые появились после обновления, начали сохраняться в отдельном месте и не попадали в общие таблицы данных.
У аналитиков это вызывало путаницу, ведь часть информации отсутствовала в общепринятом источнике данных. В итоге всё починили, но это потребовало больше усилий, чем если бы нужные этапы спланировали заранее.
Балансируйте между точностью и скоростью
Особенность профессии аналитика в том, что немало специалистов в этой сфере вышли из академической среды, имеют за плечами фундаментальное образование, а иногда и опыт работы в организациях, похожих на НИИ. В такой среде ценится точность и качество получаемых исследований, а еще зачастую нет строгих дедлайнов. И даже если в резюме у аналитика нет должности научного сотрудника, все равно людям этой профессии свойственен системный склад ума и готовность обстоятельно подходить к задаче.
И это обычно не совпадает с реалиями бизнес‑среды, где есть чёткие сроки. В такой среде аналитикам бывает тяжело адаптироваться, отказаться от привычки инвестировать слишком много времени и сил в точность в ущерб скорости. Порой в результате исследований получается четкий ответ, но принимать решение команде уже поздно.
Как это решать. На старте проекта или исследования договоритесь с командой аналитики про баланс точности и скорости. Далеко не всегда для дальнейшей работы нужна точность с долями процентов — иногда продуктовой команде достаточно примерной оценки, чтобы решить, куда двигаться. Важно предупредить аналитиков, чтобы они не тратили лишние усилия, когда они не нужны.
Пример. При планировании проектов в Яндекс Еде возникла идея — вложиться в ускорение загрузки приложения. Чтобы оценить эффект, к задаче подключили аналитиков: команда старалась точно спрогнозировать, насколько может вырасти конверсия в заказ — на два или три процента.
При этом на старте было понятно: если ускорение даст хотя бы 1% роста конверсии, проект уже оправдает затраты на разработку. То есть для принятия решения было достаточно более общей оценки, без глубокого анализа. Такой подход помогает эффективнее использовать ресурсы: иногда уже на ранней стадии можно определить, стоит ли тратить дополнительные усилия на детальные расчеты.
В конце концов, чтобы настроить эффективную работу, важно помнить, что все мы разные: у нас разные способы мыслить, разные навыки, которые в итоге позволяют добиваться нам успехов в совершенно разных профессиях. Для аналитика важно фокусироваться на исходной проблеме, внимательно относиться к деталям, быть аккуратным и порой очень въедливым. Поэтому в работе с их командой важно учитывать эту специфику, с пониманием относиться большому количеству вопросов от аналитика и работать как одна команда.
