Системный аналитик и метрики продукта — взболтать, но не смешивать?

IT-компании, которые занимаются продуктовой разработкой, часто ищут в свои команды аналитиков. Зачем тут аналитик? Чтобы проверять гипотезы, придуманные командой, разрабатывать системы метрик (и поддерживать их), проводить разные эксперименты, а потом выдавать рекомендации по улучшению продукта. Это и есть продуктовый аналитик, также известный под кодовым именем “аналитик данных”.

В удалённых каналах Альфа-Банка мы тоже разрабатываем продукты. Но у нас в командах нет других аналитиков, кроме системных, в обязанности которых входит сбор и анализ требований, а также проектирование и документирование решений. Внимательный читатель заметит тут небольшое противоречие. Это что же выходит, что системные аналитики активно занимаются еще и аналитикой продуктовой?



Под катом — небольшое исследование, которое и призвано было оценить, насколько сильно системные аналитики вовлечены в процесс работы с метриками продукта.

Опросы

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

• Кто и как в вашей команде определяет метрики к продукту?
• Откуда вы получаете данные по метрикам? Какими источниками пользуетесь?
• Кто из членов команды (роли) участвует в процессах определения метрик, сбора и анализа данных для контроля их достижения? В чём проявляется их участие?

Выяснилось, что владельцы продуктов выделяют три типа метрик.

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

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

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

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

#1 Как часто ты сталкиваешься с задачами по сбору и анализу данных для контроля метрик продукта?

Больше половины ребят (58%) ответили, что занимаются таким на нерегулярной основе.То есть сидишь и делаешь то, что обычно делают системные аналитики, потом к тебе приходит владелец продукта и просит выгрузить данные по его запросу. 17% опрошенных сказали, что их минула чаша сия вообще, поэтому следующие вопросы мы им и задавать не стали.



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

#2. Какие источники ты используешь для сбора и анализа данных для контроля метрик продукта?

Самым популярным источником стала Автоматизированная Банковская Система, это у нас — Equation (35%). Серебро взяла база Альфа-Метрики с 26% (мы в свое время сделали собственный аналог Яндекс-Метрики для подобных штук).


(АЛБО = Альфа Бизнес Онлайн)

Третий же вопрос касался инструментария.

#3 Какие инструменты ты используешь для анализа данных для контроля метрик продуктов?

Топ предсказуемо заняли SQL и Excel (53% и 40% соответственно). 7% предпочитали Python, но это пока скорее исключение из правил.

#4 Какие инструменты для мониторинга данных ты используешь?

Тут на вкус и цвет — основных инструментов сразу три.

• Superset (40%) – используется для построения дашбордов на основе данных из базы Альфа-Метрики;
• Kibana (33%) – используется для создания дашбордов на основе данных логов приложений, а также данных локальных баз продуктов;
• Grafana (20%) – часто используется для создания дашбордов для мониторинга метрик здоровья.

Так а вывод-то какой?

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

Основными инструментами для анализа данных для контроля метрик продукта являются SQL и Excel. Системному аналитику не требуются другие специализированные инструменты для анализа данных, он вовлечён в процесс мониторинга данных для контроля метрик продукта и использует для этого разные инструменты. Возможно, было бы полезным перейти к единому инструменту для мониторинга данных.

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

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