FTE Utilization vs часы: одна метрика врёт
Команда из 8 инженеров отлогировала 1 280 часов в марте 2026 — ровно столько, сколько даёт месяц при 160 часах на FTE. На таблице всё выглядело чисто. Двое инженеров были в трёх неделях от увольнения. Цифра часов это полностью скрыла; FTE utilization показала на пятый день.
Это разрыв между метрикой посещаемости и метрикой вовлечённости относительно базовой нагрузки. Исследование Microsoft Research WorkLab 2022 года про «triple peak workday» задокументировало третий вечерний пик продуктивности у knowledge workers — невидимый, если считать только сумму часов. Часы не говорят, кто спринтует, а кто плывёт. FTE utilization — говорит.
{/* truncate */}
Почему часы — это успокоительная метрика
«Команда отлогировала 1 280 часов» — инженерная версия «мы закрыли 47 тикетов». Выглядит как измерение. На деле — счётчик.
Счётчик говорит, что никто не пропал. Он не говорит:
- была ли нагрузка сбалансирована
- работал ли кто-то стабильно больше 50 часов в неделю
- отдохнул ли реально человек, у которого был оплаченный отпуск
- держится ли скорость на пятерых, перерабатывающих, или на восьмерых, работающих устойчиво
Стэнфордский экономист John Pencavel в своём исследовании 2014 года про working hours и productivity дал самое чистое доказательство по теме. Output растёт с количеством часов до примерно 49 в неделю. После 55 output на час падает настолько резко, что 70-часовая неделя даёт почти столько же, сколько 56-часовая. Лишние 14 часов — это чистая стоимость без отдачи. Отчётность по часам этот разрыв увидеть не может. По utilization — может.
Как PanDev считает FTE utilization
Формула намеренно скучная:
utilization = avgMonthlySeconds / (160h × 3600)
avgMonthlySeconds берётся из IDE-телеметрии — heartbeat-based время активного редактирования, а не «у меня был ноут открыт». 160h × 3600 — стандартная FTE-база (40ч × 4 недели). Для сотрудников с кастомным графиком — декрет 50%, контракторы на 4-дневке, лиды с формальным 30% management time — знаменатель переопределяется через CustomEmployeeWorkingTime, и график 50% считается против базы 80ч, а не 160.
Результат идёт в heatmap с тремя зонами:
| Зона | Диапазон | Что значит | Действие |
|---|---|---|---|
| Зелёная | <70% | Недоутилизация. Запас мощности. | Брать новую работу, менторить, экспериментировать |
| Оранжевая | 70–90% | Здоровая. Устойчивая нагрузка. | Защищать этот диапазон |
| Красная | >90% | Устойчивая перегрузка. Риск выгорания. | Разобраться на той же неделе, перераспределить |
Виджет рендерит scrollable per-day timeline с фиксированной Y-осью, чтобы строка, которая внезапно становится красной в середине месяца, была видна с первого взгляда. Мы намеренно выбрали такую раскладку вместо месячных средних, потому что один 95% месяц — редкость; три подряд — это заявление об увольнении в процессе написания.
Скажу прямо: это инструмент для направления внимания, а не приговор. Красная клетка — это вопрос «что произошло на той неделе?», а не performance review.
Часы vs FTE utilization: одинаковые суммы, разные истории
Шесть инженеров, тот же март, по 160ч «отлогированных»:
| Инженер | Часы залогировано | Активные IDE-часы | Кастомная база | FTE utilization | Зона |
|---|---|---|---|---|---|
| Alex (senior) | 160ч | 152ч | 160ч | 95% | Красная |
| Maria (senior) | 160ч | 148ч | 160ч | 93% | Красная |
| James (mid) | 160ч | 124ч | 160ч | 78% | Оранжевая |
| Sarah (mid) | 160ч | 118ч | 160ч | 74% | Оранжевая |
| Daria (lead, 30% mgmt) | 160ч | 98ч | 112ч | 88% | Оранжевая |
| Tomás (декрет 50%) | 80ч | 72ч | 80ч | 90% | Оранжевая |
Две красных в «идеальном» месяце. Daria выглядит нормально, потому что её база корректно учитывает management time — без override она бы читалась как 61% и казалась лентяйкой. Tomás отлогировал в два раза меньше часов, но ближе к своему потолку, чем James и Sarah к своим. Среднее — «команда отлогировала 1 000 часов, это норма» — стирает всё это.
Это и есть аргумент за FTE utilization в одной таблице. Часы дают вам прямоугольник. Утилизация — heatmap.
Три архетипа команды, которые видит heatmap
Прогоните heatmap по 4 неделям для команды из 8. Повторяются три паттерна:
| Архетип | Распределение по зонам | Что реально происходит |
|---|---|---|
| Скрытое выгорание | 60% красная, 15% оранжевая, 25% зелёная | Двое-трое тащат, остальные плывут. Скорость выглядит нормальной, пока кто-то из тащущих не уйдёт. |
| High-performance | 10% красная, 75% оранжевая, 15% зелёная | Большинство в диапазоне 70–90%. Красные — короткие, привязаны к конкретному инциденту. Зелёные — намеренные (отпуск, обучение). |
| Недоутилизация | 0% красная, 30% оранжевая, 70% зелёная | Реальный запас мощности. Либо штат раздут, либо сломан intake задач. Это не «ленивая команда» — это сбой планирования сверху. |
Скрытое выгорание — самый опасный. На дашборде по часам он выглядит здоровым, потому что тащущие компенсируют плывущих. Сумма — норма. Проблема в распределении. Gallup в State of the Global Workplace 2024 ставит глобальную вовлечённость на уровне 23%, а активную невовлечённость — 15%. То есть в среднем в команде больше disengaged, чем burnt-out, но именно burnt-out делают работу. Математика по часам их усредняет. FTE utilization их разделяет.
Та же команда, та же сумма часов. Недели 1–2: паттерн скрытого выгорания — красные тащущие, зелёные плывущие. Недели 3–4 после redistribution: разброс сжался в диапазон 70–82%.
Реальный пример: −23% cycle time, ноль найма
Команда из 8 инженеров отлогировала 1 280 часов в марте 2026. Отчёт по часам читался как «месяц укомплектован, идём по плану». Heatmap FTE utilization рассказывал другое:
- 5 инженеров на 92–98% (красная зона) три недели подряд
- 3 инженера на 45–55% (зелёная зона) — не в отпуске, не на обучении, просто недоразданы
Их лид прокликал drill-down через /dashboard/finances/employee/:id для каждого инженера в красной зоне. Двое тонули в очереди code review. Двое были вытащены в security-проект под регулятора, который никто не отразил в спринт-плане. Один в одиночку парно-дебажил flaky-пайплайн 12 дней.
Фикс был неромантичный: переключить CR-нагрузку security-проекта на двух инженеров из зелёной зоны и подсадить третьего парой к владельцу flaky-пайплайна. К апрелю разброс на heatmap сжался в диапазон 70–82% по всем 8.
Cycle time улучшился на 23%. Найм: ноль. Сумма часов месяц-к-месяцу была идентичная. Форма этих часов — совершенно разная. Именно форма предсказывает, останется ли команда в Q4.
Та же динамика, которую мы разобрали в статье про overhead coefficient: utilization напрямую кормит расчёт nontaskTotal, который вылезает в математике cost-per-feature. Команда, работающая в красной зоне, несёт 1.3–1.5× эффективной стоимости команды того же размера в оранжевой — потому что налог на выгорание компаундится в churn в течение двух кварталов.
Что FTE utilization НЕ измеряет
Скажу прямо, чтобы никто не вешал планирование на метрику, которая это не вытянет:
- Не ловит мышление вне клавиатуры. Staff-инженер, проектирующий систему на доске два часа, читается как IDE-idle. Для research-heavy и design-heavy ролей сочетайте метрику с self-reported deep-work блоками. Сторону deep work мы разобрали в почему два часа непрерывного кода равны шести.
- Не измеряет качество кода. Инженер на 95% в красной зоне может выдавать фичи и одновременно баги. Смотрите вместе с review velocity из code review checklist 2026, а не изолированно.
- Не работает для соло- и opensource-контрибьюторов. Наш датасет — B2B инженерные команды. Соло-фаундеры и OSS-мейнтейнеры живут совсем в другом ритме: рваные пики, асинхронная коллаборация, нет фиксированной FTE-базы.
- Одна неделя высокой утилизации — это шум. Три подряд — сигнал. Сила heatmap в time series, а не в снапшоте.
Как действовать на том, что показывает heatmap
Для каждой зоны playbook короткий:
Красная (>90% устойчиво ≥3 недель): 1:1 на той же неделе. Не делайте это performance-разговором — делайте load-разговором. Аудит того, чем человек владеет: очередь CR, on-call, проекты, ad-hoc-запросы. Перенесите минимум один поток работы в течение спринта. Перепроверьте через две недели.
Оранжевая (70–90%): ничего не делать. Это диапазон, в котором вы хотите видеть 70–80% команды. Не оптимизируйте людей, которые уже там, где надо.
Зелёная (<70%): вопрос, не обвинение. Спросите, что блокирует — низкий intake? Тикеты неправильно нарезаны? Инженер ждёт review? Раскачивается после смены роли? Если ничего из этого — это реальный запас мощности под новые инициативы или менторство.
Самая частая ошибка, которую мы видим: команды реагируют на красные зоны наймом. Найм занимает 4–6 месяцев до выхода эффективного инженера. Перераспределение — один спринт. Нанимайте, когда перераспределение перестало работать, не до того.
Метрика, которую мы бы повесили на стену
Если бы пришлось выбрать одну цифру для стены инженерных операций, это были бы не часы. И даже не средняя утилизация. Это была бы доля команды в красной зоне ≥3 недель подряд.
Выше 25% — у вас структурная перегрузка. Ниже 5% — возможно, перебор по штату. Между 5% и 15% — здоровая работа с нормальной частотой инцидентов и кранчей. Эта одна цифра предсказывает риск attrition, стабильность cycle time и здоровье review-очереди лучше любого тщеславного дашборда.
Часы говорят, что никто не пропал. FTE utilization — кто из них останется через полгода. Выбирайте ту, что отвечает на вопрос, который стоит задавать.