Иду на Матемаркетинг 18-19 ноября

Конференция пройдёт в Москве со всеми анти-ковидными мерами. В этот раз будет отдельный трек по Analytics Engineering, в основном иду послушать доклады оттуда. Вот какие темы мне интересны:


селф-сервис

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

Это тоже отдельный процесс: нельзя просто кидать в людей креденшелами от базы и фразой «на вот сам посмотри какой там был оборот за прошлую неделю». Надеюсь узнать как это лучше организовать.

Доклады в тему:
⁃ Артем Давтян, Тинькофф, ведущий аналитик - Построение автономной системы обучения аналитиков и продактов работе с Tableau
⁃ Олеся Миронова, head of analytics, Ostrovok.ru - Как мы развивали экспертизу селф-сервис работы с данными во всей компании
⁃ Николай Валиотти, основатель Valiotti Analytics - Этапы проектирования BI-платформы, которая позволяет строить отчеты и получать данные специалистам без знания SQL


организация всего этого дата-дривен балагана

дашборды всё-таки нужны: без них никуда. Как заряд на телефоне — должно быть место, где оно просто показывается (и не надо писать SQL запрос для этого).

но дашбордов становиться всё больше — как уследить, что со старыми всё в порядке, а новые не повторяют уже имеющихся? как новым сотрудникам найти ответ на нужный вопрос в этом обилие дашбордов (и не тыркать аналитиков каждый раз)?

Доклады по теме:
⁃ Роман Бунин, руководитель группы развития BI-систем, Яндекс Go - Фреймворк развития системы отчётности в крупной компании
⁃ Дмитрий Илесин, Head of Data Platform, СберМаркет - Построение эффективного взаимодействия аналитиков данных и команды инженеров. Повышение доступности данных для аналитиков
⁃ Николай Голов, Chief Data Architect, ManyChat - Выбор инструментов построения современной аналитической платформы. Взгляд data-архитектора


И ещё будет отдельный трек в конце второго дня про поиск работы.

Официальная программа в Google Sheets

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

Если тоже идёте — отмечайтесь в комментариях, давайте встречаться)

читаю «Как работает Google», а там такое:

Статистика – это сексуально. Как ни крути. Самые сексуальные занятия в Эпоху Интернета будут включать в себя статистику, причем не только в мире фантазий гиков.

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

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

Данные – это меч XXI века: те, кто хорошо им владеет, – самураи. Так что начните затачивать клинок своего меча, образованные воины, и займитесь статистикой.


Эрик Шмидт, СЕО Гугла писал это ещё в 2014 году. Все, кто работает с данными — самураи 21 века 🤺

Подкаст про зарплату

Болтают Илья Красильщик и Саша Поливанов, в гостях HR-директора Яндекса, Альфа-Банка и Aviasales, плюс два независимых консультанта; а Альфа-Банк даёт деньги на профессиональный монтаж в студии подкастов Либо/Либо.

Деньги — никогда не сама цель обсуждения; деньги — это производная от приносимой бизнесу пользы и сделанной работы (заметьте: последние два не одно и то же).

порядок обсуждения:
1. собрать сделанное за последние полгода (посмотреть есть ли такое)
2. спросить начальника что он про это думает
3. если ваши оценки сделанного совпадают, обсудить куда можно расти и развиваться, чтобы получать больше
4. профит

Приятно слышать , что слово саббатикал уже не такое дикое и постепенно залазит через окно Овертона.

Слушать в iTunes и Overcast



Для ориентира — распределение зарплат по грейдам из Слака ODS (был пост выше); если ваша зарплата меньше третьего квартиля для своего грейда, то крайне рекомендую послушать этот подкаст. А если выше — дайте совет в комментах ))

#подкаст

Рабочий контракт

🐉 Астрологи объявили неделю софтовых рекомендаций.

Представьте ситуацию: аналитик устраивается на работу и работает. Через какое-то время понимает, что уже долго его обязанности и оклад не менялся — что делать? подходит к руководителю и… руководитель пожимает плечами и предлагает составить ПЛАН НА БУДУЩЕЕ (в лучшем случае, да); то есть отслеживание показателей сотрудника ещё только начнётся!

Алексей Шаграев советует поступать иначе: в любой момент между сотрудником и руководителем должен быть чёткий контракт (не путать с трудовым договором). В этом контракте должны быть указаны конкретные действия, которые ожидаются от сотрудника; когда это всё должно быть сделано; и что в итоге сотрудник за это получит.

Лицо Алексея может быть знакомо тем, кто смотрел туториалы по прохождению алгоритмических секций в Яндексе. И вот после 10 лет работы в Яндексе, Алексей ушёл из «любимой компании» и делится опытом как это лучше устроить. Несмотря на название доклада, ²⁄₃ времени он рассказывает как надо работать в компании.

https://www.youtube.com/watch?v=r1aCFpvtPy0

Вопросы на подумать:
⁃ Над чем сейчас работаете?
⁃ Когда следующая встреча с руководителем по оценке итогов вашей работы?
⁃ Что от вас ждут? А чего ожидаете вы от этой встречи?

Как в 2019 году в Яндекс Такси «взорвался» DWH

Фёдор Лаврентьев — руководитель тамошнего хранилища — рассказал на конференции HighLoad, как хранилище перестало выполнять свои задачи и как они потом это всё чинили (на первый этап ушёл год).

Само хранилище разрабатывали с 2016 года. Как обычно, всё начинается с одной прикладной задачи, потом добавляется ещё одна и так наслаивается одна за другой. А про общую архитектуру подумать как-то всё некогда.

В какой-то момент начинается «ой всё сложно»: пайплайны падают. Витрины опаздывают. Данные неверные. Бизнес негодует.

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

В итоге окончательно ломается контроль над рантаймом: не знаешь что происходит прямо сейчас.

Хочется всё взять и переписать!

Но тут надо разобраться.

В итоге родился план «Вулкан» в три этапа:

I Архитектура
1. Придумать целевую архитектуру
2. Наметить план перехода к ней (неотделимо от п. 1)

II Рутина
3. Почистить бэклог
4. Наладить работу с закзчиками

III Техдолг
1. Найти и замониторить всё важное
2. Переписать легаси-процессы
3. Перестать плодить легаси-код

Разделить команду на инфраструктуру и продукт

Команда инфраструктуры:
⁃ Разработчики с широким кругозором
⁃ Найм небольшой

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

Команда развития продукта:
⁃ Разработчики, близкие к бизнес процессу
⁃ «Реальная» работа (в терминах бизнеса)
⁃ Весь найм сюда

Работа начала налаживаться, но система имеет большую инерцию и по-прежнему пайплайны падают. Просто взять и переписать всё с нуля заняло бы год (= полностью остановить работу над продуктом на это время).

Решение:
⁃ Выделить квоты времени на починку самого важного: 20-40% своего времени разработчики разбираются с технологом.
⁃ Ввести «дежурство». Разработчик на 100% времени занимается стабильностью системы: выкатывает релизы, оперативно чинит мелкие баги, сложные — диагностирует и делегирует. Дежурят все по очереди.

[ЧЕРЕЗ ПОЛГОДА] Команда инфраструктуры приносит работающий продукт:
⁃ Понятно, какие СУБД нужны
⁃ Какие бывают «стрелочки» между ними
⁃ Как раскладывать данные на слои

<<< здесь пригождается план перехода с текущей архитектуры на целевую (только что ↑ придуманную)


Как отрефакторить большой DWH? Разделить на небольшие кусочки!

Как монолит делят на микросервисы, так и хранилище данных можно разделить на свои етл-сервисы. Каждый по отдельности проще отрефакторить, чем всё и сразу (и потом ещё удобно стыдить другие сервисы за их отсталость!).

Ещё в каждом етл-сервисе свои релизы — можно тестить новые фичи независимо от других сервисов.


[ЕЩЁ ЧЕРЕЗ ГОД] Изменения в команде

Команда инфраструктуры:
⁃ Целевая картина появилась и работает
⁃ Разработчики узко специализированы

Команда продукта:
⁃ Выросла в 2 раза
⁃ Переписали самое болезненное легаси
⁃ Собрали «низкие фрукты»
⁃ Наладился контакт с бизнес-заказчиками

Следующие цели:
⁃ Ускорять работу продукта
⁃ Переходим на работу по эпикам
⁃ В каждый эпик подмешиваем рафакторинг

Видео с доклада на Youtube | Презентация на сайте конференции

прямо сейчас идёт конференция Матемаркетинг — на сайте есть трансляция одного трека (из трёх доступных).

Уже был мега-полезный доклад от Влада Флакса про общие концепции как сделать данные на бещбордах актуальными

И новый бомбический доклад Ромы Бунина (лучше, чем новый фильм Марвел!) — ещё один взгляд под капот архитектуры дашбордов на примере Яндекс GO.

https://youtu.be/BowbeThqKmU
(идёт трансляция, поэтому не даёт дать ссылку на конкретный таймкоды — Флакс был в начале, Бунин примерно на 1:15 от начала)

П.С.: я сейчас здесь, на выставке — если что, давайте встречаться :-)

Что болит

Общее впечатление что все хотят в data driven. Уже никого не надо убеждать в ценности данных — этот этап пройден.

Теперь следующая проблема — данные собрали, пайплайны настроили, первые дашборды нарисовали. Постепенно данных становится всё больше: добавляются новые, старые — меняются. И в какой-то момент наступает ДАТА-ХАОС!

И вот сейчас основные боли — это документация и описанные модели данных.
⁃ Таблицы на десятки и сотни колонок без описания и странными названиями
⁃ Таблиц по заказам — пять разных вариантов (плюс ещё сколько-то вьюх по ним)
⁃ Эвенты, названные абы как
⁃ Метрики, которые каждый рассчитывает по-своему и в конце ни у кого ничего не сходится ¯\_(ツ)_/¯

Короче, тренд сезона — дата-инфраструктура.

Документация на данные

Принцип «всё как код» — и таблицы тоже.

Частая проблема в документации — её просто нет ¯\_(ツ)_/¯ а если есть, то она устаревшая.

Так бывает, когда документация не зависит от текущей реальности: красивые описания живут в модном Ноушене, но DDL в Postgres ничего про это не знает))

Что делать? Переселить документацию ближе к реальности. В Яндекс.Такси решили, что все сущности в ДВХ будут описываться в коде — названия, колонки, их тип и комментарии (!). Нельзя просто так поменять атрибут без изменения документации — всё связано.

А раз описания уже в коде, это всё версионируется через гит с указанием ответственных. К тому же всё можно обвешать автотестами (всё как у настоящих разработчиков!): назвал колонку не по канону — не сможешь замержить свой пулл-реквест, пока не исправишь.

А ещё пулл-реквесты удобно ревьюить. Скинул ссылку старшему коллеге и он в одном месте видит все изменения, аккуратно подсвеченные. Если что не так — комментит нужную строку.