📌 Сомнительные рабочие практики
В твиттере на днях разгонялисрач дискуссию про информационную гигиену в работе. Там было больше с уклоном в собесы и лайв кодинг, но и ряд общих моментов тоже затронули.
Прокомментирую со своей стороны:
🔵 Переработки. Абсолютное зло, тут даже что-то обсуждать странно. С огромной натяжкой это может быть ок, если это заранее оговорённая разовая история с доплатой ради какого-то великого (не для тебя, конечно) дела. Но не вот эти ежедневные, потому что надо было вчера. Горят сроки, сгори и ты 😄
🔵 Активность в слаке вне рабочее время. В том же твиттере часто бомбят потому что “начальник написал мне в 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
Очень прикольный тред про поиск работы. Как кастомизировать своё резюме под ATS и значительно увеличить колличество откликов.
https://twitter.com/venus_in_moss/status/1785239928378441930?t=12AKm8lj5etTqaWsqBv9Yg&s=19
https://twitter.com/venus_in_moss/status/1785239928378441930?t=12AKm8lj5etTqaWsqBv9Yg&s=19
X (formerly Twitter)
maiasmokk (@venus_in_moss) on X
2 оффера за 2 недели
тред о том, как я изменила подход к поиску работы в эмиграции после четырех месяцев безуспешных поисков, и за две недели получила возможность выбирать из двух отличных офферов
надеюсь, это поможет тем, кто сейчас в поиске!
тред о том, как я изменила подход к поиску работы в эмиграции после четырех месяцев безуспешных поисков, и за две недели получила возможность выбирать из двух отличных офферов
надеюсь, это поможет тем, кто сейчас в поиске!
👍10
📌 Про группировки пользователей
В анализе данных постоянно используются различные группировки пользователей. И очень часто я замечаю, что для многих (особенно продактов, но и для аналитиков) нет разницы в терминологии между сегментами, когортами и кластерами. Термины используют как карта ляжет, но это разные сущности и они по разному работают.
Давай разберёмся и больше не будем путать:
1️⃣ Сегменты — это группы юзеров на основе каких-то характеристик или поведенческих признаков. Сегментировать можно по гео, платформе, по демографии, лайфтайму, по экономическим показателям или по паттернам поведения. Да всё что угодно. Вообще, чаще всего, когда ты говоришь о группах — ты говоришь о сегментах.
2️⃣ Когорты — это группы юзеров, объединённые общим событием в определённый период времени. Время тут ключевой фактор. Когорты могут быть за неделю, за меся, за год, это уже не так важно. Событие тоже не принципиально, это может быть как регистрация, так и первая покупка, например. Но это всегда с акцентом на период времени. Не бывает российской когорты, бывает когорта январская. Хотя никто не запрещает сегментировать когорты, но это уже другое! 🙂
3️⃣ Кластеры — это уже более редкое явление, когда сегменты обзывают кластерами, но всё равно ещё встречается. Так вот, кластер это группа, сформированная в результате анализа, которая строится на основе схожих характеристик или паттернов поведения, но критерии никогда не определены заранее (ты, конечно, знаешь весь список на момент запуска модели, но что там как повлияет всё ещё не понятно).
В анализе данных постоянно используются различные группировки пользователей. И очень часто я замечаю, что для многих (особенно продактов, но и для аналитиков) нет разницы в терминологии между сегментами, когортами и кластерами. Термины используют как карта ляжет, но это разные сущности и они по разному работают.
Давай разберёмся и больше не будем путать:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20🎉8❤4
Приветики, я тут пока затих, майские, сами понимаете 🙂
Махнули в автотрип по Черногории, 550км до побережья, и вдоль по всем интересным городкам.
Проехали заповедник, Херцег-нови и Пераст, сегодня Порто Монтенегро, Котор и Будва.
Шашлыков пока не обнаружено 😐
Махнули в автотрип по Черногории, 550км до побережья, и вдоль по всем интересным городкам.
Проехали заповедник, Херцег-нови и Пераст, сегодня Порто Монтенегро, Котор и Будва.
Шашлыков пока не обнаружено 😐
👍19❤8🔥5😁1