Аналитик в запуске нового продукта

Всем привет! На связи Дима Кротов, старший аналитик в Работе.

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

1️⃣ Ценность каждой выполняемой вами задачи очень высока (те самые 20% усилий дают 80% результата), и один сделанный чарт может дать такой импакт, над которым в уже устоявшейся команде нужно работать месяцами. 🚀

2️⃣ Работая над новым продуктом, вы строите фундамент, которым будут пользоваться годами (если, конечно, всё пойдёт по плану). Ловушка с временными решениями, оказавшимися в итоге самыми постоянными, здесь работает на все 100%. Поэтому лучше сразу сделать хорошо (ну или хотя бы приемлемо), чтобы через несколько лет не пришлось на вопрос: «Почему так криво / неудобно / костыльно?» отвечать — «Так исторически сложилось». 🛠

3️⃣ Сильно сомневаться в данных на старте — очень полезно. Как бы странно это ни звучало для аналитика, но это так: когда вы только начинаете получать первые логи из сервисов и пользовательские события, челленджите их. Возможно, что-то не доезжает, передаётся не в том виде. На старте это нормально, и именно аналитик может вовремя заметить поломку и поднять вопрос о фиксах. 📊

4️⃣ Память подводит, а документация — нет. Через полгода вы не вспомните, почему на одном из двадцати графиков в конкретную дату что-то отвалилось. А бизнес вдруг возьмёт и заинтересуется. И тогда из широких штанин аналитик достанет документацию и заметки. Аналогично и со всеми аналитическими артефактами в целом. Важно инвестировать время в описание процессов, источников и событий — это окупится в виде меньшего числа вопросов и противоречий в будущем. 📄

5️⃣ Контекст очень изменчив, поэтому важна постоянная коммуникация. Во время запуска команда движется очень быстро, и фокус может меняться буквально за пару дней или даже часов. На этом этапе очень важно много слушать и не менее важно — говорить: подсвечивать любые инсайты, задавать вопросы и оценивать, что в фокусе у команды именно сейчас. Вполне возможно, что то, что вы собрались делать, уже просто неактуально, и это тоже нормально. Главное — вовремя сменить фокус. 💭

Резюмируя, основные отличительные черты данной стадии развития продукта: обилие коммуникации и процессных вопросов (сильно больше, чем обычно), преобладание инфраструктурных задач, большой импакт даже от небольших ресерчей и роль аналитика-навигатора, без которого продукт может легко свернуть не туда. И, как по мне, строить что-то полезное и большое из ничего — очень драйвово. 🚀

Интересно, что ближе вам: стабильные и понятные задачи в устоявшихся продуктах и командах или много неизвестности и открытости в командах-стартапах? Делитесь в комментах!

#ДимаКр

Сила простого языка

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

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

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

1️⃣Упрощение снижает вероятность искажений. Чем проще язык, тем меньше шансов, что смысл ваших выводов теряется в «переводе». Ясная формулировка помогает избежать недопонимания, ускоряет согласование и снижает вероятность ошибок — итоговые решения и рекомендации становятся более действенными.

2️⃣Нынешний синьор когда-то был стажёром, который задавал кучу вопросов с очевидным ответом. В компетенции любого эксперта, даже если он не стремится в менеджерский трек, входит обмен знаниями. Без этого любая команда быстро превратится в набор разрозненных сотрудников, которые всё делают по-своему и не согласуются между собой.

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

3️⃣Упрощать сторител, значит, облегчать продажу результатов. Собирать данные и строить сложные модели — это только полдела. Если ты не можешь объяснить, какой инсайт нашёл, почему это важно и как поможет бизнесу, работа рискует превратиться в тыкву и лечь в стол. Более того, подстраиваясь под контекст собеседника, мы включаем его эмпатию и повышаем расположение к себе. А это напрямую влияет на шанс, что предложение услышат, поддержат и доведут до реализации.

4️⃣Упрощать не значит демонстрировать некомпетентность. Напрасно ощущать неловкость и раздражаться из-за того, что приходится объяснять что-то «на пальцах». Порой бывает непросто в десятый раз отвечать на, казалось бы, базовый вопрос. Но все не обязаны разбираться во всём, и это ок. Настоящая сила в том, чтобы спрятать сложность под капот и, как в хорошем продукте, показать пользователю понятный интерфейс, скрыв устройство изнутри.

🐾 Помню, когда был ещё стажёром, встретил коллегу, которая нарочито сыпала терминами, а на моё непонимание и просьбу объяснить реагировала, мягко говоря, с презрением. Тогда я, наверно, подумал, что проблема во мне. Но сейчас убеждён, что такое поведение — проявление непрофессионализма. Всё равно, что самоутверждаться за счёт более «слабого». Такие специалисты токсичны и точно проигрывают на долгой дистанции.

Резюмируя — чем выше грейд и зона ответственности, тем больше важных коммуникаций с соседними функциями приходится вести. И умение говорить простым языком становится не полезным, а вовсе необходимым для создания ценности продукту и бизнесу. Не зря одна из основных ценностей в нашей компании звучит так: «Упрощай».

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


#ДимаКр

Да настройте вы уже эти лифты…🛗

Всем привет! На связи Дима Кротов. После нескольких лет в профессии у каждого из нас появляется «профдеформация»: стоматолог первым делом смотрит прикус, дизайнер — отступы и шрифты, а аналитик… не может пройти мимо криво работающего лифта 😳

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

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

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

✅ Целевая: время от нажатия на кнопку до доставки на целевой этаж
🔷 Прокси: среднее время ожидания лифта, количество промежуточных остановок
🛑 Контр: доля пустых рейсов, износ лифта

А по пути можно ещё и какой-нибудь CSAT замерять🙂

Ок, а какие алгоритмы подобрать, если лифт вызывается через ввод этажа в вестибюле? У меня получилось несколько вариантов (названия я придумал сам, не судите строго):

1️⃣Batching (группировка заявок) — система собирает заявки за «интервал сбора», затем группирует людей с близкими целями в одну кабину (батчи), минимизируя число остановок и общее время поездки.

2️⃣Zoning (зональное разделение) — этажи делятся на зоны (например, 1–7, 8–14, 15–20). В зависимости от введённого пользователем этажа, система направляет его в лифт, обслуживающий именно эту зону. Это снижает количество «пересечений» между зонами и ускоряет доставку, однако разные зоны могут пользоваться разным спросом, из-за чего может простаивать свободный ресурс.

3️⃣Nearest (ближайший в своей группе) — из сгруппированных заявок система выбирает кабину, которая быстрее всех сможет забрать пассажиров и отвезти их по маршруту с минимальным «пробегом» без пассажиров.

Супер, мы близки к решению. Надо понять, как задизайнить тест.

Это оказалось непросто. Лифты работают в комплексе, и эффект от работы алгоритмов надо оценивать на целом лифтовом холле, а их у нас в бизнес-центре целых… один. Как вариант, можно сделать time‑based A/B (crossover) — переключаем всё здание между алгоритмами по дням или сменам, например: чётные/нечётные дни, утренние/вечерние смены. Или можно попробовать засетапить синтетический контроль — сконструировать его из комбинации данных других зданий или периодов, однако на практике такое сделать крайне непросто. При наличии похожих бизнес‑центров можно также попробовать сделать Difference‑in‑Difference.

Тут, конечно, придется позаботиться о логировании: фиксируем каждый вызов → поездку, промежуточные остановки, пустые рейсы, технические инциденты. Убеждаемся, что тест небесполезный: рассчитаем нужный объём выборки [кол‑во сотрудников × поездок на человека] и MDE.

На этом мой разгон закончился, так как лифт наконец-то довез меня до нужного этажа)

Как думаете, какой алгоритм был бы эффективнее? 🎯

P.S. Если вам зашла история про разбор аналитических кейсов в жизни — ставьте 🤓 и кидайте идеи задачек в чат. Разберём в следующий постах!

#ДимаКр