КАК ОБРАЩАТЬСЯ К БИЗНЕСУ В КАЧЕСТВЕ ДАННЫХ

3 совета, которые помогут сохранить объем вашего проекта по науке о данных

Никогда не тратьте время на создание приложения-монстра, которое далеко от первоначального предложения. И быть виноватым в этом.

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

Ваш проект все дальше и дальше продвигается от первоначального объема, а вы на много миль от завершения. Демка - вторник, слезятся глаза и потеют ладони.

"Это не входит в требование!" - почти каждый разработчик

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

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

Они сказали, что создайте модель оттока клиентов

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

До.

Scope Creep: давайте включим несколько новых источников данных ...

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

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

А потом.

Изменение объема: давайте полностью изменим наше предположение ...

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

Давайте сделаем паузу и вспомним, когда это случилось с вами. Взгляните на три варианта ниже, связанные со снижением или изменением объема. Если бы вы могли вернуться в прошлое и выбрать что-то одно, что бы вы сделали?

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

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

Совет 1. Знайте, кто заинтересован в вашем проекте

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

1⃣ Поговорите с командами, у которых есть нужные нам данные

2⃣ Модель поезда

3⃣ Поговорите с группами, которые помогут нам развернуть режим (например, с группами разработки данных и инфраструктуры, если вам не повезло уже работать с ними).

Круто, а что здесь пошло не так?

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

Не имея твердого представления о множестве заинтересованных сторон, вы поняли…

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

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

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

Часто изменение объема происходит из-за того, что вначале не вовлекались нужные заинтересованные стороны.

Если бы мы знали, что проект финансирует команда по управлению взаимоотношениями, мы бы включили показатели, которые их волнуют - будь то NPS или количество ретвитов. Если бы мы знали, что сотрудник колл-центра является нашим пользователем, мы бы включили надежное объяснение модели, чтобы они могли оптимизировать первые 3 секунды телефонного звонка, прежде чем клиент положит свой телефон со словами «Нет, мне не нужен новый контракт на мобильную связь - третий раз за неделю ».

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

Есть много хороших материалов по анализу заинтересованных сторон, но суть такова:

Не стремитесь удовлетворить всех.

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

В противном случае у вас не хватит времени и бюджета.

Совет 2: используйте очень конкретное предложение, чтобы передать формулировку проблемы.

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

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

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

Например, у вас может быть расплывчатое предложение, в котором говорится:

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

Следующие три предложения являются лучшими примерами уточненных формулировок проблемы:

Это помогает разбить предложения на четыре части:

🔍 Выявление / понимание: это контролируемая или неконтролируемая проблема? это проблема классификации или регрессии?

❓ Какой показатель мы пытаемся оптимизировать: количество активных отмен или коэффициент конверсии исходящих звонков?

🙋‍♀ На кого мы ориентируемся: на всех контрактных клиентов или только на ценных клиентов, которые имеют право на обновление?

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

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

Совет 3. Определите однозначные показатели успеха

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

Вместо того, чтобы пытаться сбалансировать точность и запоминание, нашему мозгу легче воспринимать только результат F1. Вместо того, чтобы сравнивать балл F1 между регионом A и регионом B, легче понять взвешенный показатель F1 между обоими регионами.

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

Приятно видеть, что точность увеличивается на 0,1%, но вложения часто непрактичны.

Иногда, когда у вас есть несколько показателей (например, n показателей), которые нельзя объединить, вам следует выбрать n-1 удовлетворительную метрику и только 1 оптимизирующую метрику:

👍 Удовлетворительная метрика: достаточно хорошая метрика. Обычно имеют пороговое значение, например размер модели менее 5 МБ или время выполнения менее 1 секунды.

🚀 Оптимизирующий показатель: показатель, который нужно минимизировать или максимизировать. Обычно нет ограничений, например, максимальная точность, которую я могу получить (теоретически это 100%, но вы поняли мою точку зрения).

Наличие только одного оптимизирующего показателя - ключ к сравнению нескольких экспериментов. Если мы воспользуемся примером сверху:

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

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

Эндрю Нг обсуждал идею выбора единственной метрики в своей книге - Machine Learning Turnning. Я призываю всех, кто занимается данными, прочитать эту книгу. Он также опубликовал курс Структурирование проектов машинного обучения на Coursera по этой (и не только) теме.

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

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

«Если обязательства не приняты, остаются только обещания и надежды; но никакого плана ». ~ Питер Ф. Друкер

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

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

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

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

Дорожная карта должна включать как минимум следующие 4 пункта:

1⃣ Что вы будете делать: фактические задачи, которые вы будете выполнять, такие как оценка готовности среды, консолидация входных данных или создание базовой модели. Они должны быть небольшими спринтами (скажем, 2–6 недель), чтобы можно было легко повысить риски, если они начнутся.

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

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

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

Наконец…

Не бойтесь просить о помощи.

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

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

Спасибо за чтение ⭐ Подписывайтесь на меня в Medium, LinkedIn или посетите мой Веб-сайт. Кроме того, если вы хотите оценить структуру развертывания машинного обучения, напишите нам в Melio Consulting.