This is Data

Продукты 24

12 сентября в Москве Т-Банк собирает конференцию Продукты 24 x ffdd2d в комплексе «Мечта» на набережной парка Горького. Можно смотреть онлайн, но лучше приходите лично.

Сама конфа для продактов, аналитиков и дизайнеров. Кроме Т-Банка со своими кейсами приедут Яндекс, Авито и Додо Пицца.

Три зала на разные темы, и один из них, «Говорим прямо», идет без трансляции и записи. В нем обсуждают спорные темы и решения, отвечают на неудобные вопросы, рассказывают о провалах и неожиданных победах. В общем все то, о чем обычно не говорят публично.

А вечером стендап и вечеринка с видом на Москву-реку.

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

Я тоже там буду, подходите знакомиться, поболтаем про метрики и про то, как у кого устроена аналитика.

Мест на площадке немного, лучше не тянуть с регистрацией.

День знаний, или Я все еще студент

Лето опять пролетело подозрительно быстро. Я не успел накачаться, съездить на море и как следует отдохнуть. Впрочем, сегодня другой повод удивиться - начинается второй год моего обучения в магистратуре МИФИ на программе «Специалист по работе с данными и применению ИИ».

Первый год оказался очень сложным. Совмещать учебу, работу на руководящей должности и семью в зрелом возрасте было не просто смело, это было пи🤬ец как смело. Иногда ничего не успевал, иногда просто сжимал зубы и продолжал. Но раз пишу этот пост, значит меня не отчислили. И это я правда считаю большим личным достижением)

За год прошел Python, Linux, основы Data Science, бизнес- и системную аналитику. Где-то освежил знакомое, где-то наконец собрал тот самый технический фундамент, ради которого и поступал.

Далее нужно было выбрать специализацию. Я выбрал дата-инженерию, ведь людям, которые копают золото, всегда нужны продавцы лопат. Плюс этот трек соответствует моему карьерному плану стать CDO. К тому же, он показался мне немного легче чисто математических специализаций.

Впереди хранилища, качество и подготовка данных, потоковая обработка, озёра и облака. Потом ВКР. А там свобода, причем уже с дипломом магистра!

С возрастом учеба воспринимается иначе - ты хорошо понимаешь, зачем тратишь на нее вечера и выходные. В нашей сфере надолго останавливаться опасно, профессия быстро убежит вперед без тебя.

Всех с Днем знаний!

Поделитесь, а вы в этом году куда-нибудь поступили, чему-то учитесь? Или уже умеете?)

#личное

Обновил телеграм-курс по метрикам

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

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

Читать лучше последовательно, разделы опираются друг на друга.

База
▪️ Что такое метрика?
▪️ Фреймворки для работы с метриками

Целеполагание
▪️ Цели и ключевые результаты (OKR)
▪️ Книга.Измеряйте самое важное

NSM
▪️ Метрика Полярной звезды (NSM)
▪️ Почему Revenue и Profit плохие кандидаты в NSM
▪️ Книга.The North Star Playbook

Иерархия и пирамида
▪️ Дерево или иерархия метрик
▪️ Пирамида метрик
▪️ Построение пирамиды метрик
▪️ Слой бизнеса
▪️ От GMV к Net Profit
▪️ Слой маржинальности
▪️ Юнит-экономика
▪️ Слой продукта. Метрики лояльности
▪️ Слой продукта. Метрики ценности
▪️ Слой продукта. Метрики качества
▪️ Слой интерфейса и маркетинга
▪️ Экосистемные метрики

Опыт Amazon
▪️ Опережающие и запаздывающие индикаторы
▪️ Маховик Amazon
▪ Книга.Стратегия Amazon

Для конкретной задачи
▪️ Фреймворк AARRR
▪ Фреймворк HEART
▪️ Фреймворк PULSE

Подробно про LTV и CAC
▪️ Простой способ расчета LTV
▪️ LTV с учетом маржи и дисконтирования
▪️ Когортный LTV
▪️ Сравнение подходов
▪️ Customer Acquisition Cost
▪️ Что делать, когда показатели посчитаны

Все бесплатно. Сохраняйте в закладки и делитесь с коллегами.

#метрики

AI в работе. Что изменилось?

Почти два года назад я написал пост «Когда тебя заменит робот?» и там уверенно заявлял: «Человеческий дух никакой ИИ не заменит!»

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

Развитие ИИ реально пугает. Но факт остается фактом - тот, кто освоил ИИ, обойдет тех, кто забил.

Поделюсь одним кейсом, который меня отрезвил. Нужно было собрать финмодель для продукта, плюс прогноз на пару лет. Я, по старинке, открыл презентацию с описанием идеи, открыл Excel, сел собирать таблицу руками. Далее созваниваюсь с продактом (привет, Стас) по этому же вопросу и вместо того чтобы долго объяснять, он открывает Телегу, записывает голосовое своему боту, тот передает его агенту и через пару минут в чат прилетает готовая финмодель! В Excel и с учетом того, о чем я даже не подумал. Несколько минут и готовый результат, осталось немного поправить и обогатить данными.

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

Если вы, также как и я, ощущаете, что отстали - хватит смотреть со стороны. Найдите курс, поставьте Cursor, Codex или Claude Code и соберите своего первого агента. Не все получится с первого раза, но попробовать стоит уже сейчас.

А если не знаете, с чего начать - вот несколько точек входа:
▪️ Anthropic Academy (бесплатно) - курсы от самого Anthropic на английском, с сертификатами: от базового промптинга до Claude Code, MCP и агентов.
▪️ Кодовый ИИ-агент Cursor AI (бесплатно) - системный разбор всего инструмента на Stepik, от первого запуска до автономных агентов в CI.
▪️ Нейроцех (платно) - клуб, где сейчас учусь сам: мини-курсы с нуля, вайбкодинг, чат сообщества в ТГ.

Кстати, насколько вообще интересна эта тема? По мере изучения могу делиться инсайтами.

🦄 - да, хочу все знать про AI
🥱 - нет, все тлен

#мысли #опыт

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

📚 From Data to Insights. The strategy of a Data Analytics Team
John Mackay

Джон начинал инженером данных, вырос до руководителя аналитики в крупном европейском банке, а сейчас управляет data-аналитикой в ведущей технологической компании и консультирует Fortune 500. За два десятка лет он построил не одну команду, которая возвращала бизнесу миллионы и делала процессы заметно человечнее. Свой опыт он упаковал в короткое прикладное руководство.

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

Вот семь типовых симптомов, знакомых почти каждой команде аналитики:

▪️Завал ad-hoc запросами.
▪️Репутация подорвана и вам не доверяют.
▪️На анализ и инсайты времени нет.
▪️Срочные задачи прилетают в последний момент.
▪️Отчеты разрозненные, пользоваться ими больно.
▪️Коллеги выгорели и потеряли драйв.
▪️Стейкхолдеры вынуждены делать отчеты сами.

Причина, по Маккею, одна - слабая стратегия и плохой дизайн команды. Книга ровно про то, как это исправить. Пригодится и CTO, и тимлидам, и рядовым аналитикам - чтобы понимать, как устроен здоровый data‑организм и в какой момент все пошло не так.

🔗 Электронную версию на английском в PDF качайте по ссылке.

#книга

Как написать стратегию аналитики и зачем она нужна?

Ура, я наконец-то закончил эту статью! Писал ее долго, потому что хотел сделать по-настоящему крутой гайд, в который вложил много сил. И теперь с радостью делюсь с вами.

Эта статья для тех, кто недавно стал тимлидом или хедом аналитики и чувствует, что пора выйти из режима «просто делаем задачи» и начать думать системно.

Перед тем, как ее опубликовать, я искал подобные материалы и не нашел ничего достойного на русском языке. Есть пересказы Gartner, есть руководства от вендоров уровня «нужно делать data-driven», есть какие-то корпоративные посты. Поэтому статья - попытка закрыть реальный пробел.

В ней вы найдете практическое руководство: как вывести стратегию аналитики из бизнес-целей, честно оценить зрелость команды, пройти три фазы развития и собрать дорожную карту. Это выжимка из моего опыта, с конкретными шагами. Приятного чтения.

#опыт

Друзья, это финальный пост про пирамиду метрик.

Я довольно много писал про метрики и разные фреймворки, и к пирамиде мы возвращались не раз. Но с последним слоем я немного подзатянул - исправляюсь 🙂

На последнем уровне - интерфейс продукта и маркетинг - находятся самые прикладные метрики. Те, с которыми команды работают каждый день и которые напрямую отражают поведение пользователей.

Этот слой отвечает на базовые вопросы:
- как пользователи приходят в продукт?
- что они в нем делают?
- доходят ли до целевого действия?

Как и в предыдущих слоях, здесь есть своя логика группировки. Я выделяю четыре блока:

1. Маркетинг
Это про вход в продукт: кого мы приводим и за какие деньги.

2. Интерфейс
Это уже про UX и то, насколько продукт понятен.

3. Вовлеченность
Здесь видно, «цепляет» продукт или нет.

4. Аудитория
Это наша текущая и потенциальная база.

Этот слой - точка, где формируется все поведение пользователя: как он зашел, что сделал, получил ли пользу. А дальше поднимается выше по пирамиде - в ценность, лояльность и деньги.

На этом мы полностью разобрали пирамиду метрик - от бизнес-уровня до конкретных действий пользователя.

Главное не фреймворк, а используете ли вы его на практике. Будь то пирамида, дерево метрик или что-то свое - важно, чтобы метрики были системой, а не набором цифр.

#харды #метрики #разбор_метрик

Эффективные встречи один на один - существуют ли они?

Я терпеть не могу встречи ради встреч. Обычно это просто сжигание времени. Но есть один формат, в который я по-настоящему верю 🙏

Встречи один на один - не просто регулярный разговор сотрудника с начальником, а один из главных инструментов управления. К сожалению, многие относятся к ним как к простой формальности и проводят их «для галочки».

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

Формат может быть таким:

1. Начинаем с короткого неформального разговора.

2. Даем слово сотруднику: какие есть вопросы, сложности, идеи, что беспокоит, где нужна помощь (и действительно стараемся помочь).

3. Переходим к своей части: рассказываем новости, делимся мыслями, советуем, если это уместно, обсуждаем планы и изменения.

4. Самый важный блок - фокус недели. Фиксируем 1-2 главных приоритета на ближайшие дни. На следующей встрече разбираем: что вышло, что нет и почему.

⚠️ Сами фокусы не должны браться из воздуха. Они должны рождаться из стратегии развития. Если у руководителя нет понимания, куда движется функция, то 1-1 быстро скатывается в обсуждение только текучки. А когда есть стратегия, такие встречи становятся способом регулярно переводить ее в конкретные шаги для команды.

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

⚠️ Еще одна практика, которую считаю очень полезной - это фиксировать письменно темы встреч и договоренности в любом удобном инструменте. Всегда можно вернуться и вспомнить, что обсуждали. Потому что если договоренности не зафиксированы, то их не существует.

Как часто проводить 1-1?

Все зависит от вашей команды и контекста, но мне нравятся недельные каденции. Они позволяют не терять фокус и темп: за 5 рабочих дней обычно накапливается достаточно прогресса для обсуждения. Для зрелой команды хватит и двухнедельного интервала, но реже есть риск упустить проблемы.

Такой подход делает встречи не формальностью, а рабочим инструментом. Помогает держать курс, поддерживать людей и не тонуть в текучке.

А вы верите в эффективный 1-1?

👍 - да
🔥 - нет, сжигание времени

#опыт

Как аналитику оптимизировать свои запросы?

Ранее я рассказывал, почему оконные функции могут тормозить, и дал 4 совета по оптимизации. Но если ты действительно хочешь ускорить свои запросы, то начинать нужно с анализа плана выполнения.

Знакомьтесь - EXPLAIN

Команда простая и очевидная, но почему-то ею мало кто пользуется. Может, потому что хочется быстрее решить задачу, а не копаться в том, как база данных обрабатывает запросы. Но когда ты пишешь боевой запрос, от которого зависит работа важной системы, или когда на кластере жесткие лимиты по ресурсам - умение читать EXPLAIN твое все!

Как SQL работает под капотом?

Прежде чем говорить о плане, важно понимать этапы, которые проходит SQL-запрос внутри базы данных (на примере PostgreSQL):

1⃣ Parser - разбирает текст SQL, проверяет синтаксис и строит абстрактное синтаксическое дерево.

2⃣ Analyzer - проверяет существуют ли таблицы, колонки, функции, есть ли права доступа. Если ты опечатался в названии колонки, то ошибка упадет именно здесь.

3⃣ Rewriter - делает логическое преобразование запроса.

4⃣ Planner / Optimizer - самый важный этап для нас. Он перебирает возможные планы выполнения и выбирает тот, у которого наименьшая стоимость.

5⃣ Executor - выполняет план и возвращает результат.

EXPLAIN показывает результат работы planner и это тот самый план, который база данных посчитает оптимальным на основе статистики.

Как читать EXPLAIN?

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

Команда EXPLAIN показывает, как именно база данных собирается выполнять запрос: какие индексы использовать, как соединять таблицы, будет ли сортировка.

А EXPLAIN ANALYZE еще и выполняет запрос, добавляя фактические цифры: сколько строк прошло через каждый шаг, сколько времени заняло, сколько памяти использовано.

Основные операторы в плане:

◾ Seq Scan - последовательное чтение всей таблицы (для маленьких таблиц - это окей).
✔ Оптимизация: добавить индекс на поля, которые используются в WHERE, JOIN, ORDER BY.

◾ Index Scan - чтение по индексу.
✔ Оптимизация: следи, чтобы индекс реально использовался: без функций, кастов и с правильным порядком колонок.

◾ Sort - дорогая операция, особенно на больших объемах и без индексов.
✔ Оптимизация: если сортировка нужна, то убедись, что есть индекс на поля сортировки. Если не нужна - убери.

◾ Hash Join / Merge Join / Nested Loop - это способы соединить таблицы. Hash Join и Merge Join обычно быстрее на больших данных, Nested Loop - на маленьких.
✔ Оптимизация: главный прием - уменьшить данные до JOIN, а не после.

◾ Cost=1..123 - оценка оптимизатора, где первое число - стоимость получить первую строку, второе - все строки. Чем меньше - тем лучше.
✔ Оптимизация: это лишь оценка оптимизатора, ориентируйся на реальные метрики из EXPLAIN ANALYZE.

Я не буду переписывать сюда всю документацию. Вот ссылки на официальные руководства, где все подробно расписано:
- PostgreSQL
- MySQL
- SQL Server
- Greenplum
- ClickHouse

Твое задание на сегодня

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

Интересными кейсами делись в комментариях!

#харды #sql

Как учатся модели машинного обучения?

Ранее я написал небольшую статью про историю ML, а сегодня хочу развить тему дальше.

Речь пойдет о моделях, которые учатся, минимизируя функцию потерь градиентными методами. У других алгоритмов (например, деревья) свои механизмы, но они тоже оптимизируют критерий качества. Есть и алгоритмы, которые вообще не проходят этап обучения - например, kNN просто хранит обучающие данные и делает предсказания на основе ближайших соседей.

Когда модель обучается с «учителем», у нее есть простая джоба: на вход размеченные данные, на выход - предсказание. Но дальше возникает ключевой вопрос: как понять, насколько предсказание хорошее, и как сделать так, чтобы в следующий раз было лучше?

Для этого нужна функция потерь (loss). Формально функция потерь сравнивает две вещи:
▪️ правильный ответ (y);
▪️ предсказание модели ŷ.

И превращает разницу между ними в число ошибки. Именно это число становится целью обучения - модель старается его уменьшить.

Как выглядит обучение по шагам?

Обычно перед обучением проводят подготовку и делят данные на три части:
▪️тренировочная выборка - это те данные, на которых будет учиться модель;
▪️валидационная выборка - чтобы проверять, не начинает ли модель «зазубривать» тренировочные данные и как лучше настроить параметры;
▪️тестовая выборка - финальная честная проверка, когда обучение уже закончено.

1⃣ Модель делает предсказание
Мы подаем признаки (X) в модель, она считает ответ и выдает свой прогноз.

2⃣ Считаем ошибку (loss)
Теперь сравниваем получившееся предсказание модели с правильным ответом, то есть y и ŷ. Получаем ошибку модели и если модель сильно ошибается - loss будет большим. Если предсказывает хорошо, то маленьким.

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

4⃣ Обновляем параметры модели
Сам градиент параметры не меняет. Его использует оптимизатор - специальный алгоритм обновления весов. Оптимизатор делает маленький шаг в сторону уменьшения ошибки.
И после обновления параметров цикл начинается заново.

В итоге получается такой алгоритм:
Сделали предсказание > Посчитали ошибку > Вычислили градиент > Обновили параметры > Повторили тысячи раз.

Какие бывают функции потерь?

Их много, потому что разные задачи требуют разных способов измерять ошибку.

Для интуитивного понимания достаточно двух примеров:
▪️MSE (mean squared error) - ошибка возводится в квадрат. Это значит, что большие ошибки «наказываются» особенно сильно, поэтому модель старается избегать крупных промахов.
▪️MAE (mean absolute error) - берется просто абсолютная разница. Такая функция потерь относится к ошибкам более спокойно и обычно лучше переносит редкие выбросы.

Понимание этого цикла - одна из базовых идей ML. Многие современные модели, от простой линейной регрессии до нейросетей, в той или иной форме обучаются именно так.

#харды #ml

Почему оконные функции могут тормозить запрос?

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

Главный виновник тут обычно не сама функция, а сортировка. Сортировать много строк - дорогая операция на больших объемах данных, и ее лучше избегать везде, где она не нужна. Ниже 4 прикладных совета по оптимизации.

1⃣ Убери ORDER BY из окна, если порядок не влияет на смысл

Частая ошибка - писать ORDER BY внутри OVER() «на всякий случай». Как только он появляется, базе нужно обеспечить порядок строк, а это почти всегда дорого.

Если тебе нужен просто итог по группе (например, общий доход за день для каждой строки), а не накопительная сумма или скользящее окно - ORDER BY внутри окна не нужен.

-- Накопительная сумма (дороже)
SUM(revenue) OVER (PARTITION BY date ORDER BY created_at)

-- Просто итог по дню (дешевле)
SUM(revenue) OVER (PARTITION BY date)

2⃣ Чем меньше строк, тем быстрее

Оконки «проходят» по всем строкам, часто упорядочивают их, а иногда еще и держат большие куски данных в памяти. Поэтому самый простой ускоритель - сократить объем данных ДО оконки:

✔ Отфильтруй период (например, последние 30/90 дней);
✔ Не тащи лишние колонки («SELECT *» - плохо);
✔ Если можно, то сначала агрегируй данные до нужной гранулярности, а окно считай уже на агрегате.

3⃣ Несколько разных окон = несколько сортировок

Если в одном запросе несколько окон с разным ORDER BY, база может быть вынуждена упорядочивать данные несколько раз. И как итог: больше времени и памяти.

SUM(x) OVER (PARTITION BY a ORDER BY b) AS s1,
AVG(x) OVER (PARTITION BY a ORDER BY c) AS s2

Если можешь, унифицируй порядок в окнах. Если не можешь, то иногда лучше разнести расчеты на 2 шага, чем собирать все в одном SELECT.

4⃣ Используй план выполнения запроса

EXPLAIN - это команда, которая показывает план выполнения запроса: какие шаги база собирается сделать и где она потратит ресурсы. А EXPLAIN ANALYZE еще и выполняет запрос добавляя фактические цифры: сколько строк прошло через каждый шаг и сколько времени заняло.

Далее я разберу, как именно читать EXPLAIN и использовать эту команду для оптимизации.

#харды #sql

В АБ-тестах самая частая ошибка не расчет p-value, а неправильный выбор статистического теста.

▪️Одна выборка или две?
▪️Если две - зависимые или независимые?
▪️Сравниваем средние или пропорции?
▪️Есть ли выбросы?
▪️Насколько однородны группы?

От этого зависит правильность ваших выводов.

Я сделал простую схему-шпаргалку по выбору тестов. Минимальный старт, чтобы не выбирать метод наугад.

Но важно понимать, что схема не заменяет понимание.
Перед применением теста стоит:
✔️проверить однородность выборок;
✔️посмотреть на распределения;
✔️оценить выбросы;
✔️убедиться в независимости наблюдений;
✔️проверить предпосылки конкретного теста.

И только после этого принимать решение.

Для первого шага такой карты достаточно. Дальше все равно придется углубляться: читать, разбирать кейсы, ошибаться и нарабатывать практику.

Если хотите системно разобраться в АБ-тестах, могу порекомендовать курс Паши. Я его знаю лично и доверяю его подходу.

У него как раз упор на практику и полный цикл эксперимента. Сам планирую пойти, потому что в менеджерской роли стал подзабывать АБ.

Сейчас как раз стартует новый поток, и следующий будет только осенью.

#харды #аб

Как перестать хвататься за все сразу

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

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

Я давно использую приоритизацию Must - Should - Nice to Have. Это упрощенная версия метода MoSCoW, разработанного Даем Клеггом в компании Oracle в 1994 году. Метод простой, но действенный. Благодаря ему я всегда понимаю, что именно делать и зачем.

Шаг 1. Соберите полный список проектов

Выпишите все проекты и крупные задачи. Именно все. Не только KPI, но и побочные активности.

Например: запуск нового продукта, развитие дерева метрик, ведение корпоративного блога, организация мероприятия, менторинг стажеров.

Даже сам список уже многое проясняет. Часто кажется, что делаешь мало, но когда видишь 10-15 проектов одновременно, становится понятно, куда уходит время.

Шаг 2. Расставьте приоритеты

Теперь распределите проекты по трем категориям.

▪Must. То, что кровь из носу нужно сделать. Иначе - срыв обязательств, провал цели или потеря доверия.

▪Should. Важно, но можно перенести. Это развитие, улучшения, стратегические заделы.

▪Nice to Have. Было бы классно сделать, но если не сделаете, ничего критичного не произойдет.

Важно! В Must не должно быть половины списка. Если все критично, значит вы не сделали выбор.

Шаг 3. Разложите по неделям

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

На пересечении проекта и недели пишите конкретный результат. Не «заняться», а «подготовить концепт», «согласовать», «запустить пилот».

После этого неделя перестает быть абстрактной. Появляется понятный план действий.

Перегруженность чаще возникает не из-за количества задач, а из-за отсутствия фокуса. Когда приоритет зафиксирован, работать становится проще и спокойнее 😌

#опыт

Решил попробовать написать серию постов про машинное обучение.

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

В какой-то момент стало понятно, что это уже не пост для Telegram. Текст разросся, плюс захотелось добавить фоток и немного контекста.

➡️ Поэтому вынес его в блог.

Приятного чтения и поделитесь фидбеком!

#харды #ml

Давно я не писал про пирамиду метрик, а ведь с последнего поста остались неразобранными еще два слоя.

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

Здесь хочется вспомнить незатейливый слоган:

Нормально делай – нормально будет.

Метрики качества – это фундамент доверия и долгосрочного успеха. Без них можно сколько угодно создавать ценность и работать над лояльностью, но один сбой, медленная загрузка или волна ошибок сведут все усилия на нет. Именно качество напрямую влияет на удержание, репутацию и в конечном счете на экономику продукта.

Как это измерить? Я выделяю четыре группы метрик, которые стоит мониторить любой продуктовой и инженерной команде.

1. Метрики надежности

Здесь все просто. Пользователь должен иметь доступ к продукту. Ключевые показатели:
▪️Uptime;
▪️SLA;
▪️Коэффициент ошибок.
Это базовый уровень доверия.

2. Метрики функциональности и стабильности

Продукт не только должен работать, но и работать правильно.
▪️Доля ошибок;
▪️Процент негативных обращений в поддержку;
▪️Доля пользователей, столкнувшихся с проблемами.
Эти цифры показывают, насколько стабилен ваш функционал в реальных условиях, а не в тестовой среде.

3. Метрики производительности

Даже если все работает без ошибок, но медленно – ценность падает.
▪️Время загрузки страниц или экранов;
▪️Время отклика на действия.
Просадки здесь сразу бьют по вовлечению и конверсиям.

4. Метрики контроля качества

Это уже про внутренние процессы:
▪️Бюджет ошибок (сколько проблем мы готовы принять);
▪️Процент успешных тестов;
▪️Количество непредвиденных инцидентов после релиза.
Эти метрики помогают оценить, насколько эффективно мы предупреждаем сбои и управляем рисками.

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

Последний слой пирамиды метрик – самый близкий к пользователю: интерфейс продукта и маркетинг. Но его мы разберем в следующий раз.

#харды #метрики #разбор_метрик

Как в SQL настроить фокус окна?

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

Когда я осваивал оконные функции, для меня самым сложным было разобраться не с OVER, партициями или самими функциями, а именно с настройками окна.

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

RANGE, в отличие от ROWS, работает не с физическими строками, а с диапазоном значений ORDER BY. Поэтому несколько строк с одинаковым значением могут попадать в одно окно.

Обе инструкции ROWS и RANGE всегда используются вместе с ORDER BY.

Возьмем наш пример и посчитаем сумму по текущей и следующей строке внутри каждого дня:

SELECT 
  date
, medium
, conversions
, SUM(conversions) OVER(PARTITION BY date ORDER BY medium ROWS BETWEEN CURRENT ROW AND 1 FOLLOWING) AS sum 
FROM orders

Результат выполнения и логику запроса смотрите на картинке.

В выражении для ограничения окна также можно использовать следующие ключевые слова:

▪️UNBOUNDED PRECEDING - указывает, что окно начинается с первой строки группы;
▪️UNBOUNDED FOLLOWING - с помощью данной инструкции можно указать, что окно заканчивается на последней строке группы;
▪️CURRENT ROW - инструкция указывает, что окно начинается или заканчивается на текущей строке;
▪️BETWEEN «граница окна» AND «граница окна» - указывает нижнюю и верхнюю границу;
▪️«Значение» PRECEDING - определяет число строк перед текущей строкой (не допускается в RANGE);
▪️«Значение» FOLLOWING - определяет число строк после текущей строки (не допускается в RANGE).

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

Далее разберем самые полезные оконные функции.

#харды #sql

📁 300+ экспертов и каналов, за которыми следят аналитики

В рамках ежегодного исследования рынка аналитиков, ребята из NEWHR выпустили первую его часть, а именно ТОП экспертов и каналов.

На лендинге вы найдете рейтинги ТОП-15 экспертов и ТОП-30 Telegram-каналов, интересных аналитикам + полные списки.

Они разделены по специализациям: для продуктовых, маркетинговых, дата-, веб- и BI-аналитиков и отдельно для системных и бизнес-аналитиков.

Также хотел поделиться небольшим списком каналов, которые читаю сам и вам советую:
🔹 Статистика и R в науке и аналитике
🔹 JetMetrics
🔹 Data Nature

А что читаете вы? Поделитесь в комментариях.

Как поддерживать форму, будучи руководителем?

Помнишь то чувство, когда ты впервые стал руководителем? Выходишь со встречи, на которой решаются важные вопросы, и понимаешь масштаб новой роли! А какие открываются горизонты…

Но в этой новой реальности есть и обратная сторона - постепенное отдаление от «земли». Как бывший аналитик, я ощутил это на себе: чем глубже погружаешься в менеджмент, тем выше риск потерять харды. Если расслабиться, то однажды можно обнаружить, что опыт больше не подкрепляется актуальными знаниями.

Здесь должен работать принцип, знакомый любому спортсмену: чтобы не потерять форму, нужно постоянно тренироваться. Нельзя уйти только в менеджмент, полностью забросив профессиональные навыки.

Я выработал для себя несколько рабочих практик:

▪️Сознательно оставлять за собой право брать сложные проекты, которые требуют глубокого погружения. Делегировать важно, но иногда нужно и самому «поработать руками», чтобы поддерживать уровень и понимать, с какими реальными вызовами сейчас сталкивается команда.

▪️Системное обучение - обязательно. Это может быть изучение перспективного языка, фреймворка или углубленный курс по новой технологии. Такой подход позволяет расширять кругозор и приносить в команду конкретные, проверенные на себе знания и идеи для внедрения.

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

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

Тренируйте свои профессиональные «мышцы» так же регулярно, как и управленческие. Именно эта дисциплина отделяет просто начальника от настоящего лидера.

#опыт