«Срок жизни аналитика — год»: как мы снизили отток и перестроили команду аналитики в CloudPayments

Продолжаем рассказывать, как устроены команды CloudPayments изнутри. В прошлый раз говорили о B2B-продажах, а теперь — о департаменте аналитики и истории команды, в которой когда-то шутили, что «срок жизни аналитика — год».

Кемран Мехтиев, руководитель департамента аналитики CloudPayments, пришёл в компанию полтора года назад. В команде были сильные специалисты, но процессы вокруг них практически отсутствовали: нагрузку было сложно прогнозировать, задачи приходили из разных каналов, а приоритеты постоянно менялись.

За это время команда выросла с шести до 11 человек, несколько сотрудников перешли на новые грейды, а из департамента никто не ушёл. Но главный результат не только в цифрах. Раньше к аналитикам чаще приходили с запросом «посчитайте». Сейчас — с вопросом «стоит ли вообще это делать?».

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

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

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

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

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

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

Начали мы с единой точки входа — Jira. Для команды переход оказался понятным, а вот бизнесу потребовалось время.

К третьему месяцу уже 80–90% запросов приходили через Jira. У команды появилась понятная загрузка и возможность оценивать сроки, а заказчики видели, что происходит с их задачей и почему перед ней стоят другие.

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

Параллельно я провёл аудит бэклога* и проектов на несколько кварталов вперёд. Было понятно, что шести человек для всей компании мало, но аргумент «мы зашиваемся» сам по себе слабое основание для расширения штата.

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

Когда мы начали расширять команду, технические требования были базовыми: сильный SQL, хороший Python и математика. Опыт в B2B — большой плюс, но не обязательное условие: специфику этого рынка можно быстро освоить.

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

Тогда в разговоре может выясниться, что на самом деле нужна другая метрика или совсем другой этап воронки. Поэтому на собеседованиях с кандидатами на позиции лида я люблю задавать вопрос: «Расскажите про задачу, которую вы отказались делать в том виде, в котором её поставили».

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

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

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

Первый — предсказуемость. Человек понимает свою загрузку и может планировать работу хотя бы на спринт вперёд.

Второй — влияние на бизнес. Если полгода делать одинаковые выгрузки, которые никто не открывает, или поддерживать дашборд, которым никто не пользуется, проблема не в сложности такой работы, а в её ценности. Сильному специалисту важно понимать, что изменилось благодаря его работе.

Третий — признание результата. Я часто говорю: героев надо знать в лицо. Если человек сделал расчёт, который помог принять важное решение, об этом должны знать не только он, руководитель и заказчик. Иногда простое упоминание его вклада на общей встрече работает лучше сложной системы мотивации.

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

За время моей работы несколько сотрудников выросли по грейдам: часть — из мидлов в сеньоров, двое сеньоров уже стали лидами, ещё один человек близок к следующему шагу.

Кемран ищет в команду еще двух сотрудников. Переходи на карьерный сайт, если хочешь стать частью CloudPayments.

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

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

Пока один из главных маркеров для меня — момент, когда человек перестаёт просто выполнять задачи и начинает решать проблемы. Например, не принимает «посчитай конверсию» как готовое ТЗ, а разбирается, зачем она нужна. Замечает, что два отчёта по-разному считают одну метрику, и сам инициирует исправление. Делает ревью* чужой работы и смотрит шире своего списка задач.

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

Ещё один признак профессионального роста — умение оценивать эффект собственной работы. Что изменилось после твоего анализа или модели? Какой результат получил бизнес? Если специалист умеет отвечать не только на вопрос «что я сделал», но и «что это дало», это уже другой уровень ответственности и компетенций.

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

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

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

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

Например, мы замечаем, что у клиента снизился оборот через CloudPayments. Если опираться только на наши данные, то виден сам факт падения, но не его причина. Более широкий контекст позволяет разобраться, что произошло: у клиента в целом просел бизнес или он перераспределил платежи. Это два разных диагноза — и последующие действия команды тоже будут разными.

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

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

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

Сейчас в команду Кемрана ищем двух сотрудников: аналитик данных (middle) и младший аналитик данных. Переходи по ссылке и стань частью CloudPayments.