Bottom-up бюджет инженерии: от ставки до P&L
R&D-организация на 50 инженеров, с которой мы работали в прошлом фискальном году, верстала годовой бюджет так же, как большинство: взять прошлогодний расход ($5.4M), прибавить 10%, получить $5.94M. К концу третьего квартала финансы согласовывали с советом директоров дополнительно $700K. Недостача оказалась почти ровно $710K — 12% сверх top-down цифры — и постмортем привязал каждый доллар к допущениям, которые никто не записывал. Праздничные месяцы шли с повышенным overhead. Двое контрактников официально были part-time, по факту биллили 0.9 FTE. Одна команда выросла на трёх человек в марте, и стоимость накопилась за девять месяцев, а не за четыре, как заложил планировщик.
Gartner в IT Spending Forecast 2025 оценивает рост R&D в софте на 9-11% год к году, но разброс по конкретным компаниям шире — Deloitte в отчёте CFO Insights: Budgeting in Volatile Times (2024) зафиксировал медианную ошибку прогноза 18% в софт-ориентированных компаниях, использующих top-down, а худший квартиль промахивается больше чем на 30%. McKinsey в Tech Talent Tectonics (2023) формулирует резче: топ-квартиль инженерных организаций тратит не только меньше на единицу выхода — они точнее прогнозируют, и поэтому могут аллоцировать капитал агрессивно там, где нижний квартиль вынужден держать запас наличных как страховку от собственной плохой математики.
{/* truncate */}
Почему top-down промахивается
Привычный подход: «потратили в прошлом году $X, прибавим инфляцию и рост — получим план». Для аренды и электричества это работает. Для инженерии ломается по трём причинам, которые усиливают друг друга.
Изменения headcount не сглаживаются. Команда, выросшая на 10% по головам, не выросла на 10% по стоимости — она выросла на 12-18%, в зависимости от месяца найма и loaded rate новичков. Top-down считает headcount как годовой вход. Реальность: инженер, нанятый в марте, стоит компании девять месяцев полной зарплаты плюс единоразовая стоимость онбординга, а нанятый в октябре — три месяца, и его стоимость случайно «уезжает» в следующий год.
Утилизация считается за 100%. Почти любой top-down бюджет неявно моделирует каждого инженера как 12 месяцев × 160 часов. Реальная утилизация в B2B инженерных организациях держится на 70-85% оплачиваемых часов с учётом отпусков, больничных, родительских отпусков и четырёх-шести недель в год, которые поглощают собеседования, онбординг новых сотрудников и квартальное планирование. Подробнее эту сторону мы разбирали в FTE Utilization vs. Hours: The Honest Productivity Metric — главный вывод: даже дисциплинированные команды редко переходят 0.85 FTE в годовом измерении.
K не константа. Один числовой «overhead 30%», накатанный на каждую команду в бюджете, скрывает помесячные колебания от 0.30 до 0.55, вызванные кластерами праздников, отпускными ямами и admin-зарплатой, размазанной на меньшее количество биллабельных часов. Это разбирали в Overhead Coefficient: The Hidden Tax Per Developer. Если бюджет планирует K = 0.30, а организация фактически работает на K = 0.37, это 23% промаха по трети общей стоимости — и это всегда вылезает в Q3.
Лекарство — не добавлять буфер к top-down цифре. Лекарство — собирать бюджет так же, как формируется реальная стоимость: по инженеру, по месяцу, с реальной утилизацией и реальным overhead. Это и есть bottom-up.
Стадии bottom-up
Шесть стадий. Каждая стоит на предыдущей, и математика скучно-механическая — это и есть смысл. Скучно-механический бюджет — это бюджет, который выдержит вопросы скептичного CFO.
Ставка (loaded $/час или $/мес)
× Утилизация (FTE 0.0–1.0)
× Рабочие часы/год (после праздников)
= Годовая стоимость инженера
Сумма по команде → годовой direct cost команды
Сумма по командам → годовой direct cost организации
× (1 + K) → годовой loaded cost
+ Резервы на найм → операционный бюджет
+ Tools / infra → итоговый R&D бюджет
Первая стадия — loaded rate — это фундамент. Разобрана в Loaded Hourly Rate: Why Your Engineer Costs 50% More Than Their Salary. Если проскочить её прикидкой «зарплата × 1.3», вся вышестоящая конструкция унаследует ошибку. Точность всего подхода равна точности входной ставки.
Сборка бюджета. Каждая стадия механическая; допущения сидят во входах, не в формулах.
Стадия 1: ставка × утилизация × часы по ролям
Помодельный build-up для организации на 50 инженеров с четырьмя функциями, годовая стоимость на инженера:
| Роль | Loaded ставка | Утилизация (FTE) | Продуктивных часов/год | Годовая стоимость |
|---|---|---|---|---|
| Backend инженер | $7,500/мес | 0.82 | 1,574 | $73,800 |
| Frontend инженер | $6,800/мес | 0.80 | 1,536 | $65,280 |
| QA инженер | $5,500/мес | 0.78 | 1,498 | $51,480 |
| Platform / DevOps | $9,000/мес | 0.85 | 1,632 | $91,800 |
| Engineering manager | $11,000/мес | 0.70 (75% admin) | 1,344 | $92,400 |
Цифры утилизации — из телеметрии. Эндпоинт POST /departments/{id}/finance/employees в PanDev Metrics возвращает годовую стоимость на инженера с уже применённой утилизацией — он подтягивает heartbeat-данные из IDE-плагинов, считает coding hours по месяцу, делит на оплачиваемые часы и выдаёт FTE, не зависящий от чьих-либо самоотчётов. Для ролей, где код — не основной выход (менеджеры, principal-инженеры, треть недели сидящие в design review), мы переопределяем утилизацию через ролевую конфигурацию, не через измеренное coding time. Правило простое: измеряем для строителей, декларируем для менеджеров, никогда не предполагаем 100%.
Перемножьте ставку на утилизацию и часы — получите построчные годовые цифры. Организация из примера тратит $4.50M прямого labor cost в год: 20 backend по $73.8K = $1.476M, 15 frontend по $65.28K = $0.979M, 10 QA по $51.48K = $0.515M, 5 platform по $91.8K = $0.459M, 5 EM по $92.4K = $0.462M. Округляем до $4.5M в свод бюджета; реконсилируем в variance review.
Стадия 2: агрегация в команду и в организацию
Свод по команде — сумма по инженерам. Свод по организации — сумма по командам. Никакой математики тут нет, только структура. Структура и есть смысл.
Эндпоинт POST /finance/summary в PanDev Metrics возвращает 30-дневную стоимость организации с разбивкой по департаментам. Прогоните его на прошлый фискальный год помесячно — получите 12 точек данных на департамент за год, скользящий baseline для валидации bottom-up сборки. Если арифметика «инженер × утилизация» утверждает, что backend стоит $1.476M в год, а /finance/summary за прошлый год показывает $1.612M — этот разрыв и есть свидетельство, что либо loaded rate занижена, либо утилизация переоценена. Используем разрыв как петлю калибровки, не как противоречие.
Year Dropdown в /dashboard/finances — практичный UI для этого. Он позволяет проиграть форму помесячной стоимости любого предыдущего года и наложить bottom-up прогноз поверх до того, как бюджет залочат. Без этого шага валидации, как мы выяснили на собственном опыте, bottom-up превращается в более сложную догадку.
Стадия 3: K помесячно, не плоско
Накладываем overhead помесячно, не одним годовым числом. K колеблется от 0.30 в феврале (steady state) до 0.55 в июле-августе, когда отпуска утончают продуктивный знаменатель, а admin-зарплата идёт ровной линией. Плоский K = 0.37 на год переоценил бы февраль и недооценил бы август — выровнялся бы только при идентичной форме календаря из года в год, что обычно не так.
Для нашей организации прямой labor cost $4.50M × годовой взвешенный K 0.37 даёт overhead $1.665M, округляем до $1.65M. В отчёт совету директоров overhead идёт одной строкой, но сборка под ней — двенадцать. Variance review в конце каждого квартала сравнивает плановое-K-по-месяцам с фактическим-K-по-месяцам. Это и есть сравнение, которое ловит 12% перерасход на шестой неделе, а не на тридцать шестой.
Стадия 4: резервы и инструменты
Две статьи, которые top-down бюджеты регулярно сворачивают в overhead и забывают:
Резервы на найм. Если план — добавить пять инженеров за год, стоимость не равна пять × годовая ставка. Это частично-годовая стоимость каждого найма (зависит от месяца старта) плюс единоразовая стоимость рекрутинга (агентский fee, sign-on, релокейшн, оборудование, лицензии, security review). Бенчмарк Deloitte: $15-25K единоразово на инженера, плюс 30-50% годового loaded cost на частично-годовую зарплату. Для пяти запланированных найма с разбросом по году $300K — обороноспособный резерв.
Инструменты и инфраструктура. AWS / GCP, GitHub seats, Jira, observability, лицензии IDE, AI-ассистенты для кода, security сканеры, мониторинг. Для 50-инженерной организации $200K/год — консервативно; $400K/год — нормально на масштабе. Держим отдельной строкой, потому что растёт с headcount, но по другому наклону (часть per-seat, часть per-environment, часть — флаговая ставка со ступеньками на порогах).
Два бюджета, бок о бок
Та же организация, тот же фискальный год, два метода — разные числа.
| Статья | Top-down ($5.4M + 10%) | Bottom-up | Где прячется разница |
|---|---|---|---|
| Прямой labor | $4.20M | $4.50M | Реальные loaded rates, реальная по-ролевая утилизация |
| Overhead | $1.26M (плоско 30%) | $1.65M (K = 0.37, помесячно) | K не равен 0.30 ни в одной измеренной нами организации |
| Резервы на найм | $0 (свёрнуты) | $0.30M | Частично-годовые + единоразовые расходы невидимы в top-down |
| Tools / infra | $0.48M | $0.20M | Top-down обычно завышает: инфра растёт медленнее headcount |
| Итого | $5.94M | $6.65M | +$710K, ~12% |
Bottom-up на $710K выше, и разрыв сосредоточен в двух статьях: реальный overhead K выше 30%, а частично-годовые расходы на найм вообще не появляются в top-down. С допущениями совет директоров может спорить — это feature. С числом, которое выпало из «прошлый год + 10%», спорить не о чем — внутри ничего нет, чтобы ткнуть.
Контртезис, который я готов защищать: bottom-up бюджет в здоровой организации обязан выходить выше top-down. Если ваш bottom-up ниже top-down — вы скорее всего моделируете утилизацию на 100% или K = 0.20, и Q3 это всё равно вскроет, только без времени на коррекцию.
Где это ломается: новые организации без baseline
Bottom-up бюджетирование работает, когда есть хотя бы шесть месяцев телеметрии для калибровки утилизации и K. У новых организаций и свежепересобранных команд этого нет. Им приходится допускать: утилизация ≈ 0.78 для строителей и 0.70 для менеджеров — разумная стартовая точка, K ≈ 0.35 для маленькой команды и ≈ 0.42 для большой — оборонимо. Затем пересобрать бюджет после Q1 нового фискального года, заменив допущения первыми тремя месяцами реальной телеметрии. Q1-калибровка ловит большую часть шума, который иначе накопится к Q3.
Year Dropdown в PanDev Metrics помогает и здесь — даже в новой организации, если есть доступ к помесячным данным сравнимого предыдущего года (другая команда, та же функция в прошлой компании, индустриальный бенчмарк от McKinsey или Gartner), можно прогнать bottom-up против них как sanity check. Грубо, но грубо лучше плоских 30%, которые нечем защитить.
Что выдержит аудит
Финансовые команды собирают бюджет bottom-up потому, что каждая строка обороноспособна перед CFO, который спрашивает «откуда это число?». Loaded rate — из payroll плюс K. K — из помесячной телеметрии по департаментам. Утилизация — из coding time IDE, делённого на оплачиваемые часы. Резерв на найм — из расписания по головам со стартовыми датами. Tools — из контрактов и числа seats.
У top-down один аргумент защиты: «прошлый год плюс инфляция». В переговорной он работает примерно девяносто дней. После — каждый разговор о variance крутится вокруг «ну, мы предположили, что всё масштабируется линейно», и финансы теряют рычаг давить на инженерию, когда инженерия фактически идёт на 12% горячее плана.
Тест на выживаемость в аудите простой: возьмите наугад любую строку бюджета и спросите, можете ли вы назвать входы, из которых она получилась. Если ответ — «взяли прошлый год и добавили процент», эта строка ревью не пройдёт. Если ответ — цепочка ставка × утилизация × часы × K × форма календаря, она выдержит.
Связанный долларовый учёт по конкретным фичам — в Cost per Feature: The SQL Formula That Actually Reconciles. Ролевой взгляд на те же числа — в CFO's Guide to Engineering Metrics и Engineering ROI: Calculating Real Return on Code. Параллельный текст про ту же повестку с дата-стороны — IT Budgeting With Data.
В следующий раз, когда кто-то в финансах скажет «потратим $X на инженерию в этом году» — спросите, из какой строки build-up вышло это число. Если ткнуть не во что — у вас не бюджет. У вас догадка в одежде бюджета.