Комментарии

Процессы продуктовой аналитики

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

Мы в компании работаем по таким процессам:

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

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

Тестирование. Когда есть несколько гипотез, нужно подтвердить их через A/B-эксперимент. Создаём измененный вариант продукта и тестируем его на определённом количестве пользователей — например на 10% от всех текущих. После эксперимента анализируем альтернативный и основной варианта продукта с помощью математических алгоритмов. Если видно, что новый вариант лучше, решаем, вносить ли данное изменение в основной продукт.

Релиз. После эксперимента считаем затраты на полную разработку решения, а также прибыль, которую получит продукт после внедрения решения. Если расчёты показывают, что решение принесёт пользу, перносим в основной продукт в полном объёме.

Такой подход защищает от лишних расходов на разработку и возможных ухудшений показателей.

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

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

Продуктовая аналитика состоит из нескольких столпов: команда, инструменты и процессы. А результатом работы этого механизма становится инсайт — полезная информация для принятия решения.

Продуктовая аналитика — командная игра

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

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

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

Сравнивая поле командной игры и продуктовый отдел, идеальное распределение ролей будет следующим:

Продакт-менеджер. Капитан, определяющий стратегию игры и координирующий действия всех игроков. Он лидер, который взаимодействует напрямую с «тренером» — руководством — и оценивает «соперников» — рынок.

Продуктовый аналитик. Голкипер, предвидит и отбивает удары — прикрывает слабые стороны продукта. Он анализирует точки роста и делает успешный «пас», который задаёт начало очередному тайму.

Аналитик данных. Игрок в защите. Подтверждая или опровергая данные, помогает нападающим — то есть команде разработки — создать новое прорывное решение.

Разработчики, включая дизайнеров. Игроки в нападении, которые фактически воплощают стратегию и инструкции капитана. Они разрабатывают продукты, играя от «паса» продуктового аналитика.

Инструменты продуктовой аналитики

Ещё один немаловажный столп продуктовой аналитики — передовые инструменты. Вот примеры некоторых из них.

Amplitude

Система поведенческой аналитики. Она фиксирует действия пользователей и самостоятельно визуализирует критически важные показатели. С помощью Amplitude можно выявить аномалии, влияющие на финансовые метрики продукта.

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

Hotjar

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

Например, можно переместить кнопку «Добавить в корзину» в более видное место и тем самым увеличить конверсию в покупку.

Услуги данных и генеративного ИИ стали для нас настоящим прорывом. Благодаря продвинутым стратегиям интеграции и аналитическим инструментам, нам удалось существенно повысить эффективность и точность принятия решений. Особенно впечатлили возможности NLP и ETL, которые позволили раскрыть скрытый потенциал наших информационных активов. Что мне особенно нравится — это скорость и надежность обработки данных, что прямо влияет на нашу продуктивность и инновации.

Об интеграции данных с помощью генеративного искусственного интеллекта могу сказать только положительное. Благодаря внедрению таких решений, как службы данных для анализа, ETL и NLP, наша компания значительно оптимизировала процесс обработки информационных активов. Искусственный интеллект позволил не только автоматизировать рутинные задачи, но и находить новые инсайты, ранее скрытые в наших данных. Особенно впечатляет способность ИИ к интеграции и анализу различных источников данных в реальном времени, что ускоряет принятие обоснованных решений. Наибольшее впечатление произвела простота внедрения и интуитивно понятное использование – даже сотрудники без технического опыта могут эффективно взаимодействовать с системой. Это действительно выводит наши аналитические усилия на новый уровень.

Каждый проект Kanban оп моему глубокуму убеждению, должен соответствовать этим основным принципам и практикам:

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

Управлением процессом и его и улучшение: Ход работ на доске Kanban необходимо постоянно отслеживать для возможного улучшения. Быстрый, непрерывный процесс показывает, что команда быстро создает ценность.

Незавершенная работа (WIP) определяет минимальный и максимальный объем работы для каждого столбца доски или для каждого рабочего процесса. Установив лимит на WIP, вы можете увеличить скорость и гибкость и уменьшить необходимость в определении приоритетов задач.

Четко сформулируйте принципы работы: Все должны понимать, как все работает или что считается " выполненным". Внесите изменения в доску, чтобы сделать эти процессы более понятными.

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

Agile это не методология — это манифест разработчиков с их хотелками. Говорит только об одном. Что в команде напрочь отсутствует организация в каком либо виде.

Scrum уже методология. Но не особо эффективная для больших команд. Придумана менеджерами, ее основной идеей является переложить работу менеджера проекта по общению с менеджером продукта/клиентом на команду разработчиков. Ведет к убыткам компании не оправданным расходам и увеличению срока разработки. Чем больше команда тем больше потерь для компании.

Канбан это тоже не методология, это тупо доска.

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

Успешные и эффективные команды используют комбинации подходов. Мы например используем. scrum + kanban на этапе общения между продактом и проджектом. Когда они согласовывают какую то часть, это фиксируется и проджект передает ее тимлиду, а отдел разработки уже работает по небольшим проектам в формате waterfall, несколько waterfall проектов в рамках одного продукта могут идти паралельно. Как итог, разработчики вообще не ходят на совещания, привлекать их к ним запрещено, они посвящают 100% времени написанию кода. А менеджеры получают необходимую им гибкость для развития продукта. Не уверен как это называется но это близко к Scrum-sashimi.

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

Agile это не методология — это манифест разработчиков с их хотелками. Говорит только об одном. Что в команде напрочь отсутствует организация в каком либо виде.

Scrum уже методология. Но не особо эффективная для больших команд. Придумана менеджерами, ее основной идеей является переложить работу менеджера проекта по общению с менеджером продукта/клиентом на команду разработчиков. Ведет к убыткам компании не оправданным расходам и увеличению срока разработки. Чем больше команда тем больше потерь для компании.

Канбан это тоже не методология, это тупо доска.

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

Успешные и эффективные команды используют комбинации подходов. Мы например используем. scrum + kanban на этапе общения между продактом и проджектом. Когда они согласовывают какую то часть, это фиксируется и проджект передает ее тимлиду, а отдел разработки уже работает по небольшим проектам в формате waterfall, несколько waterfall проектов в рамках одного продукта могут идти паралельно. Как итог, разработчики вообще не ходят на совещания, привлекать их к ним запрещено, они посвящают 100% времени написанию кода. А менеджеры получают необходимую им гибкость для развития продукта. Не уверен как это называется но это близко к Scrum-sashimi.

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

Насколько я помню agile это только набор правил вроде 17. Авторы этих правил отказались участвовать в её монетизации и продвижении как продукта, что сделали со скрамом.

Те кто называют agile методологией чаще всего либо не понимают что это, либо пытаются навязать свои услуги.

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

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

Насколько я помню agile это только набор правил вроде 17. Авторы этих правил отказались участвовать в её монетизации и продвижении как продукта, что сделали со скрамом.

Те кто называют agile методологией чаще всего либо не понимают что это, либо пытаются навязать свои услуги.

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

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

Ответ такой же, как и в предыдущем вопросе. Всё зависит от проекта и от того, как вы договоритесь с командой.

Если говорить про описание API, то это могут быть разные формальные языки. Описание REST API с помощью Swagger, описание транспортов/протоколов с помощью JSON-схемы, с помощью XSD + WSDL, если это SOAP-сервисы.

Ещё аналитик проектирует взаимодействие между системами или сервисами. Очень часто это визуализируют с помощью диаграммы последовательности (sequence diagram). Также можно использовать use case для описания взаимодействий не только пользователь-система, но и для описания интеграций. Также используют диаграмму потоков данных и компонентные схемы.

Ну и заключительный — какую документацию по интеграции должен уметь делать аналитик?

К сожалению, это очень сложный и абстрактный вопрос, на который трудно ответить. Хочется сказать, что при определении детализации описания требований очень важно договариваться с командой.

На одном из проектов мы действовали оперативно: начинали с самого минималистичного варианта, говорили команде, что будем экспериментировать. И затем с фидбеком от команды оперативно перейдём к тому формату требований, который всех устраивает.

Как определить необходимую детализацию описания требований REST API в конкретном проекте? Есть ли хорошие шаблоны описания?

Первое, о чём хочется рассказать сказать, это об инструменте Postman. Его можно как скачать и установить на ПК, так и работать онлайн. Postman — это некоторая утилита, которая позволяет вызывать внешние сервисы, внешние API, реальные REST-сервисы (которые работают поверх протокола HTTP) и используется для тестирования.

Также можно упомянуть SOAP UI и Swagger UI. Кстати, Swagger — это не только некоторый язык формального описания API, но ещё и редактор, с помощью которого можно вызывать реальные сервисы.

Какую последовательность действий можно посоветовать?

— Найти общедоступное API;
— Выбрать одну из утилит (я бы рекомендовал начать с Postman);
— Тренироваться.

Ясно, а еще тогда, в каких программах можно потренироваться новичкам и разобраться в командах, взаимодействиях REST (возможно, SOAP)?

Предположу, что в вопросе говорится про REST-сервисы второго уровня зрелости, когда мы говорим про HTTP API. Здесь системный аналитик может, в зависимости от компании, от проекта и от договоренности с руководителем, делать многое.

Кто-то проектирует архитектуру сервиса, кто-то только формирует API. Наиболее часто аналитик готовит описание REST-сервиса с помощью каких-нибудь формализованных языков (например, Swagger или JSON-схемы).

Если не рассматривать описание формализованных языков, то остается описание структуры запросов/ответов, описание возможных ошибок, проектирование внутренней логики сервиса и того, что он делает.

Спасибо за ответы, а тогда можно уточнить — что входит в задачи системного аналитика при проектировании REST-сервиса?

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

К сожалению, это очень сложный и абстрактный вопрос, на который трудно ответить.

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

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