Engineering ROI: 5 методов, которые переживут совет
VP инжиниринга защищает на совете директоров миграцию на микросервисы за $1.2M. Прогноз ROI: «экономим 30% на инфре, релизим в 2 раза быстрее». CFO задаёт один вопрос: «Покажите математику». В ответ — единственное число 240% и никакого метода за ним. Совет говорит нет. Через два квартала конкурент закрывает ту же миграцию за восемь месяцев и начинает выигрывать enterprise-сделки на латентности. Проект был хороший. Проблема — в математике.
Никакой единой «формулы Engineering ROI» не существует. Есть пять разных методов расчёта, каждый собран под свой вопрос. Исследование McKinsey Developer Velocity Index показало, что команды верхнего квартиля генерируют в 4–5 раз больше выручки на разработчика, чем команды нижнего. Но это соотношение ничего не значит без указания, как вы это измерили. Возьмёте не тот метод под вопрос, потеряете защитимый проект. В статье разобраны все пять, с реальными цифрами.
{/* truncate */}
Почему слово «ROI» само по себе бесполезно
Когда CTO пишет на слайде ROI = 4.8x, CFO мысленно вставляет вопрос: 4.8x от чего, на каком горизонте, против какой ставки дисконтирования? Если слайд не отвечает, число воспринимают как маркетинг. Базовый фреймворк мы разобрали в Engineering Team ROI: How to Calculate and Present to Business. Эта статья — следующий слой: пять методов и под какой вопрос работает каждый.
Методы сортируются по тому, что у них получается лучше всего:
- Инвестиция в инструмент? → Payback period.
- Платформенная ставка на несколько лет? → NPV.
- B2B SaaS-фича для enterprise-клиентов? → ARR attribution.
- Приоритизация роадмапа? → ROI на cost-per-feature.
- DevEx / апгрейд пайплайна? → DORA-improvement ROI.
Совет директоров режет правильно посчитанные цифры, когда их преподнесли в неправильной рамке. И одобряет более слабые проекты с лучшим оформлением. Планка не в точности. Планка — в защитимости.
5 методов в одной таблице
| Метод | Формула | Когда использовать | Когда врёт |
|---|---|---|---|
| Payback period | Инвестиция ÷ годовая экономия | Tooling, CI/CD, внутренний DevEx | Игнорирует всё после окупаемости; награждает короткий горизонт |
| NPV | Σ (cash flow / (1+r)^t) − инвестиция | Долгий горизонт, платформа / миграция | Ставка r — суждение CFO; NPV резко плывёт от неё |
| ARR attribution | Новый ARR ÷ стоимость фичи | B2B SaaS-фича для enterprise-уровня | Атрибуция продаж — мутная; сделки закрываются по куче причин |
| Cost-per-feature ROI | Прирост выручки ÷ cost-per-feature | Приоритизация, post-launch ревью | Нужен честный cost-per-feature; usage→revenue — модель |
| DORA-improvement ROI | $ значение DORA-дельты ÷ инвестиция | DevEx, пайплайн, платформенные апгрейды | «Lead time −5 дней» в доллары — это модель |
Метод 5 пропускают чаще всего, потому что он требует связать cost-per-feature с метриками delivery. Большинство инструментов engineering finance и DORA-инструменты — это разные продукты. PanDev Metrics держит и то, и другое в одном дашборде, поэтому связка запрашивается. Подробнее в методе 5.
Метод 1 — Payback period
Самый простой. Сколько месяцев до того, как экономия отобьёт изначальную инвестицию.
Пример: внутренний апгрейд CI/CD.
- Инвестиция: $80,000 (консалтинг + 2 внутренних инженера × 6 недель).
- Экономия: 2 ч/разработчик/неделя на медленных билдах × 50 разработчиков × loaded rate $46/ч × 50 рабочих недель/год = $230,000/год.
- Годовая экономия: $230K. В месяц: ~$19.2K.
- Payback: $80K ÷ $19.2K ≈ 4.2 месяца.
Когда метод выигрывает: решения по инструментам, где апсайд — «экономия начинается сразу». Совет директоров понимает месяцы. 4 месяца окупаемости на dev-tooling редко не одобряют.
Когда метод врёт: 10-летний и 9-летний поток экономии в момент 4 месяцев выглядят одинаково. Payback игнорирует всё после точки безубыточности. Не используйте его для платформенных миграций.
Расчёт экономии опирается на знание loaded hourly rate. Математику разобрали в Loaded Hourly Rate: What Each Engineer Actually Costs. Без этого ваши «$46/ч» — это фантазия.
Метод 2 — NPV (Net Present Value)
Для многолетних ставок, где денежные потоки во времени важны, а ставка дисконтирования — главная переменная.
Пример: миграция на микросервисы.
- Инвестиция: $1,200,000, размазано на 18 месяцев.
- Годовая экономия (годы 2–6): $400,000/год (снижение инфры + ускорение delivery).
- Ставка дисконтирования: 12% (типичная для B2B SaaS на стадии роста; решение CFO).
- Расчёт:
Year 0–1.5: −$1,200K (сумма инвестиций, сведена к year 0)
Year 2: $400K / (1.12)^2 = $319K
Year 3: $400K / (1.12)^3 = $285K
Year 4: $400K / (1.12)^4 = $254K
Year 5: $400K / (1.12)^5 = $227K
Year 6: $400K / (1.12)^6 = $203K
NPV ≈ $1,288K − $1,200K ≈ +$88K
Небольшой положительный NPV. Теперь тот же расчёт с r = 8% (ниже ставка, например, зрелая компания) — и NPV прыгает примерно до +$240K. Тот же проект, две ставки, две истории. Поэтому CFO часами спорят про discount rate.
Когда метод выигрывает: длинногоризонтные платформенные проекты, всё с потоками за горизонт 3 лет. Совет ждёт NPV для решений капитального уровня.
Когда метод врёт: ставка дисконтирования — это суждение, оформленное под математику. 12% против 8% могут перевернуть знак. Всегда показывайте таблицу чувствительности.
Метод 3 — ARR attribution
Для фич B2B SaaS, где вопрос — «эта фича разблокировала сделку?»
Пример: SSO/SAML для enterprise-уровня.
- Стоимость разработки: $100,000 (4 инженера × 6 недель loaded).
- Результат: 3 enterprise-проспекта, у которых SSO был требованием закупки, подписали. Средний ACV: $160,000.
- Новый ARR: $480,000.
- ROI: $480K / $100K = 4.8x.
Когда метод выигрывает: фичи, которые гейтят enterprise-закупки (SSO, audit logs, контроли SOC 2, on-prem deployment, RBAC). Sales может назвать сделки. CRM хранит таймстемпы.
Когда метод врёт, и это самый большой caveat во всей статье: атрибуция продаж мутная. SSO закрыло сделку, или отношения закрыли, а SSO лишь разблокировало юристов? Atlassian в плейбуке по engineering ROI отмечает, что в B2B-продажах атрибуция редко сходится в одну причину. Честная версия слайда: «Три сделки указали SSO как требование закупки; общий ARR $480K. Без SSO у двух из трёх сделок был >50% шанс уйти к конкуренту по фидбеку RFP». Это защитимые 4.8x. Голые 4.8x без caveat — слайд, который CFO разберёт за 30 секунд.
Метод 4 — Cost-per-feature ROI
Для приоритизации роадмапа и post-launch ретро. Требует, чтобы вы реально знали, во что обошлась каждая фича.
Пример: фича workflow-автоматизации.
- Cost-per-feature (рассчитано из IDE-телеметрии × loaded rate × overhead K): $32,000.
- Результат: рост активного использования модуля workflows на 18% → атрибутируемый рост выручки через expansion ARR: $145,000 за 6 месяцев после релиза.
- ROI: $145K / $32K = 4.5x.
Когда метод выигрывает: post-launch ревью («какие фичи прошлого квартала реально окупились?») и споры о приоритизации («Фича A прогноз 6x, Фича B прогноз 1.8x — начинаем с A»).
Когда метод врёт: cost-сторона корректна, только если математика cost-per-feature корректна. SQL разобрали в Cost per Feature: The SQL Formula That Actually Works. Сторона выручки мутнее — usage → expansion ARR — это модель, а не измерение.
Это и метод, наиболее близкий к тому, что измеряет PanDev Metrics. Endpoint POST /finance/top-expenses отдаёт стоимость по фичам из IDE-телеметрии, а дашборд фич джойнит эти cost'ы с тегами таск-трекера. Временное измерение мы покрыли в Cost of Delay: What Each Week of Slipping a Feature Actually Costs — когда CoD высокий, даже фича с 1.5x ROI может побить фичу с 5x ROI и низким CoD.
Метод 5 — DORA-improvement ROI
Самый недоиспользуемый метод, потому что требует связать cost-данные с метриками delivery. Большинство команд держит их в разных инструментах.
Пример: апгрейд PR-пайплайна.
- Инвестиция: $250,000 (платформенные инженеры × 3 месяца + tooling).
- DORA-результат: lead time for changes падает с 9 дней медиана до 4 дней. Deployment frequency растёт в 1.6x. Change failure rate стоит на месте (хорошо — мы не разменяли качество на скорость).
- Перевод в доллары: 5 дней экономии на изменение × ~150 изменений/квартал × $46/ч loaded × ~3 ч/изменение времени ожидания = ~$103K/квартал только от возвращённого wait time. Плюс ценность ускоренного фидбека от клиентов (продакт оценил в $50K/квартал на time-sensitive фичах) — годовой апсайд $612K/год.
- ROI: $612K / $250K = 2.48x в первый год, далее экономия продолжается.
Когда метод выигрывает: любая инвестиция в DevEx, защита бюджета platform-команды, build/test/deploy-инфраструктура. Отчёт DORA State of DevOps 2024 года раз за разом показывает, что elite-команды релизят за часы там, где low-перформеры — за недели — у этой дельты есть долларовое значение, и DORA-improvement ROI его ловит.
Когда метод врёт: шаг перевода в доллары — это модель. «Сэкономленный lead time → доллары» опирается на допущения о том, куда команда тратит сэкономленное время. Если оно уходит в дополнительные митинги, ROI = 0. Определения метрик мы разобрали в DORA Metrics: The Complete Guide for Engineering Leaders.
PanDev Metrics, насколько мы видим, единственная платформа, которая держит cost-per-feature в одной плоскости запроса с метриками DORA. Большинство инструментов engineering finance (cost) и DORA (delivery) — отдельные продукты. Для метода 5 интеграция важна напрямую — на вопрос «сколько мы потратили на апгрейд пайплайна и сколько улучшение lead time экономит нам в квартал» можно ответить в одном дашборде, а не выгружая CSV и джойня в Excel.
5 методов на одном гипотетическом пуле проектов
Если у CTO бюджет $250K и оцениваются пять кандидатов — по одному на метод — вот что увидит совет:
Тот же долларовый вход, пять методов, пять разных форм ROI. Выбор метода меняет порядок приоритизации.
| # | Проект | Метод | Стоимость | Ценность | ROI / payback |
|---|---|---|---|---|---|
| 1 | Апгрейд CI/CD | Payback period | $80K | $230K/год | 4.2 месяца payback |
| 2 | Миграция на микросервисы | NPV (8% rate) | $1.2M | $400K/год × 5 лет | +$240K NPV |
| 3 | SSO / SAML фича | ARR attribution | $100K | $480K новый ARR | 4.8x ROI |
| 4 | Workflow-automation фича | Cost-per-feature | $32K | $145K expansion | 4.5x ROI |
| 5 | Апгрейд PR-пайплайна | DORA-improvement | $250K | $612K/год | 2.48x ROI год 1 |
Заметьте: самый низкий ROI в таблице (NPV $240K на $1.2M ≈ 1.2x) — это и самая большая абсолютная сумма. Совет, оптимизирующий по соотношению, режет миграцию. Совет, оптимизирующий по абсолюту, одобряет. Поэтому выбор метода важен.
Частые ошибки, которые валят защиту в совете
1. Подавать одно число как «тот самый» ROI. Одно число приглашает атаку. Два метода на один проект (например, payback и NPV для tooling) триангулируют и нейтрализуют возражение «а как у вас с discount rate?»
2. Прятать ставку дисконтирования. Для NPV всегда показывайте таблицу чувствительности на 8%, 12%, 15%. CFO сам пересчитает. Опередите.
3. ARR attribution без подписи руководителя продаж. Если глава продаж не согласился, что фича X гейтила те три сделки — число выдумка. Получите подтверждение по почте до того, как слайд уйдёт в колоду.
4. Игнорировать временной компонент. 5x ROI на горизонте 5 лет — не то же самое, что 5x за 6 месяцев. Всегда указывайте окно.
5. Не указывать baseline «ничего не делать». В каждом расчёте ROI скрыто сравнение: ROI vs что? Иногда альтернатива — «ничего не делать» (так и пишите). Иногда — «следующий лучший проект» (тогда показывайте сравнение). Совет наказывает невидимые baselines.
Честный лимит
Все пять методов требуют защитимых вводных. ARR attribution особенно шаткий — атрибуция продаж реально мутная, и 4.8x в примере выше — это верхняя граница, а не измерение. Ставка дисконтирования NPV — суждение. Payback игнорирует всё после точки окупаемости. Сторона выручки в cost-per-feature ROI — модель, а не измерение. В DORA-improvement ROI шаг перевода в доллары — модель поверх модели.
Ни один из методов не «объективен». Берите два метода на один проект и триангулируйте. Никогда не подавайте одно число так, будто оно тот самый ROI. CTO, которые проигрывают защиту в совете, чаще ошибались не в проекте — они были слишком точны в математике. Диапазон («4.2x–5.5x в зависимости от модели атрибуции») переживает разбор там, где «4.8x» — нет.
Что сделать в этом квартале
Возьмите следующий запрос на бюджет, который вам надо защищать. Прогоните по двум методам. Если оба согласны, что проект стоит делать — у вас защитимый слайд. Если расходятся — вы нашли допущение, которое реально несущее, и именно этот разговор совет хочет вести.
Если вы CTO, которому достался квартальный бюджет без данных по cost-per-feature — начинайте с этого. Без cost-per-feature методы 4 и 5 недоступны, и вы остаётесь с тремя самыми слабыми. CFO's Guide to Engineering Metrics разбирает, как настроить разговор финансов с delivery — это предусловие для всей этой математики.