36 записей с тегом "leadership"

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.

Платформенная команда из 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 раз больше выручки на разработчика, чем команды нижнего. Но это соотношение ничего не значит без указания, как вы это измерили. Возьмёте не тот метод под вопрос, потеряете защитимый проект. В статье разобраны все пять, с реальными цифрами.

Открываете отчёт Plan-vs-Actual за Q3. План по инженерке — $1.8M. Факт — $2.34M. Расхождение — +30%. CFO хочет объяснение к пятнице.

Учебник советует: «разбирайтесь с любой строкой, где |факт − план| > 10%». На этом большинство разборов и заканчивается — и здесь же ломаются. У 30%-ного гэпа в инженерном бюджете минимум 5 разных причин. У каждой — своя сигнатура в данных. Если не декомпозировать variance, рискуете уволить PM-а, когда настоящий виновник — внеплановый раунд повышений зарплат в августе.

Variance analysis по CIMA разбирает расхождение как дерево: rate × volume × mix. С инженерным бюджетом сложнее — труд не однородный товар. Ниже версия, которая работает на реальных деньгах разработческих команд.

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

Фича опаздывает на две недели. Продакт-менеджер пожимает плечами: «Всё равно тот же квартал». 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 ответят «не знаю». Математика достижима. Просто никто её не считает.

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

Самый живучий миф в индустрии: Engineering Manager — это senior-разработчик, которому дали права админа в GitHub и разрешили одобрять pull requests по пятницам. Миф ошибочный по двум причинам. Первая: медианный EM в 100+ B2B-командах, которые мы измеряем, пишет код примерно 18 минут в день, и это здоровая цифра. Вторая: самое ценное, что делает EM, к IDE отношения не имеет. Это разговор, который удержал senior'а от ухода. Переписанная спека, которая спасла квартал. Нанятый инженер на уровень выше, чем команда считала возможным. Will Larson, который строил инженерию в Stripe, Calm и Carta, в An Elegant Puzzle формулирует прямо: задача EM — сделать так, чтобы команда выдавала больше суммы своих частей. Руками на клавиатуре этого не сделать.

Эта статья — простое определение роли. Кто такой EM, что он делает в течение недели, чем отличается от Tech Lead, как попасть туда из senior engineer и по каким метрикам понять, что человек справляется.

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