Python applications, ASGI, Kopf, testing of Elasticsearch на Python fwdays'20 | Online

Балада про ресурc-менеджмент або чому Data Scientist робить все

Працюючи кілька років інженером-геодезистом і зрозумівши, що не отримую ніякого професійного росту, я вирішив рухатись в іншому напрямку. Обрав ІТ, адже в Україні галузь дуже розвивається а особливо аутсорс/аутстаф спрямування.

Така тенденція росту тримається ще з 2000-х. І на мою думку, це буде продовжуватись ще як мінімум років 20-ть. А щодо аутстафу і аутсорсу, це основні два підходи до ведення бізнесу з закордонними замовниками. У першому випадку, в аутстаф наймають людину (ресурс), а в другому — купують послуги компанії. Є також ще два види компаній, це продукт та стартап, але про них зовсім інша розмова. У більшості кожна компанія починає як аутстаф/аутсорс і кожна після певного етапу хоче перерости в продуктову, відкривають свої відділи R&D і створювати свої продукти.

Оскільки ріст доволі стрімкий, молоді компанії дуже швидко переростають в доволі великі, за рік можуть вирости вдвічі, тричі. З таким стрімким розвитком ринок ІТ-спеціалістів — як гарячі булочки в пекарні. І це в результаті призводить до дуже багатьох проблем.

З таким напливом попиту і малою пропозицією мало хто починає розбиратись — хто і що повинен робити, які обов’язки має специфічна роль (посада). Якщо іншими словами, ніхто не має посадової інструкції, де чітко описані обов’язки або просто ніхто не знає, що така повинна існувати. Навіть якщо ви переглянете опис вакансій на іноземних ресурсах, вони всі різняться. Але в Україні це найбільше стосується малих та середніх компаній, або компаній, які дуже швидко ростуть. Виокремимо проблематику і назвемо — «ресурсний хаос».

Наступна доволі цікава проблема (чи то перевага) — це наш менталітет. У процентній більшості ми відчуваємо відповідальність за роботу, яку ми робимо, і доволі часто на підставі цього закордонні компанії люблять з нами працювати, але це не означає, що це добре, ми з вами беремо забагато на свої плечі, а в результаті не отримуємо нічого, окрім задоволення власного его хорошо професіонала. Доволі часто зариваємось в обов’язки, які не належать нам, і менеджерська ланка про це не говорить, щоб ми зупинили витрачати власний ментальний ресурс на обдумування речей, що нас не стосується. Це можна назвати «генетичний трудоголізм».

Окремо ці дві проблеми не дуже критичні, але в цілому — це просто вибухова суміш.

Надзвичайно поширений приклад цього — коли замовник пише у завданні щось схоже на «зробіть чудо та приправте перченою особливістю». Ви як простий розробник беретесь до вияснення вимог. Що призводить до зменшення продуктивності розробника та часом цілої команди. Треба зрозуміти, що для будь-якого бізнесу важливі терміни, чи то терміни розробки цілого продукту, чи то фічі (специфічного функціоналу). Тому що в кінцевому результаті інвестори будуть питати, де результат інвестицій. Або ж заплановані витрати на квартал не буде збігатись з реальними, що в результаті може призвести до втрати клієнта або навіть банкрутства клієнта (але я не знаю таких випадків). Насправді, створенням вимог повинен займатись бізнес-аналітик разом з власником продукту (Product owner) або відповідальною за продукт людиною, яка, по суті, розуміє, які повинні бути бізнес-процеси за продуктом.

Також «ресурсний хаос» може призвести до необдуманих витрат зі сторони замовника. Часто замовники не бачать цього, тому що самі дуже далекі від розуміння, які позиції, ролі їм потрібні. Одним із явних прикладів — це найняти для аналізу даних в базі з 10 таблиць, Data Scientist’а. Сама роль по собі дуже витратна для компанії, набагато простіше і дешевше найняти Data Analytyc’а або Statistician.

Але все ж давайте розглянемо більш детальний приклад. Уявіть собі: ви починаєте молодою командою аутстаф-проект, тобто вашу команду взяли для допомоги в якомусь проекті. У подальшому ваші навички і організація роботи замовнику більше подобаються, ніж стаф, який знаходиться на їхній стороні, і він вирішив вам передати велику кількість обов’язків, так би мовити, дав вам змогу вирішувати майже всі технічні аспекти проекту.

Ваша команда складається з PM (Project Manager), BE (Back-end Developer), FE (Front-end Developer), SM (Scrum Master), QA (Quality Assurance specialist). Після першої версії продукту вам необхідно зібрати дані та провести їх аналіз для визначення подальшого вектору розробки наступних версій. Доволі часто першого, кого шукають з такими обов’язками, це дата сайентиста. А чи правильно це? Чи це таку людину необхідно для вирішення цього сету завдань? Можливо, вам потрібно тільки UX Research Engineer?

Насправді, все залежить від складності цих завдань та термінів на їх виконання. Позиція Data Scientist доволі обширна, але основні обов’язки — це створення моделей машинного навчання, використання статистичних підходів для вирішення доволі великого спектру проблем в аналізі даних, визначення якості даних та передбачень поведінки різного роду об’єктів, визначення трендів. Data Scientist — це людина, яка з математикою та статистикою на «ти». Зазвичай, компанії використовують Data Scientist як універсального солдата, оскільки він в соло може зробити щось чудесне та фантасмагоричне. Питання якості чи надійності процесів мало кого, зазвичай, цікавить. Але ви уявіть, що зараз коїться на ринку, уявіть скільки всього повинен знати дата сайентист. По суті, зараз попит на специфічний сет скілів у Data Scientist і формує цю позицію.

Давайте подивимось з висоти пташиного польоту, що може робити Data Scientist і як він пересікається з іншими ролями.

Роль Data Scientist часто об’єднює деякі обов’язки інших ролей, таких як BI (Business Intelligence), BA (Business Analyst), DE (Data Engineer), ML Engineer (Machine Learning Engineer), ML Scientist (Machine Learning Scientist).

  1. Створення ETL-пайпів (Extract Transform Load Automated process, автоматизований процес витягування, трансформування та загрузки даних в спецефічне середовище). Доволі часто під час цього процесу очищують дані.
  2. Моделювання/Дизайн середовища зберігання даних.
  3. Бізнес Аналітика що включає в собі аналітика бізнес процесів та створення на підставі цього аналізу вимоги до калькуляцій метрик чи закономірності відображення (візуалізації даних).
  4. Інтеграція даних в специфічну модель збереження даних. Часто під час інтеграції даних їх збагачують даними з різних джерел щоб створити єдине правдиве джерело інформації.
  5. Використання існуючих моделей машинного навчання для різного роду передбачень або ж класифікацій або ж рекомендацій. В інтернеті дуже багато прикладів створення, наприклад, машинної моделі для рекомендації продукту, що в свою чергу збільшує прибуток компанії в рази.
  6. Моделювання машинних алгоритмів для вирішення не тривільних завдань. Часто таких людей наймають при роботі з неструктурованими даними (зображення, звуки, простий текст) для розпізнавання об’єктів на картинці, накладання фільтрів на знімок, розпізнавання голосу або речень на звуковому записі, розпізнавання настрою написаного або ж синтезація відповіді (NLP).
  7. Візуалізація даних. Часто цю візуалізацію роблять в певному середовищі, наприклад Tableau, QlikSense.
  8. Створення звітності.
  9. Аналіз якості даних та проробленої аналітики.

Повернемось до термінів і складності завдань. Якщо терміни короткі і завдання по своїй суті складні, одного Data Scientist для повного дизайну та імплементації аналітики недостатньо. Перше, це через те, що створення ETL-пайплайнів і трансформації даних, або як сьогодні модно казати «Data Wrangling» дуже часозатратно, також багато підходів і середовищ, де працювати та деплоїти пайплайни. По суті, Data Scientist може зробити аналітику швидко, бо він знає, як це робити, ну принаймні повинен, але він зазвичай не знає як написати, задеплоїти «ETL Pipeline», що нормально, бо цим насправді займаються Data Engeneer. Так у світі повелося, що близько 80 % часу — це підготовка даних для аналітики.

А тепер розглянемо великий проект і що зазвичай роблять ІТ-компанії або ресурс менеджмент. У вас дуже багато даних в Data Warehouse і замовник хоче «гарні репорти» з розсилкою на імейли, передбачати поведінку юзерів або створити розумну рекомендацію продукції. Так от, компанії наймають двох, чотирьох Data Scientist і дають їм цю роботу. І це є проблемою зазвичай, так як їм доводиться дуже швидко вчитись працювати з BI-інструментом або писати щось кастомне з купою багів також робити аналітику бізнес потреб для кращого представлення даних. І зазвичай розробка іде повільно та стресово, особливо, якщо проектування і наповнення даними Data Warehouse також віддали їм. Ідеальний випадок, коли ресурс-менеджмент знає кого необхідно, наймає BI-щика (який створює шаблони запитів у базу даних), Visualization Engineer (який знає, як краще представити дані візуально і може доволі швидко написати замість фронта візуалізацію даних), BA (який готує технічні вимоги до завдань і аналізує кінцевий результат), ML Engineer (який, по суті, створює моделі машинного навчання для передбаченнь поведінок будь-чого, або рекомендаційну модель, щоб дані були).

Також при такому формуванні команди, команда виходить дешевша, оскільки кожна позиція доволі вузькоспеціалізована і поріг входження в процеси, які відбуваються на проекті, також малі.

Насправді, позицій/ролей в ІТ-сфері є дуже багато, але мало хто про них всіх знає. Також додам: всі ролі можна уявити як дерево, тобто є більш абстрактні ролі, які можуть робити майже все, і є більш специфічні ролі, які можуть перейняти обов’язки в більш абстрактних (загальних) ролей. Часом компанії придумують свої ролі/позиції, що на мою думку є безглуздим, часто таке відбувається через непрофесіоналізм управлінської ланки.

Для того, щоб уникнути зайвих витрат компанії, збільшити продуктивність команди без вигорання і стресу, ресурс-менеджмент та рекрутери повинні знати, кого необхідно брати на проект та яку людину необхідно шукати, базуючи свій пошук на сеті скілів, а не на назвах ролей, які мала людина за час роботи в IT-сфері. Якщо ресурс-менеджмент цього не знає, то повинні бути люди в компанії, які пояснять, яка різниця між Data Scientist та Data Engeneer.

Маленький приклад формування команд:

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как только наш украинский ДС может использнять роль БА он становится Quant (с большой буквы) — самостоятельная боевая единица. Зверь редкий и на галерах почти не встречается. А то что в 99% случаев исполняют наши ДС в части требований лучше «забыть и не пущать» — такая хрень начинается, что весь проект по черте. Работаю с финансами поэтому квант, думаю в других областях есть свои названия

Насколько я знаю Quant бывают двух типов — Quant рисерчер, это как раз тот кто занимается рисерчем и создает мат модели, и Quant девелопер который берет разработки рисерчера и переносит из R и MathLab Python или что там рисерчер заюзал и уже на (обычно)плюсы в продакшен.

Но как всегда в каждой компании все немного по своему.

Если я не прав, то поправь, лично мне будет интересно.

«ПисАть как и пИсать нужно тогда, когда терпеть уже невозможно!» — М.Ж.

«Что это и для кого это?» © не статья, а набор предложений (буквострим))) ни воддной части (что это, для кого) ни внятной структуры, просто «смотрите какой я умный» )))

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

Но да, любой может изобрести собственную онтологию )) если шило жить мешает

*подача текста определила отношение

Дуже крута критика, дякую!

Я уж думал, что тут будет про бизнес анализ для задач датасаенса. А тут какие карточки.
На этих карточках не хватает картинок и правил и можно было бы карты играть.

Погоджуюсь погано приклад подав, не врахував методологію розробки під конфігурацію команд, зробив граматичні помилки, як для першої статті, доволі грубо. Пізніше перепишу з бізнес аналізом і кращими прикладами. Дякую що підкреслили зацікавленість в бізнес аналізі завдань дата саентиста.

А в статье у тебя про бизнес анализ, про анализ требований и подобное ни слова. Но может среди этих разноцветных карточек я и не нашел тщательно спрятанного.

Дякую що підкреслили зацікавленість в бізнес аналізі завдань дата саентиста.

А в от с этим в постсовке полная жопа и не только в датасаенсе, но и почти во всех других областях.

«Дата саентист» робить не все, а інфографіку. Вважаючи що все інше робиться як два пальця об асфальт, головне намалювати.

Іди в Соросята, там таких люблять.

Ви щось плутаєте, або у вас не тих найняли

Іди в Соросята, там таких люблять.

Колись були «Соросівські олімпіади для школярів», романтика!

“Scram Master” пишется как “Scrum Master”

Пізніше відредагую ;)

Почав писати комент, а потім побачив твій.

не увидел твоего комента прежде чем написать тоже самое

Конфигурирование структур команд на большом проекте без учёта конкретной методологии разработки, которую выбрали — дурь и блажь

Дякую що вказали на «Дурь и Блажь». Наступного разу виправлюсь!

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