В аналитике самое непростое — вовсе не расчёты и не эффектные графики, а именно подготовка данных. Но эту часть почти никто замечает.

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

А задачи, как правило, приходят из разряда: «Надо было сделать ещё вчера». Вы‑то понимаете, что сам расчёт как раз и займёт этот день, а вот всё, что до него, — ещё три. Объяснять бывает тяжело: кажется, будто оправдываешься, будто работаешь медленно.

На деле же в типичном проекте львиная доля времени уходит как раз на эту невидимую работу. Примерно 60-80% уходит на подготовку: собрать данные, почистить, привести к единому виду, согласовать, как именно что считать. На сам анализ остаётся 15-30%, а на оформление и слайды - всего 5-15 %. И именно на этом этапе рождается надёжность выводов. Если пропустить подготовку или сделать её кое‑как, цифры будут выглядеть красиво, но опираться на них нельзя.

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

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

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

В общем, эта «невидимая» часть - вовсе не про медлительность. Это про то, чтобы результат был рабочим, а не просто красивым.

Расскажите, что у вас чаще всего съедает время в проектах?