17 записей с тегом "finance"

Фича опаздывает на две недели. Продакт-менеджер пожимает плечами: «Всё равно тот же квартал». Tech lead кивает. CFO не узнаёт. Две недели превращаются в шесть. К этому моменту enterprise-клиент, которому фича была нужна под цикл закупок, подписывает с конкурентом. Реальная цена этой задержки для бизнеса — около $192 000, и ни один из этих долларов не появится в инженерных отчётах.

Cost of Delay (CoD) — самая обсуждаемая и самая неподсчитываемая концепция в современной разработке продукта. Дон Райнертсен заложил математику в The Principles of Product Development Flow (2009, глава 2), а SAFe оформил её в WSJF (Weighted Shortest Job First). Исследование McKinsey Developer Velocity 2023 показало, что лидеры B2B SaaS выпускают фичи в 4–5 раз быстрее аутсайдеров и непропорционально больше pipeline ARR на инженера. Но спросите у 10 PM сколько им стоила последняя задержанная фича — 9 ответят «не знаю». Математика достижима. Просто никто её не считает.

Спринт 47, команда из 8 человек. Стандартный нарратив ретро звучал бы так: «velocity упал на 20%, было много багов, в следующем спринте поприоритезируем лучше». Тот же вайб, что и в спринте 46. И в спринте 45. Теперь добавьте на то же ретро один показатель: общая стоимость спринта — $32 800, из них $11 600 (35%) ушли на тикеты с багами, против $14 200 (43%) на фичи. Скользящее среднее по багам у этой команды — 18%. Одна строка — «мы потратили на баги вдвое больше обычного» — переключила команду с «сделаем лучше» на «первые три дня спринта 48 — только bug-prevention, без исключений».

Этот пост показывает, как встроить один финансовый показатель в 30-минутное ретро так, чтобы оно производило решения, а не ощущения.

Staff-инженер задаёт аналитику простой вопрос: «Сколько на самом деле стоила фича SSO?» Через сорок минут аналитик возвращается с числом. Оно ошибается на 35%. Не потому что аналитик плохой, а потому что SQL SUM(hours) × $50 потерял ветвление по rate type, не учёл месячный K-коэффициент и обработал контрактника на месячном инвойсе так же, как штатного сотрудника. McKinsey Developer Velocity Index (2023) ставит типичный engineering overhead в 30–55% от ФОТ; если ваш cost-per-feature запрос не умножает на это, вы живёте на неправильной половине этих чисел. Лекарство — настоящий PostgreSQL-запрос со всеми тремя слоями. Эта статья — про этот запрос.

В инженерной организации на 50 человек, которую мы инструментировали в феврале 2026 года, месячный overhead-коэффициент составил K = 0.37. То есть на каждый $1 прямой разработческой работы приходилось 37 центов косвенных расходов: митинги, code review, ramp-up и доля зарплаты CTO/EM/DevOps, размазанная по команде. CFO три года использовал плоский коэффициент 30% для loaded cost. Реальное число было на 23% выше, и почти никто в компании об этом не знал.

Главная проблема была не в самом разрыве. Главная проблема: 30% — это один бакет, и даже после того, как разрыв обнаружен, внутри ничего нельзя оптимизировать. Отчёт Boston Consulting Group 2024 года про распределение G&A в софтверных компаниях фиксирует ту же картину на масштабе индустрии: компании, которые показывают overhead одной строкой, не могут его сократить, а компании, которые декомпозируют его на три компоненты, режут его на 8–15% за два квартала.

Финансовый лид команды из 12 разработчиков открывает дашборд расходов. Общий burn за месяц: $58 000. Четверо в штате на месячном окладе, пятеро контракторов на почасовой ставке, ещё трое работают через вендора с месячным инвойсом. Дашборд показывает одно среднее значение стоимости разработчика. Это неверная цифра, и каждое решение по cost-per-feature, построенное на ней, тоже неверное.

Стандартное решение — конвертация 160 часов: делим месячную ставку на 160, получаем «эквивалентную часовую» и сравниваем. По данным US Bureau of Labor Statistics, средний работник реально отрабатывает 1 791 час в год. Это 149 часов в месяц, не 160. В Казахстане 24 рабочих дня отпуска плюс 13 праздничных дней дают эффективную цифру ближе к 144 часам. 160 — это наследие, которое уже не соответствует данным даже в стране-источнике.

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) даёт примерно тот же диапазон. Большинство компаний этот множитель просто не применяют. Они квотят, скоупят и бюджетируют по «голой» цифре, а потом удивляются, почему юнит-экономика не сходится.

CFO обычно видит инженерию одной строкой в P&L: зарплаты. Колонка headcount, множитель loaded cost, большая цифра, растущая быстрее выручки. И всё. Отчёт Deloitte Global Technology Leadership Study 2024 подсветил разрыв жёстко: только 31% CFO могут сказать, приносит ли их инвестиция в инженерию отдачу пропорциональную расходам. Остальные 69% летят вслепую над, возможно, крупнейшей дискреционной статьёй компании.

Это не проблема инструментов. Это проблема вопросов. Цифры существуют — ваши коллеги-CFO просто ещё не научились задавать пять правильных вопросов, чтобы их вытащить.