Как перестать хвататься за все сразу
Часто вижу людей, которых на работе заваливает проектами. Десятки писем и чатов, параллельные инициативы, стратегические задачи вперемешку с операционкой. В итоге расфокус и постоянное ощущение, что ты что-то не успеваешь😕
Если вы себя узнали, хочется кинуть вам спасательный круг.
Я давно использую приоритизацию Must - Should - Nice to Have. Это упрощенная версия метода MoSCoW, разработанного Даем Клеггом в компании Oracle в 1994 году. Метод простой, но действенный. Благодаря ему я всегда понимаю, что именно делать и зачем.
Шаг 1. Соберите полный список проектов
Выпишите все проекты и крупные задачи. Именно все. Не только KPI, но и побочные активности.
Например: запуск нового продукта, развитие дерева метрик, ведение корпоративного блога, организация мероприятия, менторинг стажеров.
Даже сам список уже многое проясняет. Часто кажется, что делаешь мало, но когда видишь 10-15 проектов одновременно, становится понятно, куда уходит время.
Шаг 2. Расставьте приоритеты
Теперь распределите проекты по трем категориям.
▪Must. То, что кровь из носу нужно сделать. Иначе - срыв обязательств, провал цели или потеря доверия.
▪Should. Важно, но можно перенести. Это развитие, улучшения, стратегические заделы.
▪Nice to Have. Было бы классно сделать, но если не сделаете, ничего критичного не произойдет.
Важно! В Must не должно быть половины списка. Если все критично, значит вы не сделали выбор.
Шаг 3. Разложите по неделям
Создайте таблицу в строках которой - проекты из Must и Should, в столбцах недели. Лучше всего делать это упражнение в начале месяца.
На пересечении проекта и недели пишите конкретный результат. Не «заняться», а «подготовить концепт», «согласовать», «запустить пилот».
После этого неделя перестает быть абстрактной. Появляется понятный план действий.
Перегруженность чаще возникает не из-за количества задач, а из-за отсутствия фокуса. Когда приоритет зафиксирован, работать становится проще и спокойнее😌
#опыт
Часто вижу людей, которых на работе заваливает проектами. Десятки писем и чатов, параллельные инициативы, стратегические задачи вперемешку с операционкой. В итоге расфокус и постоянное ощущение, что ты что-то не успеваешь
Если вы себя узнали, хочется кинуть вам спасательный круг.
Я давно использую приоритизацию Must - Should - Nice to Have. Это упрощенная версия метода MoSCoW, разработанного Даем Клеггом в компании Oracle в 1994 году. Метод простой, но действенный. Благодаря ему я всегда понимаю, что именно делать и зачем.
Шаг 1. Соберите полный список проектов
Выпишите все проекты и крупные задачи. Именно все. Не только KPI, но и побочные активности.
Например: запуск нового продукта, развитие дерева метрик, ведение корпоративного блога, организация мероприятия, менторинг стажеров.
Даже сам список уже многое проясняет. Часто кажется, что делаешь мало, но когда видишь 10-15 проектов одновременно, становится понятно, куда уходит время.
Шаг 2. Расставьте приоритеты
Теперь распределите проекты по трем категориям.
▪Must. То, что кровь из носу нужно сделать. Иначе - срыв обязательств, провал цели или потеря доверия.
▪Should. Важно, но можно перенести. Это развитие, улучшения, стратегические заделы.
▪Nice to Have. Было бы классно сделать, но если не сделаете, ничего критичного не произойдет.
Важно! В Must не должно быть половины списка. Если все критично, значит вы не сделали выбор.
Шаг 3. Разложите по неделям
Создайте таблицу в строках которой - проекты из Must и Should, в столбцах недели. Лучше всего делать это упражнение в начале месяца.
На пересечении проекта и недели пишите конкретный результат. Не «заняться», а «подготовить концепт», «согласовать», «запустить пилот».
После этого неделя перестает быть абстрактной. Появляется понятный план действий.
Перегруженность чаще возникает не из-за количества задач, а из-за отсутствия фокуса. Когда приоритет зафиксирован, работать становится проще и спокойнее
#опыт
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥15❤2👍2
В АБ-тестах самая частая ошибка не расчет p-value, а неправильный выбор статистического теста.
▪️Одна выборка или две?
▪️Если две - зависимые или независимые?
▪️Сравниваем средние или пропорции?
▪️Есть ли выбросы?
▪️Насколько однородны группы?
От этого зависит правильность ваших выводов.
Я сделал простую схему-шпаргалку по выбору тестов. Минимальный старт, чтобы не выбирать метод наугад.
Но важно понимать, что схема не заменяет понимание.
Перед применением теста стоит:
✔️проверить однородность выборок;
✔️посмотреть на распределения;
✔️оценить выбросы;
✔️убедиться в независимости наблюдений;
✔️проверить предпосылки конкретного теста.
И только после этого принимать решение.
Для первого шага такой карты достаточно. Дальше все равно придется углубляться: читать, разбирать кейсы, ошибаться и нарабатывать практику.
Если хотите системно разобраться в АБ-тестах, могу порекомендовать курс Паши. Я его знаю лично и доверяю его подходу.
У него как раз упор на практику и полный цикл эксперимента. Сам планирую пойти, потому что в менеджерской роли стал подзабывать АБ.
Сейчас как раз стартует новый поток, и следующий будет только осенью.
#харды #аб
▪️Одна выборка или две?
▪️Если две - зависимые или независимые?
▪️Сравниваем средние или пропорции?
▪️Есть ли выбросы?
▪️Насколько однородны группы?
От этого зависит правильность ваших выводов.
Я сделал простую схему-шпаргалку по выбору тестов. Минимальный старт, чтобы не выбирать метод наугад.
Но важно понимать, что схема не заменяет понимание.
Перед применением теста стоит:
✔️проверить однородность выборок;
✔️посмотреть на распределения;
✔️оценить выбросы;
✔️убедиться в независимости наблюдений;
✔️проверить предпосылки конкретного теста.
И только после этого принимать решение.
Для первого шага такой карты достаточно. Дальше все равно придется углубляться: читать, разбирать кейсы, ошибаться и нарабатывать практику.
Если хотите системно разобраться в АБ-тестах, могу порекомендовать курс Паши. Я его знаю лично и доверяю его подходу.
У него как раз упор на практику и полный цикл эксперимента. Сам планирую пойти, потому что в менеджерской роли стал подзабывать АБ.
Сейчас как раз стартует новый поток, и следующий будет только осенью.
#харды #аб
1🔥13👎6❤3🤔3👍2🤯1
Почему оконные функции могут тормозить запрос?
Я написал уже целую серию постов про оконки (раз, два, три) и там все выглядело красиво - добавил OVER() и получил профит. Но в комментах справедливо подметили, что оконные функции - это часто один из самых тяжелых видов запросов, который сильно жрет ресурсы.
Главный виновник тут обычно не сама функция, а сортировка. Сортировать много строк - дорогая операция на больших объемах данных, и ее лучше избегать везде, где она не нужна. Ниже 4 прикладных совета по оптимизации.
1⃣ Убери ORDER BY из окна, если порядок не влияет на смысл
Частая ошибка - писать ORDER BY внутри OVER() «на всякий случай». Как только он появляется, базе нужно обеспечить порядок строк, а это почти всегда дорого.
Если тебе нужен просто итог по группе (например, общий доход за день для каждой строки), а не накопительная сумма или скользящее окно - ORDER BY внутри окна не нужен.
2⃣ Чем меньше строк, тем быстрее
Оконки «проходят» по всем строкам, часто упорядочивают их, а иногда еще и держат большие куски данных в памяти. Поэтому самый простой ускоритель - сократить объем данных ДО оконки:
✔ Отфильтруй период (например, последние 30/90 дней);
✔ Не тащи лишние колонки («SELECT *» - плохо);
✔ Если можно, то сначала агрегируй данные до нужной гранулярности, а окно считай уже на агрегате.
3⃣ Несколько разных окон = несколько сортировок
Если в одном запросе несколько окон с разным ORDER BY, база может быть вынуждена упорядочивать данные несколько раз. И как итог: больше времени и памяти.
Если можешь, унифицируй порядок в окнах. Если не можешь, то иногда лучше разнести расчеты на 2 шага, чем собирать все в одном SELECT.
4⃣ Используй план выполнения запроса
EXPLAIN - это команда, которая показывает план выполнения запроса: какие шаги база собирается сделать и где она потратит ресурсы. А EXPLAIN ANALYZE еще и выполняет запрос добавляя фактические цифры: сколько строк прошло через каждый шаг и сколько времени заняло.
Далее я разберу, как именно читать EXPLAIN и использовать эту команду для оптимизации.
#харды #sql
Я написал уже целую серию постов про оконки (раз, два, три) и там все выглядело красиво - добавил 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
1👍30❤3🥱1
Как учатся модели машинного обучения?
Ранее я написал небольшую статью про историю ML, а сегодня хочу развить тему дальше.
Речь пойдет о моделях, которые учатся, минимизируя функцию потерь градиентными методами. У других алгоритмов (например, деревья) свои механизмы, но они тоже оптимизируют критерий качества. Есть и алгоритмы, которые вообще не проходят этап обучения - например, kNN просто хранит обучающие данные и делает предсказания на основе ближайших соседей.
Когда модель обучается с «учителем», у нее есть простая джоба: на вход размеченные данные, на выход - предсказание. Но дальше возникает ключевой вопрос: как понять, насколько предсказание хорошее, и как сделать так, чтобы в следующий раз было лучше?
Для этого нужна функция потерь (loss). Формально функция потерь сравнивает две вещи:
▪️ правильный ответ (y);
▪️ предсказание модели ŷ.
И превращает разницу между ними в число ошибки. Именно это число становится целью обучения - модель старается его уменьшить.
Как выглядит обучение по шагам?
Обычно перед обучением проводят подготовку и делят данные на три части:
▪️тренировочная выборка - это те данные, на которых будет учиться модель;
▪️валидационная выборка - чтобы проверять, не начинает ли модель «зазубривать» тренировочные данные и как лучше настроить параметры;
▪️тестовая выборка - финальная честная проверка, когда обучение уже закончено.
1⃣ Модель делает предсказание
Мы подаем признаки (X) в модель, она считает ответ и выдает свой прогноз.
2⃣ Считаем ошибку (loss)
Теперь сравниваем получившееся предсказание модели с правильным ответом, то есть y и ŷ. Получаем ошибку модели и если модель сильно ошибается - loss будет большим. Если предсказывает хорошо, то маленьким.
3⃣ Считаем градиент
Дальше нужно понять, как изменить параметры модели, чтобы ошибка уменьшилась. Для этого считается градиент функции потерь - он показывает направление, в котором нужно менять параметры.
4⃣ Обновляем параметры модели
Сам градиент параметры не меняет. Его использует оптимизатор - специальный алгоритм обновления весов. Оптимизатор делает маленький шаг в сторону уменьшения ошибки.
И после обновления параметров цикл начинается заново.
В итоге получается такой алгоритм:
Сделали предсказание > Посчитали ошибку > Вычислили градиент > Обновили параметры > Повторили тысячи раз.
Какие бывают функции потерь?
Их много, потому что разные задачи требуют разных способов измерять ошибку.
Для интуитивного понимания достаточно двух примеров:
▪️MSE (mean squared error) - ошибка возводится в квадрат. Это значит, что большие ошибки «наказываются» особенно сильно, поэтому модель старается избегать крупных промахов.
▪️MAE (mean absolute error) - берется просто абсолютная разница. Такая функция потерь относится к ошибкам более спокойно и обычно лучше переносит редкие выбросы.
Понимание этого цикла - одна из базовых идей ML. Многие современные модели, от простой линейной регрессии до нейросетей, в той или иной форме обучаются именно так.
#харды #ml
Ранее я написал небольшую статью про историю ML, а сегодня хочу развить тему дальше.
Речь пойдет о моделях, которые учатся, минимизируя функцию потерь градиентными методами. У других алгоритмов (например, деревья) свои механизмы, но они тоже оптимизируют критерий качества. Есть и алгоритмы, которые вообще не проходят этап обучения - например, kNN просто хранит обучающие данные и делает предсказания на основе ближайших соседей.
Когда модель обучается с «учителем», у нее есть простая джоба: на вход размеченные данные, на выход - предсказание. Но дальше возникает ключевой вопрос: как понять, насколько предсказание хорошее, и как сделать так, чтобы в следующий раз было лучше?
Для этого нужна функция потерь (loss). Формально функция потерь сравнивает две вещи:
▪️ правильный ответ (y);
▪️ предсказание модели ŷ.
И превращает разницу между ними в число ошибки. Именно это число становится целью обучения - модель старается его уменьшить.
Как выглядит обучение по шагам?
Обычно перед обучением проводят подготовку и делят данные на три части:
▪️тренировочная выборка - это те данные, на которых будет учиться модель;
▪️валидационная выборка - чтобы проверять, не начинает ли модель «зазубривать» тренировочные данные и как лучше настроить параметры;
▪️тестовая выборка - финальная честная проверка, когда обучение уже закончено.
1⃣ Модель делает предсказание
Мы подаем признаки (X) в модель, она считает ответ и выдает свой прогноз.
2⃣ Считаем ошибку (loss)
Теперь сравниваем получившееся предсказание модели с правильным ответом, то есть y и ŷ. Получаем ошибку модели и если модель сильно ошибается - loss будет большим. Если предсказывает хорошо, то маленьким.
3⃣ Считаем градиент
Дальше нужно понять, как изменить параметры модели, чтобы ошибка уменьшилась. Для этого считается градиент функции потерь - он показывает направление, в котором нужно менять параметры.
4⃣ Обновляем параметры модели
Сам градиент параметры не меняет. Его использует оптимизатор - специальный алгоритм обновления весов. Оптимизатор делает маленький шаг в сторону уменьшения ошибки.
И после обновления параметров цикл начинается заново.
В итоге получается такой алгоритм:
Сделали предсказание > Посчитали ошибку > Вычислили градиент > Обновили параметры > Повторили тысячи раз.
Какие бывают функции потерь?
Их много, потому что разные задачи требуют разных способов измерять ошибку.
Для интуитивного понимания достаточно двух примеров:
▪️MSE (mean squared error) - ошибка возводится в квадрат. Это значит, что большие ошибки «наказываются» особенно сильно, поэтому модель старается избегать крупных промахов.
▪️MAE (mean absolute error) - берется просто абсолютная разница. Такая функция потерь относится к ошибкам более спокойно и обычно лучше переносит редкие выбросы.
Понимание этого цикла - одна из базовых идей ML. Многие современные модели, от простой линейной регрессии до нейросетей, в той или иной форме обучаются именно так.
#харды #ml
1👍15❤2
Как аналитику оптимизировать свои запросы?
Ранее я рассказывал, почему оконные функции могут тормозить, и дал 4 совета по оптимизации. Но если ты действительно хочешь ускорить свои запросы, то начинать нужно с анализа плана выполнения.
Знакомьтесь - EXPLAIN
Команда простая и очевидная, но почему-то ею мало кто пользуется. Может, потому что хочется быстрее решить задачу, а не копаться в том, как база данных обрабатывает запросы. Но когда ты пишешь боевой запрос, от которого зависит работа важной системы, или когда на кластере жесткие лимиты по ресурсам - умение читать EXPLAIN твое все!
Как SQL работает под капотом?
Прежде чем говорить о плане, важно понимать этапы, которые проходит SQL-запрос внутри базы данных (на примере PostgreSQL):
EXPLAIN показывает результат работы planner и это тот самый план, который база данных посчитает оптимальным на основе статистики.
Как читать EXPLAIN?
План выполнения - это дерево. Самый глубоко вложенный оператор выполняется первым. Всегда читай план снизу вверх - так ты увидишь реальную последовательность действий.
Команда EXPLAIN показывает, как именно база данных собирается выполнять запрос: какие индексы использовать, как соединять таблицы, будет ли сортировка.
А EXPLAIN ANALYZE еще и выполняет запрос, добавляя фактические цифры: сколько строк прошло через каждый шаг, сколько времени заняло, сколько памяти использовано.
Основные операторы в плане:
Я не буду переписывать сюда всю документацию. Вот ссылки на официальные руководства, где все подробно расписано:
- PostgreSQL
- MySQL
- SQL Server
- Greenplum
- ClickHouse
Твое задание на сегодня
Возьми любой запрос, который работал долго, и выполни перед ним EXPLAIN, найди самый дорогой узел по стоимости и попробуй его оптимизировать.
Интересными кейсами делись в комментариях!
#харды #sql
Ранее я рассказывал, почему оконные функции могут тормозить, и дал 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
👍12👎3🔥2❤1
Эффективные встречи один на один - существуют ли они?
Я терпеть не могу встречи ради встреч. Обычно это просто сжигание времени. Но есть один формат, в который я по-настоящему верю 🙏
Встречи один на один - не просто регулярный разговор сотрудника с начальником, а один из главных инструментов управления. К сожалению, многие относятся к ним как к простой формальности и проводят их «для галочки».
Для меня 1-1 - это способ синхронизироваться, вовремя заметить проблемы, поддержать и задать направление движения. Именно поэтому к таким встречам нужно готовиться. Не обязательно писать большой план, но важно хотя бы заранее понимать, что хочешь обсудить.
Формат может быть таким:
⚠️ Сами фокусы не должны браться из воздуха. Они должны рождаться из стратегии развития. Если у руководителя нет понимания, куда движется функция, то 1-1 быстро скатывается в обсуждение только текучки. А когда есть стратегия, такие встречи становятся способом регулярно переводить ее в конкретные шаги для команды.
Кстати, я уже готовлю статью про свой опыт создания и внедрения стратегии аналитики в компании.
⚠️ Еще одна практика, которую считаю очень полезной - это фиксировать письменно темы встреч и договоренности в любом удобном инструменте. Всегда можно вернуться и вспомнить, что обсуждали. Потому что если договоренности не зафиксированы, то их не существует.
Как часто проводить 1-1?
Все зависит от вашей команды и контекста, но мне нравятся недельные каденции. Они позволяют не терять фокус и темп: за 5 рабочих дней обычно накапливается достаточно прогресса для обсуждения. Для зрелой команды хватит и двухнедельного интервала, но реже есть риск упустить проблемы.
Такой подход делает встречи не формальностью, а рабочим инструментом. Помогает держать курс, поддерживать людей и не тонуть в текучке.
А вы верите в эффективный 1-1?
👍 - да
🔥 - нет, сжигание времени
#опыт
Я терпеть не могу встречи ради встреч. Обычно это просто сжигание времени. Но есть один формат, в который я по-настоящему верю 🙏
Встречи один на один - не просто регулярный разговор сотрудника с начальником, а один из главных инструментов управления. К сожалению, многие относятся к ним как к простой формальности и проводят их «для галочки».
Для меня 1-1 - это способ синхронизироваться, вовремя заметить проблемы, поддержать и задать направление движения. Именно поэтому к таким встречам нужно готовиться. Не обязательно писать большой план, но важно хотя бы заранее понимать, что хочешь обсудить.
Формат может быть таким:
1. Начинаем с короткого неформального разговора.
2. Даем слово сотруднику: какие есть вопросы, сложности, идеи, что беспокоит, где нужна помощь (и действительно стараемся помочь).
3. Переходим к своей части: рассказываем новости, делимся мыслями, советуем, если это уместно, обсуждаем планы и изменения.
4. Самый важный блок - фокус недели. Фиксируем 1-2 главных приоритета на ближайшие дни. На следующей встрече разбираем: что вышло, что нет и почему.
⚠️ Сами фокусы не должны браться из воздуха. Они должны рождаться из стратегии развития. Если у руководителя нет понимания, куда движется функция, то 1-1 быстро скатывается в обсуждение только текучки. А когда есть стратегия, такие встречи становятся способом регулярно переводить ее в конкретные шаги для команды.
Кстати, я уже готовлю статью про свой опыт создания и внедрения стратегии аналитики в компании.
⚠️ Еще одна практика, которую считаю очень полезной - это фиксировать письменно темы встреч и договоренности в любом удобном инструменте. Всегда можно вернуться и вспомнить, что обсуждали. Потому что если договоренности не зафиксированы, то их не существует.
Как часто проводить 1-1?
Все зависит от вашей команды и контекста, но мне нравятся недельные каденции. Они позволяют не терять фокус и темп: за 5 рабочих дней обычно накапливается достаточно прогресса для обсуждения. Для зрелой команды хватит и двухнедельного интервала, но реже есть риск упустить проблемы.
Такой подход делает встречи не формальностью, а рабочим инструментом. Помогает держать курс, поддерживать людей и не тонуть в текучке.
А вы верите в эффективный 1-1?
👍 - да
🔥 - нет, сжигание времени
#опыт
2👍28🔥5❤4👎1
Друзья, это финальный пост про пирамиду метрик.
Я довольно много писал про метрики и разные фреймворки, и к пирамиде мы возвращались не раз. Но с последним слоем я немного подзатянул - исправляюсь 🙂
На последнем уровне - интерфейс продукта и маркетинг - находятся самые прикладные метрики. Те, с которыми команды работают каждый день и которые напрямую отражают поведение пользователей.
Этот слой отвечает на базовые вопросы:
- как пользователи приходят в продукт?
- что они в нем делают?
- доходят ли до целевого действия?
Как и в предыдущих слоях, здесь есть своя логика группировки. Я выделяю четыре блока:
Этот слой - точка, где формируется все поведение пользователя: как он зашел, что сделал, получил ли пользу. А дальше поднимается выше по пирамиде - в ценность, лояльность и деньги.
На этом мы полностью разобрали пирамиду метрик - от бизнес-уровня до конкретных действий пользователя.
Главное не фреймворк, а используете ли вы его на практике. Будь то пирамида, дерево метрик или что-то свое - важно, чтобы метрики были системой, а не набором цифр.
#харды #метрики #разбор_метрик
Я довольно много писал про метрики и разные фреймворки, и к пирамиде мы возвращались не раз. Но с последним слоем я немного подзатянул - исправляюсь 🙂
На последнем уровне - интерфейс продукта и маркетинг - находятся самые прикладные метрики. Те, с которыми команды работают каждый день и которые напрямую отражают поведение пользователей.
Этот слой отвечает на базовые вопросы:
- как пользователи приходят в продукт?
- что они в нем делают?
- доходят ли до целевого действия?
Как и в предыдущих слоях, здесь есть своя логика группировки. Я выделяю четыре блока:
1. Маркетинг
Это про вход в продукт: кого мы приводим и за какие деньги.
2. Интерфейс
Это уже про UX и то, насколько продукт понятен.
3. Вовлеченность
Здесь видно, «цепляет» продукт или нет.
4. Аудитория
Это наша текущая и потенциальная база.
Этот слой - точка, где формируется все поведение пользователя: как он зашел, что сделал, получил ли пользу. А дальше поднимается выше по пирамиде - в ценность, лояльность и деньги.
На этом мы полностью разобрали пирамиду метрик - от бизнес-уровня до конкретных действий пользователя.
Главное не фреймворк, а используете ли вы его на практике. Будь то пирамида, дерево метрик или что-то свое - важно, чтобы метрики были системой, а не набором цифр.
#харды #метрики #разбор_метрик
❤17👎2👾2👍1
Мои друзья из команд продуктовой аналитики Т-Шопинга и Т-Бизнеса проводят Weekend Offer
4-5 июля вы сможете пройти все этапы, познакомиться с командами и задать вопросы будущим коллегам. Формат - полностью онлайн, поэтому присоединиться можно из любого города России.
Сейчас ищут аналитиков с опытом от года: мидлов, сеньоров и начинающих лидов. В Т-Банке продуктовые аналитики работают вместе с командами с самого старта и помогают формировать гипотезы, оценивать их влияние на бизнес и продукт и искать точки роста.
До 30 июня нужно подать заявку и успеть выполнить тестовое задание.
Переходите по ссылке, регистрируйтесь на Weekend Offer и приходите строить продукты вместе с нами.
P.S. Я не пропал, сейчас активно пишу новую статью про стратегию аналитики, объем материала получается большой, но скоро вернусь.
4-5 июля вы сможете пройти все этапы, познакомиться с командами и задать вопросы будущим коллегам. Формат - полностью онлайн, поэтому присоединиться можно из любого города России.
Сейчас ищут аналитиков с опытом от года: мидлов, сеньоров и начинающих лидов. В Т-Банке продуктовые аналитики работают вместе с командами с самого старта и помогают формировать гипотезы, оценивать их влияние на бизнес и продукт и искать точки роста.
До 30 июня нужно подать заявку и успеть выполнить тестовое задание.
Переходите по ссылке, регистрируйтесь на Weekend Offer и приходите строить продукты вместе с нами.
P.S. Я не пропал, сейчас активно пишу новую статью про стратегию аналитики, объем материала получается большой, но скоро вернусь.
🔥6👎5
Как написать стратегию аналитики и зачем она нужна?
Ура, я наконец-то закончил эту статью! Писал ее долго, потому что хотел сделать по-настоящему крутой гайд, в который вложил много сил. И теперь с радостью делюсь с вами.
Эта статья для тех, кто недавно стал тимлидом или хедом аналитики и чувствует, что пора выйти из режима «просто делаем задачи» и начать думать системно.
Перед тем, как ее опубликовать, я искал подобные материалы и не нашел ничего достойного на русском языке. Есть пересказы Gartner, есть руководства от вендоров уровня «нужно делать data-driven», есть какие-то корпоративные посты. Поэтому статья - попытка закрыть реальный пробел.
В ней вы найдете практическое руководство: как вывести стратегию аналитики из бизнес-целей, честно оценить зрелость команды, пройти три фазы развития и собрать дорожную карту. Это выжимка из моего опыта, с конкретными шагами. Приятного чтения.
#опыт
Ура, я наконец-то закончил эту статью! Писал ее долго, потому что хотел сделать по-настоящему крутой гайд, в который вложил много сил. И теперь с радостью делюсь с вами.
Эта статья для тех, кто недавно стал тимлидом или хедом аналитики и чувствует, что пора выйти из режима «просто делаем задачи» и начать думать системно.
Перед тем, как ее опубликовать, я искал подобные материалы и не нашел ничего достойного на русском языке. Есть пересказы Gartner, есть руководства от вендоров уровня «нужно делать data-driven», есть какие-то корпоративные посты. Поэтому статья - попытка закрыть реальный пробел.
В ней вы найдете практическое руководство: как вывести стратегию аналитики из бизнес-целей, честно оценить зрелость команды, пройти три фазы развития и собрать дорожную карту. Это выжимка из моего опыта, с конкретными шагами. Приятного чтения.
#опыт
1🔥39🦄3❤1
На русском языке о стратегии построения аналитической команды нет почти ничего. Буквально несколько статей, одна из которых моя. Тем ценнее handbook, продолжающий эту тему и превращающий разрозненные наблюдения в пошаговую систему.
📚 From Data to Insights. The strategy of a Data Analytics Team
John Mackay
Джон начинал инженером данных, вырос до руководителя аналитики в крупном европейском банке, а сейчас управляет data-аналитикой в ведущей технологической компании и консультирует Fortune 500. За два десятка лет он построил не одну команду, которая возвращала бизнесу миллионы и делала процессы заметно человечнее. Свой опыт он упаковал в короткое прикладное руководство.
Каркас книги - четыре обязательных элемента любой аналитической функции: команда, данные, стейкхолдеры и отчетность. Автор проведет вас от хаоса первых дней до внятной долгосрочной стратегии.
Вот семь типовых симптомов, знакомых почти каждой команде аналитики:
▪️Завал ad-hoc запросами.
▪️Репутация подорвана и вам не доверяют.
▪️На анализ и инсайты времени нет.
▪️Срочные задачи прилетают в последний момент.
▪️Отчеты разрозненные, пользоваться ими больно.
▪️Коллеги выгорели и потеряли драйв.
▪️Стейкхолдеры вынуждены делать отчеты сами.
Причина, по Маккею, одна - слабая стратегия и плохой дизайн команды. Книга ровно про то, как это исправить. Пригодится и CTO, и тимлидам, и рядовым аналитикам - чтобы понимать, как устроен здоровый data‑организм и в какой момент все пошло не так.
🔗 Электронную версию на английском в PDF качайте по ссылке.
#книга
📚 From Data to Insights. The strategy of a Data Analytics Team
John Mackay
Джон начинал инженером данных, вырос до руководителя аналитики в крупном европейском банке, а сейчас управляет data-аналитикой в ведущей технологической компании и консультирует Fortune 500. За два десятка лет он построил не одну команду, которая возвращала бизнесу миллионы и делала процессы заметно человечнее. Свой опыт он упаковал в короткое прикладное руководство.
Каркас книги - четыре обязательных элемента любой аналитической функции: команда, данные, стейкхолдеры и отчетность. Автор проведет вас от хаоса первых дней до внятной долгосрочной стратегии.
Вот семь типовых симптомов, знакомых почти каждой команде аналитики:
▪️Завал ad-hoc запросами.
▪️Репутация подорвана и вам не доверяют.
▪️На анализ и инсайты времени нет.
▪️Срочные задачи прилетают в последний момент.
▪️Отчеты разрозненные, пользоваться ими больно.
▪️Коллеги выгорели и потеряли драйв.
▪️Стейкхолдеры вынуждены делать отчеты сами.
Причина, по Маккею, одна - слабая стратегия и плохой дизайн команды. Книга ровно про то, как это исправить. Пригодится и CTO, и тимлидам, и рядовым аналитикам - чтобы понимать, как устроен здоровый data‑организм и в какой момент все пошло не так.
🔗 Электронную версию на английском в PDF качайте по ссылке.
#книга
1❤12🔥4✍2🤔2
Lakehouse для аналитиков и инженеров данных
Приглашаем изучить популярный подход построения хранилищ данных Data Lakehouse c разделенным Compute и Storage на основе Iceberg и Trino.
В программе курса:
• Современная архитектура аналитических систем от DWH и Data Lake до Lakehouse с разделением Compute и Storage на базе Apache Iceberg и Trino.
• Iceberg: управление файлами, снимками, каталогами, схемами изменений и очисткой.
• Практическое использование Iceberg Catalog, работа с кластером Trino (на Kubernetes), подключение данных на S3 и выполнение SQL/ Python-запросов.
• Работа с Iceberg+Trinо на больших масштабах: сложные запросы к датасету TPC-DS (2.8 млрд строк), интеграция с DBT, Apache Airflow, оценка производительность систем.
• Построение пайплайнов, инструменты для корректной поддержки, обновления и масштабирования Lakehouse-инфраструктуры на уровне предприятия.
Кто мы: R&D-центр Devhands, наш канал.
Автор курса — Алексей Белозерский, CDO в inSales (Сбер 2B),
ex: VK Tech, М.Видео, Эльдорадо
🗓 Старт курса: 27 августа
Изучить программу и записаться можно здесь.
Ждём вас!
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquZf5с8
Приглашаем изучить популярный подход построения хранилищ данных Data Lakehouse c разделенным Compute и Storage на основе Iceberg и Trino.
В программе курса:
• Современная архитектура аналитических систем от DWH и Data Lake до Lakehouse с разделением Compute и Storage на базе Apache Iceberg и Trino.
• Iceberg: управление файлами, снимками, каталогами, схемами изменений и очисткой.
• Практическое использование Iceberg Catalog, работа с кластером Trino (на Kubernetes), подключение данных на S3 и выполнение SQL/ Python-запросов.
• Работа с Iceberg+Trinо на больших масштабах: сложные запросы к датасету TPC-DS (2.8 млрд строк), интеграция с DBT, Apache Airflow, оценка производительность систем.
• Построение пайплайнов, инструменты для корректной поддержки, обновления и масштабирования Lakehouse-инфраструктуры на уровне предприятия.
Кто мы: R&D-центр Devhands, наш канал.
Автор курса — Алексей Белозерский, CDO в inSales (Сбер 2B),
ex: VK Tech, М.Видео, Эльдорадо
🗓 Старт курса: 27 августа
Изучить программу и записаться можно здесь.
Ждём вас!
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquZf5с8
👍3🔥1