Структура команды Data Science: ключевые модели и роли
Если вы следили за мнениями специалистов в data science и прогностической аналитики, то, скорее всего, сталкивались с рекомендациями использовать машинное обучение. Как рекомендует Джеймс Ходсон в Harvard Business Review, умнее всего будет стремиться к решению самой лёгкой задачи, а затем масштабировать процессы на более сложные операции.
Недавно мы обсуждали платформы machine-learning-as-a-service (MLaaS). Основной вывод из современных тенденций прост: машинное обучение становится более доступным для средних и мелких бизнесов, постепенно превращаясь в массовый товар. Ведущие поставщики (Google, Amazon, Microsoft и IBM) предоставляют API и платформы для выполнения основных операций ML без собственной инфраструктуры и большого опыта в data science. На первых этапах самым умным шагом будет выбор такого гибкого и экономного подхода. С ростом возможностей аналитики можно изменять структуру команды для ускорения её работы и расширения арсенала аналитики.
В этот раз мы поговорим о структуре команд data science и их сложности.
Команды, формируемые для обработки данных
Самые успешные data-driven-компании решают сложные задачи data science, включающие в себя исследования, использование различных моделей ML, специализированных на различных аспектах процесса принятия решений или применение множества сервисов с поддержкой ML. В случае крупных организаций, команды data science могут выполнять поддержку различных структурных подразделений и работать в рамках их конкретных областей аналитических интересов. Очевидно, что специализированные команды data science, собранные под решение конкретных задач, могут сильно отличаться друг от друга.
Для примера давайте рассмотрим команду data science Airbnb. Чтобы глубже понять, как компания создаёт свою культуру, вы можете посмотреть этот доклад дата-саентиста Airbnb Мартина Дэниела или прочитать пост бывшего руководителя отдела DS, но если вкратце, то в компании применяются три основных принципа.
Эксперимент. Поиск способов использования данных в новых проектах при помощи сложившегося процесса «изучение-планирование-тестирование-измерение».
Демократизация данных. Масштабирование команды data science на всю компанию и даже на клиентов.
Измерение влияния. Оценка степени участия команд DS в процессе принятия решений и признание их заслуг.
Эти три принципа довольно часто применяются техническими руководителями, поскольку они позволяют принимать решения на основе данных. Однако для их соблюдения у вас должна быть чёткая стратегия и понимание того, из кого состоят эти команды и как они встроены в организационные структуры.
Для успешной обработки данных критически важно иметь подходящих сотрудников. Каких людей вам стоит искать?
Роли в команде data science
Давайте поговорим о спектре навыков дата-саентистов. К сожалению, в последнее время понятие «дата-саентист» расширилось и стало слишком размытым. После того, как data science привлекла внимание бизнеса, не выработалось консенсуса о том, каким спектром навыков должен обладать дата-саентист. Дата-саентист и заместитель редактора KDNuggets Мэттью Майо говорит следующее: "Когда я слышу выражение «дата-саентист», то обычно представляю единорога, но потом вспоминаю, что их не существует, и что реальные дата-саентисты выполняют в организациях множество разнообразных ролей, с разным уровнем деловых, технических, коммуникативных, личностных и функциональных навыков."
И это правда. «Единорогов» найти сложно, но можно вырастить их из людей, имеющих нишевый опыт в data science. Наша компания при найме специалистов по машинному обучению учитывает следующие навыки data science:
Как будет показано ниже, в экосистеме data science существует множество ролей, а в Интернете представлено множество классификаций. Мы расскажем об одной из них, описанной Майклом Хохстером из Stitch Fix. Майкл разделяет дата-саентистов на два типа: тип A и тип B.
Тип A означает Analysis (анализ). Этот человек — статистик, он разбирается в данных, необязательно имея большие знания в программировании. Дата-саентисты типа A выполняют очистку данных, прогнозирование, моделирование, визуализацию и так далее.
Тип B означает Building (разработка). Эти люди используют данные в продакшене. Они превосходные разработчики ПО, имеющие опыт в создании систем рекомендаций, персонализации и так далее.
Один специалист редко относится к какой-то одной категории, но понимание этих двух функций в data science поможет вам разобраться в ролях, которые описаны ниже.
Помните, что даже профессионалы с этим гипотетическим набором навыков имеют свои сильные стороны, которые следует учитывать при распределении ролей в команде. В большинстве случаев, после найма сотрудника следует обучение в зависимости от его квалификации.
Однако люди и их роли — это две разные вещи. Например, если вы используете интегрированную модель команды, один человек может сочетать в себе несколько ролей. Так что можно не обращать внимания на то, сколько реальных специалистов у вас есть, и описать сами роли. Разумеется, многие из навыков между разными ролями могут пересекаться.
Chief Analytics Officer/Chief Data Officer. В нашей технической статье о машинном обучении мы обобщённо рассмотрели эту важнейшую руководящую роль. CAO, «бизнес-переводчик», ликвидирует пробел между data science и опытом в предметной области, действуя и как визионер, и как технический руководитель. Лучше понять его предназначение можно, взглянув на показанную ниже визуализацию.
Предпочтительные навыки: data science и аналитика, навыки программирования, знания предметной области, навыки лидера и визионера
Аналитик данных. Эта роль подразумевает работу по сбору данных и их интерпретации. Аналитик обеспечивает релевантность и подробность всех собираемых данных, а также интерпретирует результаты аналитики. Некоторые компании, например, IBM и HP, также требуют, чтобы аналитики данных имели навыки визуализации для преобразования пугающих чисел в осязаемые выводы в графиках.
Предпочтительные навыки: R, Python, JavaScript, C/C++, SQL
Бизнес-аналитик. По сути, бизнес-аналитик осуществляет функции CAO, но на операционном уровне. Под этим подразумевается преобразование ожиданий бизнеса в анализ данных. Если вашему основному дата-саентисту не хватает знаний в предметной области, бизнес-аналитик ликвидирует этот пробел.
Предпочтительные навыки: визуализация данных, business intelligence, SQL
Дата-саентист (не «единорог» data science). Чем занимается дата-саентист? (Будем считать, что вы не охотитесь на «единорогов».) Дата-саентист — это человек, решающий задачи бизнеса при помощи техник машинного обучения и data mining. Если это кажется слишком расплывчатым, то роль можно сузить до подготовки и очистки данных с дальнейшим обучением и оценкой модели.
Предпочтительные навыки: R, SAS, Python, Matlab, SQL, noSQL, Hive, Pig, Hadoop, Spark
Чтобы не запутаться и сделать поиск дата-саентиста менее утомительным, его должность часто разбивается на две роли: инженер машинного обучения и журналист данных.
Инженер машинного обучения сочетает навыки разработки ПО и моделирования, определяя, какую модель использовать и какие данные должны использоваться для каждой модели. Также его сильной стороной являются вероятности и статистика. Всё, что касается обучения, мониторинга и обслуживания модели — задача инженера ML.
Предпочтительные навыки: R, Python, Scala, Julia, Java
Журналисты данных помогают разбираться в выводимых данных, перенося их в нужный контекст. Также они занимаются формулированием задач бизнеса и превращением результатов аналитики в наглядные истории. Хотя им и требуется опыт в кодинге и статистике, они должны уметь презентовать идею владельцам бизнеса и быть представителями команды обработки данных для тех, кто не умеет работать со статистикой.
Предпочтительные навыки: SQL, Python, R, Scala, Carto, D3, QGIS, Tableau
Архитектор данных. Эта роль критически важна для работы с большими объёмами данных (да, с Big Data). Однако если вы не пользуетесь исключительно облачными платформами MLaaS, она также критически важна в хранении данных, создании архитектуры баз данных, централизации данных и обеспечении целостности между различными источниками. Также архитектор отвечает за производительность в крупных распределённых системах и больших массивах данных.
Предпочтительные навыки: SQL, noSQL, XML, Hive, Pig, Hadoop, Spark
Дата-инженер. Инженеры реализуют, тестируют и поддерживают инфраструктурные компоненты, проектируемые архитекторами данных. В реальности роль инженера и архитектора может сочетаться в одном человеке. Спектры их навыков очень близки.
Предпочтительные навыки: SQL, noSQL, Hive, Pig, Matlab, SAS, Python, Java, Ruby, C++, Perl
Чтобы подробнее узнать об дата-инжиниринге в целом, посмотрите это видео с объяснениями:
Инженер приложений/визуализации данных. По сути, эта роль необходима только в специализированной модели data science. В остальных случаях доставку результатов data science в приложениях, с которыми взаимодействуют конечные пользователи, обеспечивают разработчики ПО из ИТ-отделов. И с большой вероятностью инженер приложений или другие разработчики из отделов фронтенда будут заниматься и визуализацией данных для конечных пользователей.
Предпочтительные навыки: программирование, JavaScript (для визуализации), SQL, noSQL.
Сбор и определение масштабов команды
Первоначальной проблемой при найме сотрудников в data science, наряду с общим дефицитом специалистов, являются высокие зарплатные ожидания. Согласно O’Reilly Data Science Salary Survey 2017, медианная базовая зарплата за год составляла $90 тысяч, а на момент обновления этой статьи в США этот показатель достиг $112774. Эти числа сильно варьируются от географического положения, конкретных технических навыков, размеров организации, гендера, отрасли и образования. Если вы решили нанимать опытных специалистов в аналитике, возникнут и дополнительные сложности с их привлечением и удержанием.
Без сомнения, большинство дата-саентистов стремится работать в компании, где можно решать интересные задачи, но не каждая компания похожа на Facebook, Netflix или Amazon. Однако потребность в выполнении задач, связанных с данными, заставляет организации привлекать дата-саентистов на должности начального уровня. Таким образом, найм сотрудника с широкими познаниями, образованием в точных науках и опытом работы с данными, как советует Дэниел Танкеланг — многообещающий выбор на начальных уровнях использования машинного обучения. Такой подход подразумевает переход на дальнейших этапах к сильным и более узким специалистам. Они заменяют рудиментарные алгоритмы новыми и развивают системы на регулярной основе.
Ещё один способ решения проблемы дефицита специалистов и ограничений бюджета — разработка доступных платформ машинного обучения, которые будут привлекать новых людей из ИТ и обеспечат возможность дальнейшего масштабирования. Даже если найм опытных дата-саентистов невозможен, некоторые организации могут обойти это препятствие, наладив связи с образовательными учреждениями. В США есть около десятка программ Ph.D., делающих упор на data science, и множество буткемпов с курсами длительностью около года.
Как интегрировать команду data science в свою компанию
В процессе роста команды data science вместе с потребностями компании возникает необходимость в создании совершенно нового отдела, который нужно организовать, контролировать и отслеживать, а также управлять им. Это масштабное организационное изменение означает, что у новой группы должны быть установленные роли и обязанности, в то же время связанные с другими проектами и подразделениями. Как же интегрировать дата-саентистов в компанию?
Мы возьмём за основу ключевые типы классификации Accenture и подробнее расскажем о структуре команды.
Децентрализованная
Это наименее координируемый вариант, при котором аналитическая работа используется в организации спорадически, а ресурсы выделяются под каждую функцию группы. Такое часто происходит в компаниях, когда опыт в data science возникает органическим образом. Структурные подразделения наподобие продуктовых команд или функциональные подразделения на определённом этапе выявляют внутреннюю потребность в аналитике. Они начинают нанимать дата-саентистов или аналитиков, способных удовлетворить эту потребность. Иногда дата-саентист может быть единственным человеком с опытом анализа данных в кросс-функциональной продуктовой команде.
Децентрализованная модель лучше всего подходит для компаний, не намеревающихся превращаться в data-driven-компанию. Также эта модель может применяться на ранних этапах операций data science для кратковременного прогресса в демонстрационных проектах с использованием расширенной аналитики.
Эта модель обладает следующими недостатками:
- Часто приводит к стремлению к созданию бункеров данных (silo), отсутствию стандартизации аналитики и децентрализованной отчётности.
- Проблемой становится процесс найма. Когда менеджеры нанимают в свою команду дата-саентиста, им сложно провести с ним качественное собеседование. Они чётко представляют, допустим, типичные роли, обязанности и навыки разработчиков ПО, однако в data science им они неизвестны. Поэтому это вызывает у них сложности.
- Проблематично и управление карьерным путём дата-саентиста. Менеджеры команд совершенно чётко понимают, как повышать разработчика ПО, однако дальнейшие шаги для дата-саентистов могут вызывать вопросы. Та же проблема возникает и при создании плана индивидуального развития.
- Часто встречаются низкие стандарты качества и недооценка накопленного в этой сфере опыта. Дата-саентисты должны получать знания при менторстве других дата-саентистов. Поскольку в этой модели такая возможность отсутствует, дата-саентисты могут остаться без помощи. Обычно это приводит к отсутствию улучшений в накопленном опыте, что зачастую снижает качество данных и качество продукта в целом.
Функциональная
Большинство аналитиков работает в одном функциональном подразделении, где аналитика наиболее важна. Часто это отдел маркетинга или снабжения. Из этого следует низкий уровень координации или полное её отсутствие, а опыт не используется стратегически в рамках всей компании.
Функциональная модель лучше всего подходит для организаций, только встающих на путь аналитики. У них нет потребности анализировать данные от каждой точки, а значит, не так много аналитических процессов, чтобы создавать отдельную и централизованную команду data science для всей организации.
Недостатки функциональной модели таятся в её централизованной природе.
- Команда оторвана от проблем компании в целом. При такой модели аналитика в основном сосредоточена на функциональных потребностях, а не на нуждах всей компании. Подобная неосведомлённость может привести к изолированию аналитики и к её выпадению из контекста.
- Низкий уровень единства из-за отсутствия менеджера данных. Так как аналитическая команда в этом случае подчинена конкретному подразделению, она отправляет отчёты непосредственно главе этого подразделения. Из-за этого может и не быть непосредственного менеджера data science, понимающего специфику своей команды.
Консультационная
При такой структуре команда аналитиков работает как одна группа, но из задача в организации заключается в консультировании, то есть разные отделы могут «нанимать» её под конкретные задачи. Разумеется, это означает практически полное отсутствие распределения ресурсов — специалист или доступен, или нет.
Консультационная модель лучше всего подходит для компаний малого и среднего бизнеса, у которых время от времени возникают задачи data science мелкого или среднего масштаба. поскольку все члены команды DS подчиняются и отчитываются одному менеджером команды DS, для малого и среднего бизнеса управление такой командой DS становится проще и дешевле.
Однако всегда есть недостатки.
- Во-первых фундаментальным изъяном такой модели может стать низкое качество данных. Поскольку дата-саентисты не могут применять свой наработанный опыт в каждой из задач, они могут пожертвовать качеством в угоду потребностям бизнеса, требующего быстрых решений.
- Кроме того, существует ловушка низкой мотивации. Так как дата-саентисты не вовлечены полностью в создание продукта и принятие решений, у них практически нет заинтересованности в результате.
- Серьёзным недостатком консультационной модели является неопределённость. Дедлайны не определены, потому что дата-саентисты не полностью знакомы с источниками данных и с контекстом их появления. Долговременные и сложные проекты едва ли реализуемы, поскольку для достижения хороших результатов специалисты иногда годами работают над одним набором задач.
- Также непонятен способ расстановки приоритетов. По-прежнему сложно определить, как менеджер data science расставляет приоритеты и распределяет задачи между дата-саентистами, а также каким целям нужно отдавать предпочтение.
Централизованная
Такая структура наконец-то позволяет использовать аналитику в стратегических задачах — одна команда data science работает на всю организацию в разнообразных проектах. Это не только даёт команде DS долговременное финансирование и улучшенное управление ресурсами, но и стимулирует к карьерному росту. Единственный недостаток здесь заключается в опасности превращения функции аналитики в функцию поддержки.
Один из наилучших сценариев для создания централизованной команды таков: потребность в аналитике и количество аналитиков быстро растут, требуя срочного распределения этих ресурсов. Введением централизованного подхода компания показывает, что считает данные стратегической концепцией и что она готова создать отдел аналитики на одном уровне с отделом продаж или маркетинга.
Как всегда, у этой модели есть свои недостатки.
- Есть большая вероятность изоляции и возникновения разделения между командой аналитиков данных и направлениями бизнеса. Так как команда аналитиков данных не участвует в обычных операциях отделов, приносящих выгоду бизнесу, она может не быть знакома с их потребностями и проблемами. Это может привести к узкой применимости рекомендаций, которые могут оставаться неиспользованными и незамеченными.
- Это приводит к сложностям в осознанном взаимодействии в продуктовой команде. После того, как команда аналитиков найдёт способ решения проблемы, она предлагает решение продуктовой команде. Самая большая проблема здесь в том, что это решение может не помещаться в дорожную карту продукта. Таким образом, может возникнуть конфликт. Один из способов решения заключается в создании команды, которая будет оценивать, проектировать и реализовывать предложенное решение. Однако эта альтернатива требует много усилий, времени и денег.
Иногда централизованную модель называют Center of Excellence. И это нормально, всегда существуют уникальные сценарии. Однако мы будем придерживаться классификации Accenture, потому что она кажется более детализированной и подчёркивает различия между централизованной моделью и Center of Excellence.
Center of Excellence (CoE)
Если вы выберете этот вариант, то всё равно получите централизованный подход с единым центром координации, однако дата-саентисты будут размещены в разных подразделениях организации. Это самая сбалансированная структура — работа аналитиков хорошо координируется, однако специалисты не будут перемещаться из структурных подразделений.
Благодаря своим хорошо сбалансированным связям, этот подход применяется всё активнее, особенно в организациях корпоративного уровня. Лучше всего он подходит компаниям с корпоративной стратегией и тщательно проработанной дорожной картой обработки данных.
Однако даже такой глубоко ориентированный на данные подход имеет свои недостатки.
- Хотя он сбалансирован, в нём отсутствует единая централизованная группа, сосредоточенная на решении задач корпоративного уровня. Каждая аналитическая группа решает задачи в рамках своих подразделений.
- Ещё один недостаток заключается в отсутствии отдела инноваций — группы специалистов, в первую очередь сосредоточенных на самых современных решениях и долговременных проектах обработки данных, а не на повседневных нуждах.
Федеративная
Эта модель релевантна, когда в компании есть растущий спрос на аналитиков. В ней используется своего рода «спецназ» — аналитическая группа, работающая из центральной точки и решающая сложные кроссфункциональные задачи. Остальные дата-саентисты распределены как в модели Center of Excellence. По сути, федеративная модель сочетает в себе подходы к координации и децентрализации модели CoE, однако с сохранением «передового» отдела.
Федеративную модель лучше всего использовать компаниям, в которых аналитические процессы и задачи имеют систематическую природу и требуют ежедневных обновлений. Такой подход может служить и для целей корпоративного уровня, например, корпоративного дизайна дэшборда, и для аналитики конкретной функции с различными типами моделирования.
На первый взгляд, федеративная модель идеальна, однако имеет некоторые недостатки.
- Затраты на найм и удержание сотрудников. Так как эта модель подразумевает наличие отдельного специалиста для каждой продуктовой команды и центрального управления данными, она может быть дорогостоящей. Следовательно, в своём чистом виде такой подход не является идеальным для компаний, находящихся на ранних этапах внедрения аналитики.
- Кроссфункциональность может создать конфликтную среду. В ней может недоставать равенства власти между всеми руководителями команд, что может приводить к отставанию от дедлайнов и к сомнительным результатам из-за постоянных конфликтов между руководителями команд подразделений и руководством CoE.
Демократическая
Эта модель — ещё один способ восприятия культуры работы с данными. При демократической модели все в организации имеют доступ к данным при помощи инструментов BI или порталов данных. Это означает, что её можно комбинировать с любой другой описанной выше моделью. Можно использовать федеративный подход с CoE и специалистами по аналитике в каждом подразделении, и в то же время сделать инструменты BI доступными для каждого, кто заинтересован в использовании данных для своих задач, что отлично с точки зрения освоения культуры работы с данными.
Члены продуктовых команд, например, менеджеры продуктов и разработки, дизайнеры и инженеры получают доступ к данным напрямую, без привлечения дата-саентистов.
Каковы же недостатки?
- Компания, интегрирующая такую модель, обычно много инвестирует в инфраструктуру data science, инструментарий и обучение.
- Вам просто нужно больше людей, чтобы избегать ситуаций, когда дата-инженер занят настройкой дэшборда BI для другого торгового представителя вместо того, чтобы заниматься своей работой по дата-инжинирингу.
Помните о том, что ваша модель может меняться и эволюционировать в зависимости от потребностей бизнеса: сегодня вам может быть достаточно дата-саентистов, находящихся в своих функциональных подразделениях, а завтра необходимостью становится Center of Excellence.
Дополнительные рекомендации по построению высокопроизводительной команды data science
Ищите таланты внутри компании. Ещё до того, как начинать задумываться о найме на роли data science специалистов извне, оцените ресурсы, уже имеющиеся в компании. Узнайте, есть ли у вас сотрудники, желающие двигаться в этом направлении. Определите их навыки в data science, пробелы, которые нужно закрыть, и вложитесь в их обучение.
Меньше нанимайте людей на каждую должность, сосредоточьтесь на понимании того, какие роли может выполнять один специалист по данным. В стартапах и малых организациях обязанности могут и не быть чётко очерчены.
Взращивайте кроссфункциональные связи. Дизайнеры, маркетологи, менеджеры продуктов и инженеры должны тесно сотрудничать с командой DS.
Практикуйте встраивание. Как говорилось выше, для рекрутинга и удержания специалиста по data science требуются дополнительные действия. Одно из них — это встраивание, перевод дата-саентистов в бизнес-подразделения, чтобы они выполняли централизованную отчётность, лучше взаимодействовали и ощущали себя частью большой организации. Здесь подходят федеративная, CoE или даже децентрализованная модели.
Перед наймом команды создайте командную среду. Это значит, что менеджеры продуктов должны осознавать различия между ПО и результатами обработки данных, иметь адекватные ожидания и понимать, в чём отличия в отчётной документации и дедлайнах. Менеджеры продуктов должны иметь достаточно технических знаний для понимания этой специфики. Или же вы можете начать искать дата-саентистов, которые сразу же могут занять эту должность.
Самое важное, что нужно знать
Если вы спросите специалистов по data science из нашей компании о текущем состоянии AI/ML в разных отраслях, то они, скорее всего, скажут о двух основных проблемах: 1. Руководителей бизнеса всё ещё нужно убеждать, что разумное ROI для вложений в ML существует. 2. Если они знают это и понимают возможные выгоды и запросы рынка, то у них может недоставать технических навыков и ресурсов для реализации продуктов.
Эти барьеры в основном возникают из-за уровня цифровой культуры в организациях. Эффективные процессы работы с данными вынуждают высшее руководство осваивать горизонтальные способы принятия решений. Руководители с доступом к аналитике будут иметь больше независимости в принятии решений на основании данных, в то время как высшее руководство будет контролировать стратегию. Это снижает трудозатраты на управление и устраняет риски принятия «инстинктивных» решений. По сути, смена культурной парадигмы определяет конечный успех data-driven-бизнеса. Как пишет McKinsey, создать культуру сложнее всего, а с остальным можно справиться.
Понравилась статья? Еще больше информации на тему данных, AI, ML, LLM вы можете найти в моем Telegram канале “Роман с данными”
- Как подготовиться к сбору данных, чтобы не провалиться в процессе?
- Как работать с синтетическими данными в 2024 году?
- В чем специфика работы с ML проектами? И какие бенчмарки сравнения LLM есть на российском рынке?
Обо всем этом читайте в “Роман с данными”