Loaded hourly rate: почему час разработчика стоит в 1.5 раза дороже зарплаты
Senior backend разработчик в Алматы получает $5 000/мес. gross. CFO, который оценивает новый проект, делает очевидную арифметику: $5 000 ÷ 160 = $31.25/час. Эта цифра попадает в Excel, потом в борд-дек, потом в коммерческое предложение клиенту.
Реальная стоимость часа этого инженера, с учётом накладных расходов, ближе к $46/час. Разрыв в 48%. DORA State of DevOps Report 2024 фиксирует non-coding overhead в инженерных организациях на уровне 35–55% от ФОТ. McKinsey Developer Velocity Index (2023) даёт примерно тот же диапазон. Большинство компаний этот множитель просто не применяют. Они квотят, скоупят и бюджетируют по «голой» цифре, а потом удивляются, почему юнит-экономика не сходится.
{/* truncate */}
Наивная формула и где она ломается
Дефолтная стоимость часа выглядит как monthly_salary / 160. 160 — это европейская/казахстанская конвенция рабочего месяца: примерно 8 часов × 20 рабочих дней. PanDev Metrics использует ту же константу в dual-rate движке: когда у разработчика в Department указана MONTHLY-ставка ($/мес.), система внутренне конвертирует её в HOURLY как rate / 160.
Это direct rate. Для того, что он представляет, он корректен: financial-grade перевод оплаченной зарплаты в часовое выражение.
Чего он не учитывает:
- Зарплату EM/team-lead'a, к которому относится разработчик.
- Зарплату DevOps-инженера, который держит staging живым.
- HR-партнёра, ведущего онбординг.
- 4 часа в неделю, которые разработчик тратит на встречи и code review (коммитов нет, времени тоже).
- 2 недели на квартал, ушедшие на инциденты, ramp-up на новом проекте или research-спайки.
Ничего из этого не отображается в payslip разработчика. Всё это реальные деньги, которые компания платит, чтобы инженер мог сделать ту работу, которая в payslip отображается. В классическом учёте это называется overhead. Инженерные руководители, которые не умножают на этот коэффициент, квотят фантастику.
Stack Overflow Developer Survey 2024 даёт глобальную медиану задекларированной рабочей недели в 41.7 часов, из которых на собственно код уходит 40–60%. Остальное на встречи, планирование, обучение и ожидание зависимостей. В пересчёте на месяц это где-то 64–96 часов «реального» выхлопа из 160 оплаченных. Деление зарплаты на оплаченные часы недо-оценивает продуктивный час в 1.5–2.5 раза.
Формула loaded rate
Стандартная учётная формула:
loaded_rate = direct_rate × (1 + K)
Где K — это overhead-коэффициент: отношение косвенных издержек к прямой продуктивной работе. PanDev Metrics считает K через OverheadCoefficientService:
K = adminSalary / (taskTotal + nontaskTotal)
Три компоненты:
- taskTotal: сумма оплаты за часы разработчиков, привязанные к таск-трекеру (Jira issue, ClickUp task и т.д.). Это прямая работа, которую могут назвать заказчик или продакт.
- nontaskTotal: сумма за часы кода без таска. Встречи, code review, research-спайки, ramp-up, инцидент-разбор. Это тоже инженерный output, просто не атрибутируемый к фиче.
- adminSalary: фиксированная месячная стоимость менеджмента и эксплуатации. Time-share тимлидов на менеджмент, ФОТ EM/директоров, DevOps platform engineers, IT, амортизация затрат на найм. Всё, что платится, но это не разработчик, пишущий код.
Типичный K на нашей customer-базе: 0.20–0.60. K = 0.30 значит, что каждый $1 прямой dev-стоимости несёт $0.30 организационного overhead. K = 0.55 это почти полтора сверху.
Разбор примера: senior-инженер в Алматы
Senior backend, $5 000/мес.
| Шаг | Цифра |
|---|---|
| Месячная зарплата | $5 000 |
| Рабочих часов в месяце (конвенция) | 160 |
| Direct hourly rate | $31.25 |
| K департамента (март 2026, посчитан) | 0.48 |
| 1 + K | 1.48 |
| Loaded hourly rate | $46.25 |
K = 0.48 пришёл из реальных книг департамента в этом месяце:
| Компонент | Сумма |
|---|---|
taskTotal (код, привязанный к таскам) | $20 000 |
nontaskTotal (встречи, review, research) | $9 000 |
adminSalary (EM + DevOps + IT-аллокация) | $14 000 |
| K = 14 000 / (20 000 + 9 000) | 0.483 |
Разрыв в 50% между наивной и нагруженной ставкой не экзотика. Это нормальное состояние любой инженерной организации, где есть реальный менеджерский слой.
Почему один K на всю компанию скрывает правду
LinearB, Jellyfish, Code Climate и большинство DIY-табличек используют единый усреднённый K, выбранный раз в год и применяемый плоско на каждый проект, каждый месяц, каждый отчёт по cost-per-feature. Для годового отчёта это работает. Для квотирования проектов и середины года не работает.
Причина: K двигается от месяца к месяцу, иногда резко.
- Q4 (окт–дек):
nontaskTotalрастёт от year-end planning, performance reviews, holiday backfill, реоргов. K сдвигается вверх. - Июль–август: половина команды в отпуске.
taskTotalпадает,adminSalaryконстанта. K растёт снова, но по другой причине. - Месяц после реорга: менеджерский headcount подрос раньше, чем dev-headcount.
adminSalaryскачет, K скачет. - Месяц с тяжёлыми инцидентами:
nontaskTotalпоглощает разбор инцидентов, K сдвигается вверх.
PanDev Metrics считает K помесячно по департаменту. Cost-per-feature для фичи, выкаченной в ноябре, использует ноябрьский K, а не среднегодовой. Разница ощутима: на customer-базе мы регулярно видим K, осциллирующий между 0.32 и 0.61 в одном календарном году внутри одной команды. Плоский 0.45 неправильно ценит половину месяцев в обе стороны.
Этот помесячный K и отличает финансовую команду, сходящуюся с фактом, от той, что живёт в тумане «приблизительно».
Naive vs loaded по типичной инженерной команде
| Роль | Месячная компенсация | Direct rate | K департамента | Loaded rate | Разрыв |
|---|---|---|---|---|---|
| Junior | $3 000 | $18.75 | 0.48 | $27.75 | +48% |
| Mid | $5 000 | $31.25 | 0.48 | $46.25 | +48% |
| Senior | $7 000 | $43.75 | 0.48 | $64.75 | +48% |
| Staff | $10 000 | $62.50 | 0.48 | $92.50 | +48% |
| Контрактор | $12 000 (счёт) | $75.00 | 0.10 | $82.50 | +10% |
Строка с контрактором обычно ловит CFO врасплох. Контрактор, выставляющий счёт через своё юр.лицо, несёт минимальную аллокацию adminSalary, потому что сам платит за свой менеджмент. K для контракторской стоимости намного ниже, обычно 0.05–0.15 (только амортизация рекрутинга и PM overhead). На часовой базе $75/ч контрактор может оказаться дешевле, чем «$31/ч» senior-сотрудник, если оба нагружены честно. Этот инсайт заставил уже не одного нашего клиента пересмотреть соотношение employee/contractor.
По всей организации наивная ставка недо-оценивает каждую штатную роль примерно на 48%. Контрактор это исключение, и именно этот рычаг большинство CFO упускают.
Где K-коэффициент живёт в продукте
PanDev Metrics получает K автоматически из данных, уже текущих через платформу: IDE heartbeat-данные привязывают coding-минуты к таскам (когда разработчик сидит в task-named ветке вроде feature/PDM-3475) или к non-task-работе (всё остальное). Зарплаты и admin-аллокации настраиваются один раз в Department settings. OverheadCoefficientService пересчитывает K каждую ночь. Cost-per-feature, engineering ROI и квотирование проектов читают K текущего месяца, а не статичное значение.
Это тот же движок, что стоит за нашим модулем hourly rate и cost tracking, и это input-слой для расчётов cost per feature ниже по pipeline.
В UI K выводится отдельной карточкой с историей по месяцам. Финансовая команда видит, в каком месяце K был 0.31, а в каком 0.58, и может сразу прокликаться к составляющим: где конкретно вырос nontaskTotal, какие департаменты дали скачок adminSalary, какой проект просел по taskTotal. Это тот уровень разлёта по дереву, который превращает «у нас в среднем 45% надбавка» в реальный аудит. По нашему опыту, после первого квартала с помесячным K финансовая команда перестаёт спорить с инженерным руководством о квотах: цифра одна, источник один, история одна.
Что наша модель не сможет сказать
Честное ограничение: модель K-коэффициента предполагает, что вы можете чисто разделить task vs non-task работу через IDE-телеметрию. Если ваши разработчики не следуют convention feature/TICKET-ID, платформа не может определить, было ли coding-time таском или нет. Командам без IDE-уровня tracking'а понадобится bootstrap K через ручной time-allocation survey первые 1–2 месяца (обычно 5-минутный еженедельный self-report), пока покрытие не станет достаточным, чтобы доверять автоматическому числу.
Ещё два ограничения, которые стоит назвать:
- Капитализированная vs экспенсная работа. Некоторые учётные режимы (US GAAP) капитализируют новую продуктовую разработку и списывают maintenance в расходы. K тут то же самое число; различается, как вы книжите loaded cost. CFO применяет cap/exp split после loaded rate, а не до.
- Open-source contribution time, который косвенно работает на компанию (например, разработчик мейнтейнит библиотеку, от которой зависит продукт), сидит неудобно. По дефолту мы кладём это в
nontaskTotal. Если ваша бизнес-модель требует считать это прямыми затратами, это вопрос конфигурации, а не формулы.
Что сделать на этой неделе
- Поднять прошлый месяц по одному департаменту: суммировать ФОТ разработчиков (
dev_total). Суммировать менеджмент + DevOps + IT, аллоцированные на этот департамент (adminSalary). - Из трекера достать часы-на-тасках vs часы-вне-тасков за тот же месяц. Умножить на часовые ставки →
taskTotal,nontaskTotal. (Если разделить нельзя, нижняя оценкаnontaskTotal = 25% от dev_total.) - Посчитать
K = adminSalary / (taskTotal + nontaskTotal). - Переквотировать два самых крупных активных проекта по loaded rate. Дельта это маржа, которую вы отдавали клиенту бесплатно, не зная об этом.
Плоские 50% надбавки не ответ для всех. Но допущение нулевой надбавки неправильное для всех. Работа в том, чтобы найти свою цифру, помесячно, и дать книгам её отразить.
Ставка, которая стоит в коммерческом предложении клиенту в мае, по-хорошему должна быть посчитана из апрельского K. Не из прошлогоднего среднего. Не из того, что записал финдир в Excel позапрошлой осенью. Из реальных книг прошлого месяца, со всеми всплесками и просадками. Это и есть граница между маркетинговой ставкой и финансовой.