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

В одной 80-человечной инжиниринг-команде, с которой мы работали в марте 2026, ежемесячный обзор затрат шёл 90 минут. Шесть дашбордов. Четыре руководителя отделов, каждый защищает свои цифры. Итог: сообщение в Slack «давайте копнём глубже в следующем месяце». То же сообщение в феврале. И в январе. Дашборды были отличные. Решений не было ни одного.

Проблема не в нехватке данных. Отчёт Asana Anatomy of Work 2024 показал, что knowledge workers тратят 58% дня на «работу о работе»: митинги, статусы, обзоры дашбордов, и что типичный review-митинг не приводит ни к одному конкретному действию. Инженерные cost-обзоры — учебниковый случай. Слишком много чисел, нет forcing function для решения.

Открываем страницу Finances в организации с 38 активными проектами. По умолчанию — сортируемая таблица: имя проекта, расход за 30 дней, расход за всё время, owner, статус. Ежемесячный cost-review CFO начинается отсюда. 38 строк, 8 минут скролла, и в 60% случаев самый дорогой проект сидит на 17-й строке, куда никто реально не доходит. Эдвард Тафти ещё в The Visual Display of Quantitative Information (1983, 2-е издание 2001) показал: человек обрабатывает цвет и размер раньше, чем числа. Heatmap тех же 38 проектов выводит тёмно-красный квадрат меньше чем за секунду. Стивен Фью в Information Dashboard Design (2006, 2-е издание 2013) приходит к тому же выводу через индустриальные исследования: когда задача — «найди выброс», табличный вид это неправильное primary view. В виджете Projects Heatmap у PanDev Metrics обе модели идут бок о бок. Эта статья о том, почему mosaic должен быть дефолтом, а list — проверкой.

VP Engineering приходит на квартальный ревью с чистым DORA-дашбордом: lead time с 9 дней до 4, deployment frequency с 1.2 до 2.8 в неделю, change failure rate с 18% до 11%. CFO терпеливо слушает и задаёт единственный важный вопрос: «А сколько мы на этом сэкономили в деньгах?» В комнате становится тихо. DORA-инструмент этого не знает. Финансовый инструмент тоже не знает — он не видит deploy-данные. CTO начинает спорить «по принципу». Через два квартала бюджет платформенной команды режут, чтобы нанять ещё одного сейлза.

Большинство engineering-организаций ведут DORA и cost в двух разных системах. Sleuth, Swarmia, LinearB показывают DORA. Jellyfish (его отдельный finance-модуль) и Faros показывают cost. Отчёты DORA State of DevOps явно связывают четыре DORA-метрики с организационными результатами — но на уровне outcomes, не на уровне долларов. Чтобы перевести «мы сократили lead time с 9 дней до 4» в число, которое CFO готов защищать, нужны оба источника данных в одном запросе. Эта статья проходит через четыре точки интеграции и заканчивается практическим примером Q1 → Q2 с квартальным ROI 2.73x.

VP of Engineering выходит после Q1-ревью и объявляет 8% повышение для 12 backend-инженеров с эффективной датой 1 марта. На календаре 18 мая. Три месяца отчётов уже улетели в борд со старыми ставками. У HR два варианта: сделать вид, что повышение начинается сегодня, или ретроактивно обновить март, апрель и май. Большинство engineering finance инструментов вынуждают выбрать первый. PanDev Metrics поддерживает второй, и Sarbanes-Oxley Act 2002 — причина, почему делать это нужно очень аккуратно.

Это одна из немногих областей, где наш продукт реально расходится с LinearB, Jellyfish и Code Climate Velocity. Те инструменты построены на forward-only моделях ставок. Таблица UserRate в PanDev битемпоральная: у каждой ставки есть startPeriod и endPeriod, и OverheadCoefficientFullRecalcCronJob переигрывает activity-события через новую ставку × overhead K, когда исторические строки меняются. Это мощно. И это ровно та функциональность, на которую аудиторы смотрят дважды.

Платформенная команда из 6 инженеров стоит $156K в квартал. Они держат auth, observability, внутренний API gateway, общий кэш и деплой-пайплайн. Восемь продуктовых команд используют эти сервисы каждый день. Спросите CFO, кто за это платит — ответ «центральный R&D». Спросите тимлида платформы, кто это потребляет — ответ «все одинаково». Оба не правы, и зазор между ними — это место, где инжиниринг-финансы каждый год теряют шестизначные суммы на искажённых решениях.

Adrian Cockcroft изначально сформулировал этот аргумент, когда Netflix дробился на микросервисы: общая инфраструктура имеет unit cost, и unit cost должен следовать за запросом. CNCF FinOps Working Group в отчёте 2024 State of FinOps for Engineering нашли, что меньше 24% микросервисных организаций аллоцируют время платформенной команды обратно на команды-потребителей. Остальные 76% считают платформу overhead — то есть команда, потребляющая 41% запросов, получает тот же счёт, что и команда с 1%.

CTO смотрит на квоту SaaS-биллинга: $52K в год. В переговорной четверо инженеров, каждый стоит примерно $7K/мес. с учётом нагрузки. Математика моментальная: «4 инженера × 4 месяца = 16 человеко-месяцев. Соберём своё за $112K. Дальше бесплатно навсегда». Совет директоров кивает. Закупкам говорят отменить SaaS-evaluation. Через восемнадцать месяцев команда всё ещё владеет своим биллингом, двое инженеров поддерживают его в полставки, а первоначальные четверо в тот квартал не отгрузили ни одной revenue-фичи. Реальная 5-летняя стоимость «build» оказывается $546K, почти вдвое больше SaaS-пути. Forrester в анализе Total Economic Impact of Buy-vs-Build (2023) фиксирует медианное занижение стоимости in-house на 2,3×. Gartner повторяет это в своих TCO-фреймворках уже пятнадцать лет. Большинство команд всё равно не дочитывает математику до конца.

VP инжиниринга защищает на совете директоров миграцию на микросервисы за $1.2M. Прогноз ROI: «экономим 30% на инфре, релизим в 2 раза быстрее». CFO задаёт один вопрос: «Покажите математику». В ответ — единственное число 240% и никакого метода за ним. Совет говорит нет. Через два квартала конкурент закрывает ту же миграцию за восемь месяцев и начинает выигрывать enterprise-сделки на латентности. Проект был хороший. Проблема — в математике.

Никакой единой «формулы Engineering ROI» не существует. Есть пять разных методов расчёта, каждый собран под свой вопрос. Исследование McKinsey Developer Velocity Index показало, что команды верхнего квартиля генерируют в 4–5 раз больше выручки на разработчика, чем команды нижнего. Но это соотношение ничего не значит без указания, как вы это измерили. Возьмёте не тот метод под вопрос, потеряете защитимый проект. В статье разобраны все пять, с реальными цифрами.

Команда из 6 инженеров, 60 рабочих дней, по 8 часов. PM приходит на планирование со слайдом «2 880 dev-часов capacity». Q3 roadmap влезает в 2 400. Комфортный буфер. Через три месяца 40% roadmap не успели, а в постмортеме пишут «scope creep».

Никакого scope creep не было. Цифра capacity была неверной с первого дня. Стэнфордский экономист Джон Пенкавель в исследовании по часам и продуктивности показал, что output-per-hour начинает падать после 49 часов в неделю, задолго до 60. Microsoft Research и UC Irvine с Глорией Марк добавили второе лезвие: каждое прерывание стоит в среднем 23 минуты 15 секунд на восстановление фокуса. Сложите эти два факта поверх любого 8-часового календаря и вы получите заметно меньше 8 продуктивных часов.

В компании из 60 инженеров, которую мы инструментировали 14 месяцев подряд, средний коэффициент накладных составил K = 0.41. Это число бесполезно. Помесячный ряд: янв 0.46, фев 0.40, мар 0.39, апр 0.40, май 0.41, июн 0.43, июл 0.48, авг 0.49, сен 0.42, окт 0.40, ноя 0.43, дек 0.52. Финансовая модель с плоским K предсказала декабрьские накладные в $185K. По факту вышло $235K. Промах в 27% — это не ошибка прогноза. Это вся история сюрпризов Q4, которые CFO годами просит инженерию объяснить.

Отчёт DORA State of DevOps 2024 подсветил ту же картину с другой стороны: deployment frequency в Q4 падает на 12–18% по всему опросу, а incident volume растёт. Stack Overflow Developer Survey 2024 фиксирует в среднем 17 дней отпуска в год, со скоплением в конце декабря и августе. Harvard Business Review в Why Most Product Launches Fail показывает, что плотность Q4-релизов на 30–40% выше остальных кварталов. Три разных датасета, одно следствие: инженерная мощность в декабре структурно отличается от июня. Считать их одинаковыми в финансовой модели — это и есть ошибка.

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