Построение 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 как материалы на сегодняшний день мы используем:

• Coursera Class: Machine Learning by Andrew Ng,
• Coursera Class: Neural Networks for Machine Learning by Geoffrey Hinton,
• Stanford Engineering Everywhere: Machine Learning,
• Stanford CS229 Machine Learning — Lecture Notes and Handouts,
• Stanford Unsupervised Feature Learning and Deep Learning Tutorial,
• Udacity Class: Deep Learning

Точно такую же разбивку и ссылки на материалы имеет каждая 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, один в поле — все еще воин. И по нашему опыту — самый эффективный.