Почему Q4 всегда выходит за бюджет инженерии: сезонность per-month K

В компании из 60 инженеров, которую мы инструментировали 14 месяцев подряд, средний коэффициент накладных составил K = 0.41. Это число бесполезно. Помесячный ряд: янв 0.46, фев 0.40, мар 0.39, апр 0.40, май 0.41, июн 0.43, июл 0.48, авг 0.49, сен 0.42, окт 0.40, ноя 0.43, дек 0.52. Финансовая модель с плоским K предсказала декабрьские накладные в $185K. По факту вышло $235K. Промах в 27% — это не ошибка прогноза. Это вся история сюрпризов Q4, которые CFO годами просит инженерию объяснить.

Отчёт DORA State of DevOps 2024 подсветил ту же картину с другой стороны: deployment frequency в Q4 падает на 12–18% по всему опросу, а incident volume растёт. Stack Overflow Developer Survey 2024 фиксирует в среднем 17 дней отпуска в год, со скоплением в конце декабря и августе. Harvard Business Review в Why Most Product Launches Fail показывает, что плотность Q4-релизов на 30–40% выше остальных кварталов. Три разных датасета, одно следствие: инженерная мощность в декабре структурно отличается от июня. Считать их одинаковыми в финансовой модели — это и есть ошибка.

{/* truncate */}

Что усреднённый K делает с прогнозом

Коэффициент K отвечает на один вопрос: на каждый доллар прямой разработки сколько накладных долларов (менеджмент, митинги, ramp-up, админ) вы несёте. Большинство инструментов считает K один раз, усредняет по году и фиксирует. Для платёжной строки годится. Для помесячного прогноза — нет.

Самая простая иллюстрация. Та же команда, тот же год, два способа предсказать декабрь:

Прямые task-усилия в декабре:        $452K
Плоский K (среднегодовой 0.41):       × 0.41 = $185K накладных
Per-month K (декабрь = 0.52):         × 0.52 = $235K накладных
                                              ───────
                                     Дельта: +$50K (27%)

Эти $50K появляются не потому, что кто-то делает что-то не так. Они появляются потому, что знаменатель K — прямое время по задачам — в декабре падает (отпуска, праздники), а числитель — admin-зарплаты, удерживаемые на ретейнере подрядчики, end-of-year-синки — не меняется или растёт. K — это отношение. Отношения дёргаются, когда одна сторона двигается. Усреднение этого качка убивает прогноз.

Про формулу и три компонента K (taskTotal, nontaskTotal, adminSalary) подробно: Overhead Coefficient: The Hidden Tax Per Developer. Эта статья считает, что вы знаете что такое K, и фокусируется на том, почему его надо считать помесячно, а не годом.

14-месячный ряд с причинами

Полный ряд по 60-инженерной компании. Каждая строка — одно агрегирование (department_id, year, month). Колонка причины восстановлена по HR-данным, sprint-логам и календарю деплоев — не догадка.

Месяц	K	Причина
Ноя 2024	0.42	Подготовка к Q4-релизу, лаг найма
Дек 2024	0.50	End-of-year crunch + праздничные дыры
Янв 2025	0.46	Возврат после праздников, OKR-перепланирование
Фев 2025	0.40	Steady state
Мар 2025	0.39	Steady state, минимум по году
Апр 2025	0.40	Пасха, минорный отпускной шум
Май 2025	0.41	Steady state
Июн 2025	0.43	Начало отпусков, знаменатель сжимается
Июл 2025	0.48	Пик летних отпусков
Авг 2025	0.49	Пик летних отпусков продолжается
Сен 2025	0.42	Возврат к работе, нормализация
Окт 2025	0.40	Steady state, фокус перед релизом
Ноя 2025	0.43	Подготовка к Q4-релизу возвращается
Дек 2025	0.52	Crunch + праздники + deploy-blackout

Посмотрите на разброс. Минимум K — 0.39 в марте. Максимум — 0.52 в декабре. Это диапазон 33% в одной команде за один год. Среднегодовое размазывает этот диапазон и выдаёт 0.41 как будто год был плоский. Год никогда не был плоским. Январский вопрос CFO — «почему инженерия ушла на $50K выше бюджета в Q4?» — отвечает строка 14 этой таблицы.

Картина не уникальна. Stack Overflow Developer Survey показывает, что в ноябре–декабре концентрируется около 22% всех годовых отгулов. Исследование DORA фиксирует падение частоты деплоев в конце декабря у 78% опрошенных. Никто из тех, кто работал инженерный год, этому не удивится. Удивляется финансовая модель — потому что она это усредняет.

Пунктирная линия flat-K на 0.41 — одно и то же число каждый месяц. Столбики — реальность. Расстояние между ними в декабре и есть то, что прилетает в variance-отчёт CFO.

Три сезонных силы, три механизма

Сезонность не случайна. Это три предсказуемые силы, которые наслаиваются друг на друга.

Сила 1: отпускные дыры сжимают знаменатель. Когда 22% команды в PTO, taskTotal падает. nontaskTotal тоже падает, но меньше — те, кто работает, продолжают ходить на all-hands и code review. adminSalary не падает вообще: CTO получает зарплату вне зависимости от того, половина команды на пляже или нет. Отношение K = adminSalary / (taskTotal + nontaskTotal) растёт механически. Поэтому августовский K на 12–18% выше июньского в нашем датасете.

Сила 2: Q4-crunch поднимает числитель. Плотность релизов в Q4 (HBR: на 30–40% выше остальных кварталов) тянет дополнительные митинги, дизайн-синки, инциденты, время лидерства. nontaskTotal резко растёт, а taskTotal стоит на месте или даже падает из-за pre-holiday deploy freeze. adminSalary не двигается. Декабрьский K на 18–25% выше годового baseline.

Сила 3: январское re-baselining — отдельная история. Возврат с праздников — реальный измеримый эффект. Январский K в нашем датасете на 10–15% выше steady-state февраль–май: OKR-планирование, ретро прошлого года, перенесённое в январь, kickoff найма, медленное возвращение полной командной каденции. Люди физически за столами, но месяц по аллокации усилий смещён в планирование, не в прямую работу.

Эти три силы не взаимозаменяемы и не компенсируют друг друга. Q4 K высок из-за crunch + отпусков. Январь K высок из-за re-baselining. Лето K высок из-за отпусков. Финансовая модель, которая это знает, бюджетирует каждый случай отдельно. Плоский K считает их шумом и удивляется три раза в год.

Side-by-side: плоский K vs per-month K на одном Q4

Variance-отчёт CFO интересует одно сравнение: что мы предсказали vs что потратили. Ниже тот же Q4 (окт–дек 2025), посчитанный обоими способами.

Месяц	Прямые усилия	Плоский K (0.41) прогноз	Per-month K прогноз	Факт	Промах плоского K
Окт	$470K	$470K × 0.41 = $193K	$470K × 0.40 = $188K	$189K	+$4K (2%)
Ноя	$445K	$445K × 0.41 = $182K	$445K × 0.43 = $191K	$192K	−$10K (5%)
Дек	$452K	$452K × 0.41 = $185K	$452K × 0.52 = $235K	$235K	−$50K (27%)
Q4 итого	$1.367M	$560K	$614K	$616K	−$56K (10%)

Октябрь нормально — K случайно близок к среднегодовому. Ноябрь умеренно мимо. Декабрь — катастрофа. И этот промах Q4 в $56K сворачивается в variance-строку, которая прилетает в квартальный отчёт CFO как «перерасход инженерии» без чёткой причины. Причина чёткая. Финансовая модель просто отказалась её увидеть.

Как per-month K вписывается в полный bottom-up бюджет по нескольким командам — см. The CFO's Guide to Engineering Metrics. Как K складывается с почасовой ставкой и даёт честную loaded-cost цифру на инженера — см. Loaded Hourly Rate: The True Cost of an Engineer Hour.

Как PanDev Metrics это считает без вашего участия

Продуктовый трюк, который делает per-month K жизнеспособным, — это форма хранения, не хитрый алгоритм. PanDev Metrics пишет одну строку OverheadCoefficient на (department_id, year, month) — никогда не агрегирует, никогда не усредняет. Текущий месяц обновляется ночью через OverheadCoefficientCronJob, который инкрементально складывает вчерашние heartbeat-данные в K текущего месяца.

Когда что-то меняется задним числом — корректировка зарплаты, back-dated реорганизация департамента, две недели неправильно настроенной интеграции с трекером — OverheadCoefficientFullRecalcCronJob пересобирает затронутые месяцы. Без recalc-job одно HR-изменение тихо корраптит шесть месяцев финансовых отчётов, и никто не замечает до годового аудита. Мы выучили это на собственных книгах прежде, чем сделали recalc-job обязательным.

Чтобы вытянуть ряд для CFO, time-series API: POST /departments/{id}/finance/costs с granularity = MONTHLY. Возвращает тренд K в той же форме, что таблица выше. Те же данные кормят Costs Chart на /dashboard/finances, у которого есть Year Dropdown — финансовый лид может проиграть любой исторический год против текущего и увидеть, идёт ли 2025-й впереди или позади 2024-го по месяцам, не по среднегодовому.

Когда per-month K врёт

Per-month K максимально точен после 12+ месяцев телеметрии. Новые команды видят шумный K первые 4–6 месяцев, пока паттерны работы стабилизируются, волны найма проходят онбординг и команда сходится к своей реальной каденции митингов. Мы видели, как K качался 0.30 → 0.58 в первые шесть месяцев данных 12-инженерной команды без реального изменения затрат — просто sampling noise от маленького знаменателя.

Не принимайте бюджетные решения по первым трём месяцам K-данных. Используйте плоский отраслевой бенчмарк (0.35–0.45 — типичный диапазон B2B-инженерии) пока у вас не наберётся год телеметрии, потом переключайтесь на per-month K. Честная версия: per-month K — это роскошь команд, которые мерили себя год. Если вы начинаете мерить сегодня, ваш первый полезный Q4-прогноз — через 12 месяцев. Шорткатов нет.

Что с этим делать в январском планировании

Три конкретных шага, по убыванию импакта.

1. Замените плоский множитель в бюджетной таблице на двенадцать значений K — по одному на месяц. Это разовая миграция. Достаньте помесячный ряд из инструмента, вставьте в бюджетный шаблон, дайте декабрьским накладным своё значение. Variance Q4 у CFO съёжится на 60–80% с первой попытки.

2. Перестаньте считать январь и август выбросами в прогнозе. Это не выбросы. Это предсказуемые пики. Бюджетируйте их как +12% и +15% к steady-state K. Если придётся защищать прибавку перед финансами — приведите те же данные Stack Overflow по отпускам и DORA по падению деплоев, которые они приняли бы у внешнего аналитика.

3. Считайте K по департаментам, не только по компании. Backend, frontend и data-команды имеют разные формы K из-за разной meeting load и разного распределения фиксированных издержек. У 60-инженерной компании Backend K шёл 0.32–0.45 за год, Data K — 0.41–0.62. K по всей организации усредняет эти две и не представляет ни одну. Точность cost-per-feature зависит от этой гранулярности больше, чем от любого другого фикса.

Если ваша финансовая команда три года ловит Q4-сюрприз и не может найти — это не потому, что данных нет. Это потому, что данные усредняются до невидимости. Фикс — самое простое возможное изменение формы хранения: не усредняйте. Держите месяцы отдельно. Сезонность всегда там была.

Дополнительное чтение

• Overhead Coefficient: The Hidden Tax Per Developer — формула K и три её компонента
• Loaded Hourly Rate: The True Cost of an Engineer Hour — как K складывается со ставкой и даёт реальную цифру на час
• The CFO's Guide to Engineering Metrics — bottom-up фреймворк бюджетирования инженерии