Многие компании хотят, чтобы их технологии были не просто затратами, а конкурентными преимуществами. Это в том числе касается технологий работы с данными. Часто такое стремление выражается словами «Мы хотим воспринимать данные как продукт». Команда VK Cloud перевела статью, которая поможет применить принципы продакт-менеджмента к управлению дата-продуктами компании.

Несколько определений

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

Итак, некая компания хочет превратить свои данные в продукт. Что это значит сегодня? Есть несколько разных, но дополняющих друг друга определений.

• Определение Tableau. Дата-продукт — это любое приложение или инструмент, который использует данные, чтобы помочь бизнесу улучшить принимаемые решения и процессы. В этом определении подчёркивается польза данных. 
  
• Определение McKinsey. Дата-продукт — это высококачественный и готовый к использованию набор данных, который сотрудники компании могут с лёгкостью получить и применять для решения разных рабочих задач. В этом определении сделан акцент на стандартизации. 
  
• Определение Montecarlo. Дата-продукт — это данные, доступные в компании в пригодной для использования форме, даже если пользователю нужно преобразовать их в режиме самообслуживания. Здесь мы видим упор на data governance.
  

Принципы продакт-менеджмента для данных

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

Результат ценен, только если известен путь, который к нему приведёт. Чтобы работать с данными как с продуктом, опирайтесь на принципы продакт-менеджмента:

1. Имейте стратегию развития продукта.
   
2. Ориентируйтесь на клиента.
   
3. Проводите упрощённые качественные и количественные продуктовые исследования.
   
4. Сосредоточьтесь на поисках соответствующего продукту рынка. 
   

Исходя из этих принципов, я рекомендую десять практик работы с данными:



Чтобы придумывать и создавать дата-продукты, внедрите эти десять практик, основывающихся на принципах продакт-менеджмента.

1. Разберитесь в потоках данных в компании и поддерживайте их схему в актуальном состоянии

Упрощение — одна из ключевых функций продакт-менеджера. Слишком часто в ответ на вопрос «Какие данные у вас есть?» мы получаем таблицу с сотнями датасетов, собранных в результате опроса разных подразделений компании. Это не слишком полезно.

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

• веб-трафик;
  
• каталог товаров;
  
• веб-контент;
  
• заказы;
  
• товарные запасы;
  
• опросы клиентов.
  

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

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

2. Выявите ключевые метрики

Каталог — это просто запись имеющихся данных. Непонятно, чем они важны и для чего предназначены, и не объясняется, что нужно улучшить. Важная часть стратегии работы с данными как с продуктом — согласованность ключевых метрик на уровне компании в целом. То есть что и как вы измеряете и каково необходимое количество метрик. Эти цели меняются со временем. 

Вот что должна включать совокупность отслеживаемых метрик:

1. KPI бизнеса: какие результаты для бизнеса должны обеспечивать данные.
   
2. SLA: каковы доступность, качество и скорость обновления данных.
   
3. Активность пользователей: насколько широко и как часто данные используются в компании.
   
4. Удовлетворенность: насколько заказчики (в том числе внутренние) удовлетворены тем, какие данные им доступны и насколько просто их использовать.
   

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

Возьмем для примера показатели SLA по товарным запасам, которые видят внутренние покупатели для пополнения. Показатели включают доступность товарных запасов на уровне 99,99% времени, обновляются раз в час и поддерживаются в объемах выше прогнозируемых продаж на следующей неделе. Возможно, использовать прогнозы товарных запасов и включать их в свои дашборды должны не только внутренние покупатели, но и команды логистики. А нам нужна метрика, показывающая, часто ли корректируются суммы по спрогнозированным запасам.

3. Согласуйте критерии расстановки приоритетов, нарисуйте дорожную карту продукта, составьте бэклог на будущее

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

1. Критерии расстановки приоритетов. Стейкхолдеры согласовывают их заранее. Так обеспечивается прозрачность и вовлеченность всей компании в работу над дорожной картой продукта.
   
2. Сама дорожная карта продукта формируется в процессе исследования продукта. Так команде не придется соглашаться на сроки без нужной информации и прототипов. Исследование продукта — важный этап, и ниже я остановлюсь на нем подробнее.
   
3. То, что мы считаем важным, но еще не внесли в дорожную карту, нужно записывать в бэклог продукта. Обычно он представляет собой список проблем клиентов, которые нужно устранить, а не функций, которые нужно создать. Во многом долгосрочное видение продукта формируется именно на основании бэклога, а не дорожной карты. Организуйте информацию в бэклоге так, чтобы было понятно, о чем идет речь.
   

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

Для нашего гипотетического примера — прогноза товарных запасов на неделю вперед — нужно решить, как измерять точность прогнозов. Бывает ли, что запасы заканчиваются? Удалось ли заметно снизить расходы на закупку и хранение товаров? Закончились ли запасы на уровне склада? Или на уровне компании? Все это становится критериями расстановки приоритетов. 

Если вас просят изменить модель инвентаризации для скоропортящихся товаров, стоит ли это делать? Сначала вы добавляете эти пункты в бэклог продукта. Затем приступаете к исследованию: нужно рассчитать ROI реализации проекта. Такие подсчеты включают стоимость увеличения или уменьшения охлаждения на складах, например. Только когда вы определили стоимость, можно добавить пункт в дорожную карту продукта.

4. Ориентируйтесь на клиентов

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

Пусть продакт-менеджмент станет для вас примером. Сформируйте четкое представление о своих клиентах. Кто они? Что они создают: мобильное приложение или ежемесячный отчет? Что они знают: SQL или Java? Какими инструментами пользуются: Dashboards или Tensorflow? Нужны ли им оповещения об изменении данных или скользящие средние в реальном времени? Важен ли для них тестовый охват?

А затем «сервируйте» данные так, чтобы ваши клиенты могли ими пользоваться. Например, аналитикам можно предоставить доступ в хранилище данных, разработчикам — по API, дата-сайентистам — в feature store, а бизнес-пользователям — как семантический слой для дашбордов.

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

5. Не перекладывайте бремя управления изменениями

Изменения и конфликты неизбежны. Например:

• Поставщики данных изменили формат.
  
• У потребителей данных изменились задачи.
  
• Поменялась скорость обработки данных.
  
• Те же данные стали предоставлять по разным каналам.
  
• Ваши клиенты перешли к другому поставщику из соображений экономии.
  

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

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

Что верно для управления изменениями, верно и для вопросов безопасности. Самостоятельно принимайте меры по защите персональных данных и соблюдения требований закона, не перекладывайте это бремя на пользователей ваших дата-продуктов.

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

6. Узнавайте у клиентов их потребности в данных

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

Важно получить от потенциальных внешних или внутренних заказчиков подтверждение, что у них есть та или иная потребность. Только после этого можно включить новую идею о дата-продукте в дорожную карту продукта. Особенно рискованно ставить на техническую сторону вопроса: «Сделаем — и народ подтянется». Значительно безопаснее реализовывать идеи, которые заказчики уже одобрили.

7. Мозговой штурм и прототипы — наше все

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

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

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

1. Что нужно создать: проясните все, от пайплайнов данных до пользовательских интерфейсов, которые нужны для успешного проекта.
   
2. ROI, ожидаемая с точки зрения KPI для бизнеса.
   

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

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

8. Создавайте только то, что сразу же пойдёт в дело

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

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

9. Стандартизируйте общие сущности и KPI

Подготавливайте канонические, обогащенные датасеты общих сущностей и KPI, которые будут стандартом для компании. Обычно эти обогащенные сущности:

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

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

10. Добавьте возможности self-service для платформы данных

Нужно найти оптимальный для вашей компании компромисс между гибкостью и стандартизацией. Не перегибайте палку с № 9. Не создавайте централизованные датасеты, в которых есть все для всех на все случаи жизни. Лучше предоставить командам некую степень автономии. Это применение к данным принципа микросервисов.

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

Заключение

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

Вы прямо сейчас можете воспользоваться инструментами для работы с данными от VK Cloud. Для тестирования мы начисляем новым пользователям 3 000 бонусных рублей и будем рады вашей обратной связи.
Stay tuned

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