«МЛОпс? Да, да, мы делаем это сейчас. Меган — наша девушка из MLOps, она всем этим управляет». Как специалисты по данным и инженеры MLOps, мы все хотели бы иметь полноценную команду MLOps, которая идеально интегрирована с окружающими ее командами. Так как же тогда выглядит хорошая команда MLOps? В детстве я часами с друзьями рисовал идеальную футбольную команду из 11 человек. Ромарио здесь, Бергкамп там. И я должен вам признаться, что я до сих пор делаю это ради баскетбола НБА. Мы с друзьями горячо обсуждаем в нашей группе в WhatsApp, кто достоин какой позиции в «лучшей команде всех времён» или по какой позиционной системе ему следует играть. В этой статье я попробую сделать то же самое для MLOps. Никогда не будет отбора величайших инженеров и менеджеров по продуктам. Однако мы обсудим необходимые позиции и систему. Дайте мне знать в комментариях, что вы думаете! Горячие дискуссии приветствуются :)
Но сначала: почему вам нужна хорошая команда MLOps
К сожалению, во многих организациях MLOps по-прежнему зависит лишь от горстки людей, иногда даже от одного или двух! В более крупных организациях, где машинное обучение осуществляется в больших масштабах, команды растут в размерах. Может быть даже несколько команд, занимающихся операциями машинного обучения, поскольку наличие и работа решений машинного обучения имеет решающее значение для основных операций бизнеса. Как мы говорим, они критичны. В мире данных, где мы прошли путь от создания конвейеров ETL с инженерией данных до нынешнего мира машинного обучения и искусственного интеллекта, это требует некоторого изменения мышления. Когда я начинал работать в этой области, сбой в конвейере данных означал, что «панель мониторинга не обновилась». Обычно мы могли отладить некоторый код в достаточно спокойной обстановке. А если к концу дня не удалось исправить, всегда наступало завтра.
В нынешнюю эпоху машинного обучения и машинного обучения, когда конвейеры часто напрямую связаны с бизнес-операциями, ставки возросли. Неисправный конвейер машинного обучения может означать, что веб-сайт может выйти из строя, электронная почта не может быть отправлена, продукты не могут быть доставлены, а большие сотрудники в распределительных центрах сидят без дела. Это может привести к растратам, потере прибыли, стрессу. И это худшие случаи: риски для безопасности, защищенности и здоровья.
Потоки данных редко бывают идеальными, решения машинного обучения часто сложны и могут содержать ошибки. И в целом в нашей отрасли нам есть чему поучиться в области разработки программного обеспечения, тестирования кода и создания надежных ИТ-решений. Так что дерьмо рано или поздно попадет в вентилятор. Дерьмо гарантированно попадет в вентилятор… вопрос в том, насколько это будет плохо, как часто это будет происходить и как вы сможете это исправить в приемлемые сроки? Ответ: наличие хорошей команды MLOps. Не позволяйте всему этому лежать на плечах нашей девочки Меган (в какой-то момент ей тоже может понадобиться отпуск, может ли ваш бизнес продолжать работать без нее?).
Так как же выглядит идеальная команда MLOps?
Стратегический/исполнительный уровень
Каждый успешный проект ML начинается с поддержки стратегического и/или исполнительного уровня. Если у вас его нет, не пытайтесь (боритесь со мной в комментариях;), потому что в долгосрочной перспективе вы не добьетесь успеха. Таким образом, наличие спонсора и, возможно, даже прямого подчинения на самом высоком уровне является ключом к успеху вашего проекта(ов). Это связано с тем, что наука о данных и MLOps часто являются межведомственными, требуют значительных инвестиций и имеют тенденцию фундаментально менять (части) того, «как мы здесь работаем». Эти трансформационные цели требуют поддержки со стороны больших боссов. Поэтому относитесь к ним как к (расширенной) части вашей команды с регулярными обновлениями и короткой обратной связью. Получение зеленого света для проекта ML/MLOps, а затем предоставление результатов через несколько месяцев не поможет.
Евангелист
Так как же вы попали на стратегический/исполнительный уровень? Да, в вашей команде был отличный евангелист. О евангелистах часто забывают, поэтому я ставлю их на первое место в этом списке. У специалистов по данным и инженеров есть замечательные идеи, но именно евангелисты придают им силу и обеспечивают распределение ресурсов между командами. Поэтому они важны в начале, а также в середине и после проекта. Когда на этапе реализации дела идут плохо, евангелист следит за тем, чтобы жизнеобеспечение не было отключено, и не дает проекту зайти в тупик. После того, как проект сдан, они становятся энтузиастами, которые с радостью принимают его на вооружение! И вместе с техническими экспертами, занимающимися данными, они могут стать отличным помощником, постоянно обучая конечных пользователей чему-то, что на первый взгляд может показаться черным ящиком. Это не та конкретная роль, на которую вы бы наняли, ваш типичный евангелист может скрываться под любым названием должности, но, скорее всего, у него есть некоторая энергия типа Стива Баллмера.
Человек извне
Эта роль является связующим звеном между технической командой и заинтересованными сторонами бизнеса. Человек, выполняющий его, должен в первую очередь сосредоточиться на бизнесе! Информирование и удовлетворение заинтересованных сторон бизнеса и спонсоров обеспечит устойчивое признание и влияние инициатив ML и MLOps. Успешные люди на этой должности будут создавать отличные слайд-шоу, иметь под рукой матрицу заинтересованных сторон, являются опытными стратегами встреч и будут проводить много встреч за кофе и встречами по всей организации, чтобы держать все носы направленными в одном направлении. Ключевым приоритетом для этой роли должно быть наличие четких этапов проекта (стратегическая дорожная карта), поддерживаемых нужными людьми в организации (управление заинтересованными сторонами). В идеале «внешний-внутренний» — это человек с деловым опытом и высокой симпатией. Риск этой должности заключается в том, что многие технические специалисты получают повышение и в конечном итоге разочаровываются в медлительности и прилипчивости организаций, «они просто этого не понимают». Остерегайтесь синдрома недовольного разработчика, терпение — ключевой навык здесь! Эту роль может выполнять как один человек, так и большая команда. В разных организациях роль будет иметь разные имена, любое из этих или даже другие:
- менеджер по продукту
- бизнес-консультант
- менеджер программы
- переводчик аналитики
- владелец бизнес-процесса/специалист по бизнес-процессам
Человек изнутри-вне
Там, где человек извне-внутри является связующим звеном со стороны бизнеса, человек извне-вне делает то же самое со стороны технической команды. Вместе они могут стать динамичным дуэтом, который гарантирует сокращение часто упоминаемого «разрыва между бизнесом и технологиями». Многие организации совершают ошибку, объединяя эти две роли в одну. Что-то слишком сложное и изначально имеющее внутренний конфликт интересов. Человек, работающий изнутри наружу, должен быть защитником и наставником команды разработчиков, сопротивляясь желаниям и давлению бизнеса, в то время как человек, работающий снаружи и изнутри, является лучшим другом бизнеса. Ключевыми приоритетами должны быть определение приоритетов и совершенствование работы команды разработчиков на микроуровне (бэклог), а также управление и обновление эпических задач разработчиков на макроуровне (техническая дорожная карта). Эта роль часто появляется под именем владельца продукта или менеджера проекта, но иногда она также является частью более широкой роли менеджера ML. В последнее время, похоже, произошел сдвиг в сторону более практического владения продуктом, когда человек, работающий изнутри и снаружи, по-прежнему также занимается кодированием и проверкой. Это большое и необходимое изменение! Но возможно только при наличии хорошей поддержки со стороны человека извне. Человек, находящийся внутри-вовне, часто получает одно из следующих имен:
- Владелец продукта
- руководитель проекта
- менеджер по науке о данных
- инженер по требованиям
Технический руководитель
В идеальном мире технический руководитель — это гуру, пользующийся уважением всех разработчиков, опытный старший или главный инженер, который все это видел и все это знает. Однако такие гуру — редкая порода, и на рынке не хватает хороших пожилых людей. Да, руководитель должен быть опытным, но, я думаю, здесь также важно то, что технический руководитель является сильным коммуникатором и установщиком культуры. Технический руководитель должен хорошо знать возможности, надежды и мечты своей команды. Вместе с людьми, работающими на горизонтальных уровнях (например, руководителями подразделений и менеджерами по обучению и развитию), техническому руководителю было бы разумно создать культуру непрерывного обучения. Культура разработки может быть меритократической, и это нормально, если все поддерживают друг друга. Итак, «Пффф, этот парень даже не знал об X в командной строке» — это красный флаг, и в качестве альтернативы: «Оууу, но вы также можете просто исправить это из командной строки, позвольте мне показать вам, если хотите!» это зеленый флаг, который вам нужен. Я считаю, что это начинается сверху! Если ваши технические руководители примут такой подход и при этом всегда будут открыты для обучения чему-то новому от других, ваша команда будет процветать. Оно начинается сверху. Ключевые обязанности: разработка решений, обеспечение качества, установление культуры, стандартные рабочие процедуры, обучение и развитие команды, решение проблем. В идеале технический руководитель также обладает деловой хваткой, но эту должность можно выполнять и без нее, если технический руководитель имеет сильную поддержку со стороны других ролей.
Инженеры
В командах MLOps вы можете работать с разными типами инженеров. В следующей статье мы обсудим различные вкусы инженеров, их навыки и обязанности. Так что следите за обновлениями!
- инженеры МЛОпс
- инженеры машинного обучения
- Инженеры по инфраструктуре/облаку/DevOps
- Инженеры по BI/ETL/аналитике
- Архитекторы
Руководство среднего звена (умерло)
Я не верю в менеджеров среднего звена в области науки о данных и MLOps. Лидерами здесь являются внешнее-внутреннее, внутреннее-внешнее и технический руководитель. Решения в области науки о данных могут оказать настолько глубокое влияние на бизнес-операции и стратегический подход, что я считаю, что команды должны работать близко к стратегическому и исполнительному уровню или ниже него. Конечно, это не всегда хорошо масштабируется в более крупных организациях, и для поддержания работоспособности таксономии управления может потребоваться дополнительная иерархия прямой отчетности. Однако я считаю, что, занимаясь технологиями в нетехнологической компании, вам захочется, чтобы экспертные знания были близки к стратегическому и исполнительному уровням, чтобы обеспечить более упорядоченное принятие решений. Получение влияния на больших начальников не только приведет к повышению эффективности процессов, но также даст вашим сотрудникам возможность быть более автономными и ответственными, что приведет к более высокому удовлетворению работой и большей мотивации к успеху. А с точки зрения совета директоров: генеральным директорам, желающим «трансформировать свою компанию с помощью ИИ», лучше начать разговаривать со своими экспертами. Существует много бессмысленных слайд-дек. Будьте готовы бросить вызов своему высшему руководству и вложить время, кровь, пот и слезы в «революцию искусственного интеллекта», потому что она приближается.
За пределами ярлыков
В разных организациях эти роли будут иметь разные названия. Важно уметь видеть сквозь причудливые названия должностей и понимать, какие разные роли существуют в нашей отрасли. Точные названия не имеют большого значения, хотя я всегда выступаю за прозрачность и понятность!
Распространенной ошибкой является то, что многие организации пытаются объединить несколько ролей вместе. Я видел людей в роли менеджера по обработке данных/ведущего разработчика/владельца продукта, и да, я тоже был в этом виновен. По моему опыту, в долгосрочной перспективе это не сработает. Лучше разделить часть обязанностей, если масштаб позволяет. Конечно, в небольших организациях не все роли будут присутствовать, и 1 владелец продукта, 2 специалиста по обработке данных и ценный бизнес-кейс — это все, что вам нужно / вы можете себе позволить!
Также очень важной частью построения команды является подбор ролевых талантов в вашей команде. И получение команды – это только первый шаг. Вам нужна модель доставки, настройка процессов, обеспечение производительности и счастья команды, а также многое другое. Мы обсудим это в будущих статьях. Удачного тимбилдинга!
Следуйте за нами на Substack, чтобы увидеть эти и другие типы контента. Следите за нами в LinkedIn для регулярных обновлений.
