Разберём решение задачи с поиском ошибок данных таблицы shipments в БД межзвёздной логистической компании «SQL Bootcamp»

Напомним потенциальные аномалии данных, которые нужно было обнаружить, в рамках бизнес-логики компании:
➖ Груз без указанной станции отправления или прибытия
➖ Рейс, где груз вылетает и прибывает на ту же станцию
➖ Отрицательные значения веса или расхода топлива

Верный ответ: B
```
SELECT * FROM shipments
WHERE (dep_station IS NULL OR arr_station IS NULL)
OR (dep_station = arr_station)
OR (weight < 0 OR fuel < 0);
```
➖ Проверяет пустые станции отправления/прибытия
➖ Проверяет одинаковые станции отправления и прибытия
➖ Проверяет отрицательный вес и расход топлива

Разберём остальные ответы:

A)
```
SELECT * FROM shipments
WHERE dep_station IS NULL
OR arr_station IS NULL
OR weight < 0
OR fuel < 0;
```
Не проверяет рейсы, где станция отправления = станция прибытия.

C)
```
SELECT * FROM shipments
WHERE (weight < 0 OR fuel < 0)
OR (COALESCE(dep_station,'') = '' OR COALESCE(arr_station,'') = '');
```
Проверяет только пустые станции и отрицательные значения, не проверяет рейсы с одинаковыми станциями.

D)
```
SELECT * FROM shipments
WHERE dep_station = arr_station
OR dep_station IS NULL
OR arr_station IS NULL;
```
Проверяет пустые станции и одинаковые станции, но не отрицательный вес и расход топлива.

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

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

Подробнее про проверки мы поговорим в рамках SQL-буткемпа — регистрируйтесь, до конца сентября держим ранние цены!

🔔 Зарегистрироваться на тренинг по SQL

📊 Simulative

Катастрофа в проде: модель идеально работает в ноутбуке, но ломается после выкатки в продакшн

Привет! На связи Кристина Желтова, ментор курса «ML-инженер».

На практике нередкая ситуация, когда ML-специалист или даже целая команда празднуют победу — их модель показывает на локальных экспериментах отличное качество, а значит, задача решена!

Модель проходит код-ревью, готовится к раскатке в прод и пилотированию или A/B-тестированию, и вот час настал — её выпускают в настоящую жизнь, в production. Но через какое-то время разгневанные заказчики приходят и сетуют на сошедшую с ума модель, которая одобрила кредиты всем подряд или рекомендовала потратить весь бюджет маркетинга на удержание клиентов, которые и так не собирались уходить.

❓ Какие могут быть причины такого поведения модели, и как узнать о существовании проблемы не от заказчиков, а во время экспериментов?

1️⃣ Temporal Leakage: неправильная разбивка данных, упорядоченных по времени

Проблема: команда использовала обычный train_test_split с shuffle=True на упорядоченных данных с временными метками.

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

Правильный подход: использовать специальную валидацию для временных данных — TrainTestSplit.

2️⃣ Feature Leakage: признаки из «будущего»

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

Правильный подход: проверять, что все признаки, агрегации и статистики считаются только на данных до целевой даты предсказания.

3️⃣ Target Leakage: утечка информации из целевой переменной

Проблема: для моделирования использовали признаки, напрямую связанные с целевой переменной или вычисляемые из неё.

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

Кстати, сегодня последний день, когда можно записаться на курс-симулятор «ML-инженер» по низкой цене. Регистрируйтесь и создавайте эффективные модели машинного обучения под руководством опытного ментора-меня 😉

➡️ Записаться на курс со скидкой 15%

📊 Simulative

С какими данными работает аналитик

Приветствую любителей аналитики! С вами Павел Беляев, ментор курса «Аналитик данных». Сегодня поговорим о том, с какими данными и из каких источников приходится работать дата-аналитику.

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

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

1️⃣ CRM-системы

Что это: инструменты сбора, обработки и отображения информации о клиентах и взаимодействии с ними.

Метод сбора данных: чаще всего веб-интерфейс и свой API, через который можно отправить запрос в систему и получить ответ. Большие CRM могут дорабатываться под особенности бизнеса, также может допиливаться и API.

Данные
➖ Контакты и прочие данные клиентов;
➖ Данные о сделках, взаимодействиях и прочих процессах работы с клиентами;
➖ Новые лиды;
➖ Данные о сотрудниках, работающих с клиентами;
➖ Источники лидов;
➖ Другие сведения, которые стекаются в CRM.

Примеры: Битрикс24, amoCRM, Мегаплан.

2️⃣ Cистемы веб-аналитики

Что это: комплекс инструментов для сбора, измерения, анализа и интерпретации данных о посетителях веб-ресурсов.

Метод сбора данных: использование API, но не все системы отдают всё полностью.
Например, Google Analytics 4 не отдаёт полные сырые данные о хитах по API. Эта опция доступна только при прямой интеграции с Google BigQuery, остальным придётся довольствоваться лишь агрегированными данными.

Другой вариант — своими силами собирать нужные события, но это, скорее всего, потребует ресурсов разработчика.

Данные
➖ Хиты (события, просмотры страниц);
➖ Визиты/сессии (источники трафика, длительность, данные о приложении-клиенте пользователя и т. д.).

Примеры: Google Analytics, Яндекс Метрика, Amplitude.

3️⃣ Базы данных бизнес-приложений

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

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

Метод сбора
Данные из «своих» СУБД собираются через стандартные методы подключения, например, из Python-скриптов (например, библиотека psycopg2 для работы с PostgreSQL) или же с помощью специализированных инструментов (например, оператор PostgresOperator для Airflow).

Примеры: PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database.

4️⃣ Электронные таблицы

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

Данные: любые табличные данные.

Метод сбора: популярные облачные решения имеют свои API и Python-библиотеки. Для csv и xlsx-файлов в Python также есть функции загрузки в скрипт (например, в Pandas-датафрейм) и заливки в аналитическое хранилище.

Примеры: Google Sheets, Яндекс Таблицы, файлы Excel, файлы csv.

Все виды данных, а в особенности, как с ними работать, разбираем на курсе «Аналитик данных». Сегодня последний день по ранней цене!

⚡️ Успеть и записаться со скидкой 15%

📊 Simulative

⚡️ Вебинар: первичный анализ и очистка данных с помощью Python

Данные в аналитике зачастую требуют предобработки и очистки: пропуски, некорректные значения или типы данных. Если не проверить и не почистить такие данные, выводы в отчётах будут неточными, а решения — ошибочными.

На вебинаре Павел Беляев, тимлид аналитики в eLama, автор канала «Тимлидское об аналитике» и ментор курса «Аналитик данных», покажет, как быстро проверить и визуализировать данные в Python.

В ходе вебинара мы на примере данных сервиса по продаже подержанных авто разберём:
➖ Зачем и как проверять качество данных перед анализом;
➖ Как находить выбросы и «поломанные» значения в датасете;
➖ Какие приёмы Python помогают делать агрегацию по категориальным признакам;
➖ Как визуализировать данные и находить закономерности;
➖ Как даже новичок может собрать базовый пайплайн очистки и анализа.

❗️ Встречаемся 23 сентября в 19:00 МСК.

♾ Обязательно приходите на эфир — разберем must-have библиотеки для дата-аналитика: pandas для работы с табличными данными, matplotlib и seaborn для визуального анализа!

➡️ Регистрация на вебинар

📊 Simulative

Узнайте, почему ваши SQL-запросы тормозят 🤖

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

На вебинаре Владимир Лунев, бизнес- и системный аналитик с 5-летним опытом работы в ритейле и IT, разберёт 7 реальных кейсов оптимизации SQL-запросов, которые помогали бизнесу принимать быстрые и точные решения.

В ходе вебинара разберём:
🟠 Как понять, что запрос тормозит, и чем это грозит бизнесу;
🟠 Как читать план выполнения (EXPLAIN, EXPLAIN ANALYZE) и находить ошибки;
🟠 Типовые причины медленных запросов и как их исправлять;
🟠 7 реальных кейсов из практики: «было → стало» с разбором кода.

❗️ Встречаемся 24 сентября в 19:00 МСК.

🧡 Обязательно ждём вас в лайве — вы сможете напрямую задать свои вопросы Владимиру Луневу и получить ценный опыт оптимизации SQL-запросов!

➡️ Зарегистрироваться на вебинар

📊 Simulative

Привет, аналитики! Мы регулярно собираем обратную связь со студентов и выпускников наших курсов — пришло время подписчиков!

Пожалуйста, ответьте на четыре вопроса ниже, а мы в ответ сделаем наш контент лучше и интереснее 👇

Must-have инструменты для аналитика в Python

Привет, любители аналитики! С вами Павел Беляев, ментор курса «Дата-аналитик» и ведущий канала «Тимлидское об аналитике».

SQL это база, но сегодня хочу рассказать кое-что о Python — поразительно мощном инструменте аналитика. А именно — о базовых библиотеках Python, которые должен знать каждый специалист по данным.

1️⃣ Pandas — король обработки данных

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

➖ Чтение и запись данных в разных форматах;
➖ Фильтрация, сортировка, группировка;
➖ Объединение датасетов;
➖ Базовые статистические операции.

import pandas as pd

# Пример использования
df = pd.read_csv('data.csv') # записывает в датафрейм данные из файла csv
df.head() # выводит первые строки датафрейма

2️⃣ NumPy — математика для больших данных

➖ Работа с массивами и матрицами;
➖ Математические операции;
➖ Генерация случайных чисел.

import numpy as np

# Пример
array = np.array([1, 2, 3, 4, 5]) # создаёт одномерный массив
mean = np.mean(array) # вычисляет среднее значение массива

3️⃣ Matplotlib и Seaborn — визуализация данных, обычно датафреймов

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

import matplotlib.pyplot as plt
import seaborn as sns

# Простой график по точкам
plt.plot([1, 2, 3], [4, 5, 6])
plt.show()

4️⃣ Scipy — это уже следующий уровень, основы статистического анализа

from scipy import stats

# Проведение t-теста для независимых выборок
# Сравнивает средние значения двух групп данных
# Помогает определить, есть ли статистически значимые различия между выборками
result = stats.ttest_ind(data1, data2)  # data1 и data2 — массивы сравниваемых данных

5️⃣ Statsmodels — ещё более продвинутая статистика

➖ Регрессионный анализ;
➖ Временные ряды;
➖ Эконометрика.

import statsmodels.api as sm

# Простая линейная регрессия
model = sm.OLS(y, x).fit()

Для разработки на Python можно использовать:
🟠 Jupyter Notebook и продвинутая среда JupiterLab, которые поставляются, в частности, с пакетом Anaconda;
🟠 Google Colab — простая, но мощная «модернизация» Jupiter для пользователей Google;
🟠 Visual Studio Code — универсальная среда для профессиональных разработчиков.

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

➡️ Зарегистрироваться на вебинар

📊 Simulative

Экспресс-оптимизация SQL-запроса на реальном кейсе

Привет! На связи Владимир Лунев, ментор тренинга «Продвинутый SQL». Давайте разберём кейс, где простые приёмы оптимизации могут ускорить выполнение запроса в несколько раз.

Представим, что у нас есть база заказов крупного интернет-магазина с реальными объёмами данных. Индексов нет. Всё выполняется на сырых таблицах. СУБД PostgreSQL.

Задача: посчитать для каждой категории количество заказов, суммарную выручку и средний чек за август 2025 только для завершённых заказов (со статусом completed).

Состав БД:
Таблица orders (5 млн строк) с полями:
➖ id — уникальный идентификатор заказа;
➖ product_id — ID продукта;
➖ order_date — дата заказа;
➖ amount — сумма заказа;
➖ status — статус заказа, например, completed.

Таблица products (2 тыс. строк):
➖ id — ID продукта;
➖ category_id — ID категории;
➖ price — цена.

Таблица categories (100 строк):
➖ id — ID категории;
➖ name — название категории.

Исходный запрос (медленный), ожидаемое время выполнения 4-5 минут:

SELECT 
    c.id,  # идентификатор категории
    c.name AS category,  # название категории
    COUNT(o.id) AS orders_count,  # количество заказов
    SUM(o.amount) / COUNT(o.id) AS avg_check  # средний чек (ручное деление)
FROM orders o
JOIN products p ON o.product_id = p.id  # соединяем с таблицей продуктов
JOIN categories c ON p.category_id = c.id  # соединяем с категориями
WHERE 
    o.status = 'completed'  # фильтруем только завершённые заказы
    AND o.order_date >= '2025-08-01'  # начало периода (строковый литерал)
    AND o.order_date < '2025-09-01'  # конец периода
GROUP BY c.id, c.name   # группировка по категории (строка и id)
ORDER BY SUM(o.amount) DESC;  # сортировка по суммарной выручке

Почему медленно:
➖ JOIN происходит на 5 млн строк без фильтрации.
➖ GROUP BY по c. name — сравнение строк (TEXT) вместо чисел, это дополнительная нагрузка.
➖ AVG считается вручную (SUM / COUNT) — выполняется две агрегации.
➖ Фильтр по дате задан как строка — типы приводятся динамически, что замедляет план выполнения.

Оптимизированный запрос (быстрее в ~10 раз!), ожидаемое время выполнения 25-30 секунд:

WITH filtered_orders AS (
    # Сначала фильтруем все нужные заказы в отдельном CTE
    SELECT *
    FROM orders
    WHERE status = 'completed'  # только завершённые
      AND order_date >= DATE '2025-08-01'  # явное указание типа DATE
      AND order_date < DATE '2025-09-01'
)
SELECT 
    c.id,  # id категории
    c.name AS category,  # название категории
    COUNT(fo.id) AS orders_count,  # количество заказов
    SUM(fo.amount) AS total_sales,  # суммарная выручка
    AVG(fo.amount) AS avg_check  # средний чек (встроенная функция)
FROM filtered_orders fo
JOIN products p ON fo.product_id = p.id  # соединяем уже отфильтрованные заказы
JOIN categories c ON p.category_id = c.id  # соединяем с категориями
GROUP BY c.id  # PK, группировка по ID (name подтянется автоматически)
ORDER BY total_sales DESC;  # сортировка по суммарной выручке

Что изменилось и почему быстрее:
➖ CTE filtered_orders — с EXPLAIN ANALYZE видно, что количество строк на JOIN сократилось примерно до ~500 тыс. строк вместо 5 млн, т. е. 90%!
➖ GROUP BY c.id — сравнение по числу вместо текста, PostgreSQL подтягивает c.name автоматически.
➖ AVG() вместо SUM/COUNT — встроенная оптимизация движка.
➖ Явное указание типа даты (DATE '2025-08-01') — СУБД не тратит время на приведение типов.

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

❗️ Оптимизация SQL — это понимание того, как СУБД выполняет операции и как конкретный юзер может эффективно сэкономить свое время и бонусом ресурсы сервера. Ещё больше кейсов и рекомендаций будет на вебинаре 24 сентября — приходите, расскажу про свои способы оптимизации SQL-запросов.

➡️ Зарегистрироваться на вебинар

📊 Simulative

Сегментация клиентов с помощью машинного обучения

Привет! С вами Кристина Желтова, ментор курса «ML-инженер».

В персонализации клиентского сервиса и маркетинге важно правильно сегментировать клиентов — разделять клиентскую базу на группы (сегменты) на основе их характеристик.

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

В качестве датасета возьмем небольшой набор данных Mall Customer Segmentation с Kaggle:

path = kagglehub.dataset_download("vjchoudhary7/customer-segmentation-tutorial-in-python")
df = pd.read_csv('/kaggle/input/customer-segmentation-tutorial-in-python/Mall_Customers.csv')

Один из самых простых и известных методов кластеризации — KMeans. Он разделяет данные на K кластеров, находя центроиды (центры) каждого кластера и группируя точки данных вокруг ближайших центроидов.

❗️ Важно: KMeans не предназначен для работы с категориальными признаками. Их нужно либо анализировать отдельно, либо применять другие алгоритмы кластеризации, поддерживающие смешанные датасеты.

clustering_features = ['Age', 'Annual Income (k$)', 'Spending Score (1-100)']
X = df[clustering_features].copy()

Перед применением алгоритма KMeans важно провести масштабирование признаков, иначе признаки с большими единицами измерения будут «перетягивать на себя» расстояния и смещать всё решение.

scaler = StandardScaler()

X_scaled = scaler.fit_transform(X)
X_scaled_df = pd.DataFrame(X_scaled, columns=clustering_features, index=X.index)

При использовании KMeans всегда есть некоторая неопределенность — этому алгоритму нужно заранее задать, на сколько кластеров/групп мы будем разделять данные. Иногда это предположение можно сделать экспертно, но можно попробовать и подобрать оптимальное количество групп, используя «метод локтя» — перебираем количество кластеров, визуализируя на графике сумму квадратов расстояний от каждой точки до центра её кластера. Точка перегиба, где график «сгибается» как локоть руки, и будет оптимальным количеством кластеров.

inertias = []

k_values = range(2, 11)

for k in k_values:
    # Обучаем K-means с конкретным k
    kmeans = KMeans(n_clusters=k, random_state=42, n_init=10)
    cluster_labels = kmeans.fit_predict(X)
    
    inertia = kmeans.inertia_
    inertias.append(inertia)

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

➡️ Более подробный пример можно посмотреть в colab notebook.

📊 Simulative

⚡️ Вебинар по анализу данных в Python уже идёт!

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

➡️ Регистрируйтесь и подключайтесь по ссылке: https://vk.cc/cPLa3m

📊 Simulative

Знакомая ситуация?

Запускаете запрос, ждёте… а Excel уже подвис, BI-система крутит loading, и коллеги начинают писать, что там с отчётом.

99% таких ситуаций — не вина сервера, а ошибки в самом SQL-запросе. И да, это можно исправить.

Уже сегодня на вебинаре спикер тренинга «Продвинутый SQL» Владимир Лунев расскажет:

🟠 Как понять, что запрос тормозит, и чем это грозит бизнесу;
🟠 Как читать план выполнения (EXPLAIN, EXPLAIN ANALYZE) и находить ошибки;
🟠 Типовые причины медленных запросов и как их исправлять;
🟠 7 реальных кейсов из практики: «было → стало» с разбором кода.

😶😶Регистрация

📊 Simulative

⚡️ Уже начали вебинар по SQL, подключайтесь!

📊 Simulative

Clickhouse: что это за СУБД и для чего нужна

NoSQL СУБД типа Clickhouse заточены под определённый тип задач. Clickhouse нужна прежде всего для решения OLAP-задач — например, рассчитать какую-либо метрику типа CTR поверх всех действий всех пользователей в приложении.

Разобрали в статье, чем отличается Clickhouse от Postgres, её архитектурные особенности и возможности, а также как начать работать с СУБД.

🟡 Читать статью в блоге

📊 Simulative

Друзья, спасибо всем, кто посетил наши вебинары!

Записи занятий уже лежат в боте ✅

Продолжаем держать низкие цены на продвинутый тренинг по SQL — напомним, что это такое:

😶 Углубляемся в SQL и повышаем грейд: разбираем оптимизацию SQL-запросов, анализ качества данных и трендов на основе исторических данных в SQL;

😶 6 домашних заданий и 1 кросс-проверка, где студенты проверяют код друг друга;

😶 Практический проект для отработки полученных навыков и разбор тестового задания на senior-позицию.

Автор курса — Владимир Лунев, Fullstack-аналитик в Магните с более чем 5-летним опытом в системном и бизнес-анализе, ведёт авторский Telegram-канал SQL: Реляционные базы данных.

Регистрируйтесь и прокачивайте свой скилл в SQL!

➡️ Записаться по ранней цене

📊 Simulative

Soft skills в ML. Почему навык коммуникации критичнее знания SOTA?

Привет! Вновь на связи Кристина Желтова, ментор курса «ML-инженер».

Среди начинающих специалистов бытует мнение, что ключ к карьерному успеху — крепкие харды и знание нюансов свежих архитектур и технологий. Без hard skills действительно невозможно успешно решать рабочие задачи, однако практика показывает, что именно «софты» часто становятся решающим фактором карьерного роста ML-инженера.

Список инструментов в ML-стеке постоянно расширяется, новые архитектуры появляются каждый месяц, но кое-что остаётся неизменным — необходимость работать с людьми, объяснять решения и адаптироваться к изменениям.

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

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

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

Основные советы, которые помогут сразу быть на одной волне с заказчиком можно уместить в несколько тезисов:

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

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

🧡 Кстати, с хардами я могу помочь! Уже сегодня стартует новый поток курса «ML-инженер», где вы научитесь создавать модели машинного обучения, строить рекомендательные системы и обучать нейросети. Время пришло, решайтесь!

🔔 Записаться на поток

📊 Simulative

Харды и софты аналитика данных

Привет, коллеги! На связи Павел Беляев, ментор курса «Дата-аналитик» и автор канала Тимлидское об аналитике.

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

Hard skills:
👑 SQL — must have;
👑 Clickhouse, PostgreSQL и другие СУБД — must have;
👑 Python + pandas — must have;
😶 Электронные таблицы — крайне желательно;
*️⃣ Airflow или другие средства автоматизации — желательно;
*️⃣ Яндекс.Метрика или другие системы веб-аналитики, любой Tag Manager — желательно;
*️⃣ Git — желательно;
*️⃣ BI-системы — будет плюсом.

Soft skills
А вот тут хотел бы остановиться подробней. Каждый пунктик глубоко осмыслен и необходим!

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

🟡 Коммуникабельность, умение излагать мысли. Дата-аналитик — не кондовый технарь, и взаимодействие с людьми, причём с разными и со многими, составляет немалую часть его работы. Поэтому уметь понять, что хочет заказчик, а иногда и помочь ему это понять, а также объяснить задачу разработчикам или дата-инженерам — must have.

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

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

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

🟡 Доброжелательность. Удивительно, но с этим качеством все взаимодействия становятся проще! Да и приятнее работать в дружном коллективе, чем в токсичном или отстраненном, не так ли?

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

Софтам тоже можно научиться, главное держать их в фокусе внимания и время от времени проводить самоанализ.

Ну а по хардам — добро пожаловать на курс «Аналитик данных», там есть всё что нужно и даже больше. Кстати, он стартует уже сегодня! Так что, если вы ждали знака записаться, то это он. Действуйте!

➡️ Успеть записаться

📊 Simulative