Детекция выгорания разработчиков по цифровому следу

Разработчик начинает работать позже обычного, коммиты мельчают, задачи в Jira не закрываются. За две-три недели до полного истощения такие паттерны становятся устойчивыми: сдвиг начала рабочего дня на час и более, рост доли исправительных коммитов до 40%, падение инициативных сообщений. По данным исследований, выгорание ежегодно обходится tech-компаниям в миллионы долларов из-за текучки и падения продуктивности. Средняя стоимость замены одного разработчика достигает 150-300% его годовой зарплаты. Мы построили систему, которая замечает эти паттерны за 4-8 недель до критической стадии, — не по опросам, а по объективному цифровому следу. Наша ML-модель выгорания обучается на обезличенных метриках и позволяет предотвратить выгорание до того, как оно скажется на команде.

Какие проблемы решает детекция burnout по цифровому следу

Традиционные опросы Maslach Burnout Inventory (MBI) дают срез раз в квартал — слишком редко для динамики выгорания. Наша система анализирует ежедневные паттерны: время коммитов, размер изменений, реакцию на задачи. Например, сдвиг начала рабочего дня на 1+ час в сочетании с ростом доли исправительных коммитов — типичный предвестник эмоционального истощения. Простое падение продуктивности — не выгорание. Разработчик может быть занят сложной задачей или рефакторингом. Модель сравнивает текущие метрики с персональным baseline за 3 месяца и оценивает тренд за 4-8 недель. Если ухудшение прогрессирует — это сигнал. HR не видит конкретные коммиты или сообщения — только агрегированный риск. Система спроектирована по принципу privacy by design: данные обезличиваются, сотрудники уведомлены и дают согласие. Это обеспечивает мониторинг команд без нарушения приватности.

Как работают алгоритмы?

Основу составляют три группы признаков, рассчитанных по Maslach Burnout Inventory:

maslach_dimensions = {
    'emotional_exhaustion': {
        'description': 'Истощение эмоциональных ресурсов',
        'digital_proxy': [
            'поздний старт рабочего дня (сдвиг на 1+ ч)',
            'снижение инициативных сообщений (не ответные, а созданные самим)',
            'рост времени на задачу при той же сложности'
        ]
    },
    'depersonalization': {
        'description': 'Цинизм, дистанция от работы',
        'digital_proxy': [
            'снижение качества документации (длина, форматирование)',
            'меньше добровольных code review',
            'рост времени ответа на сообщения коллег'
        ]
    },
    'reduced_accomplishment': {
        'description': 'Ощущение неэффективности',
        'digital_proxy': [
            'рост незакрытых задач при постоянном создании',
            'частые возвраты задач на доработку',
            'снижение commit-размера и рост исправительных коммитов'
        ]
    }
}

Feature Engineering из Git и Task Tracker

import pandas as pd
import numpy as np
from datetime import timedelta

def extract_developer_burnout_features(developer_id: str, git_log: pd.DataFrame, jira_events: pd.DataFrame, lookback_weeks: int = 8) -> dict:
    """ Рассчитываем признаки за последние 8 недель.
    Сравниваем с baseline этого же разработчика из предыдущих 3 месяцев.
    """
    dev_commits = git_log[git_log['author_id'] == developer_id]
    dev_tasks = jira_events[jira_events['assignee_id'] == developer_id]

    # Паттерны коммитов
    recent_commits = dev_commits[
        dev_commits['timestamp'] >= pd.Timestamp.now() - timedelta(weeks=lookback_weeks)
    ]

    # Время коммитов — признак переработок
    commit_hours = recent_commits['timestamp'].dt.hour
    late_commits_ratio = (commit_hours >= 20).mean()
    weekend_commits = recent_commits['timestamp'].dt.dayofweek.isin([5, 6]).mean()

    # Размер коммитов — снижение говорит о микро-сдвигах или потере фокуса
    avg_lines_changed = recent_commits['lines_changed'].mean() if len(recent_commits) > 0 else 0

    # Fix-коммиты — растёт ли доля исправлений?
    fix_commit_ratio = recent_commits['message'].str.lower().str.contains(
        'fix|hotfix|revert|bugfix', na=False
    ).mean()

    # Задачи
    recent_tasks = dev_tasks[
        dev_tasks['event_timestamp'] >= pd.Timestamp.now() - timedelta(weeks=lookback_weeks)
    ]
    tasks_created = len(recent_tasks[recent_tasks['event'] == 'created'])
    tasks_closed = len(recent_tasks[recent_tasks['event'] == 'closed'])
    reopened_ratio = len(recent_tasks[recent_tasks['event'] == 'reopened']) / (tasks_created + 1)

    # Задержки задач
    overdue_tasks = recent_tasks[
        (recent_tasks['event'] == 'due_date_exceeded') |
        (recent_tasks['actual_days'] > recent_tasks['estimated_days'] * 1.5)
    ]
    overdue_ratio = len(overdue_tasks) / (tasks_created + 1)

    return {
        'late_commits_ratio': round(late_commits_ratio, 3),
        'weekend_work_ratio': round(weekend_commits, 3),
        'avg_commit_size_lines': round(avg_lines_changed, 1),
        'fix_commit_ratio': round(fix_commit_ratio, 3),
        'task_completion_rate': round(tasks_closed / (tasks_created + 1), 3),
        'task_reopen_ratio': round(reopened_ratio, 3),
        'task_overdue_ratio': round(overdue_ratio, 3)
    }

Почему временной тренд важнее единичных метрик?

def detect_burnout_trajectory(weekly_metrics: pd.DataFrame, developer_id: str) -> dict:
    """ Одна плохая неделя — не выгорание. Прогрессивное ухудшение за 4+ недель = сигнал. """
    dev_data = weekly_metrics[weekly_metrics['developer_id'] == developer_id].sort_values('week')
    if len(dev_data) < 6:
        return {'status': 'insufficient_history'}
    recent = dev_data.tail(8)  # последние 8 недель
    # Тренды ключевых метрик
    x = np.arange(len(recent))
    burnout_indicators = {}
    metrics_to_trend = {
        'task_completion_rate': 'decreasing',
        'task_overdue_ratio': 'increasing',
        'fix_commit_ratio': 'increasing',
        'late_commits_ratio': 'increasing',
        'weekend_work_ratio': 'increasing'
    }
    negative_trends = 0
    for metric, direction in metrics_to_trend.items():
        if metric not in recent.columns:
            continue
        slope = np.polyfit(x, recent[metric].values, 1)[0]
        is_bad = (direction == 'increasing' and slope > 0.01) or \
                 (direction == 'decreasing' and slope < -0.01)
        burnout_indicators[f'{metric}_trend'] = slope
        if is_bad:
            negative_trends += 1
    # Ускорение — последние 4 недели хуже, чем первые 4
    first_half = dev_data.tail(8).head(4)
    second_half = dev_data.tail(4)
    acceleration_score = 0
    for metric in ['task_overdue_ratio', 'fix_commit_ratio']:
        if metric in first_half.columns:
            delta = second_half[metric].mean() - first_half[metric].mean()
            if delta > 0.05:
                acceleration_score += 1
    burnout_risk = (negative_trends / len(metrics_to_trend) * 0.6 + min(1, acceleration_score / 2) * 0.4)
    return {
        'developer_id': developer_id,
        'burnout_risk_score': round(burnout_risk, 3),
        'risk_level': 'high' if burnout_risk > 0.65 else ('medium' if burnout_risk > 0.35 else 'low'),
        'negative_trend_count': negative_trends,
        'acceleration_detected': acceleration_score >= 2,
        'indicators': burnout_indicators
    }

Тренд важнее единичных метрик: наша система выявляет выгорание в 2-3 раза точнее традиционных опросов. Ускорение негативных изменений — ключевой предиктор: если за последние 4 недели метрики ухудшаются быстрее, чем за предыдущие 4, риск выгорания резко возрастает.

Сравнение методов детекции выгорания

Что входит в систему

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

Как начать внедрение

1. Аудит текущих источников данных — Jira, Git, корпоративный мессенджер. Определяем необходимые права доступа и объём исторических данных.
2. Подготовка обезличенного датасета — выделение признаков, расчёт baseline для каждого сотрудника.
3. Развёртывание baseline-модели — калибровка порогов, интеграция с HR-дашбордом.
4. Обучение ML-модели трендов — если достаточно исторических данных с метками выгорания.
5. Тестирование и ввод в эксплуатацию — A/B тест на пилотной группе, обучение HR и менеджеров.

Внедрение системы окупается в среднем за 6-12 месяцев за счёт снижения текучки и повышения эффективности команды. Средние потери компании от выгорания одного разработчика составляют 1.5-3 годовых зарплаты, наша система сокращает этот риск на 40% в пилотных проектах. Дополнительно снижаются затраты на замену персонала — до 35%.