Приветики, теперь о действительно важных вещах! У меня тут произошло незапланированное обновление винды, пока устанавливаю всякий софт, захотелось обновить и оформление R Studio. Выбрал 3 фаворита, никак не определюсь 😅
1-й Дефолтный Tommorow Night 80s (пусть будет 🤷♀️)
2-й Дефолтный Material (🤷♂️)
3-й Кастомный Dracula, нагло спёртый с тёмной темы PyCharm (🤷)
1-й Дефолтный Tommorow Night 80s (пусть будет 🤷♀️)
2-й Дефолтный Material (🤷♂️)
3-й Кастомный Dracula, нагло спёртый с тёмной темы PyCharm (🤷)
🤷16🤷♀12🤷♂8
📌 R или Python (1/2)
Я уже писал про выбор языка, но тогда это было совсем поверхностно. Сейчас я хочу чуть более комплексно сравнить эти два мощных инструмента аналитиков.
Оба языка прекрасно справляются с задачами обработки и анализа данных, визуализацией, и задачами машинного обучения. На базовом уровне одно и то же. А вот в деталях у них уже видны расхождения.
Если ты находишься на этапе выбора языка, я приведу тут наиболее сильные стороны обоих, а ты уж смотри сам что тебе нужнее.
Аргументы в пользу R:
🔵 Пакеты для стат. анализа: R изначально разрабатывался статистиками для статистиков, поэтому тут огромный набор пакетов, специально для стат. анализа. Да, в Python они тоже есть, но многие перекочевали из R почти без изменений, тот же
🔵 Визуализация:
🔵 Анализ временных рядов: Пакеты
🔵 CRAN: (Сеть архивов комплексных пакетов) крайне удобная штука, которая позволяет быстро найти пакет под любую аналитическую задачу или стат. метод. Обеспечивает высокую гибкость и модульность в развитии языка. Во всех статьях это один из главных аргументов в пользу R. Я с этим полностью согласен 🙂
🔵 Интеграция с документами: Через R Markdown и Shiny можно интегрировать анализ данных куда угодно, никаких файлов ноутбуков — прямой импорт хоть в док, хоть в интерактивный апп.
Я уже писал про выбор языка, но тогда это было совсем поверхностно. Сейчас я хочу чуть более комплексно сравнить эти два мощных инструмента аналитиков.
Оба языка прекрасно справляются с задачами обработки и анализа данных, визуализацией, и задачами машинного обучения. На базовом уровне одно и то же. А вот в деталях у них уже видны расхождения.
Если ты находишься на этапе выбора языка, я приведу тут наиболее сильные стороны обоих, а ты уж смотри сам что тебе нужнее.
Аргументы в пользу R:
statsmodels это сборка базовых функций R, pandas вдохновлён dplyr, а seaborn старается перенести питонистам декларативный подход из ggplot2. Так как R больше популярен в научной среде, новые методы и техники сначала появляются здесь.ggplot2 считается одним из лучших пакетов для создания сложных графиков. Он вышел в 2005 и активно развивается. Сейчас он способен создать почти любую визуализацию, ограничен только фантазией автора.forecast и tseries пока, вроде как, являются наиболее полноценными инструментами для этой задачи. Они часто используются в эконометрике и фин. моделировании.Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤1
📌 R или Python (2/2)
Аргументы в пользу Python:
🔵 ML и DL: Из-за
🔵 NLP: Библиотеки
🔵 Веб-разработка: Python поддерживает Django и Flask, поэтому задачи, которые требуют на выходе интерфейсов для взаимодействия с пользователями тут создавать тупо удобнее. В R это пытается делать Shiny, но он пока далёк от такого.
🔵 Автоматизация: Тут R даже не пытается конкурировать, под задачи автоматизации там ничего сносного не завезли. Нет, он, конечно умеет в скриптинг, даже Airflow его поддерживает. Но шансы увидеть на проде скрипты автоматизации через R примерно такие же, как найти горшочек лепрекона.
🔵 Интеграция с другими языками: Python в плане интеграции в разработку намного более гибкий, особенно полезно при разработке приложений, где анализ данных это не самоцель, а лишь часть большого приложения, требующего взаимодействия с базами данных, веб-сервисами и тд.
Для исследований, стат. анализа, визуализации и публикаций материалов я бы смотрел в сторону R. И так уж совпало, что это стандартный набор задач продуктовой аналитики.
Python более интересен в первую очередь для DS, в этой сфере он является заслуженным стандартом. Для DA, скорее всего, выбор Python тоже более оправдан из-за задач автоматизации и контроля качества данных.
Аргументы в пользу Python:
TensorFlow, PyTorch и scikit-learn, Python считается стандартом для машинного и глубокого обучения. Мощно, быстро, качественно.NLTK, spaCy и transformers для обработки естественного языка намного мощнее аналогов R. Топ инструмент для чат-ботов, переводчиков или анализа текстов.В целом, оба языка могут справиться с любыми аналитическими задачами, просто где-то удобнее один, а где-то другой.
Для исследований, стат. анализа, визуализации и публикаций материалов я бы смотрел в сторону R. И так уж совпало, что это стандартный набор задач продуктовой аналитики.
Python более интересен в первую очередь для DS, в этой сфере он является заслуженным стандартом. Для DA, скорее всего, выбор Python тоже более оправдан из-за задач автоматизации и контроля качества данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
📌 Один из способов запроса воронки
В работе часто приходится анализировать какие-нибудь воронки или последовательности с условиями. Например юзер сделал то-то, потом вот это, а потом то. Есть миллион разных способов как собрать такой лог, но мне в последнее время нравится вот такой, можно сказать, сниппет, с использованием множественных cte. Он простой, кастомизируемый и достаточно надёжный в плане точности.
Вот как он может выглядеть на примере расчёта проходимости через авторизацию в приложении через смс. Основан на фронтовых ивентах, но это вообще не важно.
🔵 В этом примере есть экран, страница или любой другой индикатор что юзер попал на страницу логина,
🔵 потом жмякнул по авторизации через смс
🔵 и успешно залогинился, попав на главную.
Логика простая, собираем отдельно каждый шаг, а потом склеиваем поюзерно с соблюдением таймингов — второй шаг после первого, третий за вторым и т.д. Я ещё добавил фильтр что это всё в один день. Но тут можно что угодно навешивать. Вообще можно независимо кастомить условия на любом шаге.
В итоге будет таблица, где
Забирайте, пользуйтесь 🙂
#сниппеты
В работе часто приходится анализировать какие-нибудь воронки или последовательности с условиями. Например юзер сделал то-то, потом вот это, а потом то. Есть миллион разных способов как собрать такой лог, но мне в последнее время нравится вот такой, можно сказать, сниппет, с использованием множественных cte. Он простой, кастомизируемый и достаточно надёжный в плане точности.
Вот как он может выглядеть на примере расчёта проходимости через авторизацию в приложении через смс. Основан на фронтовых ивентах, но это вообще не важно.
Логика простая, собираем отдельно каждый шаг, а потом склеиваем поюзерно с соблюдением таймингов — второй шаг после первого, третий за вторым и т.д. Я ещё добавил фильтр что это всё в один день. Но тут можно что угодно навешивать. Вообще можно независимо кастомить условия на любом шаге.
В итоге будет таблица, где
NULL в датах это потери, т.е. юзер дропнулся. Дальше можно уже как угодно это агрегировать и делать что там было нужно.Забирайте, пользуйтесь 🙂
# Собираем данные по первому шагу
with login as (
select user_id,
timestamp as login_screen_dt
from db
where date(timestamp) >= current_date - 30
and event = 'screen_view'
and screen_name = 'login'
),
# По второму
sms_screen as (
select user_id,
timestamp as sms_screen_dt
from db
where date(timestamp) >= current_date - 30
and event = 'screen_view'
and screen_name = 'sms'
),
# По третьему
home_page as (
select user_id,
timestamp as home_page_dt
from db
where date(timestamp) >= current_date - 30
and event = 'screen_view'
and screen_name = 'home_page'
)
# Склеиваем это всё
select ls.*,
ss.sms_screen_dt,
hp.home_page_dt
from login ls
left join sms_screen ss on ls.user_id = ss.user_id
and ls.login_screen_dt <= ss.sms_screen_dt
and date(ls.login_screen_dt) = date(ss.sms_screen_dt)
left join home_page hp on ss.user_id = hp.user_id
and ss.sms_screen_dt <= hp.home_page_dt
and date(ss.sms_screen_dt) = date(hp.home_page_dt)
#сниппеты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍9
📌 Метрика Retention Rate (1/2)
Показатель удержания (RR) — одна из главных метрик приложений SaaS. Показывает насколько приложение “увлекает” пользователей.
Метрика, сама по себе, простая, но тут есть несколько нюансов, о которых нельзя забывать.
Есть два типа расчёта этой метрики:
🔵 N-day, или классический способ — расчёт в точности на день. В такой концепции RR 7-го дня (R7) показывает сколько юзеров вернулось именно на 7-й день после первого запуска.
🔵 Rolling — более гибкий подход, здесь R7 показывает сколько юзеров вернулось на 7-й день или позже.
У метода Rolling есть весомый нюанс — он не стабилен. Исходя из определения, если юзер установил приложение, потом забросил его и вернулся через месяц — у тебя поплывут все значения на все дни до, т.к. каждый учитывается по условию “вернулся на день N или позже”.
Rolling иногда полезен для продуктов с долгими циклами, дизайн которых не предполагает ежедневного использования. Например приложение по аренде отелей, куда юзер не возвращается каждый день (и это нормально).
Показатель удержания (RR) — одна из главных метрик приложений SaaS. Показывает насколько приложение “увлекает” пользователей.
Метрика, сама по себе, простая, но тут есть несколько нюансов, о которых нельзя забывать.
Есть два типа расчёта этой метрики:
Правильнее, в большинстве случаев, использовать классический подход. Это связано с устоявшимися нормами в индустрии. Если ты хочешь сравнить показатели своего продукта с бенчмарками, то там почти всегда будет классический расчёт.
У метода Rolling есть весомый нюанс — он не стабилен. Исходя из определения, если юзер установил приложение, потом забросил его и вернулся через месяц — у тебя поплывут все значения на все дни до, т.к. каждый учитывается по условию “вернулся на день N или позже”.
Rolling иногда полезен для продуктов с долгими циклами, дизайн которых не предполагает ежедневного использования. Например приложение по аренде отелей, куда юзер не возвращается каждый день (и это нормально).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥1
📌 Метрика Retention Rate (2/2)
Ещё одним нюансом в расчёте RR является окно расчётов.
Оно бывает календарное или 24-х часовое. В календарном подходе день N считается по дате, а в часовом — по окну в 24 часа. Т.е. в подходе с часами для каждого юзера день будет завершаться по своему. Это более точно, но менее удобно. Обычно так редко заморачиваются и используют календарный.
В этой схеме выделяют три сегмента:
🔵 Краткосрочный RR — это R1-R3, показывает первые впечатления, чтобы увеличить эти показатели нужно работать с первыми сессиями.
🔵 Среднесрочный RR — промежуток где-то между R7-R14, самый сложный в управлении, обычно где-то здесь должно происходить раскрытие A-ha момента.
🔵 Долгосрочный RR — от R21 и выше, почти не управляемый сам по себе сегмент, во многом он зависит от успешности первых двух.
На что вообще обращать внимание на графике? Во-первых нужно оценивать эти сегменты, они помогут понять где можно поработать над удержанием, всё ли ок с первыми сессиями и происходит ли “щелчок” на средней дистанции.
Во-вторых, ищи плато. Ближе к долгосроку график выравнивается, вот тут происходит формирование кор-аудитории. И чем раньше оно начинается, тем лучше.
P.S. Надо завязывать с двойными постами, конечно 😅
Ещё одним нюансом в расчёте RR является окно расчётов.
Оно бывает календарное или 24-х часовое. В календарном подходе день N считается по дате, а в часовом — по окну в 24 часа. Т.е. в подходе с часами для каждого юзера день будет завершаться по своему. Это более точно, но менее удобно. Обычно так редко заморачиваются и используют календарный.
График RR часто строят в пределах 30 дней. Контрольными точками обычно являются 1, 3, 7, 14, 21 и 30-й дни.
В этой схеме выделяют три сегмента:
На что вообще обращать внимание на графике? Во-первых нужно оценивать эти сегменты, они помогут понять где можно поработать над удержанием, всё ли ок с первыми сессиями и происходит ли “щелчок” на средней дистанции.
Во-вторых, ищи плато. Ближе к долгосроку график выравнивается, вот тут происходит формирование кор-аудитории. И чем раньше оно начинается, тем лучше.
P.S. Надо завязывать с двойными постами, конечно 😅
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥5
📌 Сомнительные рабочие практики
В твиттере на днях разгонялисрач дискуссию про информационную гигиену в работе. Там было больше с уклоном в собесы и лайв кодинг, но и ряд общих моментов тоже затронули.
Прокомментирую со своей стороны:
🔵 Переработки. Абсолютное зло, тут даже что-то обсуждать странно. С огромной натяжкой это может быть ок, если это заранее оговорённая разовая история с доплатой ради какого-то великого (не для тебя, конечно) дела. Но не вот эти ежедневные, потому что надо было вчера. Горят сроки, сгори и ты 😄
🔵 Активность в слаке вне рабочее время. В том же твиттере часто бомбят потому что “начальник написал мне в 9 вечера!”. Ну написал и написал, может он только что вспомнил и отправил чтобы не забыть, подумаешь. А вот если ты считаешь что это не ждёт до утра, или, что ещё хуже — он так считает — это уже звоночек.
🔵 Созвоны по любым вопросам. Активность чуть более чем бесполезная и должна умереть вообще. Одно дело, когда вопрос объёмный и важный, есть протокол, и по итогам это выливается в какие-то артефакты, типа задач или документации. Совсем другое когда это созвон ради созвона, особенно если разбирается 1-2 вопроса, которые нужно просто прояснить. А если по итогу ничего нигде не документируется, можно считать вы просто прожгли время нескольких человек.
🔵 Дейлики. Спорная тема, причём чем дольше работаешь, тем больше переходишь в лагерь “оно ненужное”. Полно статей по тайм-менеджменту, и ни в одной никто всерьёз не пытается защищать дейли. Они создавались как 15-ти минутные синхро внутри команды с общей задачей, но переросли в какой-то мутный мит, где половина присутствующих никак не задействована в задаче другой половины. Часовые дейли, на котором одновременно присутствует и бэк и дизайн обожаю всей душой. Они оправданы только в случае когда у вас кроме этого инструмента синхронизации больше ничего нет. Если есть хотя бы слак и джира, то я не вижу ни одной причины оставлять их. Совсем другое дело это викли, раз в неделю. Вот тут смысл уже есть, но он немного в другом 🙂
В твиттере на днях разгоняли
Прокомментирую со своей стороны:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16
Тем временем, наши американские коллеги занимаются действительно важными исследованиями 🙂
https://naked-science.ru/article/medicine/vypivayushhie-vmeste-supr
https://naked-science.ru/article/medicine/vypivayushhie-vmeste-supr
Naked Science
Выпивающие вместе супруги прожили дольше, чем трезвенники и пары с одним пьющим партнером
Американские ученые установили, что, когда у мужа с женой схожие привычки в плане спиртного и они предпочитают употреблять алкоголь вместе, продолжительность жизни у таких людей выше, чем у непьющих супругов или если в паре выпивает кто-то один.
👍7😁4🤔2🎉2
This media is not supported in your browser
VIEW IN TELEGRAM
Мне этот найм абсолютно понятен, и я здесь ищу только одного — покоя, умиротворения и вот этой гармонии.
Я как будто бы уже давно глубокий синьор, бессмертный, ну или там уже почти бессмертный, который в этом айти от его самого зарождения
Я как будто бы уже давно глубокий синьор, бессмертный, ну или там уже почти бессмертный, который в этом айти от его самого зарождения
😁18🔥10
📌 Алгоритм цепей Маркова
Иногда в работе прилетают нестандартные задачи. При решении таких, ты сначала пытаешься придумать логику, а потом идёшь гуглить подходящие алгоритмы. Перебираешь реализации, пока не находишь подходящую, а потом, естественно, сохраняешь в папочку.
Наверное, у каждого аналитика есть папочка с алгоритмами, которые он использовал всего пару раз 🙂 У меня, конечно, тоже есть. Поделюсь моим любимым вариантом реализации алгоритма цепей Маркова.
В продуктовой аналитике этот алгоритм может использоваться для построения последовательностей действий юзеров в приложении. Такой более детализированный аналог sankey-диаграмм.
Одна из любимых задач на аналитику от начинающих продактов — это “посмотреть как юзеры перемещаются по страницам”. Почему эта болячка только у начинающих? Потому что из таких карт, самих по себе, редко можно что-то вытащить, не имея заготовленных “правильных” вопросов. Если у тебя есть хоть какое-то представление о своём продукте, ты скорее всего, итак сможешь сформулировать поэкранный флоу юзера. И, скорее всего, это будет с высокой степенью точности.
Тем не менее, хорошо бы иметь заготовленное решение, на случай, когда оно понадобится. А с этим все сталкиваются, рано или поздно 🙂
Перейдём к реализации. Тут всё просто:
1️⃣ Клонируем себе репозиторий.
2️⃣ Готовим данные в строгом соответствии с гайдом: первая колонка — ID юзера, вторая — название узла цепочки (например, событие или название посещённой страницы), последняя — время в цифровом формате. Названия колонок удаляем, сохраняем файл в
3️⃣ Пропускаем таблицу через python-скрипт, запускаем, получаем на выходе файл
4️⃣ Открываем файл через Gephi, и там уже настраиваем оформление.
#инструменты
Иногда в работе прилетают нестандартные задачи. При решении таких, ты сначала пытаешься придумать логику, а потом идёшь гуглить подходящие алгоритмы. Перебираешь реализации, пока не находишь подходящую, а потом, естественно, сохраняешь в папочку.
Наверное, у каждого аналитика есть папочка с алгоритмами, которые он использовал всего пару раз 🙂 У меня, конечно, тоже есть. Поделюсь моим любимым вариантом реализации алгоритма цепей Маркова.
Немного теории. Цепи Маркова — это последовательность событий, где каждое следующее событие ориентируется только на предыдущее и не зависит от остальных событий в цепочке.
В продуктовой аналитике этот алгоритм может использоваться для построения последовательностей действий юзеров в приложении. Такой более детализированный аналог sankey-диаграмм.
Одна из любимых задач на аналитику от начинающих продактов — это “посмотреть как юзеры перемещаются по страницам”. Почему эта болячка только у начинающих? Потому что из таких карт, самих по себе, редко можно что-то вытащить, не имея заготовленных “правильных” вопросов. Если у тебя есть хоть какое-то представление о своём продукте, ты скорее всего, итак сможешь сформулировать поэкранный флоу юзера. И, скорее всего, это будет с высокой степенью точности.
Тем не менее, хорошо бы иметь заготовленное решение, на случай, когда оно понадобится. А с этим все сталкиваются, рано или поздно 🙂
Перейдём к реализации. Тут всё просто:
worklist.csv.Graph.gexf.#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍8
В твиттере наткнулся на видос, у которого незаслуженно мало лайков.
Если ты рассылаешь резюме для поиска работы, то обязательно посмотри. База по найму глазами рекрутера — про 6 секунд на резюме, почему навыки должны быть сверху и т.д. Можно вынести какие-то идеи по доработке своего резюме, чтобы успешнее проходить HR-отбор.
Они обсуждают в контексте рынка США, но глобально работа HR не особо сильно меняется от региона к региону.
https://youtu.be/fEZaI7b6fi4?si=YQg0ccRE90hMhRcO
Если ты рассылаешь резюме для поиска работы, то обязательно посмотри. База по найму глазами рекрутера — про 6 секунд на резюме, почему навыки должны быть сверху и т.д. Можно вынести какие-то идеи по доработке своего резюме, чтобы успешнее проходить HR-отбор.
Они обсуждают в контексте рынка США, но глобально работа HR не особо сильно меняется от региона к региону.
https://youtu.be/fEZaI7b6fi4?si=YQg0ccRE90hMhRcO
YouTube
Как устроен процесс поиска кандидатов и как сделать так, чтобы ваше резюме рассмотрели.
Хотели бы вы узнать больше о процессе работы над вакансией глазами рекрутера? Попасть в закулисье рутины рекрутера, узнать о том, как принимаются решения и отбираются кандидаты?
Вместе с гостем моего канала - Юлей Чимисовой мы решили приоткрыть занавесу…
Вместе с гостем моего канала - Юлей Чимисовой мы решили приоткрыть занавесу…
❤11👍3
Прикольный эксперимент. Чел создал супер резюме прогера джуна и хотел посмотреть конверсии в отклик и оффер. Но что-то пошло не по плану.
С одной стороны, статистика грустная, с другой — по словам HR-ов из комментов — олимпиадники склоны к оверинжинирингу и сложно переобучаемы. Для многих нанимающих такой джун — это ходячий редфлаг 🚩
С одной стороны, статистика грустная, с другой — по словам HR-ов из комментов — олимпиадники склоны к оверинжинирингу и сложно переобучаемы. Для многих нанимающих такой джун — это ходячий редфлаг 🚩
😁13😢8👍4
📌 Идеи и гипотезы
Когда я только начинал, иногда у меня были проблемы с генерацией идей для развития продуктов. Ну это какой-то высокий уровень креатива нужен, что ли. Сидишь, придумываешь что-то из ничего.
А иногда наоборот, сидишь с дизайнером или продактом, обсуждаешь какое-то исследование и они сами собой возникают. Как так то?
А дело было в неправильном понимании терминологии.
Идея, сама по себе, это что-то общее. Что бы нам такого сделать, чтобы все метрики выросли и мы заработали больше денег. Идея предлагает новое направление или функцию без предварительной проверки ее жизнеспособности или влияния.
Гипотеза, с другой стороны, это предположение, которое делается на основе имеющихся данных или предварительного анализа и требует проверки. Гипотеза обычно формулируется в виде утверждения, которое можно подтвердить или опровергнуть путем экспериментов или анализа данных. Гипотеза связана с предположениями о том, как определенное изменение продукта повлияет на поведение пользователей или достижение бизнес-целей.
Задачей аналитика является генерация именно гипотез. Генерация идей это что-то про менеджмент продукта.
Придумать гипотезу — это более логическая задача, чем придумать идею, потому что присутствуют ограничители.
Так что, если ты вообще не творческий, не бойся строки в вакансии об “умении генерировать идеи”, скорее всего там про гипотезы.
Когда я только начинал, иногда у меня были проблемы с генерацией идей для развития продуктов. Ну это какой-то высокий уровень креатива нужен, что ли. Сидишь, придумываешь что-то из ничего.
А иногда наоборот, сидишь с дизайнером или продактом, обсуждаешь какое-то исследование и они сами собой возникают. Как так то?
А дело было в неправильном понимании терминологии.
Идея, сама по себе, это что-то общее. Что бы нам такого сделать, чтобы все метрики выросли и мы заработали больше денег. Идея предлагает новое направление или функцию без предварительной проверки ее жизнеспособности или влияния.
Гипотеза, с другой стороны, это предположение, которое делается на основе имеющихся данных или предварительного анализа и требует проверки. Гипотеза обычно формулируется в виде утверждения, которое можно подтвердить или опровергнуть путем экспериментов или анализа данных. Гипотеза связана с предположениями о том, как определенное изменение продукта повлияет на поведение пользователей или достижение бизнес-целей.
Задачей аналитика является генерация именно гипотез. Генерация идей это что-то про менеджмент продукта.
Придумать гипотезу — это более логическая задача, чем придумать идею, потому что присутствуют ограничители.
Вот например, вы выкатили фичу, которая потенциально может быть полезна всем сегментам аудитории, но спрятали её глубоко внутрь интерфейса. Из-за этого, она не производит особого эффекта и ей никто не пользуется. Вот тут можно выдвинуть гипотезу о проверке фичи, если вы её перенесёте куда-нибудь на более видное место. Т.е. гипотеза тут уже сама напрашивается. А вот изначальную идею о разработке этой фичи придумать уже не так просто.
Так что, если ты вообще не творческий, не бойся строки в вакансии об “умении генерировать идеи”, скорее всего там про гипотезы.
👍16🤔3
📌 Про мой худший онбординг
Кулстори про худший онбординг, который я застал в своей практике.
Если кто не вкурсе, онбордниг — это этап погружения в работу в новой компании. Сюда включается получение доступов, знакомство с командой, погружение в бизнес, знакомство со структурой данных и стеком, тренировка на каких-то базовых ad-hoc задачках. Всё для того, чтобы ты плавно въезжал и не охреневал от того, что тут всё не так как было раньше.
Нормальный этап онбординга длится весь первый месяц, иногда дольше, если специфика бизнеса более замудрённая.
Попал я как-то в одну компанию, где меня определили в отдел к ML-щикам, в котором аналитики до этого не было. Суть работы была в анализе алгоритмов с точки зрения их влияния на экспириенс пользователей и консультации ребят по их улучшению.
Сайентисты пилили модели и складывали их данные в какие-то свои базы в каком-то своём формате, как они считали правильным, о которых никто в команде аналитики вкурсе не был, т.к. штука новая. И это, в целом, ок, сиди себе, разбирайся, документируй, вноси правки в структуру — одним словом подгоняй под себя, тебе с этим жить.
Ещё был такой момент — разные по смыслу данные хранились на разных серверах, т.е. инфа по юзерам, монетизация и всё такое складывались в одном месте, а клики и взаимодействие с фронтом в другом.
Стоит ли говорить о нестыковках даже в таких базовых вещах как user_id, которые были просто разными сущностями и мержились только при помощи создания выгрузок (данные по кликам за месяц на сотни гигов, чтобы найти конкретный список юзеров…), внешнего инструмента (в моём случае R) и шаманского бубна. И даже это ок, если разобраться и принять правила игры.
Ещё один прикол это внутренняя терминология, тонны терминологии. И это не какие-то специфические термины бизнеса, которые гуглятся, нет, это совсем внутрянка для своих. И это, как ни странно, тоже ок, к такому со временем привыкаешь.
Не ок во всём этом был один маленький нюанс — онбординг тут был только по одному пункту — настройка google-окружения. Ну там какой софт прикручен к аккаунту, как пользоваться почтой, что такое календарь. Ну вот эти жёсткие моменты, которые обязательно нужно объяснять.
О том, что ни один коннектор не работает без корп. VPN, о том что доступ к половине данных осуществляется через удалённую машину, о том, что колонки таблиц не означают то, что можно подумать из их названий — догадаешься сам.
И, желательно разобраться в этом всём за неделю пока получаешь доступы, потому что 10 тасок у тебя уже горят, а половина из них вообще не стандартные, т.к. базируются на новых таблицах ML-щиков, с которыми, напоминаю, пока никто не пытался взаимодействовать.
Где-то через неделю я получил доступы и осуждающие взгляды тимлидов, типа это было долго. На что я им в итоге выкатил документ, в котором описал все приключения с получением доступов, к кому надо идти чтобы от него получить другое направление и может быть там уже кто-то вкурсе, какой софт нужно ставить, как провернуть подключение к удалённой машине и какие скрипты перед этим нужно прогнать и т.д.
В итоге за первый месяц я научил своего ментора как устроены данные в ML, почему user_id у него и у меня это вообще разное, сопроводив скриптом на сотню строк как их стандартизировать, как получить нужный массив из json’а который нужно собрать из строки и ещё кучу всяких таких нюансов. Он посидел, поофигевал от того что как-то чёта всё сложнее чем ему казалось, но мне уже было всё равно 🙂 я допинал месяц и пулей оттуда свалил.
Это окей, когда вы кидаете новичка на боевые задачи в первую неделю, но задача должна быть ознакомительной, базовой, про знакомство с метриками и структурой данных, про погружение в бизнес и внутрянку. Так же окей, когда онбординг не подразумевает боевых задач, а больше с уклоном во внутреннюю теорию.
Но когда первая задача на 90% не уточняемая ни у кого, работающая через костыли, которые ещё сначала нужно придумать, и дедлайн неделя сразу после доступов… Я всякого повидал, но это какой-то рак. Не надо так.
#кулстори
“Если в первую неделю вам кажется что работа говно — вам не кажется”.
Кулстори про худший онбординг, который я застал в своей практике.
Если кто не вкурсе, онбордниг — это этап погружения в работу в новой компании. Сюда включается получение доступов, знакомство с командой, погружение в бизнес, знакомство со структурой данных и стеком, тренировка на каких-то базовых ad-hoc задачках. Всё для того, чтобы ты плавно въезжал и не охреневал от того, что тут всё не так как было раньше.
Нормальный этап онбординга длится весь первый месяц, иногда дольше, если специфика бизнеса более замудрённая.
Попал я как-то в одну компанию, где меня определили в отдел к ML-щикам, в котором аналитики до этого не было. Суть работы была в анализе алгоритмов с точки зрения их влияния на экспириенс пользователей и консультации ребят по их улучшению.
Сайентисты пилили модели и складывали их данные в какие-то свои базы в каком-то своём формате, как они считали правильным, о которых никто в команде аналитики вкурсе не был, т.к. штука новая. И это, в целом, ок, сиди себе, разбирайся, документируй, вноси правки в структуру — одним словом подгоняй под себя, тебе с этим жить.
Ещё был такой момент — разные по смыслу данные хранились на разных серверах, т.е. инфа по юзерам, монетизация и всё такое складывались в одном месте, а клики и взаимодействие с фронтом в другом.
Стоит ли говорить о нестыковках даже в таких базовых вещах как user_id, которые были просто разными сущностями и мержились только при помощи создания выгрузок (данные по кликам за месяц на сотни гигов, чтобы найти конкретный список юзеров…), внешнего инструмента (в моём случае R) и шаманского бубна. И даже это ок, если разобраться и принять правила игры.
Ещё один прикол это внутренняя терминология, тонны терминологии. И это не какие-то специфические термины бизнеса, которые гуглятся, нет, это совсем внутрянка для своих. И это, как ни странно, тоже ок, к такому со временем привыкаешь.
Не ок во всём этом был один маленький нюанс — онбординг тут был только по одному пункту — настройка google-окружения. Ну там какой софт прикручен к аккаунту, как пользоваться почтой, что такое календарь. Ну вот эти жёсткие моменты, которые обязательно нужно объяснять.
О том, что ни один коннектор не работает без корп. VPN, о том что доступ к половине данных осуществляется через удалённую машину, о том, что колонки таблиц не означают то, что можно подумать из их названий — догадаешься сам.
И, желательно разобраться в этом всём за неделю пока получаешь доступы, потому что 10 тасок у тебя уже горят, а половина из них вообще не стандартные, т.к. базируются на новых таблицах ML-щиков, с которыми, напоминаю, пока никто не пытался взаимодействовать.
Где-то через неделю я получил доступы и осуждающие взгляды тимлидов, типа это было долго. На что я им в итоге выкатил документ, в котором описал все приключения с получением доступов, к кому надо идти чтобы от него получить другое направление и может быть там уже кто-то вкурсе, какой софт нужно ставить, как провернуть подключение к удалённой машине и какие скрипты перед этим нужно прогнать и т.д.
В итоге за первый месяц я научил своего ментора как устроены данные в ML, почему user_id у него и у меня это вообще разное, сопроводив скриптом на сотню строк как их стандартизировать, как получить нужный массив из json’а который нужно собрать из строки и ещё кучу всяких таких нюансов. Он посидел, поофигевал от того что как-то чёта всё сложнее чем ему казалось, но мне уже было всё равно 🙂 я допинал месяц и пулей оттуда свалил.
Это окей, когда вы кидаете новичка на боевые задачи в первую неделю, но задача должна быть ознакомительной, базовой, про знакомство с метриками и структурой данных, про погружение в бизнес и внутрянку. Так же окей, когда онбординг не подразумевает боевых задач, а больше с уклоном во внутреннюю теорию.
Но когда первая задача на 90% не уточняемая ни у кого, работающая через костыли, которые ещё сначала нужно придумать, и дедлайн неделя сразу после доступов… Я всякого повидал, но это какой-то рак. Не надо так.
#кулстори
❤27👍12
📌 Условия case в конструкциях join
В SQL, наверное, моя любимая конструкция это кейсы. С ними можно вытворять почти всё что угодно. Например, не все в курсе, что через кейс можно даже джойнить таблицы.
Представь ситуацию — у тебя в БД есть таблица заказов, где каждый заказ связан либо с id залогиненного пользователя, либо с его id гостя. Нам надо объединить данные о заказах с информацией о клиентах, выбирая тип клиента в зависимости от наличия информации о пользователе. Например, нужно имя юзера, но если он не был залогинен в текущей сессии, то ищем его имя по его гостевому id:
🔵 orders — таблица заказов с полями
🔵 customers — таблица клиентов с полями
#сниппеты
В SQL, наверное, моя любимая конструкция это кейсы. С ними можно вытворять почти всё что угодно. Например, не все в курсе, что через кейс можно даже джойнить таблицы.
Представь ситуацию — у тебя в БД есть таблица заказов, где каждый заказ связан либо с id залогиненного пользователя, либо с его id гостя. Нам надо объединить данные о заказах с информацией о клиентах, выбирая тип клиента в зависимости от наличия информации о пользователе. Например, нужно имя юзера, но если он не был залогинен в текущей сессии, то ищем его имя по его гостевому id:
order_id, customer_id и guest_idcustomer_id и nameselect o.order_id,
c.name
from orders o
left join customers c on c.customer_id =
case when o.customer_id is not null then o.customer_id
else o.guest_id end
#сниппеты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍29🤯19🔥2
📌 Про лучший онбординг
Про худший уже рассказал, справедливо будет рассказать и про самый топ, с которым я встречался.
Итак, первое что там было из необычного — план и расписание. Обычно у тебя просто есть пара задач на испыталку, но чаще ничего нет, вкатываешься по ситуации.
В этом плане не было списка задач, но был список тем для изучения и последовательное расписание ознакомительных сессий с каждой командой, с которой ты будешь пересекаться в работе.
Ответственным за онбординг был ПМ из аналитики. Вообще я никогда не видел у аналитиков отдельного ПМ-а, обычно это просто тимлид. Понятия не имею чем он занимался, но разработка онбординга была его задачей.
Так вот, началось всё из далека, первые пару недель у нас были только созвоны раз в пару дней, на которых он рассказывал про специфику бизнеса, как устроены биржи, кто с чего зарабатывает, кто как лицензируется и всё такое.
Тут же объяснял нам внутреннюю терминологию и систему метрик, что важнее и за чем нужно следить.
В закрепление он закидывал нам “домашки” в виде не душных статеек и видосов, чтобы мы больше прониклись внутрянкой. Загрузка была часа по 2-3 в день, но так и было задумано.
После погружения в бизнес, мы потихоньку начали знакомиться с инфраструктурой. Сначала была ознакомительная сессия с дата-инженерами, где они рассказали про данные, откуда берутся, как перетекают и где хранятся. Как обслуживается разметка, как заводить задачи на отдел и т.д. Затронули и всякие нюансы и проблемы, а так же показали костыли для их обхода.
Следующим этапом нам выделили по ментору, с которыми мы уже прошлись по базам, с которыми чаще всего придётся работать. Мы уже были подготовлены, поэтому таблицы выглядели знакомо, а все эти специфические колонки понятны.
Ещё была ознакомительная сессия с BI-командой, где нам показали какие есть борды, что актуально, а что не особо, где сверяться с расчётами и т.д. Не то чтобы нам это было сильно надо, но для общей картины пусть будет.
И последнее знакомство было уже с продуктовой командой, куда нас определяли. Тут довольно стандартно — чем занимается команда, кто есть кто и где какие зоны ответственности.
Параллельно с нашим погружением, ПМ аналитики организовал нам все доступы во все корп. системы и рабочим инструментам, которые аккуратно складывались в документы. Всё в одном месте, очень кайфово и очевидно, но я такого раньше не встречал 😅
Параллельно, в течение всего процесса были синхро с HR-ом команды, где ты рассказывал всё ли тебе понятно и всё ли нравится.
Весь этот процесс длился, наверное, месяц, может чуть больше. Потом начались первые боевые задачи совместно с ментором, их было по 1-2 штуки общих. Делать их было довольно легко. После всей теории, ощущения были как будто ты там уже давно работаешь и всё знакомо.
После этой мини-практики нас уже отдали в наши продуктовые команды.
Ребята потратили месяца два максимум для нашего погружения, но сразу после него мы были уже полноценные боевые единицы, которым смело можно было выдавать уже любые рабочие задачи.
#кулстори
Про худший уже рассказал, справедливо будет рассказать и про самый топ, с которым я встречался.
Для контекста — это был трейдинг. Тот онбординг-флоу, в который нас занесло (а нас было одновременно три новичка в разные команды) только тестировался и по итогу не прижился в компании, что, я считаю, огромным факапом.
Итак, первое что там было из необычного — план и расписание. Обычно у тебя просто есть пара задач на испыталку, но чаще ничего нет, вкатываешься по ситуации.
В этом плане не было списка задач, но был список тем для изучения и последовательное расписание ознакомительных сессий с каждой командой, с которой ты будешь пересекаться в работе.
Ответственным за онбординг был ПМ из аналитики. Вообще я никогда не видел у аналитиков отдельного ПМ-а, обычно это просто тимлид. Понятия не имею чем он занимался, но разработка онбординга была его задачей.
Так вот, началось всё из далека, первые пару недель у нас были только созвоны раз в пару дней, на которых он рассказывал про специфику бизнеса, как устроены биржи, кто с чего зарабатывает, кто как лицензируется и всё такое.
Тут же объяснял нам внутреннюю терминологию и систему метрик, что важнее и за чем нужно следить.
В закрепление он закидывал нам “домашки” в виде не душных статеек и видосов, чтобы мы больше прониклись внутрянкой. Загрузка была часа по 2-3 в день, но так и было задумано.
После погружения в бизнес, мы потихоньку начали знакомиться с инфраструктурой. Сначала была ознакомительная сессия с дата-инженерами, где они рассказали про данные, откуда берутся, как перетекают и где хранятся. Как обслуживается разметка, как заводить задачи на отдел и т.д. Затронули и всякие нюансы и проблемы, а так же показали костыли для их обхода.
Следующим этапом нам выделили по ментору, с которыми мы уже прошлись по базам, с которыми чаще всего придётся работать. Мы уже были подготовлены, поэтому таблицы выглядели знакомо, а все эти специфические колонки понятны.
Ещё была ознакомительная сессия с BI-командой, где нам показали какие есть борды, что актуально, а что не особо, где сверяться с расчётами и т.д. Не то чтобы нам это было сильно надо, но для общей картины пусть будет.
И последнее знакомство было уже с продуктовой командой, куда нас определяли. Тут довольно стандартно — чем занимается команда, кто есть кто и где какие зоны ответственности.
Параллельно с нашим погружением, ПМ аналитики организовал нам все доступы во все корп. системы и рабочим инструментам, которые аккуратно складывались в документы. Всё в одном месте, очень кайфово и очевидно, но я такого раньше не встречал 😅
Параллельно, в течение всего процесса были синхро с HR-ом команды, где ты рассказывал всё ли тебе понятно и всё ли нравится.
Весь этот процесс длился, наверное, месяц, может чуть больше. Потом начались первые боевые задачи совместно с ментором, их было по 1-2 штуки общих. Делать их было довольно легко. После всей теории, ощущения были как будто ты там уже давно работаешь и всё знакомо.
После этой мини-практики нас уже отдали в наши продуктовые команды.
Ребята потратили месяца два максимум для нашего погружения, но сразу после него мы были уже полноценные боевые единицы, которым смело можно было выдавать уже любые рабочие задачи.
#кулстори
🔥31❤10👍7