×Закрыть

Построение Data Science команды в аутсорсинговой компании

Data science — достаточно молодая сфера как в мире, так и в Украине. Первые data science центры компетенции появились в наших аутсорсинговых компаниях около четырех лет назад, а оформить эту компетенцию в виде бизнеса и поставить «на рельсы» service line и до сегодня удалось очень немногим.

В этой статье я расскажу о том, как мы строим Data Science Office в ELEKS, почему это работает, какие проблемы мы видим и как их решаем. Сегодня в ELEKS DSO работает 17 человек. По моей информации, это один из двух самых больших центров machine learning компетенции в Украине и самая большая data science группа в стране. И мы продолжаем искать людей.

Война определений

Пока направление было молодо и все украинские data scientists знали друг друга в лицо, контроверсии в отношении определения почти не было: мы честно говорили, что никто из нас не знает, что такое data science, и что самая важная наша задача — выяснить это. Сегодня, когда хайп вокруг data science, machine learning и artificial intelligence не обошел, кажется, никого из ИТ, звучат очень разные мнения о том, что же все-таки такое, этот data science. Инженеры видят в этом что-то одно, украинское академическое сообщество, которое недавно присоединилось к «гонке», — что-то другое, практикующие data scientists — третье.

Скажем, есть мнение, что data science — то же самое, что статистика, которой отделы статистики занимались десятилетиями.

Есть мнение, что data science — это про Big Data платформы и инструменты.

Есть — что это то же самое, что machine learning research, и главная его задача — придумать новый алгоритм или решить ML задачу наиболее элегантным способом.

Есть — что data science — это как соревнования на Kaggle, и главная задача — выжать из данных как можно больше процентов точности.

Есть (этой точки зрения придерживаются некоторые представители локального академического сообщества) — что data science — это вообще про сугубо исследовательскую деятельность.

Каждое из этих определений порождает соответствующий образ data scientist’а. Что он должен знать и уметь: статистику, machine learning и deep learning, big data, кодинг, архитектуру, управление проектами, DevOps, общение с заказчиком, все из этого или ничего из перечисленного? Периодически на конференциях и митапах вспыхивают горячие споры о том, кто более прав.

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

С этой точки зрения самое правильное определение data science может дать только одна группа людей, которую часто упускают из виду, — наши заказчики. Мы экспериментируем с моделями, сервисами, подходами и смотрим, что у нас получается. Если нам удается находить проекты, если удается их успешно выполнять, если заказчик доволен результатом — это правильный data science. Если нет — наверное, не очень правильный.

Команда... Команда?

При старте data science направления в типичной аутсорсинговой компании первый порыв — встроить его в существующую систему компетенций и проектной работы, наряду, например, с разработчиками определенного профиля. Иными словами, включить в список инженеров дополнительную категорию: data science, не меняя подход к формированию проектных команд. В стандартной проектной команде есть роли проектного менеджера (планирование, координация), бизнес-аналитика (коммуникация с заказчиком, требования), инженера (имплементация) и тестировщика (контроль качества). Теперь среди специализаций инженера добавляется data science.

Однако, чаще всего такая модель не выдерживает испытания на прочность. Если бизнес-аналитик не имеет квалификации в data science, DS модели могут выглядеть для него черной магией, а задача, решение которой простое и очевидное, — точно такой же, как задача, решения которой на сегодняшний день вообще не существует. Это приводит к проблемам в коммуникации с командой и формированию неверных ожиданий у заказчика.
Дальше: если data scientist разрабатывает только алгоритм, а сам продукт пишет инженер, возникают сложности коммуникации и кооперации. Во всех без исключения случаях из моей личной практики и практики ELEKS, если модель таки приходилось переписывать инженеру (скажем, для работы на мобильной платформе), это заканчивалось проблемами и выяснением, кто виноват в том, что финальная система работает не так точно, как прототип data scientist’а, не так быстро, не для всех случаев и так далее.

Кроме того, аналитические модели устаревают со временем — меняется бизнес клиента, меняются данные, меняются паттерны. Кто будет поддерживать модель? Data scientist? Он не умеет писать production код. Инженер? Он уже давно работает на другом проекте. Другой инженер? Ему нужно заново разбираться в продукте и модели...

Формат data science команды, на котором мы в итоге остановились, как бы парадоксально это ни звучало на первый взгляд, — отсутствие команды как таковой. Data science stream на проекте обычно ведет один человек — data scientist. Он лично ведет коммуникацию с заказчиком, занимается моделированием и продуктизацией модели до уровня компонента, который могут использовать другие инженеры без каких-либо знаний в data science вообще.

Здесь мы можем немного отвлечься от data science и вспомнить, что и в software development узкая специализация и разделение труда появилось далеко не сразу. В начале своей истории software engineers отвечали и за выявление требований, и за моделирование систем, и за имплементацию, и за тестирование. Привычный для нас формат команды появился, когда проекты начали становиться все более объемными и комплексными.

Мы пришли к такому формату работы методом проб и ценой некоторого числа ошибок, и были удивлены, когда столкнулись в работе с Pivotal Labs и McKinsey. Оказалось, что они используют для data science проектов такой же формат работы и схожую модель компетенции. Похоже, на сегодняшний день метод проб и ошибок в создании data science services приводит к одному ответу, откуда бы вы ни начали дорогу :-)

Модель компетенции

Такой одиночный формат проектной работы требует комбинации довольно специфических компетенций. Вот так, например, выглядит job profile для junior, intermediate и senior data scientist в ELEKS.

Навыки, которыми должен владеть data scientist, мы разделяем на три блока: Business, Logic и Technology.

  • Блок Business — навыки общения с заказчиком, выявления требований, формирования видения решения.
  • Блок Logic — основная «рабочая лошадка» data science: статистика, машинное обучение, искусственный интеллект.
  • Блок Technology — навыки, необходимые для имплементации модели в виде законченного компонента. В качестве компонента мы, как правило, делаем microservice с RESTful интерфейсами, «заворачиваем» его в Docker контейнер и в таком виде отдаем заказчику.

Каждая из knowledge area, в свою очередь, разбивается на knowledge items, которые относятся к какому-то из уровней: qualified, competent и expert. Например, вот так выглядит machine learning:

Каждый knowledge item содержит ссылки на материалы, где о нем можно почитать. Скажем, для machine learning как материалы на сегодняшний день мы используем:

и другие открытые ресурсы. Каждая ссылка рядом с knowledge ведет на какой-то раздел или лекцию.


Точно такую же разбивку и ссылки на материалы имеет каждая knowledge area. Вы можете скачать нашу модель компетенции в полном, хоть и неудобном, виде по этой ссылке. Заранее прошу прощения за формат — Confluence позволяет экспортировать только в таком виде.

Как это работает

Иллюстрацией работы такой модели может быть история создания ProjectHealth. Это был первый проект одной из наших junior data scientists. Постановка задачи выглядела так: «CTO хочет видеть, как обстоят дела на каждом из проектов компании. Каждый день. В ELEKS сейчас более 100 проектов, 30+ проектных менеджеров. Вот отделы компании и их руководители. Вот Project Management Office. Вот Head of PMO. Выясни, как должен выглядеть продукт и реализуй его».

Data scientist работала над проектом самостоятельно. За время работы над проектом она:

  • собрала требования к продукту, сформировала видение решения и утвердила его со всеми заинтересованными сторонами;
  • выяснила, какие данные, в каком виде и в каком качестве имеются в компании, получила к ним доступ;
  • создала на основе Bayesian network аналитическую модель, согласовала ее результаты со всеми заинтересованными сторонами;
  • спроектировала базу данных для хранения агрегации данных, промежуточных и финальных результатов анализа;
  • имплементировала на Bayesian network на Python;
  • имплементировала коннекторы ко внешним системам для получения данных: 1C, Jira, Confluence, CRM, ERP, GitLab;
  • имплементировала microservice и API с помощью Flask;
  • подключение к базе данных с результатами аналитики BI dashboard, сконфигурировала дашборды и доступ к ним;
  • «завернула» каждый компонент в Docker контейнер и развернула систему на виртуальной машине.

В лучших традициях lean approach, фокус проекта был не на качестве кода и масштабируемости архитектуры, а на time to market. Через четыре месяца первая версия продукта была готова, выведена в production и начала приносить пользу компании. СТО, Head of PMO и два деливери директора стали первыми его пользователями.

Один в поле — воин

Описанный подход и модель компетенции позволяет нам эффективно управлять ресурсами, формировать value proposition, избегать большого числа проблем в коммуникации, внедрять и поддерживать data science продукты, компоненты и модели. Конечно, в комплекте с большой свободой, которую data scientist получает в такой модели, идет и большая ответственность. Но, по крайней мере на сегодняшний день и по крайней мене в data science, один в поле — все еще воин. И по нашему опыту — самый эффективный.

45 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Ви перша компанія, яка повністю розшарила модель компетенцій! Так тримати!

Data scientist? Он не умеет писать production код.
З мого досвіду, буває по-різному.

Про программистов можно тоже сказать. Зависит от конкретного человека, организации труда.

Отличная статья, спасибо! А заказчики у вас кто — западные фирмы, или наши тоже заказывают? Вообще, было бы интересно прочитать success-story из области data science.

США и Европа в основном, как обычно.

А как заказчики вообще узнают, что вы им можете помочь? Ведь для этого надо уже быть немного data scientist’ом — быть в курсе machine learning, понимать его круг задач и его ограничения.

Мы не ожидаем, что заказчик будет понимать наш язык и нашу специфику. Мы считаем, что это задача дата сайнтиста — объяснить заказчику на его языке, какую пользу ему может принести аналитика. Business Area в модели компетенции — как раз об этом.

Гарна стаття, дякую.
Таке питання: як і коли людина звіряється з моделлю компетенцій? Зрозуміло, що перший раз на інтерв’ю, а як далі?

Ми говоримо про ці скілли на performance appraisals і плануємо розвиток людей, відповідно до них.

Задам один «неудобный» вопрос, который всегда стоит перед любым Head of ..... Office, хоть Data Science, хоть «обычной» разработки. При описанной Вами модели разработки завтра Ваша чудо-девушка уволиться, уйдет в декрет, пойдет продолжать учебу, и т.д. Что будет с описанной системой? Кто и как сможет ее поддержать?А развивать? Насколько эффективно? И насколько затратно?

У нас есть процесс knowledge transfer на этот случай.

Спасибо за статью, очень интересно. Вы крутые, удачи вам! :)

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

Спасибо большое за статью.
Было бы интересно почитать, как у вас выглядит value prop вокруг этой команды. Внутренние проекты — это хорошо, но продавать data science клиентам, — другое дело.
Мы сталкивались с тем, что клиенты хотят сохранить построение моделей или предикшены на их основе in-house ,поэтому аутсорсят неохотно.
Плюс, многие клиенты не готовы сотрудничать ,если нет солидного портфолио data science проектов именно в их индустрии (независимо от того, насколько развиты технические компетенции).
Уверен, вам эти проблемы тоже знакомы. Было бы интересно узнать ваш подход к их решению

Модель компетенции
Как модель не называй — все равно... — впрочем это другая история.
Из всего выше перечитанного так и не нашел, Какие ключевые цели позиционирует
data science
? На вопрос Как это работает, скажу сразу это не важно. Если команда не разделяет цели, либо таковых не имеет, рано ли поздно такие команды распадаются на атомы и выдумывают уже свои модели.

Где то я видел подобную модель компетенции. Предположу что ее «унаследовали» частично.

Data scientist работала над проектом самостоятельно. За время работы над проектом она:
собрала требования к продукту, сформировала видение решения и утвердила его со всеми заинтересованными сторонами;
выяснила, какие данные, в каком виде и в каком качестве имеются в компании, получила к ним доступ;
создала на основе Bayesian network аналитическую модель, согласовала ее результаты со всеми заинтересованными сторонами;
спроектировала базу данных для хранения агрегации данных, промежуточных и финальных результатов анализа;
имплементировала на Bayesian network на Python;
имплементировала коннекторы ко внешним системам для получения данных: 1C, Jira, Confluence, CRM, ERP, GitLab;
имплементировала microservice и API с помощью Flask;
подключение к базе данных с результатами аналитики BI dashboard, сконфигурировала дашборды и доступ к ним;
«завернула» каждый компонент в Docker контейнер и развернула систему на виртуальной машине.
Удивительно талантливая девушка. Советую удерживать ее всеми доступными методами (как минимум зп на уровне синьор девелопера), иначе ее в другой компании с руками и ногами оторвут на $4000-5000.

IMHO

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

создала на основе Bayesian network аналитическую модель, согласовала ее результаты со всеми заинтересованными сторонами;
и
имплементировала на Bayesian network на Python;
Как раз уровня джуна.
Все остальное это фулстак-орерфлоу девелопмент.

Не поймите меня неправильно. Девочка действительно молодец. И я ее как никто другой понимаю. Потому что когда ты сам работаешь над каким-то проектом с нуля, то приходится быстро учится. В результате ты и бутстрап освоишь, и джс, и фласк, и постгрес, и монго, и девопс,и докер и все-все-все. И это помимо МЛ тулов. Но, с другой стороны, на сам дата саенс остается мало времени.
Это тот самый случай когда количество (скилов) преобладает над качеством.
Это отличный опыт, но определенно not best practice.

Вот как раз об этом был написан раздел «Война определений».

Я видел, и как я сказал выше, это отличный опыт на 1-2 раза, каждый должен через такое пройти, но это точно не лучший подход. И вы это должны прекрасно понимать. Хорошо когда Data Scientist понимает архитектуру проекта в реальном временими и адаптирует модель под нее. Но не более. Мухи отдельно, котлеты отдельно.
З.Ы
цитата из вики:
Data science, also known as data-driven science, is an interdisciplinary field about scientific methods, processes and systems to extract knowledge or insights from data in various forms, either structured or unstructured

Поэтому если это Data Scientist, то оставьте ему задачи по анализу данных и построению модели. Пускай еще доступ к базе, что б сам экстрактил что ему надо.
А остальное, пожалуйста, другим членам команды.
Иначе не стоит называть его Data Scientist, а лучше Fullstack and Data Engineer

Дима, вы читали статью? Там же обо всем этом было написано. Если вы лично строили дата сайнс отделы, коммерциализировали эту экспертизу, напишите об этом. Мне будет интересно посмотреть на ваш опыт этого пути.

Да, прочел. И к статье претензий нет. Да и к вам лично тем-более нет. И к содержанию статьи нет претензий. Даже больше, статья мне очень понравилась. Я б только добавил к вашему списку с курсами курс Statistical Learning от стенфорда.
Просто я озвучил свое мнение по поводу вашей модели

Один в поле — воин
И, как я выше указал, это мое имхо.
А мой опыт пока что, это опыт описанной выше вами девушки, почти 1 в 1. И скажу по своему опыту, что если б не участие в Kaggle, то по вашим метрикам я б проходил далеко не так уверенно.

Неувидел тут DataScience кроме
"

создала на основе Bayesian network аналитическую модель,
"
В целом обычный BI

См. «Война определений».

У нас такую работу делают BI девелоперы, а как Вам правильно уже сказали выше — Data Engineer.

Всю работу полностью, включая создание и верификацию моделей?

Я же указал
"

кроме
"
создала на основе Bayesian network аналитическую модель,
"

Ну, так в статье ж написано, почему в случае, когда predictive/prescriptive аналитика является центральным элементом продукта, «разделение труда», по нашему опыту, работает плохо. Вы статью-то читали?

Более чем обычно.
Если таковой принцип «не разделения» труда работает на ура то вашим инженерам можно хлопать стоя.
В чем удивление то ?

Лично мое удивление в споре, условно говоря, о вкусе устриц с человеком, который их не пробовал.

Уверены что мы знакомы ?

Підтверджую, що принцип нерозділення праці може працювати на ура. І часто зустрічається у малих за кількістю працівників компаніях.
Навіть я сам є прикладом такого ’універсального солдата’.

Чи кількість не шкодить якості? Компанія зробила так: у команді для кожної сфери компетенції — як мінімум одна людина з дуже хорошими знаннями і досвідом у ній. Щоденні зідзвони, розмови на кухні, code review, і тому зводиться до мінімуму, коли хтось не знає, як якусь задачу вирішити або вирішує її не зовсім правильно. Побічний ефект — можна за короткий час почати непогано орієнтуватися у тому, у чому раніше погано розбирався.

Як мотивувати і втримати? Думаю, підібрати людей, яким було б цікаво працювати на їхніх позиціях, не займатися мікроменеджментом і створити відчуття впливу на успіх продукту, ну і запропонувати таку зп, щоб рекрутерам було важко переманити.

Ну, чуваки, у вас реально хороший шанс взяти 10 тис грн від ДОУ за кращу ( і корисну!) статтю. Дякую!

Сложно поверить, что джуниор инженеры у вас и правда обладают всеми компетенциями из таблички :) Где вы их берете?

Там же, где и все остальные :-) В компетенции джуниоров нет ничего, что не входило бы в программу бакалавра CS.

Джуны — ладно... Где вы таких синьоров берёте? :)

До речі Сергій, раз згадали освіту- як Ви примудрились бакалавра в ЛСЕ зробити,працюючи паралельно?

В программу бакалавра много че входит, но возможно все кроется в деталях критериев qualified и competent.

Я кстати, задумался по поводу вашей фразы. Я заканчивал бакалаврат примата КПИ в 2006.
Магистерскую программу я бездарно пропустил работая на фултайм, а до конца бакалаврата еще более-менее помню.
Из вышеперечисленного были на хорошем, достаочном уровне матстатистика, параллельные вычисления, на довольно низком — реляционные БД. Системный анализ/моделирование — не знаю что вы сюда включаете, скорее нет, чем да, управление требованиями — нет.
Помню были некоторая информация по нейронным сетям, но никаких ML/AI алгоритмов не помню, чтобы их изучали. Во всяком случае недавно я все это изучал и ничего подобного в памяти из института не было.
Языки R и Python не было, Python кажется был на 5 или 6 курсе. Помню был матлаб, но не помню что мы в нем делали.
При этом у меня бакалаврский диплом был с отличием, но к вам бы я по требованиям точно не прошел бы.

Дякую, дуже цікаво!

Каждая ссылка рядом с knowledge ведет на какой-то раздел или лекцию
Чи є якийсь шанс отримати розшифровку цих посилань (на які саме лекції ведуть ті чи інші references)?

По лінку в статті можна завантажити повну модель компетенції з усіма посиланнями: goo.gl/EbhWGH

За що величезне дякую! Мабуть найцінніше в статті(хоча і сама по собі стаття непогана)

Подписаться на комментарии