Все компании сегодня любят «большие данные», и почти в каждой обязательно есть отдел аналитиков, занимающихся наукой о данных.
Однако в отрасли нет четкого понимания того, что такое продуктовый аналитик и чем он отличается от специалиста по данным или UX-исследователя, который фокусируется на количественных методах.
Все более распространенным становится подразделение продуктовых аналитиков, которые:
- установить цели и метрики, определить вектор развития продукта
- исследовать природу явлений, выявлять причинно-следственные связи
- создавать прогнозирующие алгоритмы
В этой статье я хочу немного абстрагироваться от специалистов, которые занимаются исключительно машинным обучением, и рассказать о видении роли продуктового аналитика в нашей стране.
Райк и о проблемах, с которыми нашей продуктовой команде приходится сталкиваться каждый день.
Качественный против количественного
Как правило, девелоперы и девелоперы любят цифры: количественные данные помогают точно фиксировать текущее состояние, показывать динамику и оценивать перспективы рынка.При этом часто забывают, что сами цифры не позволяют дать ответ о мотивации людей, о первопричине их выбора и дальнейших действий.
Качественные методы важнее количественных: как качественные методы способствуют улучшению науки о данных Вот почему в Wirke мы не делаем четкого различия между аналитиками, которые проводят качественные и количественные исследования.
Напротив, по нашему мнению, в небольшой команде (около 10 человек) необходимо уметь максимально совмещать эти навыки, используя количественные методы для разработки идей качественного анализа.
, что часто проводится совместно с продакт-менеджером и дизайнером.
Фактически, когда дело доходит до проведения исследования, у нас есть два ожидания от аналитика.
Он должен быть в состоянии:
- найти перспективные точки роста продукта
- подтвердить проблему, сформулировав ее и масштабировав
1. Поиск точек роста продукта
Аналитик — это человек, который находит перспективные направления роста продукта путем масштабирования проблем и задач.Самый первый шаг в понимании любой проблемы для продуктового аналитика — определить, к какому классу проблем она принадлежит. Обычно выделяют три типа исследований:
- Поиск проблемы (обнаружение проблем) — когда мы не знаем, какие проблемы возникают у пользователей за пределами конкретного функционала продукта.
Обычно это этап собеседования.
- Проверка проблемы (проверка проблемы) — когда мы вроде бы знаем, что есть определенные проблемы, но хотим проверить, что они есть у действительно большого количества пользователей.
Это этап различных обследований.
- Проверка решения (проверка решения) — когда мы проверяем конкретные решения, которые мы придумали или прототипировали.
ЭПрототипирование или бета-тестирование.
Допустим, менеджер по продукту вместе с аналитиком и маркетологом провели двадцать интервью с разными клиентами.
Как понять, что этим выводам можно доверять и что озвученные проблемы действительно актуальны для всех пользователей? Как обеспечить объективность найденного потенциала развития, оценив масштабы? Другими словами, как мы можем убедиться, что то, что мы обнаружили в интервью, на самом деле является потенциальной точкой роста продукта? Здесь вы максимально эффективно используете инструменты и знания для работы с данными, которые объединяют качественные и количественные исследования.
Понимание масштаба и поиск наиболее правильного способа его определения — ключевая компетенция продуктового аналитика.
Вот лишь один небольшой пример, когда аналитический подход позволил нам изменить процесс сбора болевых точек клиентов и применить другой подход к их проверке продуктовой командой.
Мы распознаём и анализируем разговоры В Wrike есть отдел менеджеров по работе с клиентами ( менеджеры по работе с клиентами ), основная задача которого — поддержка клиентов не с целью продаж, а улучшение их опыта использования продукта.
Они звонят клиентам по видеосвязи, обсуждают их текущие болевые точки, рассказывают о лучших практиках, предлагают рабочие решения и сообщают о состоянии разработки новых функций.
Все эти разговоры долгое время записывались и практически не использовались продуктовой организацией — ПМ предпочитали лично общаться с аккаунт-менеджерами, чтобы получить какое-то общее понимание болевых точек клиентов.
Это могло добавить элемент «сломанного телефона» и не всегда раскрывало контекст, в котором пользователь столкнулся с этой проблемой.
Одним из инициативных проектов продуктовой аналитики стала разработка пайплайна, переводящего разговор в понятный текстовый формат. С помощью Google Speech API, а также нескольких дополнительных моделей пунктуации нам удалось получить представления о масштабах некоторых проблем и требованиях к функциональности, основанные на много разговоров между менеджерами и клиентами, а не одно интервью .
Благодаря такому простому источнику удалось провести полноценный поиск по ключевым словам, связанным с определенным функционалом или проблемами, оценить характер пользователей, требовавших того или иного решения, а также понять контекст, в котором оно чаще всего подошел.
В настоящее время мы также тестируем модель анализа настроений, которая помогает нам автоматически фиксировать средний уровень удовлетворенности отдельными частями продукта и уведомлять команду разработчиков.
2. Формируйте, масштабируйте и проверяйте гипотезы.
Аналитик — это человек, который может сформулировать проблему на должном уровне абстракции, измерить ее и проверить на значимость, а также предложить рекомендации к действию.Независимо от стадии исследования существуют разные уровни гипотез (подробно о них мы поговорим ниже), которые помогают оценить взаимодействие пользователя с продуктом и построить дальнейшие планы развития.
Здесь часто возникает задача правильно оценить необходимый уровень гипотезы и выбрать инструмент сбора информации или ее проверки.
Реальный процесс выглядит так:
- Формулирование гипотез – например: «для пользователей-администраторов из определенной когорты важно иметь возможность выставлять счета на основе еженедельного отчета».
- Сбор статистики использования – классическая задача аналитики – понять, способны ли цифры ответить на сформулированные выше гипотезы.
- Сбор обратной связи – проведение исследований с помощью маркетинга, рассылок или инструментов внутренней обратной связи
- Анализ и проверка результатов – проверка результатов по стат. важность
Сбор обратной связи
Многие компании считают, что после того, как они настроят систему логирования и прикрепят к своему продукту аналитические сервисы вроде Google Analytics, подготовка платформы для аналитики на этом заканчивается.Однако, к сожалению, такой подход забывает самый важный элемент — необходимость обратной связи с пользователем, возможность в нужный момент спросить его о его задачах и трудностях, с которыми он сталкивается.
Таким образом, критически важно, чтобы у команды было достаточно инструментов для ненавязчивого опроса пользователей и сбора от них обратной связи не только посредством какого-то маркетингового опроса, но и через внутренний механизм.
Мы используем внутренний инструмент QFF (форма качественной обратной связи) для формулирования и проверки гипотез и рассмотрения возможные сценарии взаимодействия с пользователем в виде трехступенчатой пирамиды (продукт → функция → взаимодействие):
- Уровень продукта
- Уровень функциональности
- Уровень конкретного взаимодействия
1. Уровень продукта Здесь важно понять самые широкие и кросс-функциональные части воронки взаимодействия с пользователем.
Это стремление найти ответы на самые глобальные вопросы, будь то удовлетворенность продуктом в целом или набором функционала для решения одной задачи (например, согласование отпуска может потребовать взаимодействия функционала календарей, статусы задач, алгоритмы планирования и т. д.).
Не существует четко регламентированных показателей, которые необходимо применять в таких ситуациях; всегда есть нюансы.
Однако, как правило, на этом уровне абстракции речь идет о метриках NPS (net Promoter Score) или SUS (шкала юзабилити системы).
Метрики не бесспорны, но, как правило, они по-прежнему являются отраслевыми стандартами и помогают ориентироваться в постановке целей в масштабе нескольких кварталов.
2. Уровень функциональности На этом уровне мы задаем более конкретные вопросы, которые относятся непосредственно к конкретному функционалу.
Из приведенного выше примера мы уже не можем отдельно рассматривать проблему «согласования отпуска» в целом, а возьмем только конкретную часть продукта, например, календари.
Насколько легко их понять? Почему люди их используют? В зависимости от стадии нашего исследования могут различаться не только вопросы, но и показатели, которые мы собираем от наших пользователей.
Самое простое — это уровень удовлетворенности, который можно прочитать от задачи к задаче с помощью разных шкал (три смайла или шкала Лайкерта), CES (customer Escore Score) — насколько сложно или легко пользователю реализовать те или иные задачи.
3. Уровень взаимодействия Задача этого уровня — оценить конкретную итерацию, которую пользователь совершил с продуктом (например, нажал определенную кнопку).
Важно, что результатом этого взаимодействия является какое-то действие или решение, которое мы не можем измерить или контролировать.
Как правило, речь идет об уровнях удовлетворенности и принятии каких-то последующих решений: например, удалось ли руководителю, глядя на календарь, понять, когда заканчивается отпуск сотрудника? Подходит ли пользователю формат экспорта данных? Поскольку все дальнейшие действия происходят либо только в голове пользователя, либо вне нашего продукта, другого метода оценки итерации у нас нет. По сути, уровень рейтинга взаимодействия — это попытка оценить метрику CSAT (удовлетворенность клиентов), которая часто используется в поддержке и других службах, где нужно оценить конкретное событие.
При этом здесь также можно использовать метрики типа CES, но в более «локальной» формулировке.
Анализ и проверка результатов
После того, как мы зафиксировали гипотезы, сформулировали вопросы и провели наши проверочные опросы на должном уровне пользовательского опыта работы с продуктом, возникает задача, которая снова требует от аналитика особых талантов — на этот раз в области статистики и проверки гипотез.Фактически после каждого опроса аналитик должен убедиться, с какой степенью уверенности он может доверять результатам, в том числе результатам своей работы.
Влияет ли на ответ фактор работы в крупной компании? А как насчет должности работника? Все эти гипотезы тщательно проверяются с помощью необходимых инструментов: как и правильность проведения A/B-теста, от аналитика напрямую зависит, какие подходы применимы в каждой конкретной ситуации.
Как правило, часто можно использовать регрессионный анализ, однако он не является единственным универсальным решением, поскольку имеет свои области применения и интерпретации.
Конкретные методы всегда остаются на усмотрение аналитика.
Вместо заключения
Выше мы раскрыли лишь два основных случая в работе аналитика и при этом сознательно не рассказали обо всех этапах его работы – подробное описание всех видов исследований, формулирование гипотез и правильный сбор данных заслуживают внимания.отдельные статьи.
Однако мы считаем, что даже такое высокоуровневое формулирование ожиданий от аналитики и фиксация ключевых методов ее работы существенно усилит любую продуктовую команду и поможет делать более качественные продукты.
Умение находить точки роста в данных (какими бы неструктурированными они ни были), правильно формулировать их в гипотезы, масштабировать и валидировать для всех нынешних и будущих пользователей — это именно те качества, которые отличают наших продуктовых аналитиков.
Поэтому мы точно знаем, что подобные требования дают наиболее ощутимый результат и не позволяют этому скатиться в оперативную рутину, и поэтому с уверенностью рекомендуем эти принципы другим командам.
А если вы хотите поговорить о количественной аналитике, больших данных и инфраструктуре, которая поддерживает всю аналитику в Wrike, приходите к нам.
на встречу в питерском офисе .
Или просто приходите в гости.
Теги: #аналитика #аналитика продуктов #качественный анализ #количественный анализ #wrike #wriketechclub #аналитика #Интеллектуальный анализ данных #Управление проектами #Управление продуктами #Карьера в ИТ-индустрии
-
Почему Люди Любят 3D-Печать
19 Oct, 24 -
Корпоративный Эксперимент
19 Oct, 24 -
Триггеры В Mysql
19 Oct, 24 -
Любители Ruby On Rails
19 Oct, 24
