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

Разработчик начинает работать позже обычного, коммиты мельчают, задачи в 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%.