#easy
Всем привет. Неделя была тяжёлой и наконец-то дошли руки до нового поста.
Сегодня поговорим о популярных Agile-фреймворках - SCRUM и Kanban, чтобы у вас уже полностью сложилась картина о популярных методологиях ведения проектов.
Начинаем)
SCRUM - наверное, самый популярный фреймворк для внедрения Agile. Как и Agile, SCRUM основан на итеративном подходе и предназначен для разработки сложных продуктов. Некоторые могут запутаться и задать вопрос: "Так а чем тогда отличается Agile от SCRUM?" Отвечаю: Agile - это набор принципов для ускорения разработки продукта через итеративный подход. SCRUM - это определённый свод правил, которые соответствуют принципам Agile. Т.е. можно сказать, что Agile - это философия, а SCRUM - практическая методология, которая этой философии следует. SCRUM - это Agile, но Agile - это не SCRUM:)
Надеюсь, хотя бы немного понятно.
Главные принципы SCRUM соответствуют принципам Agile. + ко всему этому добавляется фиксированный набор ролей, обязанностей в команде и наличие специфических мероприятий, характеризующих SCRUM. Про это немного ниже.
Преимущества SCRUM:
- больше "прозрачности" в проекте. Ежедневные stand-up митинги позволяют всегда держать руку на пульсе. Каждый член команды понимает, что было сделано или не сделано на проекте за предыдущий день и что предстоит сделать сегодня. Такой подход позволяет прогнозировать возможные проблемы и быстро предвосхищать потенциальные проблемы. Благодаря этому, разработка продукта существенно ускоряется;
- повышенная ответственность команды. В SCRUM нет project-менеджера, который будет говорить что делать команде разработки. Здесь упор делается на автономности и профессионализме специалистов, которые могут активно общаться между собой и помогать друг другу. За счёт этого быстрее находятся оптимальные решения на проекте;
- легко учесть изменения в продукте (как и в Agile);
- снижение затрат на разработку. За счёт постоянной коммуникации внутри команды и предвосхищения возможных проблем такой подход позволяет намного быстрее исправлять ошибки, когда это ещё не стоит больших денег.
Недостатки SCRUM:
- нет чётко зафиксированных сроков поставки продукта;
- необходимы высокая экспертиза команды и затраты на обучение;
- риск "неправильного" SCRUM-мастера. SCRUM-мастер - не project-менеджер. Он не должен указывать, что и как делать. Если он захочет взять контроль над командой, эффективность может существенно упасть;
- риск плохо определённых задач. Так как нельзя точно определить, каким будет конечный продукт, иногда очень сложно чётко определить задачи по внедрению различных фич. Здесь возникает риск замедления разработки.
Как происходит процесс разработки при использовании SCRUM:
Как я писал выше, в SCRUM-команде есть чётко определённые роли. Давайте разберём их.
1) Product Owner - как я уже писал в Agile, это человек, который на верхнем уровне понимает, для чего мы делаем продукт и каким он должен быть. Он несёт6 ответственность за общение со стейкхолдерами, формирование требований и пополнение бэклога.
2) Scrum Master - это своего рода тренер команды. Он несёт ответственность за продуктивность команды, за то, чтобы команда следовала SCRUM-процессу, за организацию митингов. Он также общается с владельцем продукта, чтобы обозначить, что всё готово к следующему спринту.
3) Scrum Team - команда, которая ответственна непосредственно за процесс разработки. Обычно она состоит из 5-7 человек и в ней нет жёстко определённых ролей типа "дизайнер", "разработчик", "тестировщик" и т.д. Каждый член команды должен обладать экспертизой во всех этих областях, и каждый может выполнять задачи разного рода.
Всем привет. Неделя была тяжёлой и наконец-то дошли руки до нового поста.
Сегодня поговорим о популярных Agile-фреймворках - SCRUM и Kanban, чтобы у вас уже полностью сложилась картина о популярных методологиях ведения проектов.
Начинаем)
SCRUM - наверное, самый популярный фреймворк для внедрения Agile. Как и Agile, SCRUM основан на итеративном подходе и предназначен для разработки сложных продуктов. Некоторые могут запутаться и задать вопрос: "Так а чем тогда отличается Agile от SCRUM?" Отвечаю: Agile - это набор принципов для ускорения разработки продукта через итеративный подход. SCRUM - это определённый свод правил, которые соответствуют принципам Agile. Т.е. можно сказать, что Agile - это философия, а SCRUM - практическая методология, которая этой философии следует. SCRUM - это Agile, но Agile - это не SCRUM:)
Надеюсь, хотя бы немного понятно.
Главные принципы SCRUM соответствуют принципам Agile. + ко всему этому добавляется фиксированный набор ролей, обязанностей в команде и наличие специфических мероприятий, характеризующих SCRUM. Про это немного ниже.
Преимущества SCRUM:
- больше "прозрачности" в проекте. Ежедневные stand-up митинги позволяют всегда держать руку на пульсе. Каждый член команды понимает, что было сделано или не сделано на проекте за предыдущий день и что предстоит сделать сегодня. Такой подход позволяет прогнозировать возможные проблемы и быстро предвосхищать потенциальные проблемы. Благодаря этому, разработка продукта существенно ускоряется;
- повышенная ответственность команды. В SCRUM нет project-менеджера, который будет говорить что делать команде разработки. Здесь упор делается на автономности и профессионализме специалистов, которые могут активно общаться между собой и помогать друг другу. За счёт этого быстрее находятся оптимальные решения на проекте;
- легко учесть изменения в продукте (как и в Agile);
- снижение затрат на разработку. За счёт постоянной коммуникации внутри команды и предвосхищения возможных проблем такой подход позволяет намного быстрее исправлять ошибки, когда это ещё не стоит больших денег.
Недостатки SCRUM:
- нет чётко зафиксированных сроков поставки продукта;
- необходимы высокая экспертиза команды и затраты на обучение;
- риск "неправильного" SCRUM-мастера. SCRUM-мастер - не project-менеджер. Он не должен указывать, что и как делать. Если он захочет взять контроль над командой, эффективность может существенно упасть;
- риск плохо определённых задач. Так как нельзя точно определить, каким будет конечный продукт, иногда очень сложно чётко определить задачи по внедрению различных фич. Здесь возникает риск замедления разработки.
Как происходит процесс разработки при использовании SCRUM:
Как я писал выше, в SCRUM-команде есть чётко определённые роли. Давайте разберём их.
1) Product Owner - как я уже писал в Agile, это человек, который на верхнем уровне понимает, для чего мы делаем продукт и каким он должен быть. Он несёт6 ответственность за общение со стейкхолдерами, формирование требований и пополнение бэклога.
2) Scrum Master - это своего рода тренер команды. Он несёт ответственность за продуктивность команды, за то, чтобы команда следовала SCRUM-процессу, за организацию митингов. Он также общается с владельцем продукта, чтобы обозначить, что всё готово к следующему спринту.
3) Scrum Team - команда, которая ответственна непосредственно за процесс разработки. Обычно она состоит из 5-7 человек и в ней нет жёстко определённых ролей типа "дизайнер", "разработчик", "тестировщик" и т.д. Каждый член команды должен обладать экспертизой во всех этих областях, и каждый может выполнять задачи разного рода.
Цикл разработки по SCRUM включает в себя:
1) Product Backlog. Владелец продукта и SCRUM-команда встречаются, чтобы расставить приоритеты в бэклоге продукта. Бэклог продукта - это не список задач, которые необходимо выполнить. Это список всех желаемых фич, которые могут появиться в продукте. Команда затем берёт какую-то одну фичу и разрабатывает её в процессе спринта.
2) Sprint Planning. Перед каждым спринтом владелец продукта презентует несколько топ-фич в бэклоге продукта и команда решает, над какой фичей они будут работать в следующем спринте и пополняют уже бэклог спринта (это как раз список задач, которые нужно выполнить в течение спринта).
3) Backlog refinement/grooming (доработка/обработка бэклога). В конце каждого спринта команда и владелец продукта встречаются, чтобы удалить или, наоборот, добавить пункты в бэклоге продукта. Они могут расставить приоритетность или разбить требование на более мелкие задачи.
4) Daily Scrum meetings. Ежедневные 15-минутные митинги, где каждый член команды рассказывает, что он сделал или не сделал за предыдущий день и что ему нужно сделать сегодня.
5) Sprint review meeting. В конце каждого спринта команда презентует результаты своей работы на review-митинге. Это живая демонстрация работы продукта, а не отчёт.
6) Sprint retrospective meeting. Также в конце спринта команда проводит особую встречу, где обсуждает, как SCRUM-процесс повлиял на их работу в течение спринта, какие были проблемы и что можно улучшить в процессе работы.
Теперь о Kanban.
Kanban (в переводе с японского "визуальный знак" или "карта") - это визуальный фреймворк для реализации Agile. Kanban развила компания Toyota, которая с помощью него оптимизировала свой процесс производства, смоделировав его по образцу полок в супермаркете. Инженер Тайити Оно заметил, что в супермаркетах имеется ровно столько продуктов, чтобы удовлетворить спрос покупателей. Т.е. запасы товаров будут пополнены только в том случае, когда на полке останется пустое место. Таким образом супермаркеты существенно снижают свои расходы на хранение запасов. Toyota применила эти же принципы на своих заводах. Различные команды создавали карточку (или Kanban), чтобы сообщить, что у них есть дополнительные возможности и они готовы взять больше материалов. Позднее идея Kanban вошла и в IT-среду.
В основе Kanban-фреймворка лежит Канбан-доска. Самая простая может иметь 3 колонки: "to do", "in progress", "done". Если ваша команда, например, занимается построением data lake или data-пайплайнов, Канбан-доска может иметь такие колонки: "backlog", "ready", "coding", "testing", "approval", "done". Каждая карточка на Канбан-доске представляет собой определённую задачу. И эта карточка размещается в нужной колонке в зависимости от своего статуса.
Преимущества Kanban:
- легко вписывается в уже существующую систему управления процессами. Т.е. вам не нужно дополнительно обучать команду или существенно менять процессы ведения проектов. Kanban - это просто визуальный фреймворк, который помогает более чётко увидеть состояние проекта;
- развивающаяся гибкая модель. Здесь нет жёстко определённых приоритетов, они могут меняться по мере поступления новой информации;
- ускорение поставки продукта за счёт понимания, какая работа и на каком этапе выполняется и какие изменения нужно внести;
Недостатки Kanban:
- риск неактуальности информации на доске. Канбан-доску нужно своевременно обновлять. Иначе, команда может работать с устаревшей и неактуальной информацией;
- риск слишком усложнить Канбан-доску. Здесь может произойти "горе от ума", на доске может быть слишком много этапов, кластеров задач. С такой доской команде может быть некомфортно работать, что снизит скорость разработки решения;
- на Канбан-доске не указываются дедлайны по задачам. Члены команды не знают, как долго должна продолжаться определённая фаза задачи.
И как всегда, давайте теперь переложим эти методологии на работу с данными:)
1) Product Backlog. Владелец продукта и SCRUM-команда встречаются, чтобы расставить приоритеты в бэклоге продукта. Бэклог продукта - это не список задач, которые необходимо выполнить. Это список всех желаемых фич, которые могут появиться в продукте. Команда затем берёт какую-то одну фичу и разрабатывает её в процессе спринта.
2) Sprint Planning. Перед каждым спринтом владелец продукта презентует несколько топ-фич в бэклоге продукта и команда решает, над какой фичей они будут работать в следующем спринте и пополняют уже бэклог спринта (это как раз список задач, которые нужно выполнить в течение спринта).
3) Backlog refinement/grooming (доработка/обработка бэклога). В конце каждого спринта команда и владелец продукта встречаются, чтобы удалить или, наоборот, добавить пункты в бэклоге продукта. Они могут расставить приоритетность или разбить требование на более мелкие задачи.
4) Daily Scrum meetings. Ежедневные 15-минутные митинги, где каждый член команды рассказывает, что он сделал или не сделал за предыдущий день и что ему нужно сделать сегодня.
5) Sprint review meeting. В конце каждого спринта команда презентует результаты своей работы на review-митинге. Это живая демонстрация работы продукта, а не отчёт.
6) Sprint retrospective meeting. Также в конце спринта команда проводит особую встречу, где обсуждает, как SCRUM-процесс повлиял на их работу в течение спринта, какие были проблемы и что можно улучшить в процессе работы.
Теперь о Kanban.
Kanban (в переводе с японского "визуальный знак" или "карта") - это визуальный фреймворк для реализации Agile. Kanban развила компания Toyota, которая с помощью него оптимизировала свой процесс производства, смоделировав его по образцу полок в супермаркете. Инженер Тайити Оно заметил, что в супермаркетах имеется ровно столько продуктов, чтобы удовлетворить спрос покупателей. Т.е. запасы товаров будут пополнены только в том случае, когда на полке останется пустое место. Таким образом супермаркеты существенно снижают свои расходы на хранение запасов. Toyota применила эти же принципы на своих заводах. Различные команды создавали карточку (или Kanban), чтобы сообщить, что у них есть дополнительные возможности и они готовы взять больше материалов. Позднее идея Kanban вошла и в IT-среду.
В основе Kanban-фреймворка лежит Канбан-доска. Самая простая может иметь 3 колонки: "to do", "in progress", "done". Если ваша команда, например, занимается построением data lake или data-пайплайнов, Канбан-доска может иметь такие колонки: "backlog", "ready", "coding", "testing", "approval", "done". Каждая карточка на Канбан-доске представляет собой определённую задачу. И эта карточка размещается в нужной колонке в зависимости от своего статуса.
Преимущества Kanban:
- легко вписывается в уже существующую систему управления процессами. Т.е. вам не нужно дополнительно обучать команду или существенно менять процессы ведения проектов. Kanban - это просто визуальный фреймворк, который помогает более чётко увидеть состояние проекта;
- развивающаяся гибкая модель. Здесь нет жёстко определённых приоритетов, они могут меняться по мере поступления новой информации;
- ускорение поставки продукта за счёт понимания, какая работа и на каком этапе выполняется и какие изменения нужно внести;
Недостатки Kanban:
- риск неактуальности информации на доске. Канбан-доску нужно своевременно обновлять. Иначе, команда может работать с устаревшей и неактуальной информацией;
- риск слишком усложнить Канбан-доску. Здесь может произойти "горе от ума", на доске может быть слишком много этапов, кластеров задач. С такой доской команде может быть некомфортно работать, что снизит скорость разработки решения;
- на Канбан-доске не указываются дедлайны по задачам. Члены команды не знают, как долго должна продолжаться определённая фаза задачи.
И как всегда, давайте теперь переложим эти методологии на работу с данными:)
Как и в случае с Agile, SCRUM отлично подходит для разработки сложных продуктов, когда заранее нельзя точно определить, какие фичи в них должны быть. Вы можете использовать SCRUM, если вы делаете, например, сложные пайплайны данных для Machine Learning, разрабатываете data lake и т.д.
Если говорить про Kanban, то вы можете его внедрить в уже существующую систему ведения проектов в качестве визуального фреймворка. Kanban отлично подходит, чтобы оценивать состояние проекта на верхнем уровне. Я, например, очень люблю Kanban и использую его и для рабочих, и для личных целей.
P.S. Было бы интересно услышать, какие методологии вы используете на работе или для личных задач. Пишите в комментариях)
Если говорить про Kanban, то вы можете его внедрить в уже существующую систему ведения проектов в качестве визуального фреймворка. Kanban отлично подходит, чтобы оценивать состояние проекта на верхнем уровне. Я, например, очень люблю Kanban и использую его и для рабочих, и для личных целей.
P.S. Было бы интересно услышать, какие методологии вы используете на работе или для личных задач. Пишите в комментариях)
Хочу поделиться с вами записью выступления Симо Ахавы на конференции Go Analytics 2019.
Симо Ахава - Analytics Developer из Финляндии, эксперт по Google Analytics и Google Tag Manager.
На выступлении он рассказал о важности коммуникации команды на проекте (как я уже говорил, коммуникация - одна из главных составляющих Agile) и data quality. Здесь он на примере построения data-пайплайнов показал, как проблемы в коммуникации влияют на качество данных и дальнейшую аналитику.
Очень актуальный и полезный доклад. Рекомендую:)
Симо Ахава - Analytics Developer из Финляндии, эксперт по Google Analytics и Google Tag Manager.
На выступлении он рассказал о важности коммуникации команды на проекте (как я уже говорил, коммуникация - одна из главных составляющих Agile) и data quality. Здесь он на примере построения data-пайплайнов показал, как проблемы в коммуникации влияют на качество данных и дальнейшую аналитику.
Очень актуальный и полезный доклад. Рекомендую:)
YouTube
Simo Ahava, 8-bit-sheep
In the war between tactics and strategy, communication wins the game (ENG)
Ребята, всех с наступающим Новым годом! 🎄
Желаю всем в новом году достигнуть личных и профессиональных целей, никогда не сдаваться, ну и здоровья побольше! 😊
Спасибо, что читаете, я это очень ценю)
Желаю всем в новом году достигнуть личных и профессиональных целей, никогда не сдаваться, ну и здоровья побольше! 😊
Спасибо, что читаете, я это очень ценю)
Ещё в конце лета посмотрел отличный вебинар Романа Бунина, на котором он рассказал про алгоритм проектирования дашборда в рамках образовательной платформы Data Learn.
Роман руководит командой визуализации в Яндекс Такси, и мне очень понравился его методичный и системный подход. Нетехническим пользователям по большому счёту всё равно, какие сложные ETL-процессы вы используете или какой DWH используете (т.е. весь back-end аналитического решения), они в этом как минимум мало разбираются. Им главное своевременно получать достоверную информацию, которую они увидят на дашборде, чтобы этот дашборд был визуально приятным и удобным. Поэтому к разработке BI-решения нужно подходить системно и со всей серьёзностью к процессу.
Так как мы сейчас разбираем процессы, посчитал, стоит поделиться этим вебинаром и алгоритмом с вами.
Считаю одним из самых полезных материалов для BI-разработки. Сам применяю большинство пунктов из этого алгоритма и хочу полностью его переложить на свои проекты.
В общем, для BI-разработчиков и всех, кто работает с инструментами визуализации - must have для просмотра. Остальным также рекомендую в качестве data literacy)
P.S. В описании вебинара найдёте ссылки на презентацию и на доску в miro с дашбордом canvas, где визуально представлены шаги алгоритма.
Роман руководит командой визуализации в Яндекс Такси, и мне очень понравился его методичный и системный подход. Нетехническим пользователям по большому счёту всё равно, какие сложные ETL-процессы вы используете или какой DWH используете (т.е. весь back-end аналитического решения), они в этом как минимум мало разбираются. Им главное своевременно получать достоверную информацию, которую они увидят на дашборде, чтобы этот дашборд был визуально приятным и удобным. Поэтому к разработке BI-решения нужно подходить системно и со всей серьёзностью к процессу.
Так как мы сейчас разбираем процессы, посчитал, стоит поделиться этим вебинаром и алгоритмом с вами.
Считаю одним из самых полезных материалов для BI-разработки. Сам применяю большинство пунктов из этого алгоритма и хочу полностью его переложить на свои проекты.
В общем, для BI-разработчиков и всех, кто работает с инструментами визуализации - must have для просмотра. Остальным также рекомендую в качестве data literacy)
P.S. В описании вебинара найдёте ссылки на презентацию и на доску в miro с дашбордом canvas, где визуально представлены шаги алгоритма.
YouTube
Алгоритм проектирования дашборда / Роман Бунин
🔔 Вебинар проведет Роман Бунин. Очень крутой руководитель команды визуализации из Яндекс.Такси. 🚕
Роман поделиться своими знаниями и ответит на все вопросы.
🔗 Линки:
Ссылка про пай-чарты
https://ig.ft.com/science-of-charts/
На миро:
https://miro.com/app…
Роман поделиться своими знаниями и ответит на все вопросы.
🔗 Линки:
Ссылка про пай-чарты
https://ig.ft.com/science-of-charts/
На миро:
https://miro.com/app…
А теперь вебинар от меня, который я провёл в конце ноября тоже в рамках Data Learn.
На вебинаре я пошагово разобрал кейс построения сквозной аналитики для маркетинга на Google Cloud.
Если вы владеете базовыми навыками SQL и пишете простые ETL-скрипты на Python, то после просмотра сможете тоже построить такую инфраструктуру.
Примерно такое же решение можно сделать на Amazon Web Services и Microsoft Azure.
Будут вопросы - задавайте)
P.S. Интересно услышать, кто с каким облаком работает и какие преимущества для себя нашёл. Пишите в комментариях.
На вебинаре я пошагово разобрал кейс построения сквозной аналитики для маркетинга на Google Cloud.
Если вы владеете базовыми навыками SQL и пишете простые ETL-скрипты на Python, то после просмотра сможете тоже построить такую инфраструктуру.
Примерно такое же решение можно сделать на Amazon Web Services и Microsoft Azure.
Будут вопросы - задавайте)
P.S. Интересно услышать, кто с каким облаком работает и какие преимущества для себя нашёл. Пишите в комментариях.
YouTube
КАК ПОСТРОИТЬ СИСТЕМУ МАРКЕТИНГОВОЙ АНАЛИТИКИ НА GOOGLE CLOUD / ДЕНИС СОЛОВЬЕВ
План вебинара:
- Архитектура решения и её ключевые элементы;
- На что обратить внимание перед построением решения;
- Преимущества Google BigQuery при построении маркетинговой аналитики;
- Как построить простой ETL с помощью Cloud Functions + Cloud Pub/Sub…
- Архитектура решения и её ключевые элементы;
- На что обратить внимание перед построением решения;
- Преимущества Google BigQuery при построении маркетинговой аналитики;
- Как построить простой ETL с помощью Cloud Functions + Cloud Pub/Sub…
Думаю, мы максимально подробно (насколько это возможно) разобрали 2-й фактор эффективности работы с данными - "Процессы".
Мы неплохо познакомились с пирамидой потребностей Data Science, с философиями / методологиями ведения проектов, и я привёл пару вебинаров, которые касаются системного подхода работы с данными.
Пора приступать к 3 фактору - "Структура".
И появилась у меня такая идея: сделать 1 или 2 поста на эту тему в формате интервью с несколькими опытными специалистами, которые поработали в компаниях разных размеров. Узнать, из каких ролей состоит команда по работе с данными в их компаниях и какие функции они выполняют.
Как вам такой формат?
Мы неплохо познакомились с пирамидой потребностей Data Science, с философиями / методологиями ведения проектов, и я привёл пару вебинаров, которые касаются системного подхода работы с данными.
Пора приступать к 3 фактору - "Структура".
И появилась у меня такая идея: сделать 1 или 2 поста на эту тему в формате интервью с несколькими опытными специалистами, которые поработали в компаниях разных размеров. Узнать, из каких ролей состоит команда по работе с данными в их компаниях и какие функции они выполняют.
Как вам такой формат?
Начинаем нашу серию постов о 3 факторе эффективности работы data team - "Структура".
Подумал, что лучше всего будет провести мини-интервью с опытными специалистами, которые поработали и работают в компаниях разных размеров. Чтобы они рассказали, из каких ролей состоит их команда по работе с данными, и какие функции они выполняют. Пока написал около 6-7 человек. Возможно, ешё кому-то напишу и пообщаюсь:)
Серия постов будет в формате 1-2 мини-интервью на пост, чтобы не было каши.
Первым человеком, с которым я пообщался на эту тему, был Дмитрий Аношин - Role Senior Data Engineer в Microsoft (до этого 5 лет работал в Amazon). Дима дал краткую сводку по тому, на каких проектах он работал в Amazon, над чем сейчас работает в Microsoft, какие роли были в командах проектов и с какими проблемами в структуре он столкнулся.
Цитирую:
"Смотри: Amazon:
1) Amazon Marketplace: Role BI+Data Engineer, работал с BIE
В качестве BI:
- установка Tableau Server
- Миграция SQL+Excel отчетов на Tableau
- Self-Service implementation
- Office Hours + Training (Adoption of BI)
В качестве Data Engineer:
-Миграция on premise Oracle DW + PL/SQL ETL на Amazon Redshift, работал с DBA, SDE
-Поиск и выбор Cloud ETL -> Matillion ETL и миграция всего с PL/SQL на ETL + переработка бизнес логики
-Использование AWS EMR+Spark (PySpark) для решения задачи с обработкой веб логов, так как ETL+DW просто не вывозили объем. Результат Spark был в Parquet в S3 (по сути озеро данных) и доступ к нему был через Athena и Redshift Spectrum
- Streaming данных из DynamoDB в real-time через DynamoDB Streams + Kinesis Firehose + Glue
2) Amazon Alexa BI: Role Data Engineer, работал с Product Managers, SDE и BIE
- Внедрение ETL Matillion ETL
- Создание тестовой/боевой системы в ETL и DW (Amazon Redshift)
- Оптимизация Tableau Data Sources (в среднем по 150млн строк было в одном data source)
- Разработка новой платформы для Alexa c названием Sputnik. С использованием новых нод Redshift RA3. Объем данных планировался 120ТБ в год.
- Работал вместе с Data Science над созданием Alexa Churn модели; моя задача была масштабировать модель и подготовка данных на AWS SageMaker
3) Amazon Customer Behaviour Analytics: Role Data Engineer, работал с ML, Data Science + Product Managers
- создание Big Data системы для ML модели. По сути задача системы была - feature engineering, нужно было процедить 700ТБ данных за год (clickstream + backend). Использовали EMR+Spark, логика была на SparkSQL и иногда Scala.
- моя задача была автоматизация всей этой истории, ее безопасность, privacy (GDPR и тп), и качество данных через Spark библиотеку deeque
- Дальше они уже сами брали данные через GPU EC2 instance и строили нейронную сеть (deep learning)
4) Microsoft Xbox game studios: Role Sr. Data Engineer, работаю с BIE, ML, Producers (вместо Product Managers), Artists (designers) и инженерами (SDE).
-моя задача создать новую платформу под новую игру, планирую делать Delta Lake на Databricks (активно изучаю)
-сейчас пока все на HDInsight+Hive (процессинг сырых данных) + SQL Server (dimensional model)
-дашборды в Power BI (который я не люблю после Табло)
-также для операционной аналитики Azure Data Explorer (аналог Splunk и Elastic Search)
-активно используем Azure DevOps (Git + Pipelines) и Microsoft Visual Studio в качестве IDE. Разбираюсь в CI/CD, очень крутая тема конечно, но надо время, чтобы въехать."
Главная проблема в структуре, с которой Дима столкнулся - когда в одной команде работают и разработчики программного обеспечения, и дата-инженеры. Он, как дата-инженер, выступал за простоту решения в виде использования ETL-инструментов с графическим интерфейсом, которые при этом полностью решали задачу проекта, а разработчики больше выступали за использование кода. В общем, договориться было сложно)Это тормозило разработку решения и потом было сложно найти, кто прав, кто виноват.
Подумал, что лучше всего будет провести мини-интервью с опытными специалистами, которые поработали и работают в компаниях разных размеров. Чтобы они рассказали, из каких ролей состоит их команда по работе с данными, и какие функции они выполняют. Пока написал около 6-7 человек. Возможно, ешё кому-то напишу и пообщаюсь:)
Серия постов будет в формате 1-2 мини-интервью на пост, чтобы не было каши.
Первым человеком, с которым я пообщался на эту тему, был Дмитрий Аношин - Role Senior Data Engineer в Microsoft (до этого 5 лет работал в Amazon). Дима дал краткую сводку по тому, на каких проектах он работал в Amazon, над чем сейчас работает в Microsoft, какие роли были в командах проектов и с какими проблемами в структуре он столкнулся.
Цитирую:
"Смотри: Amazon:
1) Amazon Marketplace: Role BI+Data Engineer, работал с BIE
В качестве BI:
- установка Tableau Server
- Миграция SQL+Excel отчетов на Tableau
- Self-Service implementation
- Office Hours + Training (Adoption of BI)
В качестве Data Engineer:
-Миграция on premise Oracle DW + PL/SQL ETL на Amazon Redshift, работал с DBA, SDE
-Поиск и выбор Cloud ETL -> Matillion ETL и миграция всего с PL/SQL на ETL + переработка бизнес логики
-Использование AWS EMR+Spark (PySpark) для решения задачи с обработкой веб логов, так как ETL+DW просто не вывозили объем. Результат Spark был в Parquet в S3 (по сути озеро данных) и доступ к нему был через Athena и Redshift Spectrum
- Streaming данных из DynamoDB в real-time через DynamoDB Streams + Kinesis Firehose + Glue
2) Amazon Alexa BI: Role Data Engineer, работал с Product Managers, SDE и BIE
- Внедрение ETL Matillion ETL
- Создание тестовой/боевой системы в ETL и DW (Amazon Redshift)
- Оптимизация Tableau Data Sources (в среднем по 150млн строк было в одном data source)
- Разработка новой платформы для Alexa c названием Sputnik. С использованием новых нод Redshift RA3. Объем данных планировался 120ТБ в год.
- Работал вместе с Data Science над созданием Alexa Churn модели; моя задача была масштабировать модель и подготовка данных на AWS SageMaker
3) Amazon Customer Behaviour Analytics: Role Data Engineer, работал с ML, Data Science + Product Managers
- создание Big Data системы для ML модели. По сути задача системы была - feature engineering, нужно было процедить 700ТБ данных за год (clickstream + backend). Использовали EMR+Spark, логика была на SparkSQL и иногда Scala.
- моя задача была автоматизация всей этой истории, ее безопасность, privacy (GDPR и тп), и качество данных через Spark библиотеку deeque
- Дальше они уже сами брали данные через GPU EC2 instance и строили нейронную сеть (deep learning)
4) Microsoft Xbox game studios: Role Sr. Data Engineer, работаю с BIE, ML, Producers (вместо Product Managers), Artists (designers) и инженерами (SDE).
-моя задача создать новую платформу под новую игру, планирую делать Delta Lake на Databricks (активно изучаю)
-сейчас пока все на HDInsight+Hive (процессинг сырых данных) + SQL Server (dimensional model)
-дашборды в Power BI (который я не люблю после Табло)
-также для операционной аналитики Azure Data Explorer (аналог Splunk и Elastic Search)
-активно используем Azure DevOps (Git + Pipelines) и Microsoft Visual Studio в качестве IDE. Разбираюсь в CI/CD, очень крутая тема конечно, но надо время, чтобы въехать."
Главная проблема в структуре, с которой Дима столкнулся - когда в одной команде работают и разработчики программного обеспечения, и дата-инженеры. Он, как дата-инженер, выступал за простоту решения в виде использования ETL-инструментов с графическим интерфейсом, которые при этом полностью решали задачу проекта, а разработчики больше выступали за использование кода. В общем, договориться было сложно)Это тормозило разработку решения и потом было сложно найти, кто прав, кто виноват.
В дополнение видео от Димы о его 5-летнем опыте работы в Amazon.
YouTube
5 ЛЕТ В АМАЗОН / ДМИТРИЙ АНОШИН
Данное видео это выступления Дмитрия Аношина на конференции DataMonster. Я давно хотел подвести итоги про прошедших 5 лет работы в Amazon. Подробно расскажу про собеседования в Амазоне, в каких командах я работал и какие решения внедрял, про свои сообщества…
Продолжаем нашу серию мини-интервью со специалистами по работе с данными.
Сегодня у нас 2 мини-сводки по структуре data teams от Антона Брызгалова и Адиля Хаштамова.
Мне очень понравилась статья Антона на Tproger о том, как он построил решение для стриминга данных на Yandex Cloud и по факту сделал собственный трекер событий для сайта и чат-ботов. Как оказалось, Антон - очень опытный специалист, который успел поработать в Яндексе и сейчас работает в роли Senior Data Engineer в компании KaiOS Tech.
Адиль - опытный разработчик и data engineer, автор Telegram-канала об инжиниринге данных, который я с удовольствием читаю и всем рекомендую. В последнее время был техническим лидом команды автоматизации маркетинга в компании Playrix.
Вот, что ребята рассказали про структуру команд в их компаниях:
Антон Брызгалов
"Ответить на вопрос проще через хронологию развития команды. Когда компания задумывается об извлечении пользы из данных, сначала нанимают аналитика (Data Analyst) или датасаентиста (Data Scientist). Эти специалисты могут самостоятельно сконвертировать данные в инсайты. Обычно работа этих специалистов business-driven: они выполняют прямые заказы бизнеса, не тратя время на переиспользование результатов работы — это дает гибкость и повышает скорость доставки результатов.
DA/DS как ремесленники: каждый из них талантлив в ручном труде, но чтобы поставить производство на поток, нужен инженер. Когда у данных появляется много пользователей, приходит время наращивать обороты «бизнеса данных» внутри компании. Тогда и появляется Data Engineer, который генерализует наработки аналитиков и датасаентистов, организуя платформу для работы с данными.
DA/DS + DE — это основной набор ролей. Чем больше становится нужда в генерализации подхода, тем больше специалистов появляется: тимлид (Team Lead) для управления командой дата-инженеров как командой разработки, проектный менеджер (Project Manager) для организации процессов, архитектор хранилища данных (роль часто совмещается с тимлидом) для принятия решений о модели данных и технической платформе, системные аналитики (System Analyst) для проектирования сущностей и поддержки знаний о домене, специалисты по Business Intelligence и разного рода аналитики с углубленной экспертизой в каждой отдельной области бизнеса.
Команда данных — это предприятие внутри компании. И оно проходит все стадии от кустарного производства до конвейеров и разделения труда.
Самая крупная аналитическая команда, в которой я работал, была в Яндекс.Такси. На момент, когда я ушел, у нас было 15 инженеров, включая архитектора (тимлида) и системного аналитика, и около 30 аналитиков данных, распределенных между разными направлениями: бизнес, маркетинг, продукт, CRM и пр. Насколько мне известно, сейчас в службе аналитики ЯТ около 100 человек."
Адиль Хаштамов
"Playrix - компания большая, в ней четко выделяются 2 направления касательно анализа данных:
1. Игровая аналитика
2. Маркетинговая аналитика
Для решения задач этих направлений существует департамент IT куда входят команды BI разработчиков, дата инженеры, full stack разработчики.
BI отдел визуализирует данные, создавая множество сложных и не очень дэшбордов. Основной инструмент Tableau.
Команда дата инженеров занимается построением дата пайплайнов, data modeling и отвечет за эффективную работу с данными. Периодически внутри компании проходят т.н. knowledge sharing презентации для улучшения коммуникации, т.к. все работают удаленно.
Full stack разработчики создают внутренние сервисы для автоматизации процессов, закрытые внутренние продукты для игровой и маркетинговой аналитики."
Сегодня у нас 2 мини-сводки по структуре data teams от Антона Брызгалова и Адиля Хаштамова.
Мне очень понравилась статья Антона на Tproger о том, как он построил решение для стриминга данных на Yandex Cloud и по факту сделал собственный трекер событий для сайта и чат-ботов. Как оказалось, Антон - очень опытный специалист, который успел поработать в Яндексе и сейчас работает в роли Senior Data Engineer в компании KaiOS Tech.
Адиль - опытный разработчик и data engineer, автор Telegram-канала об инжиниринге данных, который я с удовольствием читаю и всем рекомендую. В последнее время был техническим лидом команды автоматизации маркетинга в компании Playrix.
Вот, что ребята рассказали про структуру команд в их компаниях:
Антон Брызгалов
"Ответить на вопрос проще через хронологию развития команды. Когда компания задумывается об извлечении пользы из данных, сначала нанимают аналитика (Data Analyst) или датасаентиста (Data Scientist). Эти специалисты могут самостоятельно сконвертировать данные в инсайты. Обычно работа этих специалистов business-driven: они выполняют прямые заказы бизнеса, не тратя время на переиспользование результатов работы — это дает гибкость и повышает скорость доставки результатов.
DA/DS как ремесленники: каждый из них талантлив в ручном труде, но чтобы поставить производство на поток, нужен инженер. Когда у данных появляется много пользователей, приходит время наращивать обороты «бизнеса данных» внутри компании. Тогда и появляется Data Engineer, который генерализует наработки аналитиков и датасаентистов, организуя платформу для работы с данными.
DA/DS + DE — это основной набор ролей. Чем больше становится нужда в генерализации подхода, тем больше специалистов появляется: тимлид (Team Lead) для управления командой дата-инженеров как командой разработки, проектный менеджер (Project Manager) для организации процессов, архитектор хранилища данных (роль часто совмещается с тимлидом) для принятия решений о модели данных и технической платформе, системные аналитики (System Analyst) для проектирования сущностей и поддержки знаний о домене, специалисты по Business Intelligence и разного рода аналитики с углубленной экспертизой в каждой отдельной области бизнеса.
Команда данных — это предприятие внутри компании. И оно проходит все стадии от кустарного производства до конвейеров и разделения труда.
Самая крупная аналитическая команда, в которой я работал, была в Яндекс.Такси. На момент, когда я ушел, у нас было 15 инженеров, включая архитектора (тимлида) и системного аналитика, и около 30 аналитиков данных, распределенных между разными направлениями: бизнес, маркетинг, продукт, CRM и пр. Насколько мне известно, сейчас в службе аналитики ЯТ около 100 человек."
Адиль Хаштамов
"Playrix - компания большая, в ней четко выделяются 2 направления касательно анализа данных:
1. Игровая аналитика
2. Маркетинговая аналитика
Для решения задач этих направлений существует департамент IT куда входят команды BI разработчиков, дата инженеры, full stack разработчики.
BI отдел визуализирует данные, создавая множество сложных и не очень дэшбордов. Основной инструмент Tableau.
Команда дата инженеров занимается построением дата пайплайнов, data modeling и отвечет за эффективную работу с данными. Периодически внутри компании проходят т.н. knowledge sharing презентации для улучшения коммуникации, т.к. все работают удаленно.
Full stack разработчики создают внутренние сервисы для автоматизации процессов, закрытые внутренние продукты для игровой и маркетинговой аналитики."
Tproger
Как отследить активность пользователя: свой трекер в Яндекс.Облаке
В Tproger разработали аналитический веб-трекер, чтобы следить за активностью пользователей. Рассказываем о поставленных задачах и их решении.
Для создания комьюнити и наращивания экспертизы, я считаю, важно посещать профессиональные мероприятия. На них вы можете услышать об интересных кейсах, познакомиться и задать вопросы опытным специалистам, обменяться опытом.
Рекомендую подписаться на канал "Data online events & Moscow meetups". Он посвящен мероприятиям по Big Data, Machine Learning, Data Science, Data Engineering, BI/DWH и другим направлениям, связанным с данными. Мероприятия проходят в Москве и онлайн.
Предложить свой ивент можно, написав @NikolayKrupiy, @Ajvol
👉🏻 Подписаться на t.me/data_events
Рекомендую подписаться на канал "Data online events & Moscow meetups". Он посвящен мероприятиям по Big Data, Machine Learning, Data Science, Data Engineering, BI/DWH и другим направлениям, связанным с данными. Мероприятия проходят в Москве и онлайн.
Предложить свой ивент можно, написав @NikolayKrupiy, @Ajvol
👉🏻 Подписаться на t.me/data_events
Telegram
Data Events
Ивенты по Big Data, DE, BI, AI, ML, DS, DA, etc
Спец подканалы:
@AI_meetups
@DE_events
@BI_events
@datathons
@data_career
@devetups
см также @agile_events
#Календарь bit.ly/3oLMmDc
tgstat.ru/channel/@data_events
contacts: @black_titmouse
Спец подканалы:
@AI_meetups
@DE_events
@BI_events
@datathons
@data_career
@devetups
см также @agile_events
#Календарь bit.ly/3oLMmDc
tgstat.ru/channel/@data_events
contacts: @black_titmouse
Всем привет.
Продолжаем мини-интервью с опытными специалистами по работе с данными. Своим интересным опытом поделились Олег Агапов (Data Analyst в GOG.com), Николай Валиотти (руководитель компании Valiotti Analytics) и Алексей Макаров (Product Manager в Яндекс Практикум, в прошлом Product Analyst в CoMagic). Немного слов о наших гостях:
Олег Агапов начал писать фундаментальную книгу о data-инжиниринге на GitHub. В ней уже есть 2 главы. Контент действительно достойный и заслуживает внимания. Ещё и на английском:)Также Олег оставил контакт, если кто-то захочет обсудить профессиональные моменты.
Про Николая и его компанию я узнал из выступления на Матемаркетинг 2020, где Николай рассказал про кейс построения end-to-end аналитики на Amazon Web Services с использованием ClickHouse и Kafka. Очень классный кейс, который можно позаимствовать при построении аналитики для мобильного стартапа. Также было интересно услышать от него о структуре его команды, как от руководителя. Ещё Николай ведёт интересный канал про данные и аналитику LEFT JOIN.
Про Алексея я узнал, подписавшись на его крутой канал, где он пишет про анализ данных с использованием языка Python. Если вы аналитик и хотите выйти на advanced уровень, то вам обязательно стоит на него подписаться.
Теперь переходим к самим интервью.
Олег Агапов:
"У нас в команде:
- 3 аналитика включая меня (отчеты, метрики, дашборды)
- 2 дата инженера (поддержка и настройка инфраструктуры и тулзов)
- 1.5 архитектора (создание инфраструктуры, создание внутренних инструментов)
Команда молодая, только прошлым летом набрали аналитиков и инженеров, до этого всё делал в основном сам. Мы набирали в команду фул-стек аналитиков, которые могут всё (почти) если понадобится. Поэтому чёткого разграничения по обязанностям нет, аналитики могут писать агрегации, инженеры могут делать дашборды.
Из проблем. У нас пока нет чёткого тим лида, кто будет авторитарно решать куда будет развиватся команда. Авторитарного именно в плане стратегии, а не тактики типа "будем всё писать на R".
Из достоинств. Намечаются доменные области, которые могут быть закрыты конкретным человеком. Например, есть спец по Табло и бизнесу, есть спец по определенным продуктам компании, тп. Это помогает экономить time-to-deploy (сколько проходит времени от постановки задачи до её выполнения)."
Продолжаем мини-интервью с опытными специалистами по работе с данными. Своим интересным опытом поделились Олег Агапов (Data Analyst в GOG.com), Николай Валиотти (руководитель компании Valiotti Analytics) и Алексей Макаров (Product Manager в Яндекс Практикум, в прошлом Product Analyst в CoMagic). Немного слов о наших гостях:
Олег Агапов начал писать фундаментальную книгу о data-инжиниринге на GitHub. В ней уже есть 2 главы. Контент действительно достойный и заслуживает внимания. Ещё и на английском:)Также Олег оставил контакт, если кто-то захочет обсудить профессиональные моменты.
Про Николая и его компанию я узнал из выступления на Матемаркетинг 2020, где Николай рассказал про кейс построения end-to-end аналитики на Amazon Web Services с использованием ClickHouse и Kafka. Очень классный кейс, который можно позаимствовать при построении аналитики для мобильного стартапа. Также было интересно услышать от него о структуре его команды, как от руководителя. Ещё Николай ведёт интересный канал про данные и аналитику LEFT JOIN.
Про Алексея я узнал, подписавшись на его крутой канал, где он пишет про анализ данных с использованием языка Python. Если вы аналитик и хотите выйти на advanced уровень, то вам обязательно стоит на него подписаться.
Теперь переходим к самим интервью.
Олег Агапов:
"У нас в команде:
- 3 аналитика включая меня (отчеты, метрики, дашборды)
- 2 дата инженера (поддержка и настройка инфраструктуры и тулзов)
- 1.5 архитектора (создание инфраструктуры, создание внутренних инструментов)
Команда молодая, только прошлым летом набрали аналитиков и инженеров, до этого всё делал в основном сам. Мы набирали в команду фул-стек аналитиков, которые могут всё (почти) если понадобится. Поэтому чёткого разграничения по обязанностям нет, аналитики могут писать агрегации, инженеры могут делать дашборды.
Из проблем. У нас пока нет чёткого тим лида, кто будет авторитарно решать куда будет развиватся команда. Авторитарного именно в плане стратегии, а не тактики типа "будем всё писать на R".
Из достоинств. Намечаются доменные области, которые могут быть закрыты конкретным человеком. Например, есть спец по Табло и бизнесу, есть спец по определенным продуктам компании, тп. Это помогает экономить time-to-deploy (сколько проходит времени от постановки задачи до её выполнения)."
GitHub
GitHub - oleg-agapov/data-engineering-book: Accumulated knowledge and experience in the field of Data Engineering
Accumulated knowledge and experience in the field of Data Engineering - oleg-agapov/data-engineering-book
Николай Валиотти:
"В основном мы работаем с различными digital и мобильными стартапами, помогаем им выстроить end-to-end аналитику.
Другими словами, мы работаем со спектром задач от проектирования хранилища / озера данных, построения процессов инжиниринга данных до построения отчетности и иногда даже некоторых моделей машинного обучения.
Персонально я успел поработать в ряде крупных организаций и занимался анализом данных с разнообразным стеком решений, однако в последние годы перед стартом своей компании работал в стартапе, который уже тогда начал работать с так называемым modern data stack. Меня это невероятно увлекло и вдохновило на то, чтобы и другие компании могли компетентно использовать современные облачные решения и получать максимальную пользу от собственных данных.
Мы в некотором смысле стартап (по духу), хотя, конечно, больше развиваемся как традиционная консалтинговая компания. У нас небольшой штат сотрудников и соответствующих ролей, о которых речь пойдет дальше.
Поскольку работаем параллельно с несколькими проектами одновременно бОльшая часть команд кросс-функциональна, что означает, что в каждом проекте есть выделенный сотрудник, который лидирует по проекту, а другие коллеги функционально помогают ему в достижении поставленной цели.
Среди наших сотрудников имеются:
Data Engineer - работы с построением архитектуры хранилища, среди инструментов Kafka, Airflow, среди СУБД: BigQuery, Redshift, Clickhouse, Redshift, Vertica, MySQL, разумеется, SQL и Pythoh.
Analytics Engineer - работы с инструментов dbt, построение моделей данных в Looker, работа с Python для обработки данных, естественно, SQL
2x Data Analyst - мы используем ряд инструментов в зависимости от потребностей и возможностей заказчика: Tableau, Looker, Redash, PowerBI и Metabase, ребята умеют работать в этих инструментах и естественно используют SQL. Ряд задач, например, построение классификационных моделей мы строим с использованием Python, используем Jupyter, в некоторых случаях Collab.
2x Junior Data Analyst - помогают более старшим аналитикам и решают более маленькие кусочки задач с тем же стеком технологий.
В будущем планирую выстраивать организационную структуру, поскольку найм сотрудников горизонтально все-таки невозможен бесконечно и система из более 7 человек будет работать неэффективно"
"В основном мы работаем с различными digital и мобильными стартапами, помогаем им выстроить end-to-end аналитику.
Другими словами, мы работаем со спектром задач от проектирования хранилища / озера данных, построения процессов инжиниринга данных до построения отчетности и иногда даже некоторых моделей машинного обучения.
Персонально я успел поработать в ряде крупных организаций и занимался анализом данных с разнообразным стеком решений, однако в последние годы перед стартом своей компании работал в стартапе, который уже тогда начал работать с так называемым modern data stack. Меня это невероятно увлекло и вдохновило на то, чтобы и другие компании могли компетентно использовать современные облачные решения и получать максимальную пользу от собственных данных.
Мы в некотором смысле стартап (по духу), хотя, конечно, больше развиваемся как традиционная консалтинговая компания. У нас небольшой штат сотрудников и соответствующих ролей, о которых речь пойдет дальше.
Поскольку работаем параллельно с несколькими проектами одновременно бОльшая часть команд кросс-функциональна, что означает, что в каждом проекте есть выделенный сотрудник, который лидирует по проекту, а другие коллеги функционально помогают ему в достижении поставленной цели.
Среди наших сотрудников имеются:
Data Engineer - работы с построением архитектуры хранилища, среди инструментов Kafka, Airflow, среди СУБД: BigQuery, Redshift, Clickhouse, Redshift, Vertica, MySQL, разумеется, SQL и Pythoh.
Analytics Engineer - работы с инструментов dbt, построение моделей данных в Looker, работа с Python для обработки данных, естественно, SQL
2x Data Analyst - мы используем ряд инструментов в зависимости от потребностей и возможностей заказчика: Tableau, Looker, Redash, PowerBI и Metabase, ребята умеют работать в этих инструментах и естественно используют SQL. Ряд задач, например, построение классификационных моделей мы строим с использованием Python, используем Jupyter, в некоторых случаях Collab.
2x Junior Data Analyst - помогают более старшим аналитикам и решают более маленькие кусочки задач с тем же стеком технологий.
В будущем планирую выстраивать организационную структуру, поскольку найм сотрудников горизонтально все-таки невозможен бесконечно и система из более 7 человек будет работать неэффективно"
Алексей Макаров:
"Сейчас я работаю в Яндекс.Практикуме, тут я продакт на факультете данных и занимаюсь развитием программы обучения, а с непосредственно аналитикой пересекаюсь не много
Ну у нас в CoMagic была очень небольшая команда по работе с данными. По факту аналитики нанимались под определенные функциональные направления. Например, отделу маркетинга нужен аналитик — они нанимали себе аналитика, который занимается маркетинговой аналитикой или подготовкой каких-то маркетинговых материалов на основе данных. Также и с продуктовой аналитикой — созрела необходимость в поддержке принятия решений среди продукт-менеджеров, нанимают продуктового аналитика. Единой аналитической команды таким образом не формируется, нет Head of Analytics, скорее каждый Head of Something нанимает себе отдельного аналитика. В этом плане аналитическая культура в CoMagic была слабоватой, так как не обеспечивается обмена знаниями
Data Scientist также нанимался в определенное продуктовое направление, где для него были определенные задачи в рамках продуктового стрима. Получалось, что непосредственным руководителем был продакт-менеджер этого стрима.
Были также чуваки, которых называли базистами. Это что-то типа DBA с крутыми скиллами разработки. У нас в основном везде был PostgreSQL и вот эти чуваки занимались его шардированием, ускорением запросов, подготовкой запросов под какие-то продуктовые задачи и т.д."
"Сейчас я работаю в Яндекс.Практикуме, тут я продакт на факультете данных и занимаюсь развитием программы обучения, а с непосредственно аналитикой пересекаюсь не много
Ну у нас в CoMagic была очень небольшая команда по работе с данными. По факту аналитики нанимались под определенные функциональные направления. Например, отделу маркетинга нужен аналитик — они нанимали себе аналитика, который занимается маркетинговой аналитикой или подготовкой каких-то маркетинговых материалов на основе данных. Также и с продуктовой аналитикой — созрела необходимость в поддержке принятия решений среди продукт-менеджеров, нанимают продуктового аналитика. Единой аналитической команды таким образом не формируется, нет Head of Analytics, скорее каждый Head of Something нанимает себе отдельного аналитика. В этом плане аналитическая культура в CoMagic была слабоватой, так как не обеспечивается обмена знаниями
Data Scientist также нанимался в определенное продуктовое направление, где для него были определенные задачи в рамках продуктового стрима. Получалось, что непосредственным руководителем был продакт-менеджер этого стрима.
Были также чуваки, которых называли базистами. Это что-то типа DBA с крутыми скиллами разработки. У нас в основном везде был PostgreSQL и вот эти чуваки занимались его шардированием, ускорением запросов, подготовкой запросов под какие-то продуктовые задачи и т.д."
Сегодня у нас ещё одно интересное мини-интервью с Романом Буниным - руководителем команды визуализации данных в Яндекс Go.
Роман рассказал про структуру команды и как устроена работа с данными. Получилось интересно)
У Романа есть сайт и телеграм-канал, где он делится лайф-хаками визуализации данных, пишет про развитие BI-систем и, в частности, про Tableau. Рекомендую всем BI-разработчикам и всем, кто работает с визуализацией данных. Научитесь продуктовому подходу к построению дашбордов.
И само интервью:
"Я расскажу как устроена работа с данными только в бизнес-аналитике Такси, и то как это вижу я со стороны работы своей команды. Поэтому могу что-то пропустить или не дать глубоких деталей.
Яндекс имеет сильную data-driven культуры, поэтому в Go мы обслуживаем более 800 бизнес-пользователей, которые используют данные для принятия решений.
Основной «солдат» данных — это фуллстэк аналитик. Это супермены, которые могут сами собрать и понять боль бизнеса, подготовить данные, сделать их обработку на Питоне, построить модель и создать дашборд. Лучше всего они разбираются в аналитике, статистике и том направлении бизнеса за которое отвечают (продукт, маркетинг, найм водителей, безопасность и т.п.).
Чтобы помогать им работать с «технической» частью есть инфраструктурные команды: команда Data Management Platform, команды внутренних инструментов и моя команда по визуализации:
— DMP создает инструменты по работе с данными и новые низкоуровневые витрины данных. В их рядах дата-инженеры, партнеры по данным и системные инженеры.
— Команды внутренних инструментов разрабатывает библиотеки для питона, модели и инструменты прогнозирования, платформы для проведения A/B-тестов и системы аналитики в реальном времени. Здесь очень много разных ролей — от фронт-энд разработчиков до ML-инженеров.
— Моя команда помогает аналитикам делать правильные дашборды — мы обучаем и консультируем по работе с Табло, создаем темплейты и стайлгайды, налаживаем процессы управления контентом и делаем самые важные и большие отчеты. У нас в команде BI-разработчики и менеджер продукта.
Получается довольно много ролей, и это только в отделе бизнес-аналитики. А ещё есть большая команда ML-инженеров, дата сейнистов и аналитиков эффективности, которые разрабатывают алгоритмы диспетчеризации, балансируют маркетплейс, настраивают юнит-экономику и т.п."
Роман рассказал про структуру команды и как устроена работа с данными. Получилось интересно)
У Романа есть сайт и телеграм-канал, где он делится лайф-хаками визуализации данных, пишет про развитие BI-систем и, в частности, про Tableau. Рекомендую всем BI-разработчикам и всем, кто работает с визуализацией данных. Научитесь продуктовому подходу к построению дашбордов.
И само интервью:
"Я расскажу как устроена работа с данными только в бизнес-аналитике Такси, и то как это вижу я со стороны работы своей команды. Поэтому могу что-то пропустить или не дать глубоких деталей.
Яндекс имеет сильную data-driven культуры, поэтому в Go мы обслуживаем более 800 бизнес-пользователей, которые используют данные для принятия решений.
Основной «солдат» данных — это фуллстэк аналитик. Это супермены, которые могут сами собрать и понять боль бизнеса, подготовить данные, сделать их обработку на Питоне, построить модель и создать дашборд. Лучше всего они разбираются в аналитике, статистике и том направлении бизнеса за которое отвечают (продукт, маркетинг, найм водителей, безопасность и т.п.).
Чтобы помогать им работать с «технической» частью есть инфраструктурные команды: команда Data Management Platform, команды внутренних инструментов и моя команда по визуализации:
— DMP создает инструменты по работе с данными и новые низкоуровневые витрины данных. В их рядах дата-инженеры, партнеры по данным и системные инженеры.
— Команды внутренних инструментов разрабатывает библиотеки для питона, модели и инструменты прогнозирования, платформы для проведения A/B-тестов и системы аналитики в реальном времени. Здесь очень много разных ролей — от фронт-энд разработчиков до ML-инженеров.
— Моя команда помогает аналитикам делать правильные дашборды — мы обучаем и консультируем по работе с Табло, создаем темплейты и стайлгайды, налаживаем процессы управления контентом и делаем самые важные и большие отчеты. У нас в команде BI-разработчики и менеджер продукта.
Получается довольно много ролей, и это только в отделе бизнес-аналитики. А ещё есть большая команда ML-инженеров, дата сейнистов и аналитиков эффективности, которые разрабатывают алгоритмы диспетчеризации, балансируют маркетплейс, настраивают юнит-экономику и т.п."
Reveal the Data
Reveal the Data | Роман Бунин
Сайт про визуализацию данных и развитие BI-систем
Заканчиваем нашу рубрику, в которой опытные специалисты и руководители рассказывают о структуре команд по работе с данными в их компаниях.
И сегодня у нас последнее мини-интервью с Сергеем Брылем - Chief Data Science Officer в MacPaw. У Сергея есть телеграм-канал @analyzecore и блог https://www.analyzecore.com, где он в основном пишет про анализ данных, Data Science и визуализацию с использованием языка R.
Сергей Брыль:
"MacPaw мультипродуктовая компания, в текущем портфеле есть 10 продуктов, которые представлены на различных платформах. Поэтому, продуктовая аналитика для нас является ключевой экспертизой, а продуктовые аналитики - ядром команды аналитики.
На данный момент мы развиваем 6 направлений, которые входят в структуру Data Science Department. Важность и независимость аналитической функции в компании обеспечивается через то, что я представляю ее интересы на уровне Executive team.
Product Analytics. Мы пришли к выводу, что продуктовая аналитика должна быть глубоко интегрирована в продуктовую команду. С самого начала аналитики должны помочь разработать показатели успеха продукта, измерять прогресс и помогать выявлять риски и области роста для бизнеса. Более того, их понимание, основанное на данных, должно быть постоянным вкладом в разработку продукта. Функционально они подчиняются Chief Data Science Officer, а линейно - соответствующим продуктовым менеджерам.
Такой тип организационной структуры дает нам возможность:
- распространять дата-дривен культуру непосредственно на людей, принимающих ежедневные решения, вовлекать в культуру всю продуктовую команду
- всегда быть в контексте происходящего в продукте и очень оперативно и гибко действовать
- добиваться большей синергичности с другими аналитическими командами в решении задач
Кроме вышесказанного, это удобно для продуктового менеджера, иметь единую точку входа в достаточно широкую аналитическую функцию, как в MacPaw. Достаточно пообщаться с аналитиком своей команды, чтобы иметь представление какие дополнительные исследования могут быть сделаны силами всего Data Science направления.
С другой стороны, такая структура предполагает достаточно высокие требования к продуктовым аналитикам как в hard, так и soft skills.
Другие направления построены на специализированной глубокой экспертизе и в организационной структуре представлены в виде сервисов (или экспертных центров).
DataHub - тут сосредоточена наша data инженерная экспертиза. Команда DataHub делает возможной тонко-настраиваемую аналитику с помощью кастомных технических решений и интеграций с продуктами и сервисами.
Особое значение это направление приобретает из-за того, что в портфеле нашей компании продукты на различных платформах, используют различные рекламные каналы, имеют разные модели монетизации и другие специфические особенности.
AI Lab. Миссия команды повышать эффективность процессов и ежедневных решений с помощью Machine Learning.
Этот сервис отвечает за два вектора развития:
- улучшение существующих решений в области продаж продуктов и улучшения пользовательского опыта
- использование машинного обучения как части продукта (фичи)
Market & Customer/User Research - сервис, который дает нам аналитику из внешнего мира о:
- рынках и аудиториях, их особенностях
- пользовательском опыте
Это дает возможность обогащать наши внутренние данных внешними, количественные данные качественными. В итоге, мы получаем взгляд на 360 градусов о предмете изучения. Мы можем сравнить наши успехи на определенном рынке или у определенной аудитории с доступной аналитикой о них. Мы можем подтвердить, опровергнуть или сгенерировать новые гипотезы, которые мы строим о поведении пользователей на наших внутренних данных.
MarTech - сервис, который сфокусирован на автоматизации маркетинга с использованием аналитических данных. Кроме того, это наш инновационный и исследовательский центр. Благодаря работе сервиса, мы являемся бета-тестировщиками, имеем ранний доступ к различным аналитическим и маркетинговым инструментам и более подготовлены к изменениям в этой сфере.
И сегодня у нас последнее мини-интервью с Сергеем Брылем - Chief Data Science Officer в MacPaw. У Сергея есть телеграм-канал @analyzecore и блог https://www.analyzecore.com, где он в основном пишет про анализ данных, Data Science и визуализацию с использованием языка R.
Сергей Брыль:
"MacPaw мультипродуктовая компания, в текущем портфеле есть 10 продуктов, которые представлены на различных платформах. Поэтому, продуктовая аналитика для нас является ключевой экспертизой, а продуктовые аналитики - ядром команды аналитики.
На данный момент мы развиваем 6 направлений, которые входят в структуру Data Science Department. Важность и независимость аналитической функции в компании обеспечивается через то, что я представляю ее интересы на уровне Executive team.
Product Analytics. Мы пришли к выводу, что продуктовая аналитика должна быть глубоко интегрирована в продуктовую команду. С самого начала аналитики должны помочь разработать показатели успеха продукта, измерять прогресс и помогать выявлять риски и области роста для бизнеса. Более того, их понимание, основанное на данных, должно быть постоянным вкладом в разработку продукта. Функционально они подчиняются Chief Data Science Officer, а линейно - соответствующим продуктовым менеджерам.
Такой тип организационной структуры дает нам возможность:
- распространять дата-дривен культуру непосредственно на людей, принимающих ежедневные решения, вовлекать в культуру всю продуктовую команду
- всегда быть в контексте происходящего в продукте и очень оперативно и гибко действовать
- добиваться большей синергичности с другими аналитическими командами в решении задач
Кроме вышесказанного, это удобно для продуктового менеджера, иметь единую точку входа в достаточно широкую аналитическую функцию, как в MacPaw. Достаточно пообщаться с аналитиком своей команды, чтобы иметь представление какие дополнительные исследования могут быть сделаны силами всего Data Science направления.
С другой стороны, такая структура предполагает достаточно высокие требования к продуктовым аналитикам как в hard, так и soft skills.
Другие направления построены на специализированной глубокой экспертизе и в организационной структуре представлены в виде сервисов (или экспертных центров).
DataHub - тут сосредоточена наша data инженерная экспертиза. Команда DataHub делает возможной тонко-настраиваемую аналитику с помощью кастомных технических решений и интеграций с продуктами и сервисами.
Особое значение это направление приобретает из-за того, что в портфеле нашей компании продукты на различных платформах, используют различные рекламные каналы, имеют разные модели монетизации и другие специфические особенности.
AI Lab. Миссия команды повышать эффективность процессов и ежедневных решений с помощью Machine Learning.
Этот сервис отвечает за два вектора развития:
- улучшение существующих решений в области продаж продуктов и улучшения пользовательского опыта
- использование машинного обучения как части продукта (фичи)
Market & Customer/User Research - сервис, который дает нам аналитику из внешнего мира о:
- рынках и аудиториях, их особенностях
- пользовательском опыте
Это дает возможность обогащать наши внутренние данных внешними, количественные данные качественными. В итоге, мы получаем взгляд на 360 градусов о предмете изучения. Мы можем сравнить наши успехи на определенном рынке или у определенной аудитории с доступной аналитикой о них. Мы можем подтвердить, опровергнуть или сгенерировать новые гипотезы, которые мы строим о поведении пользователей на наших внутренних данных.
MarTech - сервис, который сфокусирован на автоматизации маркетинга с использованием аналитических данных. Кроме того, это наш инновационный и исследовательский центр. Благодаря работе сервиса, мы являемся бета-тестировщиками, имеем ранний доступ к различным аналитическим и маркетинговым инструментам и более подготовлены к изменениям в этой сфере.