И, конечно, пример.

Как мы видим, jet подсветила резкие перепады там, где их на деле нет. Именно поэтому в matplotlib по умолчанию используется viridis.

💬 Пожалуйста, поделитесь в комментариях — что вы думаете о таких разборах?

➖ Субботний #датавиз.

Нашла на Kaggle датасет — Kaggle Machine Learning & Data Science Survey и нарисовала по нему Stanley-диаграмму. Опросник большой и интересный, но сегодня ответим на вопрос "Чем же занимаются эти ваши айтишники".

Датасет обработан, чтобы сократить число профессий до 4 категорий:
⏺️Analyst
⏺️Data Scientist
⏺️ML Engineer
⏺️Software Engineer

Можно заметить, что задачи между ролями ощутимо пересекаются.

Инструменты: python, графическая часть на plotly.

Нужно сделать поправку на то, что опрос изначально адресован людям, работающим с данными на постоянной основе. Если расширить аудиторию опроса на Embedded-разработчиков, картинка, конечно, поменяется.

Решила вынести лонгриды на понедельник.

Хочу поисследовать процессы в аналитических командах. Если сталкивались — присоединяйтесь к обсуждению в комментариях 💬

Понедельничный #фреймворк

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

➖ Сегодня поговорим о фреймворке RICE для приоритезации.

На мой взгляд, и аналитику, и разработчику полезно понимать способы расстановки приоритетов — как минимум для того, чтобы совместно с заказчиком определить важность и срочность задачи.

Это полезно делать и на этапе планирования АБ-тестов, если они пока не автоматизированы и проводятся руками.

Аббревиатура содержит 4 фактора, которые менеджер продукта может использовать для оценки задач:

Reach — охват (сколько людей затронет фича?);
Impact — влияние (прибыльность идеи, выраженная в денежном либо любом другом численном эквиваленте);
Confidence — уверенность в оценке охвата, влияния и трудозатрат;
Effort — трудозатраты (например, число часов, которое потратит разработчик).

Чтобы получить оценку задачи, нужно перемножить первые три фактора и поделить на трудозатраты.

Например, мы хотим оценить две доработки:
(1) добавить партнерскую кнопку на финальный экран регистрации
(2) исправить баг, который влияет на 5% клиентов и гарантированно не затронет остальных.
Для оценки MAU нашего продукта составит 5000 человек, ежемесячный прирост ~10%.

➖ Reach:

(1) Охват первой фичи можно оценить в 500 человек, при сохранении темпов прироста значение будет расти;
(2) Охват второй фичи составит 250 человек, он не изменится в будущем.

➖ Impact:

Здесь не получится привести влияние к единой размерности (в случае первой задачи эффект измерим деньгами, второй — лояльностью пользователей). Поэтому мы вольны придумать собственную шкалу.
Например, я буду использовать шкалу от 0 до 3, где 0 — отсутствие влияния, 3 — влияние на всю аудиторию продукта.

(1) Оценка первой фичи — 1.5. Влияние будет оказано на небольшой сегмент, но принесет прибыль и улучшит отношения с партнерами.
(2) Оценка второй фичи — 0.5. Она даст нам лояльность очень узкого сегмента аудитории, но совершенно не факт, что принесет нам прибыль.

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

➖ Confidence:

Этот показатель субъективен, но в конце концов, автор продукта ориентируется в нем лучше.
Здесь я буду использовать шкалу от 0 до 1 — показатель, насколько мы верим в необходимость фичи.

(1) Мы знаем охват, проводили исследования, четко понимаем реализацию и знаем, что ключевые метрики продукта не просядут — ставим 1;
(2) Реальный охват может оказаться ниже (люди из этого сегмента могли перестать использовать продукт), усилия в итоге могут оказаться выше (баг не локализован) — ставим 0.3.

➖ Effort:

Можно оценивать в часах, можно в человеко-часах — зависит от распределения ролей в команде.

(1) Возьмем 1 неделю на проектирование и согласование, 1 неделю на разработку и внедрение, суммарно 2 недели;
(2) Потребуется 1-2 недели на разбор, 1 неделя на планирование, 1-2 недели на разработку, 1 неделя на тестирование, а также неизвестные на текущий момент сроки включения в релиз и раскатки. Суммарно от 4-6 недель.

Проведем оценку:

Фича 1: 500x1.5x1/2 = 375
Фича 2: 250x0.5x0.3/5 = 7.5
​
Как и любая методика оценки, RICE субъективна. Но с ее помощью можно навести порядок в бэклоге и убедиться, что команда работает на цели продукта.

➖ Субботний #датавиз.

Физики бывшими не бывают, поэтому сегодня — модель двойного маятника.

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

Инструменты: python, matplotlib.

В комментарии приложу вариант с более долгой «экспозицией» следа и итоговую траекторию движения грузов.

На этой неделе прошло три интересных митапа: Data Engineering Meetup Билайна, Python Backend Meetup Литреса, dbt Meetup.

Хочу отметить несколько докладов, которые понравились лично мне. Ссылка на доклад про квантовые вычисления ведет на страницу, где запись будет позже — через неделю этот доклад можно будет услышать на PyCon. Кстати, пообщались с автором на митапе, было очень приятно.

➖ Как мы управляем данными с помощью каталога данных, Владислав Шевченко, Альфа-банк
➖ Python Шредингера: когда ваш код и жив, и мертв, а весь мир с замиранием ожидает его выполнения, Бейлак Алиев, Raiffeisen Bank
➖ Оркестрация dbt jobs для Dev, Test, Prod без головной боли, Артемий Козырь, Wheely

📼 #конференции

Понедельничный #фреймворк
‍
Сегодня хочу продолжить тему прошлой недели и рассказать о модификации RICE-приоритезации.

➖ Речь пойдет об ICE-приоритезации. Изначально этот фреймворк заточен под эксперименты, что и вызывает интерес.

➖ Impact — как это повлияет на метрики и что даст пользователям;
➖ Confidence — насколько мы уверены в своих оценках;
➖ Ease — насколько просто реализовать эксперимент.

Обычно выбирают шкалу от 1 до 10. Лучше заранее обговорить, что считается за тройку, а что за десять.

Уже сейчас видно, что фреймворк субъективен и требует от человека целых две прикидки. На мой взгляд, RICE более сбалансирован, но ICE не требует оценок временных затрат.

Посмотрим, как фреймворк работает на примере. Есть две задачи:
(1) протестировать, влияет ли объединение нескольких экранов регистрации в один на процент завершенных регистраций;
(2) протестировать, что при изменении структуры разводящей страницы не произойдет отток аудитории.

Перед оценкой определимся, что основная метрика нашего продукта — MAU и мы нацелены на увеличение ежемесячного прироста на 5%.

➖ Impact

(1) Эксперимент влияет на активацию пользователя, а значит, опосредованно и на будущий показатель MAU. Так как влияние опосредованное, оценим на 6.
(2) Структура разводящей страницы не привлечет к нам новую аудиторию (если, конечно, не случится чудо), однако может уронить основную метрику. Эксперимент не работает на цель продукта, но нужен с точки зрения развития — оценим его на 3.

➖ Confidence

Самый скользкий момент — сложно представить, чтобы в бэклог попали задачи, в необходимости которых кто-то не уверен. Тем не менее, можно опереться на результаты UX-исследований:

(1) Согласно исследованию, 40% респондентов ушли с третьего экрана регистрации. 80% из них объяснили это тем, что ожидали, что регистрация завершится на прошлом шаге.
Мы не до конца уверены, виноваты ли экраны, количество вопросов, отсутствие прогресс-бара или сбивающий с толку текст на кнопке. Поэтому оценка уверенности — 4.
(2) Согласно исследованию, 55% пользователей не могут найти нужную им функцию на главном экране в течение 15 секунд. Таких людей много и экран явно нуждается в переработке — оценим уверенность в 8.

Почему не 10 — неизвестно, будет ли реакция пользователей положительной или новая навигация окончательно собьет всех с толку.

➖ Ease

(1) Нужно только переделать форму регистрации — UI-элементы уже готовы и сборка новой версии не займет больше пары часов. Оценка — 10.
(2) Как минимум, потребуется создать новый макет. Если он не потребует создания новых элементов, задача упростится, но все-таки займет больше времени и сотрудников. Оценка — 6.

Считаем:
(1) 6x4x10 = 240
(2) 3x8x6 = 144

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

Пользовались? Пишите в комментарии ваши впечатления 💬

➖ Очень залипательный #датавиз

Анализ спортивных мероприятий - крайне занимательная вещь. Например, футбольной статистикой очень подробно занимаются эти ребята. Объемы открытой части данных впечатляют, оценить их можно на гитхабе.

Автор датавиза проанализировал 882,536 пасов из 890 матчей. В оригинальном посте интерактивный график, советую залипнуть:

https://observablehq.com/@karimdouieb/all-the-passes

Инструменты: d3.js

Что мне нравится:
➖ Выбор цветовой схемы. Она интуитивно понятна и хорошо считывается;
➖ Указание направления (не вошло в gif, есть в оригинальном посте) - помогает сориентироваться, что происходит;
➖ В выборку вошли матчи высшей лиги, а значит, картинка более чиста.

Последнюю проблему важно избегать, но к сожалению, не все обращают на нее внимание.

Что не нравится:
➖ Само взаимодействие с читателем мне стало понятно не сразу. Я бы разводила "общий" вид, попадание в точку и на прямую в три разных графика.

Enjoy!

➖ Субботний #датавиз.

Сегодня я прочувствовала выражение «забанили в гугле» на себе — переборщила с запросами по апи =)

Спарсила мировую статистику по «выстрелившим» запросам согласно Google Trends за 2022 год и построила ridge-plot. Тематик запросов оказалось не так много, как я ожидала. Для сравнения в комментариях оставлю ковидный 2020.

Инструменты: python, pytrends (как неофициальный апи к Google Trends), seaborn.

➖ Все линии нормированы на максимальное значение в ряду — так удобнее охватить таймлайн и сравнить протяженность тренда. При этом сравнить популярность двух запросов в абсолютных величинах нельзя.

Было бы интересно поисследовать локальный топ запросов по России, но доступ к нему закрыт.

Вот и прошел июль ➖
⁠
Что было интересного в прошлом месяце:
➖Выяснили, законно ли отрывать ноль на графике;
➖ Нашли open-source замену покинувшему нас GA-Universal Analytics;
➖ Разобрались, как не обмануть читателя цветовой схемой;
➖ Послушали несколько митапов для дата-инженеров и не только.

Вчера не вышел «понедельничный фреймворк» — он выйдет через неделю в немного другом формате.

Stay tuned!

➖ Субботний #датавиз.

В блужданиях по Кэгглу я нашла датасет, в котором собраны фильмы и сериалы с Нетфликса с кратким описанием. Почему бы не сделать из этого арт?

Чем бóльшим шрифтом написано слово, тем чаще оно встречается в синопсисах. Кажется, рождественские ромкомы довольно популярны 😁

Инструменты: python и тонко настроенный matplotlib с либой WordCloud поверх.

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

Понедельничный #фреймворк

Я экспериментирую с форматом лонгридов — кажется, что так читать их намного приятнее.

➖ Сегодня поговорим про фреймворк PXL. Он должен избавить нас от субъективности ICE/RICE-подобных фреймворков.

В конце статьи вы найдете гугл-таблицу с примером использования — копируйте, пользуйтесь и внедряйте у себя, если актуально.

Расскажите в комментариях, что думаете об этом? Возможно, кто-то даже внедрял, будет круто послушать опыт.

https://telegra.ph/PXL-frejmvork-kogda-ne-vse-testy-odinakovo-polezny-08-06

➖ Субботний #датавиз.

Датавиз нужен нам, чтобы рассказывать истории. Но сам по себе график ничего не расскажет — нужно подкрепить его контекстом.

К примеру, возьмем данные о безработице в РФ с 1992 по 2010 (доступны в репозитории ООН). Вне контекста тенденции неясны.

Но стоит лишь добавить контекст:
➖ распад СССР в 1991 году;
➖ дефолт в 1998 году;
➖ мировой экономический кризис 2008-2013 годов;

и график становится наглядной иллюстрацией.

Я использовала диаграмму Найтингейл – у нее интересная история появления, о которой расскажу на будущей неделе.

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

➖ Здесь я рассказывала, как плохо подобранная цветовая схема обманывает читателя;
➖ А здесь — про rule of thumb масштабов, когда отсутствие нуля по оси Y меняет весь смысл.

А так ли плохи Pie-чарты?

➖ tl;dr: нет, сами по себе они не плохи. Но у них много ограничений, которые хорошо бы держать в голове.

Об этом и лонгрид.

https://telegra.ph/nePlohie-pirogi-08-13

Понедельничный #фреймворк
⁠
Мы поговорили про «умные» системы планирования, учитывающие контекст, трафик и альтернативные способы решения проблемы. Но что, если раскидать задачки по приоритетам нужно прямо сейчас и «на коленке»?

➖ Тогда подойдет фреймворк MoSCoW. Приятный бонус — он легко применяется как к планированию в команде, так и для себя.

https://telegra.ph/MoSCoW--kak-razobrat-hotelki-i-stat-ehffektivnee-08-13

➖ О канале

Привет!

Недавно пришло много новых читателей, добро пожаловать!

Меня зовут Алена и мне проще всего описать себя как Full stack аналитика. В моей работе есть место BI, дата-инжинирингу, дата-аналитике и даже разработке 😁 И мне это очень нравится!

Этот канал — отражение моих интересов. Я датавиз-гик и мне нравится исследовать, как рассказать историю с помощью данных.

Навигация:
#датавиз — классные визуализации. А каждую субботу я делаю небольшой датавиз экспромтом;
#фреймворк — рубрика по понедельникам о том, как построить работу и понять заказчика;
#рекомендасьон — ресурсы, которые я хочу порекомендовать, как правило образовательные;
#конференции — подборки понравившихся выступлений с прошедших конференций;
#инструменты — программы и библиотеки, которые могут пригодиться аналитику.

Немного обо мне:
🔹 Аналитик данных в Sberdevices;
🔹 Закончила физфак МГУ (а потом и ФПО МГУ);
🔹 Пишу на Python и C++;
🔹 Интересуюсь NLP.

Я всегда рада общению, можно на ты, можно на вы — как кому комфортнее.