Когда я только начинал работать аналитиком, мне казалось, что главное в профессии - научиться хорошо писать SQL, разобраться с Python, понять структуру баз данных и научиться быстро считать нужные показатели. Всё это действительно важно. Но довольно быстро я понял, что техническая часть закрывает только половину работы.

Потому что бизнес почти никогда не приходит к аналитику с формулировкой: «Посчитай мне “COUNT(DISTINCT client_id)” вот из этой таблицы с такими условиями». Бизнес приходит и говорит: «У нас стало меньше клиентов», «продажи просели», «что-то не так с конверсией», «хотим понять, почему люди не открывают продукт».

А в базе данных никаких «людей, которые не открывают продукт» нет. Там лежат “client_id”, даты, статусы, события, продукты, каналы, операции и ещё десятки технических сущностей.

И вот между этими двумя мирами стоит аналитик.

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

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

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

Но дальше происходит обратный перевод.

Представьте, что после нескольких часов анализа вы приходите к руководителю и говорите: «В сегменте наблюдается снижение conversion rate на 1,8 п.п., преимущественно за счёт когорты пользователей определённого канала».

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

Одни и те же данные. Совершенно разная ценность.

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

Поэтому SQL, Python и BI делают вас специалистом, который умеет работать с данными. А понимание бизнеса и коммуникация делают вас аналитиком, которому начинают доверять решения.

В конечном счёте бизнесу редко нужна цифра сама по себе. Ему нужен ответ на гораздо более простой вопрос: «Что происходит и что нам теперь с этим делать?»

И задача аналитика - перевести данные так, чтобы этот ответ появился.

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