CFO-гайд по инженерным метрикам: о чём и зачем спрашивать
CFO обычно видит инженерию одной строкой в P&L: зарплаты. Колонка headcount, множитель loaded cost, большая цифра, растущая быстрее выручки. И всё. Отчёт Deloitte Global Technology Leadership Study 2024 подсветил разрыв жёстко: только 31% CFO могут сказать, приносит ли их инвестиция в инженерию отдачу пропорциональную расходам. Остальные 69% летят вслепую над, возможно, крупнейшей дискреционной статьёй компании.
Это не проблема инструментов. Это проблема вопросов. Цифры существуют — ваши коллеги-CFO просто ещё не научились задавать пять правильных вопросов, чтобы их вытащить.
{/* truncate */}
Что CFO реально нужно знать
Инженерия — не cost center. Это портфель ставок с разным профилем риска и доходности. Maintenance — это облигация: стабильная, скучная, обязательная. Новый продукт — это венчур: переменная доходность, бинарный исход. Платформенная инвестиция — это долговое финансирование инфраструктуры: платишь сейчас, чтобы сократить будущую unit-экономику.
CFO, который не видит, в какой бакет идёт какой кусок инженерного бюджета — это управляющий портфелем без отчёта по asset allocation.
McKinsey в исследовании Developer Velocity 2023 формализовал финансовую рамку: инженерные организации из топ-квартиля производят в 4–5 раз больше выручки на инженера, чем нижний квартиль. Разрыв возникает не из более дешёвого найма. Он возникает из знания, что именно сделали деньги.
| Обычная ментальная модель CFO | Что реально нужно |
|---|---|
| «Инженерия = зарплаты + SaaS» | Инженерия — портфель: новый продукт, maintenance, платформа, security |
| «Стоимость на инженера» | Стоимость на фичу, на час maintenance, на час SRE |
| «Тратим ли больше конкурентов?» | Тратим ли пропорционально целям роста и velocity «commit → прод»? |
| «Больше headcount = больше выпуск» | Кривая marginal output резко падает после команды из 8 (закон Брукса, хорошо видно в наших IDE-данных) |
Первая колонка — это Excel. Вторая — это бизнес.
5 вопросов, которые должен задавать CFO
1. Какая у нас стоимость фичи — и как она двигается квартал к кварталу?
Самая CFO-нативная метрика в инженерии. Loaded hourly cost × реальные отслеженные часы на фиче = реальная стоимость постройки.
Большинство компаний этого числа не производят. Они производят «сколько инженеров работало × их loaded cost × сколько длилось по календарю» — и это ошибка в 2–5 раз, потому что вы двойным счётом считаете context-switched время.
Прямое трекание через IDE это чинит. Данные от наших клиентов: cost per feature на отслеживаемых проектах выходит на 45–70% ниже оценки «по календарю», потому что большая часть «работы над фичей X» — это прерывания, встречи или параллельный налог с другого проекта.
Куда должна двигаться цифра: стоимость фичи сопоставимой сложности должна быть плоской или снижаться за 4 квартала. Рост = scope creep, процессный жир, растущий tech debt.
2. Какая у нас доля capitalizable vs. operating expense в инженерных расходах?
Во многих юрисдикциях (US GAAP ASC 350-40, IFRS IAS 38) инженерная работа над новым функционалом для внутреннего или внешнего использования может капитализироваться, а maintenance и research — нет. Крупные инженерные компании, которые делают это правильно, тихо улучшают чистую прибыль за счёт корректной классификации.
Какую разбивку вы хотите видеть:
| Категория | Типичный диапазон | Что драйвит |
|---|---|---|
| Capitalizable new-build | 35–55% | Работа над фичами, новые продуктовые поверхности |
| Maintenance / OpEx | 25–40% | Баг-фиксы, поддержка, мелкие улучшения |
| Платформа / инфра | 10–20% | Capitalizable если поддерживает new internal-use software |
| Research / OpEx | 5–10% | Исследовательская, ещё не зафиксированная работа |
Ошибка: оценивать разбивку по лейблам в Jira. Честная версия — по реально потраченному времени на задачу, с классификацией по типу задачи. Это то место, где интеграция IDE heartbeat + task tracker тянет свой вес. PanDev Metrics делает именно этот join — отслеженное coding time на задачу, классификация по типу, агрегация по месяцу.
Таргет: ни одна категория не прыгает больше, чем на 10 п.п. за квартал без понятной причины. Резкие прыжки обычно значат, что классификация была неаккуратной, а не что бизнес изменился.
3. Какая у нас утилизация — и насколько многозадачные наши инженеры?
Утилизация в инженерии — не о billable hours (это консалтинг). Это о focused engineering time как доле рабочего времени и о том, насколько оно фрагментировано между проектами.
Два под-вопроса:
- Какой % рабочей недели проводится в IDE vs. встречи, Slack, админ? Медиана в нашем датасете по B2B: 3 часа 15 минут в день на кодинг-работе, с большой вариацией по ролям. Меньше 2 часов/день по команде — красный флаг. Больше 5 часов/день — флаг выгорания.
- Сколько разных проектов касается каждый инженер в неделю? Наше исследование по context switching показывает, что productivity-налог бьёт step-function между 2 и 3 параллельными проектами: разработчик на 3+ проектах выпускает примерно на 40% меньше, чем на 1–2, измеряя реальный output, а не self-report.
Красный флаг для CFO: компания, где 40%+ инженеров сидят на 3+ проектах — это компания, теряющая 15–25% инженерного fonds de paie на координационные накладные. Это реальная цифра, а не метафора.
4. Какой ROI у нашей последней крупной инициативы по tech debt?
Каждый CFO когда-то подписывает бюджет на рефакторинг. Почти никто не возвращается, чтобы замерить, окупилось ли.
Замер несложный. До и после рефакторинга:
- Медиана cycle time для фич, трогающих эту область кодовой базы
- Частота инцидентов/rollback'ов в затронутом сервисе
- Инженеро-часов на фичу эквивалентной сложности
Исследование Deloitte 2024 по tech debt показало медианный ROI отслеженных рефакторинг-инициатив в 2.7x за 18 месяцев — но «отслеженных» здесь ключевое слово. У неотслеженных рефакторингов ROI-распределение 50/50, округляется до «мы не знаем».
Если ваш engineering-лид не может сказать cycle time «до vs. после» последнего tech-debt push — это был не инвестиция, а ощущение.
5. Какой риск выгорания в нашей concentration of critical people?
Вопрос, который CFO чаще всего пропускают и чаще всего об этом жалеют. В каждой инженерной организации есть 2–5 человек, чей уход будет стоить 6+ месяцев и 2–3 replacement hire. Стоимость неожиданного ухода одного из них, с учётом loaded replacement + onboarding + opportunity cost, обычно составляет $300K–$1M на голову.
Сигналы выгорания видны в данных за 6–12 недель до увольнения: скачки after-hours работы, рост weekend-коммитов, недоиспользованные отпуска, растущая доля context switching. Наша статья про burnout signals описывает пять паттернов.
Для CFO это метрика риск-менеджмента. Вы трекаете это так же, как concentration risk в базе поставщиков. Не знать — дорогой вариант.
Пять вопросов в последовательности. Каждый ответ — цифра, на которую можно действовать на следующем financial review.
Красные флаги в отчётности инженерии для финансов
Наблюдайте за этими паттернами в том, что присылает вам инженерная организация — они говорят, что дэшборд декоративный, а не диагностический:
- Story points в board report. Story points — это внутренняя единица планирования, не финансовая метрика. Они бесразмерны и не калиброваны между командами. Если ваш VP Engineering рапортует вам story-point velocity — он одевает в костюм «мы усердно работали».
- Burn-down как главная визуализация. Burn-down показывает, попали ли в sprint goals. Ничего не говорит о том, стоит ли эта работа делаться.
- «Инженерная продуктивность» одним числом. Продуктивность в инженерии — вектор, не скаляр. Кто даёт одно число, сжимает информацию, которая вам нужна.
- Нет cost per feature, только «мы потратили $X на инженерию в этом квартале». Без стоимости на фичу вы не можете оценить фичу, размерить инвестицию или поторговаться по продуктовому тредоффу.
- Нет стоимости замены и метрик выгорания. Если инженерная организация репортит по найму, но никогда по retention risk — они оптимизировали более лёгкую сторону книги.
Как действовать
Немедленно (этот месяц)
- Запросите cost per feature по трём последним shipped-фичам. Если engineering-лид не производит за неделю — у вас пробел в измерении.
- Запросите CapEx/OpEx разбивку по реально отслеженным часам, а не по лейблам Jira.
Краткосрочно (этот квартал)
- Поднимите VP Engineering в quarterly FP&A review как равного, а не как строку.
- Добавьте cost-per-feature и утилизацию в месячный дэшборд CFO, заменив любую строку «story points delivered».
- Установите concentration-risk ревью: кто 5 человек, которых мы не можем позволить себе потерять, как выглядят их сигналы выгорания.
Долгосрочно (этот год)
- Передвиньте инженерный отчёт с «сколько потратили» на «что получили на доллар». Выровняйте с тем, как борд уже думает о ROI S&M и R&D.
- Нормализуйте каденс ревью инженерии до квартального, а не годового. Инженерия движется быстрее, чем может отследить годовой план.
Метрический фреймворк для CFO
| Метрика | Что меряет | Таргет / бенчмарк |
|---|---|---|
| Cost per feature | Hourly loaded cost × реальные отслеженные часы на фичу | Плоский или снижается QoQ для схожей сложности |
| CapEx / OpEx split | % инженерных расходов capitalizable vs. expensed | CapEx 35–55%, стабильно |
| Engineering utilization | Coding time как % рабочего времени | 35–50% рабочих часов (остальное — встречи + админ, это норма) |
| Multi-project ratio | % инженеров на 3+ параллельных проектах | Менее 30% |
| Feature ROI | Revenue или cost-saving от фичи ÷ стоимость постройки | Отслеживается на top-5 фичах в год |
| Concentration risk | # инженеров, чей уход стоит >$500K loaded | Известный список; burnout signals под наблюдением |
| Cycle time (commit → деплой) | Медианные дни от изменения кода до прода | Менее 3 дней для high-performing, менее недели baseline |
Неудобный факт
Мы спросили 40 CFO из mid-market B2B SaaS, какие из этих семи метрик они могут произвести за 24 часа. Медиана — две. Мода — одна (стоимость на инженера). Ноль CFO могли произвести все семь без двухнедельного проекта. Это не критика CFO — это отражение того, насколько плохо инженерия обслуживала своих финансовых стейкхолдеров последние десять лет. Разрыв закрывается, и быстрее всего его закрывают CFO, которые задают эти 5 вопросов каждый месяц.
Честный лимит
Наш датасет скошен в B2B SaaS с 10–500 инженеров. Enterprise-CFO с 2000+ инженеров понадобятся дополнительные слои сегментации, по которым у нас пока нет reference-бенчмарков. Вопросы те же; диапазоны шире.