Не только цифры: как быть успешным аналитиком, развиваться в профессии и не выгорать. Часть 2
Привет! На связи тимлиды аналитики Авито — Андрей Красовицкий и Сергей Медин. В первой части статьи мы сфокусировались на том, как аналитикам выстраивать эффективные рабочие отношения с коллегами и заботиться о балансе между работой и личной жизнью. В продолжении материала речь пойдёт о решении задач и развитии профессиональных навыков.
Расскажем о принципах декомпозиции задач и эффективном планировании рабочего времени. А также поделимся рекомендациями, как развиваться в аналитике, даже если времени на курсы и обучение совсем немного.
Все советы основаны на нашем опыте — как успешных кейсов, так и ошибок, которые мы разобрали и учли. Надеемся, что эта часть материала будет для вас не менее полезной.
Решение задач
Одна из основных проблем аналитиков — недостаток внимания к тому, как организована их работа. Теоретически они знают, как структурировать решение задачи, но на практике часто начинают действовать хаотично.
Ещё одна распространённая сложность — неуверенность в своих силах, которая возникает из-за ощущения, что в других командах решают более амбициозные и масштабные задачи. Аналитикам кажется, что коллеги строят «космолёт», в то время как они занимаются чем-то простым и незначительным.
Нашей команде поручили выделить среди новых клиентов тех, кто приносит наиболее высокий доход (LTV), чтобы назначить им персонального менеджера. Аналитик, который взялся за задачу, предложил использовать ML-моделирование для оценки клиентов, но из-за неуверенности в собственных силах или недостатка опыта в подобных задачах, процесс замедлился.
Специалисту казалось, что кто-то из коллег справился бы с задачей лучше, и это мешало ему сосредоточиться. За первые две недели у нас практически не было результатов, так как аналитик сразу бросился в расчёты без продуманного плана.
Чтобы исправить ситуацию, мы провели встречу, разложили задачу на ключевые шаги и определили, что нужно сделать в каждом из них. Прописали сроки и риски для каждого этапа. Это позволило двигаться постепенно, шаг за шагом улучшая модель.
В итоге мы смогли создать несколько версий модели, которые успешно прошли тестирование. Хотя наш скоринг имел свои недостатки, на общем митапе команда восприняла его с большим энтузиазмом — казалось, что мы действительно собрали тот самый «космолёт».
Совет 1: Декомпозируйте задачи — сложные решения состоят из более простых
Аналитики часто сталкиваются с задачами с расплывчатой формулировкой и неопределённым прообразом результата. При этом заказчики часто хотят сразу узнать сроки или порой даже требуют уложиться в конкретный дедлайн. Такая ситуация может вызвать растерянность. И тут важно не паниковать, а декомпозировать задачу.
Аналитические задачи обычно делятся на два основных типа:
1. Исследование — задачи, результатом которых должно быть выявление взаимосвязей, сегментов или расчёт ещё неизвестной метрики. На старте может даже не быть гипотез.
2. Разработка — здесь уже есть представление о конечном результате или функционале модели, инструмента, и задача состоит в том, чтобы определить путь к цели.
Нередко исследование может быть предвестником задачи по разработке, и наоборот. Но подходы к декомпозиции для них немного отличаются.
Используйте принцип МЕСЕ для задач, где мало вводных. К таким мы как раз отнесли исследования. В них зачастую неизвестно, каким будет результат или возможно ли вообще ответить на поставленные вопросы. Поэтому полезно использовать принцип MECE.
МЕCE: mutually exclusive — взаимно исключающие и collectively exhaustive — совместно исчерпывающие. На этот подход делают упор в рамках собеседований в компаниях большой тройки — McKinsey, Bain, BCG.
Этот принцип структурирует информацию, помогает разделять её на взаимно исключающие и полностью исчерпывающие части. Это позволяет охватить все аспекты проблемы. Рассмотрим на примере, чтобы было понятнее.
🔍 Пример: как применять МЕСЕ, чтобы найти причину снижения прибыли компании. Случайный перебор гипотез редко приводит к пониманию причины какого-то события. А фразы: «упали продажи» или «выросли издержки» мало что объяснят.
Чтобы более чётко увидеть картину, прибыль следует разложить на основные составляющие. С помощью дерева, построенного по принципу MECE, прибыль можно разложить на выручку и издержки. Затем выручка распадается на — количество и цену товаров, а издержки на — фиксированные и переменные.
Даже в рамках такой простой структуры мы получаем более полную картину и можем выдвигать гипотезы в чётко заданных границах. Например, снизились продажи, упали цены, выросли переменные или фиксированные издержки.
Преимущество этого подхода в том, что каждый шаг исключает другие: если причина не в выручке, то она точно в издержках. Кроме того, структура охватывает все возможные варианты — проблемы с прибылью могут быть связаны только с выручкой или с издержками.
Недавно мы применили этот подход в Авито. Нам нужно было оценить эффективность продукта, но единой метрики для этого не было, и придумать её сразу не получалось. Поскольку продукт был сложный и состоял из множества элементов, нам было важно получить общую картину по всем функциям.
Чтобы решить задачу, мы взяли ключевую потребность клиентов и начали дробить её на логические блоки. В результате получилось многоуровневое дерево, на котором мы сразу увидели: одну часть аспектов мы вовсе упускали из внимания, а для другой части ещё не было метрик оценки эффективности.
Я применял метод MECE на своём прошлом месте работы, когда нужно было разобраться с проблемами в приложении для курьеров Яндекса.
Мы начали с классификации всех проблем: критические — те, что блокируют работу, значительные — создающие неудобства, и незначительные — мелочи, которые всё равно требуют внимания. Это позволило понять, что действительно важно, а что может подождать.
Затем разделили на группы критические потребности: интерфейс, функциональность, производительность и интеграции. Разработчикам стало проще расставить приоритеты и сосредоточиться на самом важном.
Когда оказалось, что корень многих сложностей — производительность, мы снова применили MECE: разделили всё на серверные, клиентские, сетевые и платформенные проблемы. Глубже копнули в серверную часть — там выяснилось, что основные узкие места связаны с базой данных, балансировкой нагрузки и настройкой серверов.
В результате проделанной работы разработчики чётко знали, что делать, решали задачи быстрее, и команда в целом стала продуктивнее. Метод MECE помог нам превратить хаос в структуру, а проблемы — в задачи, которые легко решать.
📌 Пробуйте выделять время для декомпозиции повседневных задач по принципу MECE. Со временем взгляд на задачи станет более структурированным, и процесс деления их на логические части начнёт происходить автоматически. Этот принцип полезен не только для решения задач, но и для развития системного образа мышления.
При разработке сложного инструмента или модели также используется подход MECE, но с акцентом на деление задачи на последовательные, взаимно исключающие шаги, которые полностью покрывают все этапы разработки.
🔍 Пример: как мы применяли этот принцип для построения модели поиска высокопотенциальных клиентов. Сначала остановились на базовом подходе по созданию ML-модели:
Этот план был слишком простым, поэтому каждый шаг мы разложили детально. Например, «подготовка данных» включала:
Такой детализированный план помогал нам видеть чёткую последовательность действий, сроки, и делал работу прозрачной и понятной.
Метод МЕСЕ помог нам начать чётко двигаться к цели и уйти от путаницы. Сначала мы сделали сегментацию на основе бизнес-правил, затем добавили ML-модель, расширили функционал, наладили подачу данных и сократили время между регистрацией пользователя и получением результата. Выполняя задачу поэтапно и последовательно, мы смогли создать мощное решение, собранное из простых, понятных частей.
📌 Попробуйте перейти от подхода, когда задачи выглядят как одно большое целое, к «LEGO-подходу». Представляйте их как набор небольших элементов, которые можно собрать в общее решение.
Совет 2: Научитесь планировать задачи и управлять ожиданиями
Одна из частых проблем при работе с аналитиком — это несоблюдение сроков. Заказчики могут давить, требуя быстрых результатов, а аналитики часто боятся предлагать более длительный срок, чтобы не показаться неэффективными. Поэтому называют нереалистичное время.
У нас был случай, когда аналитик пообещал построить модель прогноза спроса за три дня. Заказчик из коммерческого отдела настаивал на сжатых сроках, и аналитик, чтобы показать свою эффективность, согласился, не учитывая при этом объём работы и возможные сложности.
Когда началась работа, оказалось, что данные из нового региона неполные, их качество низкое, а доступ к некоторым источникам требует согласований. Параллельно всплыли уточнения по параметрам модели, которые также затянули процесс. Уже на второй день стало ясно, что уложиться в сроки невозможно. Чтобы успеть к заявленному сроку, аналитику пришлось работать ночами, но модель всё равно получилась сырой. Её доработка заняла ещё несколько дней, а сам аналитик был вымотан.
Этот случай стал уроком: лучше изначально давать реалистичную оценку сроков и честно объяснять заказчику все риски. А если возникают сомнения — запрашивать время на уточнение или обсуждать проблемы сразу, как только они появляются.
Чтобы решить сложности с оценкой, мы сформулировали правило. После нескольких экспертных замеров выяснили, что реалистичный срок для аналитической задачи — это негативный, по оценке аналитика сценарий, умноженный на два.
В негативный сценарий закладываем возникающие новые задачи, баги и просьбы о доработках от заказчиков.
Учитесь аргументировать время, которое закладываете на задачу, и предлагать другие решения, когда сроки заказчиков нереалистичны. Если задача оценивается в один день, но вы заявляете два, объясните, что нужно дополнительное время на проверку результатов.
Если задача требует недели — можно удвоить срок для учёта параллельных задач.
А если заказчик требует сделать что-то сложное, ещё и за короткий промежуток времени — предложите более реалистичное решение. Например, у нас был случай, когда заказчик попросил создать модель скоринга клиентов для одной из задач за месяц. Мы понимали, что сделать это невозможно, и предложили более простую сегментацию по бизнес-правилам. Это позволило уложиться в срок и выиграть дополнительное время для полноценного решения.
📌 Прозрачность помогает избегать выгорания и приносит больше пользы заказчику, чем героические попытки сделать невозможное. Лучше заранее закладывать больше времени и в идеале завершать задачу раньше. Тогда заказчик будет доволен, что получил результат раньше, и у него сложится положительное впечатление об аналитике.
Совет 3: Учитывайте, что обёртка аналитики важна не меньше, чем содержание
Часто аналитики с сильными техническими навыками продвигаются по карьерной лестнице медленнее, чем их менее опытные коллеги. Одна из главных причин — недостаточное внимание к тому, как они презентуют свои результаты.
Такие специалисты чувствуют неуверенность в своих силах, несмотря на высокий уровень экспертизы, а ещё им может быть трудно строить коммуникацию и презентовать результаты своего труда. И тогда формируется образ специалиста, которому заказчики доверяют меньше, даже несмотря на его профессиональные достижения.
Весь процесс работы аналитика в целом сводится к двум составляющим: провести расчёты, а потом убедительно и понятно презентовать результаты. Советы для каждого этапа:
Оформляйте скрипты аккуратно и понятно для других людей — помните, он может понадобиться вам через время, а ещё его может захотеть посмотреть другой аналитик.
Например, если создаёте SQL-скрипт для витрины данных, помните, что коллега может попросить его для анализа логики расчёта некоторых столбцов. Если в скрипте не будет форматирования, длинные операторы будут записаны в одну строку, пробелы и табуляции расставлены несистемно, а команды вроде SELECT указаны то в верхнем, то в нижнем регистре — в таком коде будет сложно разобраться.
А вот чёткая структура и комментарии помогут другому аналитику легко понять логику и снизят вероятность ошибок.
Разбивайте скрипт на логические блоки и не размещайте всю логику в одном месте. Применение «LEGO-подхода» — разбиение задачи на более простые части — также сделает расчёты более понятными и структурированными. Пишите скрипты так, чтобы через полгода их можно было легко обновить и вспомнить заложенную логику.
Я особенно остро ощутил важность форматирования на своём первом проекте, когда ещё был стажёром в McKinsey.
Нам нужно было срочно подготовить презентацию с большим набором цифр из разных источников для клиента. Я принялся за расчёты, вставил полученные данные в презентацию, после чего отправил её коллегам на проверку.
Они вернулись с замечанием, что цифры в ряде мест не сходятся и их нужно срочно исправить. Мне пришлось потратить почти всю ночь, чтобы найти ошибку, так как в скрипте отсутствовало форматирование и структура. И после того как нашёл ошибку, я снова проверял скрипт на наличие других неточностей.
После того случая я получил от старшего коллеги ценный совет — всегда использовать форматирование для повышения точности и удобства работы с кодом.
Несколько советов для создания хорошей презентации результатов:
Собирайте материалы для рассказов и делайте небольшие презентации или доски для демонстрации важных данных. Многие аналитики часто не персонализируют презентации или не готовят их вообще. На демо встречах, когда рассказывают о результатах, они просто читают со скриптов, задач в трекере или сочиняют рассказ на ходу. Такие выступления сложно воспринимать, а значит, сложно оценить и дать полезную обратную связь.
Мы рекомендуем готовиться к выступлениям и собирать материалы. С презентациями данные будут более наглядными, и слушателям будет проще воспринимать информацию.
Стройте структуру по простому шаблону, например, STAR. Сначала опишите контекст, затем задачу, ключевые этапы решения, результаты и следующие шаги. Используйте буллиты для текста, добавьте скриншоты скриптов или графиков. Такой формат будет выглядеть последовательно.
Учитывайте специфику аудитории, для которой делаете рассказ. Чтобы создавать подходящий материалы, важно ставить себя на место слушателей. Представьте ситуацию: вы построили сложную многоуровневую модель, потратили месяцы на обработку данных, создание фич и устранение багов. Теперь пришло время поделиться результатами — с ключевыми заказчиками, другими аналитиками и друзьями не из IT.
Для каждой группы подход должен быть разным.
🙋 У ключевых заказчиков много задач, и для них ваша модель — часть большого проекта. Им важен эффект и область применения модели, а не технические детали.
Подготовьте для них лаконичный документ с ключевыми моментами и выводами. Цель — кратко и ясно объяснить пользу модели, избегая перегрузки информацией.
🧑💻 Другие аналитики интересуются технической частью — как и почему вы пришли к такому решению. Хотя они знакомы с аналитическими инструментами, просто показывать им скрипты недостаточно. Бывает что, даже если тема интересна, разобраться в информации всё равно сложно. Поэтому стоит упрощать материалы, добавлять визуализации и примеры.
🧍Друзья не нуждаются в технических деталях, часть из которых ещё и под NDA.
Здесь лучше всего делиться общими впечатлениями или забавными моментами. Важно учитывать интересы собеседников, чтобы не утомить их рассказом о работе.
Однажды мы с командой представляли менеджерам по продажам идею внедрения RFM-сегментации клиентской базы. Подробно объяснили им, как рассчитываются метрики, зачем нужны перцентили и как мы проверяли результаты через корреляционный анализ. Нам казалось, что всё изложено ясно. Но для менеджеров информация оказалась сложной, и они не увидели, как эти данные связаны с их задачами.
Мы взяли паузу, переработали презентацию и сосредоточились на том, какую пользу это принесёт именно их работе. Вместо аналитических терминов использовали язык слушателей: показали, как сегментация помогает повышать конверсии, экономить время и точнее работать с клиентами. Вместо сложных расчётов использовали понятные категории: активные клиенты, спящие, премиальные.
Результат не заставил себя ждать. Менеджеры поняли суть, стали задавать вопросы и обсуждать внедрение. Этот случай научил нас: успешная презентация — это не демонстрация вашей экспертизы, а способность говорить на языке аудитории.
Поймите, что важно для ваших слушателей, отберите только ключевые моменты и покажите, как это улучшит их результаты. Тогда ваше сообщение услышат.
✍ Больше о RFM-сегментации, её пользе и тонкостях расчётов вы можете найти в моей статье на Хабре: «Какие сложности мы преодолели при внедрении RFM-сегментации клиентов в Авито Недвижимости».
Там я описал реальные кейсы и результаты, которые сделали анализ понятным и полезным для работы.
Совет 4: Не ищите сложные решения
Аналитики часто стремятся сразу использовать сложные, непонятные для менеджеров подходы, которые требуют долгой разработки. В результате, когда такие проекты запускаются, менеджеры бывают недовольны. Они ожидали идеальной точности, а первая версия решения редко отвечает этим запросам. Отсюда совет — начните с простого решения, например, бизнес-правил или логики if-else.
Такие подходы понятны заказчикам, их легко объяснить, а прозрачная логика помогает снизить критику. Кроме того, аналитики получают время для разработки более сложного решения, которое позже можно будет сравнить с первым вариантом и показать, как оно улучшило результаты.
В одном из проектов в McKinsey мы разрабатывали персонализированные предложения для ритейл-компании, чтобы увеличить прибыль от клиентов. Сначала мы взяли простой метод RFM-сегментации и быстро внедрили его. Тем самым мы выиграли больше времени на разработку ML-модели.
В первом тесте RFM-сегментация показала более хорошие результаты, которые ML-модель обогнала только после нескольких доработок.
В Яндексе мы решали задачу кластеризации поисковых запросов. Команда предложила использовать нейронные сети, чтобы анализировать семантику запросов и находить между ними связи. Решение выглядело перспективным, но на практике оказалось сложным, требовало постоянных доработок и всё равно не давало ожидаемых результатов.
Тогда я предложил упростить подход: вместо анализа семантики просто посмотреть на совпадения URL-адресов в выдаче Google. Если у двух запросов было хотя бы три общих URL из десяти, мы объединяли их в один кластер. На реализацию ушло всего несколько часов, а результаты превзошли все предыдущие попытки. Метод оказался не только точным, но и легко реализуемым.
Этот случай напомнил, что сложные решения не всегда оправданы. Простое, но продуманное решение может быть быстрее, эффективнее и понятнее. Иногда стоит остановиться, взглянуть на задачу по-новому и сначала попробовать наиболее очевидный путь.
Совет 5: Помните: отсутствие результата — тоже результат
Ещё со времён университета нам внушают мысль, что каждое исследование или решение должно приносить заметный эффект. Однако в реальности большинство экспериментов завершаются без ярких успехов, и это совершенно нормально. Такие задачи нельзя считать бесполезными, потому что даже отсутствие результата может дать ценные инсайты.
Тем не менее в некоторых компаниях для хороших результатов на ревью важнее сделать простое и быстрое действие, например, перекрасить кнопку и получить дополнительные деньги. Но с точки зрения аналитических усилий, очевидно, что эффективнее провести комплексное исследование, в результате которого можно сформулировать выводы о причинах падения показателей и предложить дальнейшие шаги для развития продукта.
Если вы пришли на перформанс ревью с исследованиями, у которых не было ярких результатов — можно сделать следующее:
Привяжите результаты к числам. Если прямого влияния на прибыль нет, результаты можно выразить через экономию времени (FTE), человеко-часы, потенциальные потери или выгоды. Даже в сложных проектах стоит искать количественные показатели, которые помогут обосновать ценность работы.
Говорите о ценности опыта. Важно фиксировать, какие знания и навыки вы получили в процессе, какие точки роста вы нашли, а какие направления оказались неэффективными.
📌 Даже если эксперимент не дал ожидаемого результата, он помогает компании двигаться вперёд. Без таких попыток прогресс остановится.
Развитие
Не все готовы посвящать личное время чтению статей, просмотру обучающих видео или посещению курсов. Однако это не означает, что развитие аналитических навыков останавливается. Есть и другие подходы, которые позволяют прогрессировать, не превращая обучение в дополнительную нагрузку.
Совет 1: Посещайте внутренние и внешние аналитические встречи
Многие компании регулярно проводят внутренние аналитические встречи, а также дают возможность посещать внешние мероприятия. Найти время для внутренних встреч обычно несложно — их можно слушать даже параллельно с другими задачами.
Для внешних мероприятий стоит выделить ресурс, но на таких встречах не обязательно пытаться уловить каждую деталь или полностью вникнуть в суть. Главное — расширять кругозор. Слушайте, что делают другие аналитики, и формируйте представление о возможных подходах. Это поможет увидеть больше вариантов решений и применять новые идеи в своих задачах.
Совет 2: Ищите ответы в процессе работы
Навык поиска информации стал важнее, чем умение помнить всё наизусть. Например, вместо того чтобы держать в голове различия между precision и recall, достаточно найти это в интернете. Умение быстро искать ответы через Google, Яндекс или AI-ботов помогает не только решать конкретные задачи, но и изучать новые темы.
Когда и как использовать поиск информации для развития:
В процессе решения задач
Если задача новая или вы собираетесь использовать подход, который никогда не применяли на практике, имеет смысл выделить время для изучения темы. Это поможет не только познакомиться с новым методом, но и сразу закрепить его через практику.
Во время встреч и мероприятий
На рабочих синках, демо или конференциях часто звучат незнакомые решения. Если они кажутся полезными или актуальными, стоит глубже погрузиться в тему, чтобы понять основы и расширить кругозор.
Во время общения с коллегами
Работа с опытными специалистами открывает возможность учиться у них. Если тема кажется интересной, можно договориться о встрече, чтобы коллега объяснил детали и ответил на вопросы. Это не только помогает лучше понять материал, но и укрепляет профессиональные отношения.
📌 Используйте своё время эффективно, сочетая работу с развитием. Не стесняйтесь спрашивать, искать ответы и изучать новое. Главное — развивать аналитический кругозор, а остальные навыки придут с опытом.
Вся статья кратко:
Надеемся, что статья была полезной и вдохновила вас на новые подходы в работе. Вот три главных вывода, которые вы можете начать применять прямо сейчас:
👉 Декомпозируйте задачи и начинайте с простого. Разбивайте проекты на понятные шаги и начинайте с простых решений. Это сделает процесс более управляемым и повысит уверенность в своих силах.
👉 Планируйте реалистично. Учитывайте риски и закладывайте время на проверки. Заранее обсуждайте сроки с заказчиками и будьте готовы предложить компромисс, если срок дедлайна слишком сжатый.
👉 Преподносите результаты в соответствии с целевой аудиторией. Презентация выводов не менее важна, чем сами расчёты. Учитывайте специфику аудитории: для заказчиков — краткость и польза, для коллег — технические детали, для друзей — простота и интересные моменты.
Если вам интересно строить карьеру аналитика и развиваться вместе с сильной командой, приходите работать в Авито! Мы всегда ищем талантливых специалистов. Подробности можно найти на нашем карьерном сайте.