Опубликовано: 01.10.2026 | Источник: CNews (новости)

Индекс курьера SuperJob в ВКР: HR-аналитика и прогноз зарплатных предложений

В конце марта 2026 года SuperJob выпустил очередной «Индекс курьера»: средние рыночные зарплатные предложения в этой профессии выросли на 5% год к году, а с января по март рынок пережил привычный сезонный подъём. Для выпускника ИТ-направления это не абстрактная экономическая новость, а готовый входной сигнал для дипломного проекта. Во-первых, появились свежие числовые данные, которые можно цитировать в аналитической главе без ссылок на «примерные оценки экспертов». Во-первых, во-вторых и в-третьих — тема идеально ложится на классический стек: сбор данных, ETL-пайплайн, прогнозная модель, дашборд, наблюдаемость. Рынок труда курьеров стал измеримым, а значит, его можно превратить в объект исследования и в работающий программный продукт. Ниже — как это сделать без воды и с прицелом на защиту.

Три темы ВКР, которые вырастают из одной новости

Тема 1. Сервис мониторинга и прогнозирования зарплатных предложений на рынке доставки

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

• Цель: разработать сервис сбора, хранения и прогнозирования зарплатных предложений с оценкой точности модели.
• Задачи: обзор источников и их API; проектирование ETL-пайплайна; схема хранилища; модель прогноза; веб-дашборд; оценка качества по MAPE и MAE.
• Структура: Глава 1 — анализ рынка доставки и методов прогнозирования временных рядов; Глава 2 — архитектура (Airflow + PostgreSQL + FastAPI + Grafana); Глава 3 — тестирование, метрики точности, экономика внедрения.

Тема 2. Оптимизация затрат на оплату труда курьеров с учётом рыночной динамики

Актуальность. Рост предложения на 5% год к году и сезонный скачок января–марта напрямую увеличивают фонд оплаты труда в доставке. Служба, которая не умеет пересчитывать маршруты и смены под новую стоимость часа, теряет маржу.

• Цель: построить модель распределения заказов и смен, минимизирующую стоимость доставки при ограничениях по времени.
• Задачи: формализация задачи как VRP с весовым коэффициентом стоимости; реализация решателя; имитационное моделирование; сравнение с жадным алгоритмом.
• Структура: Глава 1 — теория маршрутизации и экономика труда; Глава 2 — проектирование сервиса расчёта; Глава 3 — эксперименты, графики сходимости, расчёт эффекта.

Тема 3. HR-дашборд с наблюдаемостью: метрики качества данных и SLO

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

• Цель: спроектировать наблюдаемую систему HR-аналитики с формализованными SLI/SLO и контролем качества данных.
• Задачи: определить SLI/SLO; инструментировать сервис через OpenTelemetry; настроить алерты; провести нагрузочное тестирование; оценить атрибуты качества по ISO/IEC 25010.
• Структура: Глава 1 — наблюдаемость и метрики качества; Глава 2 — архитектура в Kubernetes; Глава 3 — нагрузочные испытания, RTO/RPO, отказоустойчивость.

Аналитическая глава: из новости — в обоснование выбора

Сравнение источников данных

Первое, что проверяет комиссия, — откуда взялись цифры. Один индекс SuperJob проблему не закрывает: он даёт точку на графике, а модели нужен ряд. Соберите таблицу источников и обоснуйте, почему берёте именно этот набор.

Обоснование стека без «потому что модно»

Каждый выбор в главе 2 привязывайте к свойству задачи. Данные приходят раз в месяц пачкой — значит, оркестрация важнее потоковой обработки. Отсюда Airflow, а не Kafka. Аналитика небольшая по объёму — PostgreSQL закрывает потребность, ClickHouse избыточен. Визуализация — Grafana, если нужен мониторинг, или Metabase, если важнее самообслуживание аналитиков.

Проектная часть: схемы, слои, алгоритм

Архитектура сервиса

Разделите систему на четыре слоя и опишите каждый отдельной схемой: загрузка (парсеры и планировщик), хранение (сырой слой + витрина), аналитика (модель прогноза), представление (API + дашборд). Такая декомпозиция удобна тем, что любой вопрос комиссии о масштабировании вы парируете фразой «слой изолирован, замена не затрагивает остальные».

Алгоритм прогноза

Для помесячного ряда с выраженной сезонностью покажите декомпозицию на тренд и сезонную компоненту — этого достаточно для защиты, и это честнее, чем «обучили нейросеть на 40 точках».

import pandas as pd
from statsmodels.tsa.seasonal import STL

# индекс курьера SuperJob приводим к помесячному ряду
df = pd.read_csv("courier_index.csv", parse_dates=["month"]).set_index("month")
df = df.asfreq("MS")

res = STL(df["salary_offer"], period=12, robust=True).fit()
df["trend"] = res.trend
df["seasonal"] = res.seasonal

# базовый прогноз: тренд + сезонный коэффициент соответствующего месяца
next_month = df.index[-1] + pd.DateOffset(months=1)
forecast = df["trend"].iloc[-1] + df["seasonal"][df["seasonal"].index.month == next_month.month].mean()
print(f"Прогноз на {next_month:%m.%Y}: {forecast:.0f}")

Развёртывание и CI/CD

Сервис прогноза удобно упаковать в контейнер и описать манифестами Kubernetes: отдельный Deployment для API, CronJob для ежемесячной загрузки, ConfigMap для порогов алертов. Пайплайн CI/CD описывайте кратко, но с проверками: линтер, тесты модели на фиксированном срезе данных, сборка образа.

Тестирование и метрики: то, что реально спрашивают на защите

Раздел «Тестирование» обычно самый слабый. Исправляется он таблицей метрик с нормативами — тогда у комиссии нет повода спросить «а как вы поняли, что стало лучше».

Отдельно приложите скриншот Grafana с панелью, где видно нагрузочный прогон: пик, деградацию, восстановление. Один такой график стоит трёх абзацев текста.

Чему вы научитесь на такой работе

• Превращать публичную отраслевую метрику в набор требований и пользовательских сценариев.
• Проектировать ETL-пайплайн с идемпотентной загрузкой и обработкой ошибок источника.
• Обосновывать стек через свойства задачи, а не через популярность технологии.
• Считать метрики качества модели и качества данных, а не только «модель работает».
• Оформлять техническую документацию по ГОСТ 34.602-89 и схемы по ГОСТ 19.701-90.
• Настраивать наблюдаемость через OpenTelemetry и доказывать готовность системы к отказам.

FAQ: короткие ответы на частые вопросы

Источник: Индекс курьера SuperJob: март 2026 (опубликовано 2026-03-26)