tgoop.com/asisakov_channel/1005
Last Update:
Могут ли аналитики-разработчики закрывать все DS задачи?
Если вы помните мой недавний пост про analytics-first или development-first датасаентистов, то я там упоминал достаточно полярные роли - либо мы сильно упарываемся в аналитику и общение с бизнесом, либо мы сильно погружаемся в сторону разработки и выкатки моделей в прод.
На самом деле, в командах это выглядит более размыто - то есть скорее относится к нотации T-shaped специалистов. Если команда работает в своих проектах end-to-end, то скорее вы не увидите там аналитика, который даже там регулярный расчет SQL-скриптов в прод выкатить не сможет, так же как и нет только разработчиков, которые не смогут провести легкую аналитику или не поговорят с бизнесом. Все это скорее подразумевает такой подход, где у всех есть определенная база и пара очень сильно вкачанных веток развития скиллов.
Почему это работает именно в таком виде?
Потому что направление работы сильно зависит от зрелости продукта:
Бизнес только задачу. И продукт-менеджер (Product Owner) вместе с аналитиком-разработчиком формулируют гипотезу и определяют метрики. Здесь важно понять, какую проблему будет решать продукт/фича или моделька и сразу понять что и зачем делать
Допустим, аналитик-разработчик проводит EDA, собирает MVP модели в ноутбуке, чекает гипотезу. Самое главное - это быстрые итерации и вообще похер какой код (главное, чтобы работало и воспроизводилось). Нам нужно быстро доказать или опровергнуть ценность идеи с минимальными затратами
Если наш MVP показал необходимый результат, то его надо выводить в прод - короче сделать решение автоматизируемым. И здесь уже нужна другая вкачанная ветка нашего аналитика-разработчика, чтобы этот самый код переписать нормально, с пониманием архитектуры, масштабируемости. Приправить это логированием, тестированием и при необходимости интегрировать с другими сервисами. Самое простое - обернуть модель в API, поднять несколько под или Docker-контейнер, ну и настроить CI/CD, просто чтобы решение работало надежно, стабильно и эффективно
После выкатки аналитик-разработчик (в дэшах, сделанных им же) следит не только за бизнес-метриками и считает эффекты от модели и влияние на бизнес, а также чекает технические моменты: время ответа, нагрузка. Дополнительно к этому проводятся итеративные улучшения от обратной связи коллег или работы с краевыми кейсами
Сколько ролей мы здесь насчитали?
Как минимум аналитик, разработчик, mlops
Распределив роли, мы можем не заставлять аналитика писать идеальный код, а разработчика часами копаться в сырых данных. Каждый занимается тем, в чем он наиболее силен. Но аналитик-разработчик занимается всем
Достаточно ли аналитика-разработчика для решения всех DS проблем?
Нет
Потому что есть тот, кто не строит ML-модели и не пишет бэкенд. Но этот специалист и пишет много кода, и работает с данными. Вы наверно уже догадались, что это Data Engineer - и его суть превращать сырые данные из хранилищ в чистые и понятные витрины, на которых уже будут работать аналитики. По сути, аналитик-разработчик без этого не сможет делать свою работу. И кстати вкачать эту ветку развития будет довольно не быстро (попробуйте например заботать HDFS и Spark).
К чему я веду
К тому, что узкие специализации в больших командах позволяют каждому работать в своей области более эффективно, чем несколько многоруких-многоногов над разными проектами. И вместо споров о важности аналитиков-разработчиков или разработчиков-аналитиков можно подумать в сторону кросс-функциональных команд для создания постоянной ценности.
Проблема не в том, чтобы найти "многорукого многонога" или заплатить две ставки. Проблема в том, чтобы выстроить процесс и собрать команду, где каждый специалист максимально эффективен на своем этапе. И тогда вы платите не "за две ставки"
👍Лайки - за аналитиков-разработчиков
❤🔥Сердечки - за разработчиков-аналитиков
🔥Огонечки - за дата-инженеров (ну и mlops пусть будет сюда же)
#career