Principal-инженер в финтехе на 200 человек за Q3 написала 180 строк кода. Её команда за тот же период отгрузила 340 000 строк. Когда CTO посмотрел дашборды coding-time для performance review, её едва не пометили как отстающую. Что реально произошло в Q3: она переписала спецификацию сверки платежей, разблокировав две команды, менторила трёх senior-инженеров в tech-lead, и закрыла полугодовой проект, который отгрузил бы то, что рынку не нужно. Её измеримый output был крошечный. Её impact — крупнейшим среди всех инженеров компании за квартал.

Это парадокс измерения principal-инженера. Каждый staff-plus-фреймворк (Will Larson, книга Tanya Reilly The Staff Engineer's Path, внутренняя лестница Google) это признаёт: principal-инженерам платят за суждение и умножение силы, а не за throughput. Но большинство инженерных организаций меряют их как senior-инженеров с большим титулом. Эта статья — о том, как честно измерять principal-impact, и как самому principal мерить свой impact к моменту review.

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.

Инженерная команда 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 уплощается в пределах квартала.

Три года назад команда включила feature-флаги — казалось, это ответственный подход: постепенные раскатки, kill switch, A/B-тесты. Сегодня в flag-сервисе 87 живых флагов, и никто в команде не может объяснить, что делают 34 из них. Два флага прямо сейчас противоречат друг другу в проде. Один должен был быть удалён в 2024. Airbnb публично описал тот же сценарий в 2023 — они дошли до 6000+ флагов, прежде чем полный аудит заставил сделать чистку. GitHub отчитался о 3700 одновременно работающих экспериментах на пике.

Проблема не в feature-флагах. Проблема в том, что команды считают флаги бесплатными — дёшево добавить, не видно обслуживать. Этот плейбук — lifecycle-фреймворк, который работает для команд от 10 до 200 инженеров, подкреплённый данными 100+ B2B-компаний, которые мы трекаем через IDE heartbeats. Цель: чтобы количество флагов росло примерно с размером команды, а не с её возрастом.

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

Twilio поддерживает 14 активных версий API. Stripe фиксирует каждого клиента на версии, активной на момент регистрации, и держит версии аж с 2011 года. GitHub REST параллельно ведёт три major-версии и шлёт deprecation-заголовки за 12 месяцев до отключения. Ваша команда, скорее всего, пытается выжить с одной — и спорит, куда пихать версию: в URL, header или Accept.

Этот спор на самом деле — три разных решения, склеенных в один аргумент: где живёт версия, как скоупятся breaking changes и когда старые версии умирают. Правильный ответ на одно не спасёт, если два других кривые. Это плейбук на основе того, как реально работают компании с публичным API на скейле, плюс что мы видим внутри PanDev Metrics у клиентов с внутренними API на 20-200 потребителей.

Платформенная команда из 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%.

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 накладывает сверху геопространственную сложность.