TL;DR

• Develop–Deploy–Operate: разработка — творчество; развертывание — конвейер; эксплуатация — работа с неожиданностями. Фазы взаимозависимы.

• Ценность только в использовании: фича без релиза = 0; WIP вреден.

• Чем раньше и чаще, тем лучше: мелкие релизы повышают совокупную ценность (до ~50% при том же объёме).

• Фикс-косты ≠ потери: предсказуемые затраты vs реальные потери от дефектов в проде (выручка, доверие, бренд).

• «Меньше сбоев» — слабая метрика влияния инструментов; ориентируемся на связку DORA ↔ бизнес-результаты.

• Контрфакты почти не измеримы; используем крупные агрегаты и тренды.

• Лестница прокси-проверок: unit → интеграция → квалификация релиза → канареечный релиз → прод. Чем позже, тем точнее и дороже. Shift-left снижает стоимость.

• DDR: стоимость обнаружения/устранения ≈ затронутые люди × время с момента внесения. Ранние автофиксы дают максимальный ROI.

• Три измеримых эффекта + один качественный: успех продукта, эффективность ресурсов, инженерная ёмкость + стратегические возможности.

• Эффективность ресурсов в двух плоскостях: runtime для пользователей и внутренние вычисления (CI/CD и др.); инвестируем по ROI.

• Инженерная ёмкость через снижение toil/рутины в тестировании и деплое; часто выгоднее найма.

• Роль платформы/инфры: ускоряют команды, экономят ресурсы, расширяют стратегические возможности; мерим по сдвигам DORA «клиентских» команд и утилизации ресурсов.

• Консистентный процесс с разумными исключениями: общие инструменты для масштаба, локальные отступления — по необходимости.

• Что оптимизируем по DORA: ниже CFR и MTTR, короче lead time «commit→deploy», выше частота релизов при меньшем человеческом участии.

• Пост-сабмит vs «человеческая» часть: DORA — про механику после коммита; до коммита — цикл edit–build–test, возможности IDE, меньше трения и ложных срабатываний, сигналы благополучия.

• Общий язык параметров: частота дефектов, задержки фаз, стоимость вычислений, затраты людей, доли обнаружений, ложноположительные/ложноотрицательные.

Сколько стоит инвестировать в инструменты для разработчиков? Как посчитать выгоду от улучшений в платформе? Как оценить бизнес-эффект от того, что приложение стало есть меньше CPU? Какие тесты гонять на этапе разработки, а какие — уже на интеграции?

Вроде бы индустрия софта накопила тонны опыта — от open source до академии, — но на такие, казалось бы, простые вопросы до сих пор нет прямых и однозначных ответов.

Чтобы компания жила не только «здесь и сейчас», но и на длинной дистанции, ей нужно держать баланс между затратами на разработку и той ценностью, которую приносит софт. При этом важно учитывать и риски. Ценность появляется из разных источников: успех продукта на рынке, продуктивность команды, эффективность использования железа, инновации и снижение рисков. Всё это переплетено: где-то можно посчитать в рублях или долларах (зарплаты, стоимость серверов), а где-то в цифры это укладывается с трудом, особенно в краткосроке.

В этом тексте я попробую показать целостную модель — как смотреть на затраты и ценность разработки софта через призму бизнес-целей. Разберём несколько наблюдений и общий словарь понятий, который может быть полезен и продактам, и инженерам, и менеджерам. А ещё посмотрим на модель процесса разработки с четырьмя типами эффектов и обсудим, как инфраструктура и архитектура влияют на всё это.

Разработка ПО и бизнес-цели

Когда компания вкладывается не просто в создание конкретной фичи, а именно в сам процесс разработки, цель одна — выжать максимум ценности из имеющихся ресурсов: получить приемлемое качество без неустойчивых затрат.

Программное обеспечение начинает приносить пользу только тогда, когда им реально пользуются. А путь до этого — это постоянные компромиссы: люди, железо, время, стратегические приоритеты.

Как бы ни различались процессы в разных компаниях, ценность коммерческого софта обычно складывается из трёх взаимосвязанных этапов: разработка, развертывание и эксплуатация. У каждого свои задачи и своя логика затрат/выгод, а изменения в одном этапе неминуемо отзываются на остальных.

Почему это важно

Смотреть на разработку нужно целиком, а не кусками. Если упираться только в железо и забывать про остальные процессы, легко получить задержки релиза или падение качества. Классический пример: меньше тестов — меньше затрат на ресурсы, но потом ошибки в проде обходятся куда дороже.

Поэтому компромиссы стоит формулировать не в вакууме, а через призму всех трёх процессов — разработки, развертывания и эксплуатации. Так управленцы видят полную картину и принимают решения осознаннее.

Несколько базовых инсайтов

ПО имеет ценность только тогда, когда его используют. Новая фича или фикс, лежащие «на полке», — это потраченное время и деньги без отдачи.

Высокая задержка на любом этапе не только тормозит выход ценности к пользователям, но и повышает риски: серьёзные баги в проде всё равно случатся, и чем быстрее команда сможет реагировать, тем меньше будут потери.

Процессы создания ценности

У каждого этапа разработки свой баланс ресурсов и свои компромиссы.

Разработка — это творчество

Одна из главных загадок индустрии: как измерить продуктивность разработчиков? Очевидно, не в строках кода — Дейкстра это сформулировал ещё десятилетия назад. Количество коммитов тоже ничего не доказывает: это лишь активность, а не результат. «Скорость появления фич» звучит красиво, но даже здесь куча вопросов: что считать фичей? как понять, что реализовали именно ту, что была нужна?

Причина проста: каждое изменение уникально. Почти никогда нельзя взять две фичи и сравнить их напрямую. Разработка — это проектирование, исследования, изобретательность, глубокое понимание системы. Вся работа до отправки изменений в репозиторий — это в первую очередь человеческий творческий процесс, выражение замысла.

Как заметила Мэри Шоу ещё десятки лет назад: «Написание программного обеспечения должно соответствовать проектированию продукта, а не его производству».

Статья SPACE напоминает: агрегаты и прокси-метрики могут быть полезны, но только в связке с другими показателями, которые уравновешивают друг друга. Сами по себе они редко позволяют оценить затраты настолько точно, чтобы напрямую сопоставить их с доходами бизнеса.

Если же смотреть на разработку как на проектирование и выражение замысла, становится понятнее, куда инвестировать, чтобы повысить продуктивность. В автоиндустрии, например, сначала вкладываются в стандарты, типовые компоненты, инструменты моделирования и проработку дизайна. А в серию идёт уже готовый прототип.

В разработке софта логика та же:

• сначала вместе решаем, что строим;

• потом — как это реализовать;

• и только после этого код уходит в прод.

Ключевой момент — время на прототипы, эксперименты и итерации. Тут особенно помогают переиспользуемые компоненты, удобные высокоуровневые инструменты и цельное понимание системы.

Развёртывание — это конвейер

В отличие от этапа разработки, после коммита человеку в процессе деплоя делать особо нечего. Проверка тестов, анализ сигналов из продакшна, решение «эта сборка годится или нет» — всё это лучше и надёжнее умеют машины.

Исключение — SRE, которые отвечают за инфраструктуру, устранение сбоев и сложные аварии. Они нужны всегда. Но если команда вручную участвует в рутинных частях деплоя, значит, где-то мы недотянули: либо автоматизацию, либо сбор сигналов, либо и то и другое.

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

Метрики DORA (см. свежие публикации, такие как отчёты State of DevOps, или более раннюю, но влиятельную книгу Accelerate) фактически фиксируют этот факт: время «от коммита до развертывания» можно измерять и сравнивать между командами, потому что в основе своей каждое действие по релизу или деплою может быть полностью механизировано.

Операционные процессы

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

Релизы: чем раньше, тем лучше

Главная цель большинства коммерческих проектов тривиальна: как можно быстрее и в нужном качестве отдавать ценность пользователю. Отсюда и культ Continuous Deployment — чем чаще релизим, тем больше выигрываем.

Пример: две команды за квартал делают одинаковый объём изменений. Первая выкатывает всё разом в конце квартала. Вторая — по релизу в день. Результат? Вторая команда приносит заметно больше совокупной ценности, иногда до +50%, только за счёт частоты релизов.

На практике, конечно, не всё так гладко:

• часть изменений в продакшне будет проваливаться (особенно экспериментальные или UX-новинки), и им нужны итерации, чтобы заработать;

• релизы стоят ресурсов: вычисления, автоматизация, да и пользователи ненавидят долгие обновления (все помнят, как телефон висит на ребуте).

Но всё это вторично. Ранний и частый релиз почти всегда приносит больше пользы, чем редкий и крупный.

Качественные свойства программных систем

Продукт — это сочетание фич и атрибутов качества (QAs). Фичи локальны: можно ткнуть в кусок кода, который делает, скажем, логин. QAs — нефункциональные требования, распределённые по всей системе: они проявляются во взаимодействиях, зависимостях и общем поведении, их сложно изолировать.

Атрибуты качества часто конфликтуют друг с другом и с затратами.

Таксономию тут не строим — дальше просто разберём несколько ключевых наблюдений.

Фиксированные издержки — это не потери

Важно не путать две разные вещи. Затраты на разработку — предсказуемые и планируемые; потери из-за дефектов в продакшне — реальные ударные последствия для бизнеса. Баги, которые доходят до пользователей, бьют по выручке, удовлетворённости и репутации. Да, идеального качества не бывает (привет error budgets), но планка должна быть такой, чтобы большинство проблем оставались незамеченными для пользователя. Когда качество «проседает» уже в проде, начинаются настоящие и часто непредсказуемые убытки.

На коротких отрезках — например, в рамках квартала — картина иная: человеческие и машинные ресурсы в основном фиксированы. Зарплаты инженеров и счёт за облако можно прикинуть заранее. Обнаружение и исправление дефектов на этапе разработки — часть этой «фиксированной ёмкости»: они отнимают время, сдвигают релизы, но не меняют сам по себе финансовый контур периода. Аналогично, непрожатые оптимизации и неэффективное потребление ресурсов уменьшают доступную вычислительную мощность, но общая стоимость владения кодовой базой в этот период остаётся примерно той же.

Из этого следует простой вывод. Дефект, пойманный до релиза, — это задержка и внутренние издержки процесса. Неприятно, но ожидаемо. Дефект, улетевший в прод, — это риск и часто прямые потери, причём основная «стоимость» тут — не сам фикс или откат, а удар по доверию и ощущению надёжности продукта. Поэтому ценность быстрой и автоматической поставки нужно уметь сбалансировать с риском «переборщить» с дефектами на релизе.

И ещё один организационный момент: считайте отдельно дефекты, которые добрались до продакшна, и те, что были устранены внутри процесса. Это разные по природе события, и смешивать их в одну метрику — значит терять фокус на настоящих потерях.

Снижение числа сбоев — слабая метрика влияния

Считать общее число инцидентов можно, но как метрика влияния конкретного инструмента или процесса это почти всегда мимо. Статистики там мало: редкие, разнокалиберные события, сильный шум. В результате легко сделать ложный вывод — будто инструменты «не работают», качество «не влияет» или нужен ещё один «волшебный KPI». Гораздо надёжнее смотреть на связь командных метрик процесса с бизнес-результатами: команды с лучшими DORA-показателями, как правило, показывают и лучшую организационную эффективность. К этой логике мы вернёмся дальше.

Почему контрфакты не ловятся

Чтобы оценить эффект «по-настоящему», нужно сравнить факт с тем, что бы произошло без вмешательства. Для этого необходимы две вещи: чёткая базовая метрика «до», и заметное, причинно связанное отклонение «после». Нет вменяемого графика во времени с падением/пиком, совпадающим с событием, — нет и оценки контрфакта. А в инженерной практике такие условия выполняются редко.

Что тогда измерять

Единой метрики «продуктивности инженеров» не существует, и общепринятого индексного показателя тоже. Поэтому работают только крупные агрегированные прокси — те, что отражают поведение больших групп и целых потоков поставки (вроде DORA). Измеримыми оказываются события, которые реально затрагивают значимую долю системы или популяции. Влияние же конкретного инструмента на продуктивность одного человека или небольшой команды почти всегда утонет в шуме и останется статистически неубедительным.

Стоимость дефектов vs достоверность тестов

Тестирование в продакшне даёт самый «честный» сигнал о ценности и качестве — выше достоверности не бывает. Цена — высокий риск: дефекты, долетающие до пользователей, обходятся дорого. Поэтому в реальной жизни мы предпочитаем менее точные, но более ранние проверки: они дешевле и безопаснее. Чем раньше пойман баг, тем меньше стоит его починка — классический shift-left.

Полезно мыслить «лестницей прокси»:

• Юнит-тесты частично заменяют будущие интеграционные проверки.

• Интеграция — прокси для квалификации релиза.

• Квалификация релиза — прокси для канареечного анализа в продакшне.

Чем выше по этой лестнице, тем точнее сигнал о реальном качестве, но тем дороже становится дефект: больше потребление ресурсов, больше затронутых людей и процессов.

Почему «поздние» баги такие дорогие? Их сложнее локализовать прямо перед релизом, они тянут за собой переработку кода и тестов, увеличивают коммуникационные издержки, заставляют собирать нового release candidate, тормозят график и съедают доверие. Отсюда практический вывод: строим пайплайн так, чтобы максимально сдвигать обнаружение дефектов влево, а высокоточные проверки ближе к продакшну оставляем для того, что действительно требует подтверждения «боевыми» сигналами.

Оценка влияния

Смысла мерить «всё подряд» нет — важно отделять то, что реально влияет на бизнес-ценность. Предлагаю смотреть на четыре формы влияния, из них три — измеримые:

1. успех продукта,

2. эффективность использования аппаратных/облачных ресурсов,

3. инженерная ёмкость.

И четвёртая — стратегические возможности: их сложнее загнать в цифры, но игнорировать нельзя. Такой набор хорошо соотносится с идеей, что фиксированные издержки отличаются от реальных потерь: мерить стоит то, что меняет итоговую ценность, а не просто «шумит» внутри процесса.

Успех продукта

Главный вопрос простой: продукт успешен или нет. Конкретная формула успеха у каждой компании своя, но обычно это комбинация показателей вроде выручки, охвата и внедрения, доверия пользователей и удовлетворённости клиентов. На эти метрики работают две вещи:

• скорость и регулярность поставки ценности (чем раньше и чаще мы доставляем полезные изменения, тем выше интегральная польза),

• снижение дефектов и сбоев (меньше инцидентов — больше доверия и лояльности).

Важно помнить: успех продукта — это не KPI одной фичи, а портфельный результат всей системы поставки — от идеи до эксплуатации.

Эффективность использования аппаратных ресурсов

Эффективно ли расходуются продакшн-железо и облако? Это близкий к продакшну и хорошо измеряемый эффект; сильнее всего на него влияют оптимизации кодовой базы и компилятора.

Улучшения проявляются в двух плоскостях:

• Клиентское потребление: сколько вычислений нужно, чтобы отдавать фичи. «Чистые» оптимизации ценностно нейтральны; если продиктованы требованиями пользователей (latency, стабильность под пиком) — добавляют ценность.

• Внутренние процессы: сколько вычислений съедают сборки, тесты и оценка релиза. Здесь всегда компромисс: время разработчиков vs экономия железа/облака. Имеет смысл вкладываться, если экономия окупается; иначе — нет.

Инженерная ёмкость

Эффективно ли используются человеческие ресурсы? Измерить это напрямую сложно, но есть два практичных подхода, которые снижают зависимость от «идеальных» метрик.

Во-первых, развертывание — это конвейер: почти любое ручное участие в тестах, деплое и релизах — лишние накладные. DORA называет это deployment pain. Если удаётся удерживать успех продукта и одновременно сокращать человеческую рутину в этих процессах, это даёт реальную ценность и часто обеспечивает больший ROI, чем дополнительный найм.

Во-вторых, контрфакты почти не измеряются, поэтому остаются два пути оценки влияния на ёмкость:
— измерять дельту от конкретного вмешательства (редко возможно из-за отсутствия чистого «до/после»);
— считать, сколько ёмкости съедает текущий процесс и во что это обходится, а затем целенаправленно уменьшать совокупные затраты. Первый путь отвечает на «сколько мы сэкономили сейчас», второй — на «как сделать расточительный процесс эффективнее».

Как оценивать «профилактику» дефектов

Оценивать пользу от предотвращения конкретного бага — это всегда игра с контрфактом. Нужно ответить сразу на несколько «если»: дошёл бы баг до продакшна и привёл бы к потерям, или его всё равно поймали бы позже? На каком этапе его бы отсеяли? Какова ожидаемая совокупная «стоимость по ёмкости» (время людей и машин) по всем оставшимся фазам? Посчитать это, особенно «дефект за дефектом», крайне сложно — что и объясняет, почему влияние процессных и инструментальных улучшений так трудно количественно доказать.

Вместо точных контрфактов используем согласованную оценку DDR (defect detection & resolution): стоимость растёт линейно с двумя факторами — числом инженеров, которых затронул дефект, и временем с момента его появления. Отсюда практический вывод: чем раньше диагностируем класс проблем, тем он дешевле. Простой пример — автоформатирование в IDE: пробельные огрехи правятся сразу и касаются только автора. Без такого вмешательства они всплывут через минуты или уже на интеграции — через часы и дни, вовлекая больше людей и ресурсов.

С автоформатированием в IDE «жизнь» незамеченного дефекта сокращается до секунд или минут: уменьшение периода DDR с часов до минут — ощутимая выгода. Но такие вложения оправданы только тогда, когда этот класс проблем возникает достаточно часто, чтобы окупить изменения. И наоборот: если цена позднего исправления несоразмерна выгоде (например, стопорить релиз из-за пробельных мелочей), такие проблемы стоит игнорировать.

Из этой простой оценки DDR и принципа «минимум людей в деплое» следуют два рычага роста инженерной ёмкости:

1. снижать рутину в деплое и интеграции, удерживая DDR на прежнем уровне;

2. уменьшать совокупную стоимость дефектов — отдельных или целых классов.

Стратегические возможности

Это четвёртый вид эффекта — важный, но трудносчитаемый. Речь о возможности делать то, что раньше было невозможно или слишком дорого. Такие вещи нельзя мерить теми же шкалами, что успех продукта, ресурсы или инженерную ёмкость. Сюда же относится и доступ к качественной информации для принятия решений — даже если ею пользуются редко (телеметрия раз в квартал всё равно даёт огромный рычаг).

Пример — ИИ, который агрегирует и сжимает информацию. С появлением поисковиков в 90-х продуктивность резко выросла во многом из-за того, что данные стали доступными в удобоваримом виде — не сырыми, а уже структурированными и резюмированными. Из инженерных инструментов из той же оперы — flame graph по вызовам функций: он помогает быстро понять, где и как оптимизировать производительность.

Стратегические возможности

Это долгосрочные или экспериментальные инвестиции, способные радикально изменить работу бизнеса (например, объявление нового домена стратегическим приоритетом). У таких ставок длинный горизонт и высокая неопределённость, поэтому они требуют осознанного подхода и поддержки топ-менеджмента — включая продуманные правила оценки и продвижения команд. В портфеле инфраструктурных инвестиций доля подобных инициатив должна быть ограниченной.

Компромиссы

Улучшение в одной области рабочего процесса почти наверняка сдвинет баланс в двух других — это нужно учитывать при планировании (см. таблицу 1).

Роль инфраструктуры и платформенной инженерии

Команды инфраструктуры и платформенной инженерии дают ёмкость и стратегический эффект, косвенно влияя на метрики успеха продукта. Фичи делает продактовая команда, а инфраструктура ускоряет инженерную работу и помогает держать качество. Централизованные платформы влияют тремя способами:

• Инженерная ёмкость: сокращать циклы edit–build–test, уменьшать дефекты и переделки, снижать рутину в развертывании, повышать удовлетворённость разработчиков.

• Эффективность ресурсов: уменьшать потребление железа/облака без просадки по другим эффектам и осмысленно разруливать компромиссы.

• Стратегические возможности: давать новые типы инфраструктуры, улучшенную телеметрию и т.п.

У разных специализаций внутри инфраструктуры — свой микс эффектов. Примеры:

• Обучение напрямую повышает инженерную ёмкость: снижает генерацию дефектов, объём переделок и число циклов edit–build–test. Именно эти показатели и стоит использовать для оценки инвестиций в техобучение.

• Инструменты разработчика могут и нарастить ёмкость (быстрее разрабатывать), и улучшить эффективность ресурсов, и добавить стратегические возможности (телеметрия, новые платформы).

• Оптимизация кодовой базы ощутимо повышает эффективность использования аппаратных ресурсов.

Как измерить влияние инфраструктуры

Сверху смотрят на агрегаты по портфелю: выручка, затраты и прочие бизнес-показатели. Для инфраструктурных и центральных дев-команд релевантны другие агрегаты: потребление железа/облака и метрики DORA (или аналоги). DORA отвечает на практичный вопрос: как предоставленная инфраструктура влияет на инженерную, а не продуктовую, производительность и ёмкость команд, которые ей пользуются?

Когда платформенная команда ставит себе KPI, полезно спросить: как изменились DORA‑метрики наших «клиентских» команд после подключения нашего сервиса?

Мы уже говорили про снижение рутины в деплое и рост частоты релизов. Чтобы это работало, важно:

• мерить правильные показатели на нужных этапах пайплайна;

• встраивать детекторы дефектов там, где им место;

• балансировать задержки, расход ресурсов и человеческий тоил.

Модель разработки программного обеспечения

Объединив наблюдения и оценку стоимости дефектов, предлагаем модель, сфокусированную на бизнес-стороне процесса. Она позволяет рассуждать об эффективности и оптимизировать разработку на основе наблюдаемых (не контрфактических) измерений.

Параметры для стохастического моделирования:

• Частота генерации дефектов (разработчиком). Зависит от квалификации; со временем падает за счёт практики. Обучение — более точное, но и более дорогое вмешательство.

• Задержка (фаза/проект). Какую wall-clock латентность добавляет каждый этап пайплайна. Поскольку развертывание — «конвейер», сокращение его задержки особенно ценно.

• Стоимость ёмкости аппаратных ресурсов (фаза/проект). Сколько машинных ресурсов требуется этапу для нужных тестов и вычислений.

• Затраты инженерной ёмкости (фаза/проект). Сколько людей вовлечено на каждом этапе. Во время деплоя время разработчиков обычно не требуется; местами разумно снижать участие людей и в разработке.

• Обнаружение дефектов (фаза/проект). Доля дефектов, отсеянных на данном этапе.

• Ложноотрицательные срабатывания (фаза/проект). Как часто этап пропускает дефект, перенося его обнаружение дальше — с большей длительностью и ресурсными затратами и с вовлечением большего числа людей (особенно при достижении деплоя).

• Ложноположительные срабатывания (фаза/проект). Как часто этап сигналит о проблеме, которой в продакшне не было бы.

Эта сетка параметров задаёт общий язык и позволяет сравнивать команды и проекты без притворных «идеальных» контрфактов.

Консистентность процесса и баланс тестов

Повторяющееся «на каждом этапе каждого проекта» — напоминание: ценность даёт консистентный рабочий процесс. Чем больше общих инструментов и инфраструктуры у команд, тем проще получать эффект масштаба и применять глобальные оптимизации. Но если у проекта особые требования, стандартного процесса может не хватать — допускайте локальные отклонения.

Последние три параметра возвращают к тезису про стоимость vs достоверность тестов. Маленькие и быстрые проверки нужны, но они не всегда репрезентативны. Ближе к релизу сигналы точнее, но дороже по ёмкости. Переносить «всё» в ранние тесты нельзя — вырастут ресурсы и латентность; переносить «всё» в квалификацию релиза тоже нельзя — поздние находки слишком дороги и вовлекают больше людей. Нужен баланс.

Что оптимизируем и как это мерить

Цель — выстроить такой пайплайн, чтобы отфильтровать дефекты до приемлемого качества при минимальной латентности для разработчика и минимальных суммарных затратах на устранение.

Здесь помогает логика стандартных метрик DORA:

• Доля неудачных изменений (Change Failure Rate). Чем лучше фильтруем дефекты по пути к релизу, тем реже инциденты и баги в проде.

• Время восстановления после неудачного развертывания (Time to Restore). Хорошо настроенные процессы и автоматизация дают два плюса:
  — Мониторинг. Переход между поздними фазами (квалификация релиза, канарейка) опирается на метрики и наблюдаемость SRE; улучшая раннее обнаружение, мы повышаем и качество прод-мониторинга. Откатываемые дефекты ловятся мониторингом.
  — Темп фиксов. Если в прод попали некритичные баги, чем быстрее собрать, проверить и выкатить фикс, тем ниже время восстановления.

• От коммита до деплоя (Lead Time). Удобна для сравнения между командами; в большинстве случаев её нужно целенаправленно сокращать.

• Частота релизов. При достаточной автоматизации и мониторинге чаще и меньшими порциями: меньше незавершённой работы, больше времени, когда изменения уже приносят ценность.

Что и как мерить: пост-сабмит vs «человеческая» часть

DORA-метрики относятся к этапам после сабмита и хорошо описывают механику процесса: умеем ли мы вовремя находить баги, надёжно деплоить и выполнять SLO/SLA. Улучшения в CI, релизах, канареечных выкладках и мониторинге напрямую подтягивают эти системные показатели; команды могут внедрять и докручивать такие решения сами. Важно не только мерить, но и снижать общий объём ручного участия в процессе.

Напротив, метрики «человеческой» части — это про эффективность отдельных инженеров в творческой работе. Из-за гетерогенности изменений здесь работают агрегаты и метрики использования инструментов на больших популяциях (шире одной команды). Главные рычаги: меньше циклов edit–build–test, больше возможностей IDE (автоматизация, понимание кода), меньше трения для разработчиков. На presubmit влияют: улучшение возможностей, документация, обучение, более качественный дизайн-процесс, мощные IDE, лучшая диагностика, снижение ложноположительных на пресабмите, уменьшение его задержки и код-ревью.

Здесь полезны и качественные сигналы: спрашивать разработчиков, насколько они чувствуют себя продуктивными, — рабочая (хоть и ограниченная) прокси-метрика. В DORA продуктивность рассматривается как метрика благополучия именно по этой причине; фрустрации часто указывают на узкие места в творческом процессе.

Заключение

Смотрим на коммерческую разработку целостно — и видим, где именно возникают напряжения между факторами и как изменения в одной фазе или в инфраструктуре отражаются на других. Мы разделили четыре вида эффекта, предупредили о рисках попыток мерить влияние через неизвестные контрфакты и предложили согласованную оценку стоимости DDR (обнаружения и устранения дефектов).

Такой подход помогает сбалансировать продуктовые результаты и стратегические изменения с человеческими и машинными затратами. В этой модели процесс разработки становится понятнее на разных ролях и уровнях — а значит, его проще целенаправленно улучшать внутри организации.

---

Чтобы не останавливаться на теории и перевести идеи в реальные процессы, пригодятся два практических курса.

• CTO / Технический директор. Про стратегию и операционку технического подразделения: как выстроить структуру, метрики, инвестиции в платформу и снизить ручную рутину. На странице курса можно записаться на бесплатные уроки

• Enterprise Architect. Про связь стратегии и архитектуры: TOGAF, ArchiMate, дорожные карты и управляемый ИТ-ландшафт. Бесплатные уроки курса

А тем, кто настроен на серьезное системное обучение, крайне рекомедуем рассмотреть Подписку — выбираете курсы под свои задачи, экономите на обучении, получаете профессиональный рост. Подробности на странице