Комментарии

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

Максим недавно открыл барбершоп. До сентября 2020 года он просто давал рекламу и привлекал новых клиентов. Персональные данные Максим не обрабатывал. Когда появилась постоянная аудитория, барбершоп ввёл программу лояльности — скидочные карты. Чтобы их оформить, клиенты оставляют фамилию, имя и номер телефона. Так Максим стал оператором персональных данных.

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

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

Не считаются операторами только:

— Физические лица, которые собирают данные для личных или семейных нужд. Например, если человек записал номер телефона друга или спросил имейлы коллег, чтобы разослать приглашения на юбилей.
— Компании, которые обязаны хранить архивные документы по закону «Об архивном деле». Это государственные организации, которые занимаются делами Архивного фонда РФ.
— Компании, которые обрабатывают данные, отнесенные к гостайне указом Президента. Это органы власти и государственные организации.

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

И как же понять, что я оператор персональных данных или нет?

Пока еще нигде не видел нормально выстроенную ПА, многие путают продуктовые и бизнес метрики

Если по мобилкам, на текущий момент делаем АБ на Firebase, в виду стека. А вообще, по функционалу лучше Amplitude.

Спасибо, а где делаете АБ тесты, какая платформа?

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

2. Используйте продвинутые инструменты. Например, те, что я описал в статье. Либо доверьтесь опыту специалистам — они подберут инструменты под специфику продукта.

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

Чтобы начать внедрять продуктовую аналитику в компании, объясните что нужно сделать? Желательно понятным языком

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

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

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

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

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

Тестирование. Когда есть несколько гипотез, нужно подтвердить их через 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 в конкретном проекте? Есть ли хорошие шаблоны описания?