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

Полный HTML-код статьи с семантическим анализом ниже. ## Семантический анализ **Primary keyword:** HR-аналитика в ВКР / предиктивная аналитика удержания персонала в дипломе **LSI-запросы:** микросервисная архитектура, REST API, Apache Kafka, PostgreSQL, ML-модель прогнозирования оттока, Feature Store, OpenTelemetry, Prometheus/Grafana, CI/CD-пайплайн, нагрузочное тестирование, 152-ФЗ и RBAC **Вопросы студентов:** Как измерить качество ML-модели в дипломе? Обязательно ли писать рабочий код? Где брать датасет для обучения? Как обосновать выбор стека перед комиссией? Как оформить ТЗ по ГОСТ? **Ключевые сущности:** ГОСТ 34.602-89, ГОСТ 19.701-90, ISO/IEC 25010, Kubernetes, OpenTelemetry, CI/CD-пайплайны --- ```html

HR-аналитика в ВКР: как опрос о лояльности сотрудников превращается в защищаемый ИТ-проект

«Авито Работа» опубликовала результаты опроса более чем 1,3 тыс. молодых специалистов 18–24 лет. Ключевая цифра: 39% работающих респондентов готовы остаться на одном месте дольше пяти лет — при условии, что их устраивают условия труда. Для ИТ-выпускника это не просто новость о рынке труда, а готовое обоснование актуальности.

Смотрите на ситуацию инженерно. Есть поведенческий сигнал (готовность остаться), есть набор факторов (условия, развитие, доход), и есть бизнес-задача — удержать специалиста, пока он не ушёл. Всё это раскладывается в типовой конвейер: сбор данных → нормализация → модель → прогноз → интерфейс решения. Именно такой конвейер и защищается в ВКР по направлениям 09.03.01, 09.03.02, 09.03.03 и 02.03.02. Дальше разберём, как не превратить диплом в пересказ новости, а построить на ней работоспособный проект с метриками.

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

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

• Актуальность: 39% удержания — это потенциал, который нужно измерять, а не предполагать. Классические HRIS фиксируют увольнение постфактум; прогнозная модель даёт окно для управленческого решения.
• Цель: разработать модуль бинарной классификации, который с заданной точностью помечает сотрудника как «риск ухода в течение 6 месяцев».
• Задачи: сформировать набор признаков (стаж, динамика грейда, вовлечённость из опросов); обучить и сравнить модели; оценить важность признаков; встроить модуль в API.
• Структура: Глава 1 — анализ методов машинного обучения и обзор рынка HRTech; Глава 2 — архитектура решения, схема данных, Feature Store; Глава 3 — оценка качества, нагрузочные испытания, расчёт экономического эффекта от снижения текучести.

Тема 2. Платформа сбора и аналитики опросов вовлечённости

• Актуальность: опрос «Авито Работы» собран вручную. Автоматизация подобных исследований — прикладная задача, которую легко защитить.
• Цель: построить сервис анкетирования с ETL-конвейером и дашбордами агрегированных метрик.
• Задачи: спроектировать схему БД; реализовать REST API и очередь событий; построить витрину данных; настроить мониторинг и разграничение прав по 152-ФЗ.
• Структура: Глава 1 — сравнительный анализ готовых решений (SaaS vs собственная разработка); Глава 2 — проектирование микросервисов и контрактов API; Глава 3 — нагрузочное тестирование, проверка RTO/RPO, оценка TCO.

Тема 3. Рекомендательная система подбора условий удержания

• Актуальность: вопрос «что именно удерживает конкретного сотрудника» из опроса превращается в задачу ранжирования факторов.
• Цель: спроектировать рекомендательный сервис, предлагающий набор мер (гибкий график, обучение, пересмотр грейда) с оценкой вероятности эффекта.
• Задачи: формализовать профиль сотрудника; применить коллаборативную фильтрацию или градиентный бустинг; реализовать объяснимость решений (SHAP); провести A/B-оценку на исторических данных.
• Структура: Глава 1 — теория рекомендательных систем; Глава 2 — проектирование сервиса и пайплайна признаков; Глава 3 — эксперименты, метрики NDCG/Precision@k, внедрение.

Аналитическая глава: как обосновать стек, а не перечислить технологии

Самая частая слабость первого раздела — список инструментов без критериев. Комиссия задаёт один вопрос: «Почему не наоборот?» Готовьте ответ таблицей.

Опора на ISO/IEC 25010 сразу переводит разговор из «нравится/не нравится» в инженерные характеристики. Для сервисов опросов добавьте сравнение моделей: логистическая регрессия (интерпретируемость, быстрый baseline), градиентный бустинг (точность на табличных данных), нейросеть (избыточна при 1–2 тыс. наблюдений). Вывод «выбрана логистическая регрессия как baseline, бустинг — как основной вариант» звучит куда убедительнее, чем безапелляционное «используем нейросеть».

Проектная часть: от схемы до кода

Архитектура и поток данных

Минимально жизнеспособная схема для темы 2 выглядит так: сервис анкетирования → брокер сообщений (Kafka) → сервис нормализации → хранилище (PostgreSQL) → сервис аналитики → дашборд. Разделение на потоки «онлайн-ответы» и «пакетная агрегация» снимает нагрузку с транзакционной БД. На защите нарисуйте эту схему в нотации C4 (уровни Context и Container) — она читается комиссией лучше, чем UML-«каша».

Пример: подготовка признаков для модели удержания

-- Витрина признаков сотрудника на дату среза
SELECT
    e.employee_id,
    e.grade,
    DATE_PART('year', AGE(:snapshot_date, e.hire_date))   AS tenure_years,
    COUNT(DISTINCT t.training_id)                          AS trainings_12m,
    AVG(s.engagement_score)                                AS avg_engagement,
    CASE WHEN e.salary_ratio_to_market < 0.85
         THEN 1 ELSE 0 END                                 AS pay_gap_flag
FROM hr.employees e
LEFT JOIN hr.trainings  t ON t.employee_id = e.employee_id
                         AND t.finished_at >= :snapshot_date - INTERVAL '12 months'
LEFT JOIN hr.surveys    s ON s.employee_id = e.employee_id
                         AND s.created_at  >= :snapshot_date - INTERVAL '6 months'
WHERE e.age BETWEEN 18 AND 24
GROUP BY e.employee_id, e.grade, e.hire_date, e.salary_ratio_to_market;

Такой запрос — уже половина второй главы. Он показывает, что вы умеете работать с временными срезами (point-in-time correctness) и не допускаете утечки целевой переменной в признаки.

Тестирование и метрики: где чаще всего «плывут» студенты

Разделяйте три разных вида проверок — их нельзя смешивать в одном подразделе.

• Качество модели. ROC-AUC, F1, Precision/Recall при заданном пороге. Обязательно матрица ошибок: ложное «уйдёт» дешевле ложного «останется». Считайте на отложенной выборке по времени, а не случайным сплитом.
• Нагрузочная устойчивость. k6 или JMeter, сценарий на 500 одновременных заполнений анкеты, p95 времени отклика, точка отказа. Сравните с требованиями в ТЗ.
• Отказоустойчивость. Для сервиса опросов достаточно указать RTO ≤ 1 ч и RPO ≤ 15 мин при ежедневном резервном копировании и включённом WAL-архивировании.

Наблюдаемость оформляйте через OpenTelemetry: трассировки по запросу от API до БД, метрики в Prometheus, дашборд в Grafana. Скриншот дашборда в приложении — сильный аргумент на защите.

FAQ

Нужно ли писать рабочий код или хватит прототипа?

Зависит от кафедры, но тренд однозначный: прототип, который запускается и обрабатывает тестовый набор данных, весит больше, чем 60 страниц теории. Достаточно одного сервиса и одной модели. Полноценный production-кластер Kubernetes в дипломной работе не требуется — опишите его как направление развития.

Где брать датасет, если реальных HR-данных нет?

Три пути: открытые наборы (HR Analytics на Kaggle, IBM HR Attrition), синтетическая генерация генератором вроде SDV с явным описанием распределений, либо анонимизированные данные вендора при стажировке. Обязательно укажите в работе, что данные синтетические, и опишите, чем генератор отличается от реального распределения.

Обязательно ли разворачивать Kubernetes для сервиса на 2 тыс. пользователей?

Нет. Для защиты достаточно docker-compose и обоснования, что оркестратор избыточен при текущем профиле нагрузки. Но если цель работы — именно микросервисная архитектура, покажите манифесты развёртывания и горизонтальное автомасштабирование как эксперимент с замерами.

Как оформить диаграммы, чтобы их не завернули?

Держите единый набор нотаций: C4 для архитектуры, BPMN или IDEF0 для процессов, UML-диаграммы классов и последовательностей для проектирования, ГОСТ 19.701-90 для блок-схем алгоритмов. Каждая диаграмма — с подписью «Рисунок N — ...» и обязательной ссылкой из текста. Диаграммы без пояснения в тексте считаются декоративными.

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

• Проектировать конвейер данных от сбора до витрины, включая корректные временные срезы.
• Обосновывать выбор стека через измеримые критерии качества ПО, а не через личные предпочтения.
• Оценивать модель не одной цифрой, а набором метрик с интерпретацией бизнес-последствий ошибок.
• Готовить техническую документацию по ГОСТ 34 и ГОСТ 19 — навык, который напрямую спрашивают на собеседованиях в госсекторе и системной интеграции.
• Настраивать наблюдаемость и нагрузочные испытания — то, что отличает учебный проект от инженерного.

Источник: 39% работающих молодых россиян готовы работать на одном месте больше пяти лет, если их устраивают условия — «Авито Работа» (опубликовано 2026-03-26)

```