«Если это невозможно измерить, им нельзя управлять» - Питер Друкер
Наука о данных - относительно новая область, которая стала популярной в последние годы и находится параллельно с ИТ и эксплуатацией во многих организациях. Поскольку он все еще находится на начальной стадии и отличается от традиционных проектов в области ИТ и программного обеспечения, существует много неясностей, связанных с тем, как проекты Data Science выполняются в организациях. В отчете за 2019 год предполагается, что только 20% проектов в области науки о данных успешно реализуются в производственной среде. Этот низкий уровень успеха ясно иллюстрирует плачевное состояние проектов в области науки о данных в отрасли и огромные улучшения, которые необходимо сделать.
Одна из основных причин провала науки о данных - отсутствие сотрудничества между специалистами по обработке данных, ИТ-отделом и операционными группами. Это создает узкое место для быстрой реализации гипотезы модели от экспериментов до производства или для повторения многих изменений версий моделей в процессе производства. Чтобы справиться с этой ситуацией, индустрия позаимствовала идею DevOps из традиционных программных проектов и перепрофилировала ее для проектов в области науки о данных и машинного обучения под названием MLOP.
Хотя MLOP помогли в значительной степени упростить процесс, все же этого недостаточно для обеспечения успеха проекта в области науки о данных, если он не управляется надлежащим образом! По сравнению с менеджерами программных проектов менеджеры проектов по науке о данных все еще работают без стандартных ключевых показателей эффективности управления проектами, и, прежде чем они осознают, их планы постепенно выходят из-под контроля в сторону неудач.
Давайте сначала разберемся, каковы текущие проблемы и проблемы в управлении проектами в области науки о данных.
Проблемы управления проектами в области науки о данных
У менеджеров программных проектов есть масса проверенных показателей и ключевых показателей эффективности для отслеживания прогресса и результатов своих проектов. Менеджеры по анализу данных не могут просто повторно использовать эти традиционные KPI, и в этом разделе мы обсудим, почему это так.
Отслеживание проекта
Каждый этап программных проектов имеет четкие ожидания и результаты, например: фаза требований дает конкретные входные данные для фазы проектирования, дизайн предоставляет разработчикам часть явной информации, а разработчик создает код, который соответствует требованиям. Это помогает распределить фазы по времени и соответствующим образом отслеживать их.
С другой стороны, чтобы заняться постановкой проблемы, проект по науке о данных постепенно развивается от первоначального набора гипотез. Это может привести к дополнительным неожиданным открытиям, в результате которых будет больше вопросов, чем ответов, и для их решения потребуется больше усилий. Из-за такого экспериментального и нелинейного пути вы не можете слепо использовать KPI традиционных программных проектов для оценки прогресса ваших проектов в области науки о данных. Следовательно, становится сложно отследить, движется ли ваш проект в правильном направлении или отклоняется от своих первоначальных целей.
Отслеживание производительности
Важным артефактом в традиционных программных проектах является код, созданный разработчиками, а менеджеры используют такие показатели, как строка кодов, функциональные точки, сюжетные точки, для оценки трудозатрат и измерения производительности команды.
Однако в проектах по науке о данных основными материальными результатами являются модели машинного обучения, но на этапе экспериментов специалисты по данным обычно создают и отбрасывают множество моделей, пока они не придут к наиболее эффективной. Отказ от модели не означает, что специалист по обработке данных непродуктивен; это то, как они работают. Но длительное ожидание разработки хороших моделей машинного обучения также может быть признаком неумелости или непродуктивности. Таким образом, это затрудняет оценку и отслеживание производительности как на уровне команды, так и на индивидуальном уровне.
Отсутствие ясного видения
Обычно в программном проекте есть хороший мыслительный процесс, цель и коммуникация, которая осуществляется прямо от бизнеса и руководства до команды проекта программного обеспечения. Различные заинтересованные стороны анализируют ход проекта с гораздо большей ясностью на разных этапах, чтобы убедиться, что все идет не так, как надо.
Однако, когда дело доходит до науки о данных, большинство организаций начали инвестировать в проекты по науке о данных под давлением коллег только потому, что вокруг этого был большой ажиотаж, и все занимались наукой о данных. В различных компаниях бюджеты на науку о данных утверждались в спешке, и команда была создана в одночасье без кристально ясного видения или цели. Отсутствие четких формулировок проблем и целей привело к тому, что никто не знал, как эффективно измерить успех или провал различных этапов проекта по науке о данных или всего проекта в целом.
КПЭ проектов в области науки о данных
Действительно, мы не можем просто повторно использовать все ключевые показатели эффективности программного проекта, но мы можем адаптировать их для проектов по науке о данных, подобно тому, как MLOps был выделен из DevOps. Здесь мы перечисляем некоторые полезные KPI, которые вы можете использовать в своих проектах по науке о данных.
1. Четкая цель и видение
Четко сформулированная цель является основой для измерения успеха всего проекта. Цель не должна быть двусмысленной; вместо этого он должен быть поддающимся количественной оценке и измерению, чтобы вы могли отслеживать прогресс проекта в сравнении с этим.
Пример неоднозначной цели бизнеса: «Мы хотим, чтобы наши клиенты не уходили из нашей службы». Вы не можете проверить результат своего проекта на соответствие этой цели.
Вместо этого измеримая цель выглядит так: «Мы хотим снизить уровень оттока клиентов на 10% в следующем финансовом году». У этого есть измеримая цель и конкретный график, в соответствии с которым вам придется вести свой проект по науке о данных.
2. Отправленные истории пользователей
Мы также можем определить четкие цели и сроки для более мелких этапов проекта Data Science. Для этого вы можете применить гибкую методологию для создания пользовательских историй для своего проекта, назначить их членам команды и запланировать их на 2–3-недельный спринт. Ниже приведены некоторые возможные примеры четко определенных историй для типичного проекта в области науки о данных.
● История 1 - «Соберите данные из базы данных MongoDB и Oracle и создайте комбинированный набор данных».
● История 2 - «Проведите подробный исследовательский анализ данных и подготовьте отчет».
● История 3 - «Создайте модель гипотез с базовой точностью не менее 60%».
● История 4 - «Подготовьте бизнес-отчет о наших выводах с помощью визуализаций».
Обратите внимание, что все эти истории имеют четко определенные материальные ожидаемые результаты, такие как «набор данных», «отчет», «модель», «бизнес-отчет».
Отслеживая истории пользователей, вы можете получить следующие два показателя:
- Результат каждой истории в конце спринта определяется, был ли результат завершен успешно или нет, и это очень полезно для измерения продуктивности человека. Если человек не может рассказать истории в слишком большом количестве спринтов, вам следует принять соответствующие меры.
- Успех каждого спринта можно определить по тому, сколько историй было успешно закрыто. Это поможет понять общую продуктивность команды, а также состояние всего проекта. Если вы видите спринт с несколькими успешными историями, то это признак того, что все вышло из-под контроля, и вам необходимо оценить разрыв.
3. Произведены многоразовые артефакты.
В программных проектах всегда желательна возможность повторного использования. Некоторые артефакты могут быть созданы с учетом возможности повторного использования, что может не только повысить продуктивность текущего проекта, но также может быть полезным для других проектов. Точно так же, если вы можете использовать повторно используемые артефакты в своем проекте, вы можете сэкономить много времени.
В проекте по науке о данных вы можете создавать повторно используемые артефакты, такие как инструменты для сбора или сбора данных, фреймворки, модели машинного обучения и т. Д. Чтобы дать перспективу, Tensorflow и PyTorch были созданы Google и FB, потому что они хотели разработать фреймворки, которые можно было бы повторно использовать внутри компании. для всех проектов и позже был открыт для повторного использования более широким сообществом. Нет. Количество таких артефактов, которые вы создаете или повторно используете, является полезной метрикой, показывающей продуктивность проекта.
4. Количество развертываний производства
Независимо от того, сколько экспериментов и POC вы делаете для создания модели машинного обучения, если вы не можете развернуть модели в производственной среде, усилия не могут быть оправданы. И как только модель развернута, она редко работает идеально; следовательно, в производстве требуется несколько итераций и усовершенствований моделей.
В некоторых проектах развертывание выполняется после каждого спринта или в заранее определенном цикле, но идея состоит в том, чтобы довольно часто развертывать небольшие изменения в производственной среде. Если количество производственных развертываний за период времени меньше, это означает, что вам нужно время, чтобы внедрить идею в производство. Пришло время определить узкое место в непрерывном процессе или в конвейере MLOps.
5. Полученные практические идеи
Ключевыми результатами проектов в области науки о данных для бизнеса являются практические выводы из их расширенной аналитики или модели машинного обучения. Практические идеи обычно представляют собой различные виды предложений по оптимизации бизнеса для улучшения таких процессов, как операции, продажи, запасы и т. Д.
Эффективные проекты в области науки о данных должны давать много действенных идей в течение определенного периода времени. Это можно отслеживать ежемесячно или ежеквартально, и это важный ключевой показатель эффективности, который показывает, какую ценность для бизнеса приносит ваш проект. Если за какой-то период получено меньше аналитических данных, вам следует проверить другие перечисленные выше ключевые показатели эффективности, чтобы выявить проблему.
6. Возврат инвестиций (ROI)
Когда компания инвестирует в проект по науке о данных, в конечном итоге все сводится к тому, может ли он помочь компании максимизировать прибыль или минимизировать убытки. Это вершина успеха проекта в области науки о данных. То, сколько ваш проект смог вернуть компании помимо их инвестиций, называется рентабельностью инвестиций, и это конечный KPI, за которым вы следите.
Даже если по прошествии многих месяцев или лет проект по науке о данных так и не продвинется к безубыточности для организации, тогда стоит пересмотреть проект сверху вниз. С другой стороны, если вы можете обеспечить значительную рентабельность инвестиций для компании, поздравляем, что ваш проект по науке о данных очень успешен.
Заключение
В настоящее время не существует стандартных KPI для управления проектами в области науки о данных, которые были бы успешно проверены. Но если скоротать время и извлечь уроки из неудач проектов, эта отрасль в конечном итоге создаст надежную структуру управления проектами, точно так же, как индустрия программного обеспечения развивалась с годами. Тем временем в этой статье мы позаимствовали идеи KPI из программных проектов и показали, как вы можете использовать их в своем проекте по науке о данных.
Дополнительные справочные материалы:
