Заскуль питона (Аналитика данных)

Как запланировать на 90% меньше задач в спринте Наконец-то появилось время написать пост. Представим ситуацию: продукт стремительно растет, развиваются новые направления, соответственно, появляется и много стейкхолдеров, которым потенциально интересно решение разного рода задач. Предположим есть 10-20 стейкхолдеров и 5 сотрудников, которым нужно закрывать задачи. Но все было бы просто, если бы не существовало рутины + дополнительных исследований, инициированных самим отделом (допустим, аналитики). Каждому из заказчиков всегда важно решить задачу вчера как можно раньше. У всех высокий приоритет перманентно. Планирование косвенно решает эту проблему, но никто не защищен от так называемых влетов: посчитать метрики, принести выводы к презентации C-level и так далее, спринт может изменяться динамично (но не всегда это хорошо). 1. Начинаем с простого: оцениваем цель задачи. Задаем вопрос: "Для чего нам это нужно?". Обычно ответ на этот вопрос есть всегда, но далеко не всегда задача после этого остается в первом приоритете. Часть задач по доработкам имеющихся инструментов может быть просто не нужна, так как на основной вопрос собранный инструмент отвечает. 2. Оцениваем масштаб задачи. Можно вот тут прочитать про различные методы оценки задач. Если понимаем, что задача комплексная и требует большого количества усилий, декомпозируем и отдаем кусками, чтобы с заказчиком быть в коннекте. 3. Заказчики между собой могут не общаться, поэтому важно на планировании подсветить конкретный капаситет на решение задач. На эти обсуждения особенно интересно наблюдать. Если не раскидывается, уводить в другой спринт или деприоритизировать. 4. Автоматизируем всё, что начинает повторяться. Если один и тот же запрос прилетает второй-третий раз, скорее всего, это уже не разовая задача, а кандидат на инструмент. Некоторые люди не хотят брать на себя ответственность за автоматизацию, но тут задача донести до стейкхолдера, что теперь вместо разовых "выгрузок" он будет смотреть в инстру… Читать полностью →

Плохое ведение проектов может заруинить рост аналитику Может прозвучать банально, но факт остается фактом. В бизнесе есть разные направления: какие-то приносят заметный импакт в тотале, какие-то нет. 🔍 Это может быть стратегический проект, а может быть просто утилизация ресурсов на так называемый дискавери. Представим ситуацию. Проект кажется овнеру классным и амбициозным. Аналитика решают полностью в него погрузить. В процессе оказывается, что большого эффекта как такового нет: по сути, делается удобная фича, которая закрывает определенную боль пользователей продукта. Аналитик тратит на этот проект практически все свое время. Проходит квартал, ожидания не соотносятся с действительностью, а проект в итоге так и не реализован до конца. И тут возникает следующая проблема: оценка результатов и дальнейшая судьба аналитика. 🎰 В бигтехе существуют так называемые калибровки, где аналитиков сравнивают между собой, чтобы определить, кто отработал лучше, а кто хуже. ⌛️ В итоге имеем аналитика, который потратил большую часть квартала на проект, который либо вообще не был реализован, либо был стратегически важен только на уровне конкретного продукта, но не компании в целом. При этом сам аналитик мог отлично проявлять себя внутри продукта: закрывать потребности бизнеса, находить проблемы, влиять на решения и местами буквально тащить продукт, участвуя в определении его стратегии. 😢 Но возникает неприятный момент. Ты можешь отлично сделать свою работу, но выбрать проект, который почти ничего не даст твоему карьерному росту 😎 Аналитик все сделал круто, но его дальнейшее продвижение внутри компании зависит не только от качества его работы. Оно зависит еще и от самого продукта, выбранных бизнесом приоритетов, стейкхолдеров и того, насколько результат проекта вообще можно показать на уровне компании. Поэтому аналитику важно управлять не только исполнением проекта, но и своим портфелем проектов и видимостью результата. 🍪🍪 И еще важнее: заранее подсвечивать такие риски ру… Читать полностью →

♾️ Можно бесконечно оптимизировать систему, но к прорыву это вряд ли приведет. 🙃 🔄 ⬇️ 📈 Знаете, есть естественное желание постоянно улучшать то, что уже работает: добавлять новые фичи, подкручивать технические метрики, ускорять процессы, исправлять мелкие проблемы. 😮 Каждое такое изменение вроде бы делает продукт лучше. Но в какой-то момент возникает вопрос: мы действительно движемся вперед или просто все эффективнее оптимизируем то, что уже построили? ⬇️ Можно бесконечно работать над улучшением дашбордов ⬇️ Ускорять SQL ⬇️ Улучшать качество витрин ⬇️ Автоматизировать отчетность ⬇️ Делать более сложные модели 💸 Прорыв чаще возникает, когда аналитика меняет сам способ принятия решений: находит новый сегмент роста, показывает, что привычная продуктовая гипотеза неверна, перераспределить бюджет, поменять механику монетизации или обнаружить ограничение, которое бизнес вообще не считал главным. Аналитик может бесконечно улучшать качество измерения системы, но настоящий импакт появляется, когда он помогает изменить саму систему Можно идеально научиться измерять бизнес, но так и не найти в нем то, что можно улучшить. 🔥 А у вас был кейс, когда аналитика не просто улучшила текущий процесс, а реально изменила сам подход бизнеса к решению проблемы? Пишите в комментариях 🍪🍪 zasqlpython.ru

Когда у вас откроется уникальная возможность бесплатно поработать на какую-нибудь компанию — обязательно залетайте. Такие шансы выпадают не каждый день. 🐸 Возможно, вы даже получите: 🟣бесценный опыт 🟣строчку в резюме 🟣дмс и другие бенефиты 🟣доступ к стартаперскому вайбу 🟣и ненулевую вероятность, что фаундер поделится прибылью в виде кириешек с холодцом и хреном @zasql_python

Кажется, собеседования аналитиков (да не только аналитиков) немного сломались. На работе аналитик: 🟢гуглит документацию 🟢смотрит старые запросы 🟢использует ChatGPT / Claude / Copilot 🟢спрашивает коллег 🟢проверяет гипотезы На собеседовании: Расшарь экран. Ничего не открывай. Или по базе дать задачу на алгоритмы, которые аналитику в принципе не нужны. ❓ И у меня вопрос. Мы проверяем, насколько хорошо человек будет работать аналитиком или насколько хорошо он подготовился сдавать экзамен? Я бы скорее взял человека, который с AI и документацией решит реальную задачу правильно за 15 минут, чем того, кто идеально помнит синтаксис, но плохо понимает продукт. Хотя полностью убирать базовые знания с интервью тоже кажется неправильным. Где для вас проходит граница? Как бы вы проводили собесы в текущих реалиях? Пишите в комментах, интересно почитать... 📱 Один из популярных комментов под моим постом в LinkedIn Я бы честно смотрел на другое. Даёшь человеку реальную задачку, разрешаешь гуглить, мучить Claude и звать воображаемого коллегу, и просто наблюдаешь, как он думает. Если он через пять минут говорит "стоп, тут цифры не сходятся, давайте сначала проверим данные", берём . А если просто вставил ответ нейронки, даже не проверив, и гордо откинулся на стуле, то это уже тревожный звоночек А если хотите подготовите к собесам на аналитика, переходите на ресурс 🔥 zasqlpython.ru

🏆 Хотим проактивного сотрудника. Чтобы сам находил проблемы, предлагал гипотезы и думал, как улучшить продукт. Нашли. Наняли. Забили ему календарь и очередь задач 😁 В понедельник срочная выгрузка. Во вторник отчёт руководству. В среду упала метрика, нужно разобраться. В четверг ещё пять задач, все нужны вчера. В пятницу катим 🆎 На ревью: ⌚️ Хотелось бы больше инициативы. 😡 А в какой момент? Между двумя срочными задачами или уже после работы? Да, аналитик не должен молча брать всё подряд. Можно уточнять, спорить со сроками, предлагать другой способ решить задачу. ❗️ Но если на каждую попытку заняться своей гипотезой слышишь: "давай сначала закроем рутину, а уже потом приступим к твоей супер крутой задаче, которая повлияет на всю компанию", довольно быстро понимаешь, что до неё очередь не дойдёт. Мне кажется, нельзя одновременно требовать, чтобы человек выполнял все входящие запросы, и удивляться, почему он ничего не предлагает сам. В первую очередь, это задача руководителя: создать необходимые условия под рост своего сотрудника. У вас есть время проверить свои идеи на работе или этим можно заняться, только когда разгребёшь другие задачи? @zasql_python