Почему два аналитика с одинаковыми навыками стоят по-разному

Разница не в хардах - они у обоих равные, - а в том, как каждый доводит работу до результата.

Этому почти нигде не учат: на курсах показывают, как написать запрос и собрать модель, а как провести проект от вопроса бизнеса до внедренного решения - остается за кадром. Считается, что человек впитает это сам, но обычно не впитывает.

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

1. Договориться, что вообще нужно, - до старта

Самая частая причина бесполезной работы - аналитик понял задачу не так.

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

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

Проблема не в навыках, а в том, что аналитик не уточнил, какой вопрос на самом деле решают.

Чтобы так не выходило, перед работой стоит проговорить три вещи:

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

Хороший прием - описать задачу словами, без готового решения: «маркетинг не понимает, какие каналы окупаются» - это проблема, а «сделай дашборд по каналам» - уже чужое решение, и часто неверное.

Решается это одним вопросом к продакту в начале: «какое решение ты примешь по результату?» - и тогда аналитика зовут в проект раньше, а не в конце.

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

2. Разбить работу на куски

Большая задача «построить аналитику по продукту» пугает и тянется месяцами - ее тяжело оценить по срокам и легко завалить.

Поэтому до того как открыть редактор, потрать 5-10 минут на грубый план: раздели задачу на этапы и по каждому реши:

• что будет результатом этого куска;
• от чего он зависит: чужие данные, доступы, чье-то решение;
• сколько он примерно займет.

Это дает две вещи: реалистичные сроки вместо «ну, недели две» и раннюю видимость, где застрянешь, - так можно заранее предупредить тех, от кого зависишь.

Потом сравни план с тем, что вышло, и через несколько проектов начнешь оценивать сроки заметно точнее - а это то, за что senior и ценят.

3. Снимать блокеры - свои и чужие

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

И если спрашиваешь - спрашивай так, чтобы помочь было легко:

• что именно не получается;
• что уже попробовал;
• какой конкретно ответ нужен.

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

4. Держать слово

Звучит скучно, но доверие строится именно тут: сказал «к четвергу» - сделал к четвергу; понял, что не успеваешь - предупредил заранее, а не когда дедлайн уже прошел.

Хуже всего - тишина: когда коллега узнает о срыве срока, потому что сам пришел спросить, доверие падает сильнее, чем от самого срыва.

Что помогает:

• в конце встречи за минуту проговорить, кто что делает дальше;
• самому писать о статусе, а не ждать вопроса;
• о сдвиге срока сообщать сразу, как стало понятно.

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

5. Оставлять следы

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

Лечится легкой документацией - не тома на сто страниц, которые никто не читает, а короткая запись по проекту:

• какую проблему решаем;
• кто за что отвечает;
• какие ключевые решения приняли и почему.

Этого хватает, чтобы команда была в курсе, а ты не превратился в узкое горлышко.

С чего начать

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

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

Харды дают пропуск в профессию, но репутацию «ему можно доверить сложное» строят не они, а умение довести дело до результата - и как раз это AI у тебя не заберет.