Как избежать создания правильного решения неправильной проблемы?

Введение

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

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

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

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

Что такое Data Product Canvas?

Это структура для разработки продуктов данных, основанная на модели Canvas, которая следует принципам Agile/Lean. методика. Его основная цель — служить практическим инструментом для создания дорожной карты продукта данных, согласованного в одном документе. полное представление всех участников о настоящей цели проекта.

Карта продукта данных разделена на 10 блоков (проблема, решение, данные, гипотезы, действующие лица, действия, ключевые показатели эффективности, значения, риски и производительность/воздействие) и разделена 3 предметными областями , а именно: видение продукта (охватывающее блоки: проблема, решение, данные и гипотезы); видение стратегии (со следующими блоками: действующие лица, действия и KPI); и, наконец, бизнес-видение (ценности, риски и производительность/воздействие).

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

Для чего это?

Идея DPC состоит в том, чтобы обеспечить практическое и объективное планирование продукта данных на основе общего понимания. strong> между технической и деловой сферами. Таким образом, можно отобразить весь проект от начала до конца, тем самым обеспечивая единое представление того, что было запланировано и что будет выполнено. Кроме того, он также помогает создавать действия и отслеживать основные показатели для отслеживания решения, которое будет разрабатываться на протяжении жизненного цикла.

Таким образом, можно четко идентифицировать и сопоставить следующие элементы:

  1. Определение проблемы;
  2. решение, которое будет принято;
  3. сопоставление данных;

4. гипотезы, которые будут проверены;

5. Все вовлеченные субъекты (клиенты и заинтересованные стороны);

6. Стратегические действия, которые будут разработаны.

7. KPI, которые следует отслеживать;

8. ценности (размер проблемы);

9. Риски; и

10. Производительность и/или влияние продукта на бизнес (созданная или сохраненная ценность).

Зачем использовать?

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

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

Это очень важно, потому что без этого понимания вы, вероятно, потерпите неудачу.

Как использовать?

1. Начните с проблемы

Как хороший менеджер продукта данных, вы должны направлять продукт Discovery через самую важную часть: проблему. В противном случае есть большая вероятность, что вы придумаете правильное решение не той проблемы. Поверь в это!

Таким образом, независимо от того, как возникает спрос (очень часто исходит от заинтересованного лица, у которого уже есть «готовое» решение), всегда начинайте с проблемы. В конце концов, четко сформулированная проблема — это решенная проблема. Это важный и не подлежащий обсуждению момент. Можно даже исходить из предпосылки, из идеи решения или из проверки гипотезы. Однако заполнение холста и все начальные усилия должны быть сосредоточены на этой точке. То есть четкое и конкретное определение проблемы.

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

Итак, помните: всегда сосредоточьтесь на первом блоке холста, то есть ясно и объективно установите проблему, которую вы хотите решить. И для этого всегда спрашивайте:

  • В чем проблема?
  • Почему это проблема?
  • Чья проблема?

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

В качестве примера я приведу свой опыт работы с генеральным директором группы электронной коммерции. Посмотрите диалог между генеральным директором и менеджером данных (DPM) и обратите внимание на то, как все изменилось:

Генеральный директор: Я бы хотел, чтобы вы придумали решение, которое могло бы привлечь в компанию больше клиентов. Это может быть проект, использующий сегментацию клиентов и A/B-тестирование с нашими данными, а затем рекомендации. Что вы думаете? (Обратите внимание, что заказчик уже навязал, что проблема заключалась в поиске дополнительных клиентов и уже определил техническое решение!!!)

DPM: Конечно, мы можем это сделать. Ведь речь идет о проблеме наверху воронки. Но прежде чем мы пойдем дальше, не могли бы вы объяснить мне, почему вам нужно больше клиентов? (В настоящее время ДПМ молится, чтобы его не отослали);

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

DPM: Хм… Я понимаю, но вы можете продавать больше, сосредоточившись на существующих клиентах. Мне кажется, что это проблема в середине воронки, то есть мы можем решить это с помощью повторяющихся покупок и увеличения потребительской корзины, работая поверх текущей клиентской базы. В этом случае я считаю, что решение с использованием методов допродажи и кросс-продаж было бы более подходящим. Что вы думаете?

Генеральный директор: Именно поэтому я всегда говорю, что наука о данных — это решение любой проблемы. Идите прямо!

DPM: Конечно, поехали! Но перед этим ответьте мне: зачем вам больше продаж?

Генеральный директор: Послушайте, наши доходы действительно снижаются. Вот почему мне нужно больше клиентов, которые покупают больше, чтобы получать больше дохода. Ты понимаешь? (В этот момент генеральный директор уже проявляет немного больше нетерпения).

DPM: Теперь у нас настоящая проблема! Если выручка падает, это потому, что у нас есть проблема с удержанием клиентов (нижняя часть воронки), и эту проблему можно решить с помощью решения для предотвращения и реактивации оттока (потеря клиентов). Что вы думаете?

Генеральный директор: Вот почему я всегда говорю, что наука о данных — это решение любой проблемы. Идите прямо!

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

Поэтому правильно спросить:

  • В чем проблема?
  • Почему это проблема?
  • Чья проблема?

Затем для каждого вопроса: a сохранить ответ. Запишите это и наклейте на стикер в Canvas. Тогда спросите: почему? сохраните ответ. Запишите это и наклейте на стикер в Canvas. Тогда спросите: почему? сохраните ответ. Запишите это и наклейте на стикер в Canvas. А затем спросите почему, почему???…

В конце вы все равно можете подкрепить, спросив: почему?

2. Попытайтесь определить решение, которое будет принято

Здесь стоит подчеркнуть уже отмеченный ранее момент: продукт данных является не технической проблемой, а бизнес-проблемой. Таким образом, перестаньте влюбляться в модные термины (глубокое обучение, нейронные сети, большие данные, искусственный интеллект) и начните сосредотачиваться на практических Решение проблемы. Зачем использовать глубокое обучение, если работает логистическая регрессия? Зачем использовать большие данные, если вы даже не занимаетесь базовой статистикой своих данных? Иногда продукт данных — это простой поиск данных, потому что, если у вас нет данных, вы должны начать здесь.

Поэтому сосредоточьтесь на поиске самого простого и наиболее объективного решения для решения проблемы. Помните цель методологии Lean и известную фразу:

«Быстро тестируйте, быстро ошибайтесь и быстро настраивайте», — Том Питерс

Поэтому всегда спрашивайте:

  • Какое решение будет принято? (Пример: аналитика, машинное обучение , искусственный интеллект и т. д.).
  • Каким будет решение? Например:
    Если принятое решение — это машинное обучение, мы должны учитывать, что: для каждой проблемы у нас есть разные подходы. Для каждого подхода несколько алгоритмов. И для каждого алгоритма несколько параметризаций. То есть нет и никогда не будет «лучшего алгоритма» для данной задачи. Но в любом случае наличие карты того, что вы хотите, послужит ориентиром для развития проекта.
  • Что ожидается от решения? Каковы будут результаты продукта?
    Например: отчет с конечным продуктом анализа? Конкретный прогноз относительно типа данных?
    Да, и не забывайте, в конце каждого из этих вопросов всегда спрашивайте: почему, почему, почему???

3. Сопоставьте все данные

Если вы менеджер по продуктам данных и намерены работать с проектами данных, помните:

1) Основная проблема заключается в происхождении данных и их источниках;

2) результат будет гораздо больше зависеть от качества этих данных, чем от анализа и моделей;

3) Всегда уделяйте приоритетное внимание созданию внутренней среды, благоприятствующей культуре управления данными.

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

  • Каков источник данных, т.е. что такое источник? (Например: это в системе? Это набор файлов? Имеет ли он структурированное форматирование?)
  • Что такое качество данных? Являются ли они достаточными для анализа?
  • Доступ и Доступность — есть ли у вас доступ к данным? Они доступны?
  • Процесс/преобразование — необходимо ли установить процесс чтения данных? Будет ли процесс трансформации?
  • Выходные данные. Какие существуют выходные форматы?
  • Тестирование/обучение/проверка. Существуют ли какие-либо стратегии или предположения относительно данных тестирования, обучения и проверки?

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

4. Какие гипотезы будут проверены

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

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

  • Какие гипотезы мы хотим проверить?
  • Каковы ожидаемые ответы для каждого из них?
  • Что делать с каждым ответом? Другими словами, какой стратегии мы должны следовать?

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

Например: снизит ли предлагаемое решение скорость оттока? Можно ли с помощью предложенного решения предсказать клиентов, которые думают уйти?

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

5. Определите всех действующих лиц (клиентов и заинтересованных лиц)

Теперь пришло время перейти к второй доменной области Data Product Canvas, которая посвящена разработке продукта с точки зрения продукта представление стратегии.

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

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

Таким образом, мы должны спрашивать в любое время:

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

Пункты внимания: вам необходимо оценить, следует ли продолжать проект, если вы не можете найти спонсора для продукта. Это должно послужить сигналом предупреждения. Однако, если вы не можете найти клиента продукта, немедленно остановите проект. Ведь нет продукта, если нет покупателя.

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

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

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

Пример: представьте, что компании, занимающейся электронной коммерцией, удалось создать прогнозную модель для предотвращения оттока клиентов. Как только продукт будет доставлен и готов к использованию, что вы будете с ним делать? Какие действия будут созданы? Получив сигнал о том, что клиент покинет компанию, что можно сделать, чтобы он продолжил работу? Будет ли это автоматическое действие (маркетинг по электронной почте) или действие человека (кто-то свяжется с вами)?

Поэтому, чтобы ваш продукт не был забыт в «ящике стола», а точнее, на облачном сервере, который стоит компании денег, мы должны обеспечить, еще до начала внедрение продукта, что бизнес-сфера сможет отображать стратегические действия, которые будут использоваться. Поэтому спросите:

  • Какие действия будут использоваться?
  • Какие кампании следует создать?
  • Как создать ценность для бизнеса за счет использования разработанного информационного продукта?

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

Этот блок Canvas является мостом между двумя другими блоками: Решение и Действия. Здесь вы будете создавать показатели качества и мониторинга вашего продукта.

Со стороны решения можно использовать технические индикаторы для контроля качества разрабатываемого продукта, например, если это em>Машинное обучение, вы можете указать, какой показатель будет использоваться для измерения точности вашей модели (например, F1, полнота и т. д.). В этом случае, вот несколько вопросов, которые следует задать на этом этапе:

  • Как оценить качество готового продукта? (Например, если это модель машинного обучения, мы можем использовать ее показатель точности.);
  • Какие показатели следует использовать?

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

  • Как измерить результаты действий?
  • Если это с A/B-тестированием, то как?
  • С какой неопределенностью мы можем справиться?

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

Таким образом, мы заканчиваем вторую область (стратегическое видение) и переходим к третьей и последней области продукта данных. Холст.

8. Оцените стоимость проекта

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

  • Насколько серьезна ваша проблема ?
  • Каков базовый уровень?
  • Какова ожидаемая выгода или экономия от использования продукта?

Помните, в конце каждого вопроса, выслушав каждый ответ, всегда спрашивайте еще раз, почему?

9. Сопоставьте риски

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

  • Каковы риски?
  • Что эти риски могут заблокировать во время разработки продукта?

10. Определите производительность и влияние продукта на бизнес.

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

  • Каково влияние на бизнес?
  • Как это измерить?
  • Где и как мы можем увидеть это улучшение или влияние/производительность?

Заключение

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

Ведь эффективные проекты всегда должны начинаться со стратегии, то есть это не технический вопрос, а вопрос бизнеса.

О, и если вам понравилось, пожалуйста, не стесняйтесь хлопать и делиться.

Спасибо за ваше чтение!