Команда занята на 95%, а заказов меньше: разделяем загрузку и производительность

Руководитель поддержки видит в табеле загрузку 95%, но закрытых обращений стало меньше. Предлагает нанять ещё двух сотрудников. Команда отвечает, что половина дня уходит на повторные исправления и ожидание согласований. Оба описания могут быть верны: высокий процент занятых часов сам по себе не показывает, сколько полезного результата получено. Разложим рабочее время и выпуск так, чтобы стало понятно, какую проблему решать.

Зафиксировать четыре разных величины

Оплаченные часы нужны для стоимости. Доступная мощность — часы, когда сотрудники могли выполнять работу после отпусков, больничных и заранее исключённого обучения. Занятые часы — время, записанное на задачи. Продуктивная обработка — часть занятого времени, которая создаёт результат с первого прохода. Для нашей задачи повторная работа учитывается отдельно, иначе исправление одной заявки дважды выглядит как двойной выпуск.

Предположим, оплачено 1000 часов, из них 200 недоступны по согласованным причинам. Команда могла обработать обращения в течение 800 часов и записала на задачи 760. Это действительно 95% загрузки доступной мощности. Но 160 часов заняли исправления, ещё 100 — ожидания, учтённые внутри задач. На первичную обработку осталось 500 часов. За период закрыли 250 обращений, каждое соответствует принятому критерию качества.

Посчитать отношения с правильными знаменателями

Выпуск на доступный час равен 250 / 800, то есть 0,3125 обращения. Выпуск на час первичной обработки — 0,5. Второй показатель помогает понять процесс обработки, первый — планировать общую мощность команды. Убирать ожидания из знаменателя плана нельзя: календарь сотрудников всё равно расходуется. А делить 250 на оплаченные 1000 полезно для стоимости, но это уже третий вопрос.

paid = 1000
unavailable = 200
busy = 760
rework = 160
waiting = 100
completed_good = 250
capacity = paid - unavailable
processing = busy - rework - waiting
assert 0 < processing <= busy <= capacity <= paid
print({'utilization': busy/capacity,
       'good_per_capacity_hour': completed_good/capacity,
       'good_per_processing_hour': completed_good/processing,
       'rework_share_of_busy': round(rework/busy, 3)})
assert busy/capacity == 0.95
assert processing == 500
assert completed_good/capacity == 0.3125
assert completed_good/processing == 0.5

Не превратить сложность задач в обвинение сотрудников

Если раньше обращения касались смены пароля, а теперь — восстановления интеграций, одинаковое число закрытых тикетов требует разного труда. Перед сравнением разделите поток по типам или тяжести, используя категории, известные до выполнения. Вес, назначенный задним числом по фактически потраченным часам, способен спрятать ухудшение процесса: всё медленное автоматически станет сложным.

Нужна и единая граница завершения. Закрытый тикет, который на следующий день открыли повторно, может давать ложный рост выпуска. Выберите, например, закрытие без повторного открытия в течение семи дней и сравнивайте только достаточно старые обращения. Свежие закрытия покажите отдельно как ещё не прошедшие проверку. Параллельно сохраните размер очереди и возраст старых задач: команда способна улучшить среднее за счёт выбора коротких обращений.

Как цифры меняют решение о найме

В нашем примере сначала стоит разобрать 160 часов исправлений. Возьмите несколько повторных обращений, свяжите их с первыми и найдите повторяющиеся причины: неверный шаблон ответа, отсутствие данных, ошибка маршрутизации. Для ожиданий посчитайте конкретные этапы и ответственных за согласование. Если они занимают время задачи, но сотрудник в этот момент обрабатывает другую, нельзя дважды списывать одни и те же часы; данные нужно привести к взаимно исключающим категориям.

После изменения процесса сравните сопоставимый поток: выпуск хороших обращений, доступные часы, повторную работу и очередь. Если выпуск на доступный час вырос, а очередь всё равно увеличивается из-за входящего потока, дополнительная мощность действительно нужна. Если нет, найм может просто масштабировать исправления. Такой отчёт даёт руководителю предмет для решения: изменить процесс, пересмотреть приоритеты или расширить команду с понятным расчётом потребности.

Продолжить работу с данными

Для следующего шага — согласовать определения часов и собрать отчёт по периодам — пригодятся паспорт метрики, проверка данных и аналитическая записка из «Практической аналитики данных». На кейсах курса вы отработаете переход от таблицы к графику и рекомендации, которую можно обсуждать с руководителем команды. Откройте программу платного курса «Практическая аналитика данных».