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

Розробник починає працювати пізніше звичайного, коміти дрібнішають, завдання в 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%.