4 записи с тегом "cost-management"

30-дневный срез Q1 2026 с команды из 14 инженеров: за год 187 тикетов прошли через легаси-компонент авторизации, средняя стоимость $1,820 за тикет при 18 часах. Greenfield-компонент онбординга у той же команды закрывал тикеты сопоставимого типа и severity по $640 за 6 часов. Разница — это и есть налог технического долга. После умножения один этот легаси-компонент течёт на $220K в год, и CFO подписывает эту сумму, не видя её отдельной строкой. Stripe в Developer Coefficient (обновление 2024) оценивает потери из-за «плохого кода» примерно в 17 часов в неделю на разработчика — около 42% задекларированной нагрузки. Это глобальное среднее. Цифра выше — то, как оно выглядит, когда вы наконец считаете локально.

Эта статья — для engineering manager, которому CEO сказал «принеси бизнес-обоснование для рефакторинга», а в табличку положить нечего. Формула — скучная. Настоящая работа — данные под ней.

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

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

В инженерной организации на 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 — это наследие, которое уже не соответствует данным даже в стране-источнике.