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

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