65 записей с тегом "engineering-metrics"

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

В Q1 2026 мы инструментировали инженерную организацию, у которой в отчёте красиво стоял «$340K на проект X за квартал». Но если посмотреть в топ-5 тикетов внутри этого проекта, картина другая. PROJ-1245 рефакторинг auth: $4 820. PROJ-1281 баг с форматом даты: $3 140. Двухчасовой багфикс стоил больше половины архитектурного рефакторинга. Шесть инженеров трогали этот тикет три недели подряд, потому что у него не было хозяина.

Этот разговор невозможно вести с цифрой по проекту. С цифрой по конкретному тикету — можно. В этом весь аргумент поста — и причина, по которой большинство Engineering Intelligence тулов спорят про не тот слой.

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

Ваша команда из 40 инженеров держит 34 репозитория. Звучит разумно? Мы видим эту форму часто. Типичный разработчик в такой конфигурации триггерит 11,4 переключения контекста в день между репо — почти все невидимы EM, каждое стоит ~23 минут рефокуса (UC Irvine, Gloria Mark, The Cost of Interrupted Work, 2008, и последующие репликации). Та же команда после миграции в monorepo: 3,2 переключения в день. Продуктивностная математика очевидна; стоимостная — интереснее.

Обе архитектуры работают. Google держит крупнейший известный monorepo (2B+ строк, ~85,000 инженеров). Netflix — тысячи polyrepo. Вопрос не в том, что лучше в вакууме — а что подходит вашему размеру команды, вашему CI-бюджету и вашей терпимости к координационному оверхеду.

Команда из 8 инженеров отлогировала 1 280 часов в марте 2026 — ровно столько, сколько даёт месяц при 160 часах на FTE. На таблице всё выглядело чисто. Двое инженеров были в трёх неделях от увольнения. Цифра часов это полностью скрыла; FTE utilization показала на пятый день.

Это разрыв между метрикой посещаемости и метрикой вовлечённости относительно базовой нагрузки. Исследование Microsoft Research WorkLab 2022 года про «triple peak workday» задокументировало третий вечерний пик продуктивности у knowledge workers — невидимый, если считать только сумму часов. Часы не говорят, кто спринтует, а кто плывёт. FTE utilization — говорит.

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

AI-ревью кода сидит на гребне хайп-цикла. GitHub Copilot, CodeRabbit, Qodo, Graphite и ещё полдюжины стартапов продают будущее, где LLM ловят баги быстрее людей. Классическое исследование Microsoft Research и Bacchelli 2013 года задало бейзлайн, с которым мы сравниваемся десять лет: человеческое ревью ловит ~14% функциональных дефектов, но 68% проблем maintainability. Вопрос сегодня: сдвигает ли добавление LLM хоть одну из этих цифр?

Мы вытащили данные по ревью со 100 B2B-команд между Q1 2025 и Q1 2026 — микс команд с AI-ревью, без, и с гибридом. Паттерн не такой, как рассказывают вендоры.

Большинство нетехнических CEO относятся к инженерии либо как к чёрному ящику, либо как к театру. CEO-чёрный-ящик спрашивает «как дела у инженерки?» на исполкоме, принимает ответ «идём по плану» и через четыре квартала удивляется, когда уходит архитектор, а роадмап встаёт. CEO-театр становится самодеятельным инженерным менеджером — учит DORA-метрики, неправильно произносит «Kubernetes» и превращает любое обсуждение roadmap в технический спор, за которым сам не успевает.

Ни то ни другое — не про интеллект. Это про отсутствие короткого нетехнического словаря для оценки здоровья инженерии. First Round State of Startups 2023 показал, что 68% CEO-первопроходцев считают себя «скорее» или «очень» зависимыми от CTO по любым инженерным решениям — это нормально, пока CTO не уходит или не расходится с советом директоров во взглядах.

Этот гайд — минимальный словарь CEO: 6 вопросов, позволяющих проверить здоровье инженерии без попытки стать техническим.