7 записей с тегом "financial-analytics"

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

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

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

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

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

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

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

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

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

Jellyfish силён в том, ради чего он был построен: portfolio-уровневая видимость для VP Engineering в организациях с 200+ разработчиков. Платформа отвечает на вопрос «какую долю инженерных усилий мы вкладываем в рост vs. поддержку» в формате готовом для совета директоров. Это реальная задача на реальном масштабе, и Jellyfish её решает.

Трение начинается с цены и фита. По публичным референсам и отчётам клиентов контракты Jellyfish стоят $50K-$250K в год, причём большинство сделок ближе к $100K и выше. Для компании в 60 инженеров, которая хотела «DORA плюс немного resource allocation», это не та форма и не тот счёт.

Если вы ищете «Jellyfish альтернатива», вы обычно в одном из двух лагерей. Либо вы пилотировали Jellyfish и цена не пережила procurement, либо у вас 30-150 инженеров и платформа избыточна для вашего реального вопроса. Оба сценария частые. Вот честная картина рынка в 2026.

Четыре дашборда. Одна платформа. От рабочего дня одного инженера до затрат всей организации. Ниже — что показывает каждый, на скриншотах.

CEO диджитал-агентств живут и умирают по показателям утилизации. Бенчмарки SoDA (Society of Digital Agencies) показывают, что целевая биллабельная утилизация команд разработки — ~75-85%, и большинство агентств не дотягивают. Каждый час, который разработчик тратит на небиллабельную работу, — упущенный доход. Каждый проект, вышедший за рамки бюджета, съедает маржу. А с 5, 10 или 20 клиентскими проектами одновременно знать, куда реально уходит время каждого, практически невозможно.

Большинство агентств полагаются на ручной учёт времени. Разработчики заполняют таймшиты в конце недели, прикидывая, сколько часов ушло на каждый проект. Данные неточны, процесс ненавистен, а полученные цифры определяют решения на сотни тысяч долларов.

Есть способ лучше.