Побудова 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, один в полі — воїн. І з нашого досвіду — найбільш ефективний.

Опубліковано: 24/04/17 @ 10:00
Розділ Різне

SEO Блог