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

Инженерная команда delivery-платформы работает с нагрузкой принципиально другой формы, чем B2B SaaS. Мобильное приложение курьера пингует локацию каждые 3–5 секунд. Консоль диспетчера ждёт sub-200ms на назначение заказа. Route-optimization крутит комбинаторику ночью и обязан закончить до утренней смены. Отчёт McKinsey по last-mile 2024 оценил час простоя диспетчерской в $12,000–$35,000 для среднего регионального перевозчика.

Эта форма работы меняет то, какие инженерные метрики реально важны. DORA Four Keys всё ещё применимы, но картина delivery performance и team health смещается. Вот метрик-стек, который ложится на логистические команды — и места, где «скопируй SaaS-DORA-дашборд» вводит в заблуждение.

Один CTO маркетплейса сказал фразу, которую я слышу регулярно: «Supply-команда релизит быстро, demand-команда релизит быстро, а GMV стоит». Оба DORA-дашборда были зелёными. Matching-движок — нет. У двусторонних продуктов есть метрический разрыв, которого нет у односторонних SaaS: инженерный выход на одной стороне создаёт бизнес-ценность только в том случае, если ему отвечает выход на другой.

Фреймворк маркетплейсов от a16z ставит liquidity — вероятность того, что листинг реально совершит транзакцию в окне, — на первое место по прогностической силе здоровья маркетплейса. И это инженерный исход, не маркетинговый. Когда P95 поискового запроса растёт на 200ms, конверсия листингов падает измеримо. Когда онбординг продавца занимает 14 дней вместо 4 — кривая роста supply уплощается в пределах квартала.

Крупный автопоставщик, с которым я консультировал в 2024, получил production-баг во вторник в 03:15. Фикс написали за 8 минут и выкатывали 19 дней — потому что требовался софт-апдейт PLC на 14 производственных ячейках, каждую из которых можно было обновить только в 4-минутное окно между сменами. Средний lead time инженерной команды на офисной IT-стороне — 31 час. На shop-floor-стороне — 14 дней. Та же команда, тот же репозиторий, две разные вселенные constraint'ов delivery.

Manufacturing software engineering — это Agile, столкнувшийся с железом. Практики, работающие в SaaS-стартапе — deploy-whenever, feature flags, canary-релизы — сталкиваются с регулируемой реальностью plant floor: цели OEE, стоимость changeover, разделение OT/IT и production-линии, которые нельзя остановить ради деплоя. Исследование Deloitte Smart Factory 2023 обнаружило, что 73% производителей называют «интеграцию IT/OT» главным барьером цифровизации. Дело не в технологии — дело в том, что метрики и ритуалы, придуманные для чистого софта, ломаются, когда софт касается физического процесса.

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, когда исторические строки меняются. Это мощно. И это ровно та функциональность, на которую аудиторы смотрят дважды.

PropTech-команда, с которой я работал в прошлом году, отгружает 4,2 деплоя в неделю по флагманскому продукту. Их CEO сравнивает это с бенчмарком по SaaS-портфелю и делает вывод: "средненько". Неправда. Финтех с похожим штатом даёт 7,1; чистый B2B SaaS — 9,4. PropTech живёт на пересечении регулируемых данных, геопространственной сложности и MLS-интеграций из 90-х — и сырое число деплоев скрывает, с чем реально борется инженерная команда.

Stack Overflow Developer Survey 2024 помещает real-estate software в нижнюю треть по отчётной скорости сборки и интеграционных тестов. DevEx-бенчмарки Microsoft Research 2024 показывают, что регулируемые отрасли теряют в среднем 23% инженерного throughput только на compliance friction. PropTech накладывает сверху геопространственную сложность.

Команда, которая делает батарейный сельхоз-сенсор, гоняет CI-пайплайн 38 минут: собрать firmware, прошить HIL-стенд, прогнать 12-минутный on-device smoke, опубликовать артефакты. Их коллеги из веб-команды пушат в main и видят зелёные галки за 7 минут. Когда обе команды меряют по deployment frequency, firmware-команда выглядит отстающей в 5 раз. Они не отстают. Они делают более сложную работу с более длинным циклом обратной связи, а метрика этого не видит.

Большинство инженерных метрик построены под веб: быстрые билды, обратимые деплои, observability с первого дня. IoT- и embedded-команды наследуют эти метрики и выглядят на их фоне плохо. Фреймворк DORA это явно признаёт — отчёт Accelerate State of DevOps 2023 отмечал, что "команды, шипящие embedded или регулируемый софт, имеют другое распределение и не должны сравниваться с веб-командами по deployment frequency". Эта статья — о том, что трекать вместо этого.

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. С инженерным бюджетом сложнее — труд не однородный товар. Ниже версия, которая работает на реальных деньгах разработческих команд.

Команда из 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 продуктивных часов.

Две инженерные организации одинакового размера шипят одним темпом. Организация A: у каждого файла есть владелец, PR требуют его аппрува. Организация B: любой может смержить любую часть кода после peer review. У A на 40% меньше багов на KLOC. B восстанавливается после ухода senior-инженера в 3× быстрее. Microsoft Research (Bird et al., 2011, Don't Touch My Code) провели этот эксперимент на 3000+ файлах в Windows Vista/7 и показали: файлы с чётким владельцем имеют значительно меньше post-release отказов — но также чаще становятся бутылочным горлом.

Эта статья сравнивает три реальные модели владения — strong, collective, hybrid — по данным Microsoft, Google 2018 по code review и 100+ компаниям из нашего IDE-датасета. Цель — выбрать модель под этап и работу команды, а не ту, что была в блогпосте на прошлой неделе.