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

CTO смотрит на квоту SaaS-биллинга: $52K в год. В переговорной четверо инженеров, каждый стоит примерно $7K/мес. с учётом нагрузки. Математика моментальная: «4 инженера × 4 месяца = 16 человеко-месяцев. Соберём своё за $112K. Дальше бесплатно навсегда». Совет директоров кивает. Закупкам говорят отменить SaaS-evaluation. Через восемнадцать месяцев команда всё ещё владеет своим биллингом, двое инженеров поддерживают его в полставки, а первоначальные четверо в тот квартал не отгрузили ни одной revenue-фичи. Реальная 5-летняя стоимость «build» оказывается $546K, почти вдвое больше SaaS-пути. Forrester в анализе Total Economic Impact of Buy-vs-Build (2023) фиксирует медианное занижение стоимости in-house на 2,3×. Gartner повторяет это в своих TCO-фреймворках уже пятнадцать лет. Большинство команд всё равно не дочитывает математику до конца.

Production-релиз в 60-инженерной SaaS-команде, с которой я работал в 2025, выкатили в пятницу в 16:48. Пейджер on-call сработал в 17:22 — 34 минуты скрытого фейла в фиче, которую release manager одобрил «потому что CI зелёный». Rollback занял 71 минуту, потому что автоматизацию никогда не прогоняли на реальном трафике. Итог: один возврат клиенту, две потерянные на выходных команды и политика, которую надо было ввести с первого дня.

Release management — это неглянцевая половина delivery. Отчёт DORA State of DevOps 2024 напрямую связывает change failure rate и MTTR с дисциплиной релизов, а не с талантом инженеров или test coverage. Этот playbook — конкретный набор правил и ритуалов, который перевёл две команды, с которыми я работал, с ежемесячных болезненных релизов на ежедневные уверенные.

VP инжиниринга защищает на совете директоров миграцию на микросервисы за $1.2M. Прогноз ROI: «экономим 30% на инфре, релизим в 2 раза быстрее». CFO задаёт один вопрос: «Покажите математику». В ответ — единственное число 240% и никакого метода за ним. Совет говорит нет. Через два квартала конкурент закрывает ту же миграцию за восемь месяцев и начинает выигрывать enterprise-сделки на латентности. Проект был хороший. Проблема — в математике.

Никакой единой «формулы Engineering ROI» не существует. Есть пять разных методов расчёта, каждый собран под свой вопрос. Исследование McKinsey Developer Velocity Index показало, что команды верхнего квартиля генерируют в 4–5 раз больше выручки на разработчика, чем команды нижнего. Но это соотношение ничего не значит без указания, как вы это измерили. Возьмёте не тот метод под вопрос, потеряете защитимый проект. В статье разобраны все пять, с реальными цифрами.

В инженерной культуре Google есть правило: до первой строчки кода для любой нетривиальной задачи пишется design doc. Не 40-страничный монумент, а обычно 5-12 страниц, с двумя ревьюерами и комментариями на полях. Команда Engineering Practices из Google публично называла это одним из самых дешёвых рычагов качества в компании.

Большинство команд вне Google либо пропускают этот шаг, либо прикручивают шаблон в Confluence к существующему процессу и смотрят, как он атрофируется. Шаблон ниже — тот, который реально выживает при встрече с уставшим ревьюером в 16:45 в четверг. Это тот момент, когда спека живёт или умирает.

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

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

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

Команда из 40 инженеров за 8 месяцев приняла одно и то же архитектурное решение дважды — в июне и в феврале, оба раза откатила. После второго отката наконец внедрили RFC-процесс. Разбирая историю коммитов, они обнаружили: оригинальный контекст остался в Slack-треде, который автоматически архивировался через 90 дней, а инженер, который владел решением, уже уволился. RFC-документ стоил бы 4 часа на написание и сэкономил бы примерно 3 инженеро-недели переделок.

RFC-процессы существуют потому, что технические решения переживают людей, которые их приняли. Stripe, Cloudflare, Oxide Computer и проект Rust публично описывают свои RFC-форматы — и общая структура уже, чем кажется большинству команд. Эта статья — тот самый шаблон, к которому они сходятся, плюс реалистичный ревью-цикл для команд 10-80 человек, плюс честные цифры о том, когда RFC просто тратят время.

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

Команда из 60 инженеров, с которой я работал в прошлом году, имела 1400+ страниц Confluence, Notion-воркспейс на 380 страниц, GitHub wiki в каждом из 22 репозиториев и Google Drive с «командными знаниями». Задачей новой сотрудницы на второй неделе было найти runbook стейджинга. Ушло четыре часа. Он существовал во всех четырёх системах, с тремя разными URL, двумя противоречивыми версиями и одной корректной, но устаревшей на три года инструкцией в wiki.

Это сравнение четырёх подходов к knowledge management — Confluence, Notion, GitHub Wiki, Git-native docs (Obsidian/MkDocs/Docusaurus поверх репозитория) — и фреймворк выбора. Microsoft Research в отчёте по productivity 2024 назвал «не могу найти документацию» фактором трения №3 после медленных билдов и сломанных тестов, выше задержек code review. Выбор инструмента не нейтрален: он определяет, будет ли документация написана, найдена и доверяема.