К счастью, я наткнулся на горячую область «науки о данных/машинного обучения» после того, как отказался от незаконченной докторской диссертации. Я работал в инвестиционном банке, различных технологических стартапах и FAANG (Facebook, Amazon, Apple, Netflix и Google). Сегодня я работаю с инженерами по машинному обучению и учеными над созданием сервисов, которые автоматически обнаруживают и устраняют аномалии в приложениях. Мне посчастливилось попасть в эту область до того, как она стала такой большой, как сегодня, и много лет работала специалистом по данным. После руководства и управления многочисленными проектами в разных отраслях я решил перейти к управлению продуктами и поставлять решения машинного обучения внутренним и внешним клиентам.

Менеджеры по продукту с более легким опытом машинного обучения иногда жалуются на трудности с управлением проектами с компонентами ML (обычные гибкие подходы почему-то внезапно перестали работать, а выполнение требований к продукту с командой докторов наук кажется неоправданно сложным) — настолько, что многие советуют против вовлечения ML в MVP, чтобы избежать полного провала.

Общие ловушки в управлении жизненным циклом продукта машинного обучения обычно возникают из-за отсутствия понимания относительно четкого прогресса разработки (по сравнению с традиционной разработкой программного обеспечения) для ML. У Луи Дорара есть отличный поток прогресса для проекта ML, который я очень рекомендую.

Однако доля каждого сегмента полностью зависит от вашей организационной поддержки, талантов и технической инфраструктуры. Более новая область (ML для проектирования безопасности или инструменты автоматизации, такие как DevOps), вероятно, потребует от вас выделения значительных ресурсов для сбора данных и принятия решений, потому что никто раньше не пробовал решение на основе ML. Напротив, устоявшаяся область (такая как таргетинг рекламы и обнаружение мошенничества), вероятно, потребует большего внимания к частям «составления прогнозов» и «живой оценки и мониторинга», потому что существующие модели и процессы, вероятно, уже очень хороши, и вам нужно превзойти их. чтобы ваше новое решение было принято.

Наша работа как менеджера по продукту по-прежнему состоит в том, чтобы «продвигать продукт вперед». «Как» может сильно различаться в зависимости от задач. В моей прежней жизни в качестве специалиста по данным было много нытья о менеджерах по продуктам, которые просто ничего не понимали. В одной из моих команд неприязнь между PM и специалистами по данным была настолько сильной, что за два года было развернуто менее 10% всего прогресса команды. Специалисты по продуктам были возмущены, когда не смогли получить оценку рабочих процессов (подождите, вы сказали, что для получения обучающих данных потребуется спринт, что случилось?[оказывается что данные имеют дерьмовую политику хранения, и нам нужно было вообще сменить источник данных]), но также знаем, что специалисты по данным ненавидят собрания (где могут быть достигнуты более разумные оценки зависимостей и усилий). Ученые хотели построить хорошие модели (что включает в себя измерение множества различных показателей на разных этапах процесса разработки), а не заполнять отчет о состоянии и отслеживать показатели производительности, в которых их коллеги по управлению проектами так отчаянно нуждаются для поддержания порядка. Обе стороны видят друг в друге препятствие для прогресса, хотя на самом деле они нуждаются друг в друге.

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

Вывод

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