Эта глава подготовлена при участии
Nathen Harvey — руководитель DORA, Google Cloud
Эффективность поставки программного обеспечения
Момент выпуска нового программного продукта — это всегда событие, потому что реальная ценность разработки становится понятна только тогда, когда мир может начать ею пользоваться. Этими пользователями могут быть клиенты, партнеры, коллеги, незнакомые люди и даже другие технические системы.
Это также момент, когда мы начинаем понимать, как программное обеспечение будет работать в боевом окружении и насколько хорошо оно удовлетворяет потребности пользователей. Мы можем многое сделать заранее, чтобы быть уверенными, что продукт будет работать как задумано, но именно момент релиза показывает, превращаются ли ожидания в реальность — или нет.
Запуск нового софта — это не просто выпуск приложения или сервиса.
После релиза пользователи начинают давать обратную связь, и она будет либо побуждать, либо прямо вынуждать вас вносить улучшения.
Конечно, существует множество причин, по которым вам может понадобиться изменить приложение: устранить уязвимости безопасности, повысить производительность, снизить операционные расходы или уменьшить углеродный след. В основе этих действий — стремление помочь пользователям и обеспечить долгосрочный успех приложения.
Но важно думать не только о продукте, но и о долгосрочном благополучии команд, которые создают, развертывают, сопровождают и поддерживают это приложение. Чтобы эти команды могли добиваться устойчивых и качественных результатов, им нужны правильные условия и необходимые компетенции.
Все эти факторы вместе с давлением бизнеса двигаться быстрее и добиваться больших результатов привели DORA к тому, что эффективность поставки программного обеспечения стала центральной темой нашего исследования.
{{cta}}
Факторы эффективности поставки ПО
Модель DORA рассматривает процесс поставки ПО на высоком уровне и выделяет два ключевых показателя: пропускную способность и нестабильность.
Пропускная способность
Пропускная способность показывает, сколько изменений может пройти через систему за определенный период времени. Чем выше этот показатель, тем больше изменений организация способна доставлять в продакшн.
DORA измеряет пропускную способность по трём метрикам:
1. Время выполнения изменения
Сколько времени проходит от момента фиксации изменения в системе контроля версий до его развертывания в продакшене.
2. Частота развертываний
Сколько раз команда делает релизы за выбранный период или сколько времени проходит между развертываниями.
3. Время восстановления после неудачного релиза
Сколько времени требуется, чтобы восстановиться после неуспешного развертывания, которое требует немедленного вмешательства.
Нестабильность
Нестабильность показывает, насколько хорошо проходят развертывания. Если релизы проходят гладко, команда может уверенно выпускать больше изменений, а пользователи реже сталкиваются с проблемами сразу после обновления.
DORA оценивает нестабильность по двум метрикам:
1. Доля неуспешных развертываний
Процент релизов, которые требуют немедленного вмешательства.
Чаще всего это приводит к откату изменений или срочному хотфиксу для устранения возникших проблем.
2. Доля незапланированных развертываний
Процент релизов, которые изначально не планировались, но происходят из-за инцидентов в продакшене.
В совокупности эти два показателя дают командам общую картину эффективности поставки ПО. Регулярное измерение этих метрик позволяет увидеть, как меняется качество поставки во времени.
Эти показатели применимы к любому приложению или сервису, независимо от используемого технологического стека, сложности процессов развертывания или типа конечных пользователей.
Смотрите шире, чем просто показатели поставки ПО
Хотя эти пять метрик дают важный срез текущей эффективности, по сути это только результаты. Они показывают, что происходит, но не объясняют, почему.
Низкая частота развертываний, например, может быть следствием технического долга, бюрократии или выгорания команды — и сами метрики не позволяют различить эти причины.
Чтобы связать показатели эффективности с человеческими факторами, которые на них влияют, мы провели кластерный анализ.
Этот метод позволяет выйти за рамки отдельных чисел и выявить семь типичных профилей команд — более глубокие модели, отражающие взаимосвязь между эффективностью, благополучием и рабочей средой.
Поиск общих закономерностей
Мы провели кластерный анализ, чтобы понять человеческие и системные факторы, стоящие за эффективностью поставки ПО, и выявить повторяющиеся модели поведения команд.
Статистический анализ выделил семь типов команд, учитывая следующие параметры:
1. Командная эффективность
Оценивает, насколько эффективно работает ближайшая команда человека и насколько хорошо она сотрудничает.
2. Эффективность продукта
Измеряет качество и успешность продукта или сервиса, над которым работает команда.
Учитываются такие характеристики, как способность помогать пользователям выполнять важные задачи, безопасность данных и метрики производительности (например, задержки).
3. Пропускная способность поставки ПО
Показывает скорость и эффективность процесса поставки.
4. Нестабильность поставки ПО
Отражает качество и надежность процесса развертываний.
5. Индивидуальная эффективность
Самооценка сотрудником своей продуктивности и чувства достижения в работе.
6. Ценность работы
Доля времени, которую человек считает действительно полезной и значимой.
7. Трение в процессе
Оценивает, насколько препятствия мешают выполнению работы. Меньше трения — лучше результат.
8. Эмоциональное выгорание
Оценивает чувство истощения и цинизма, связанное с работой. Более низкий уровень — позитивный признак.
Организации, команды и отдельные сотрудники обычно стремятся повышать командную и продуктовую эффективность, пропускную способность, индивидуальную результативность и долю ценной работы, одновременно снижая нестабильность поставки, трение и выгорание.
Наш анализ показал семь отчетливых архетипов команд — от тех, кто достигает высоких результатов в здоровой и устойчивой среде, до тех, кого ограничивает технический долг или неэффективные процессы.
Кластер 1: Базовые трудности
Эти команды работают в режиме выживания. Они сталкиваются с серьезными проблемами, связанными с фундаментальными пробелами в процессах, рабочей среде и результатах.
Доля респондентов: 10% участников опроса относятся к кластеру 1.
Показатели эффективности: ключевые метрики, связанные с результативностью команды, качеством поставки продукта и созданием ценности, стабильно низкие.
Благополучие команды: по данным исследования, у сотрудников наблюдаются высокие уровни выгорания и значительные препятствия в работе.
Стабильность системы: заметны серьезные проблемы со стабильностью программного обеспечения и операционной среды.
Кластер 2: Узкое место наследия
Команды в этом кластере постоянно работают в режиме реакции. Нестабильные системы определяют их повседневную работу и подрывают моральный дух.
Доля респондентов: 11% участников опроса относятся к кластеру 2.
Показатели эффективности: ключевые метрики качества продукта низкие.
Команда регулярно выпускает обновления, но их ценность значительно снижается из-за постоянных проблем с качеством.
Благополучие команды: данные показывают тяжелую рабочую среду.
Сотрудники сообщают о высоком уровне препятствий в работе и повышенном выгорании.
Стабильность системы: наблюдаются серьезные и частые проблемы со стабильностью ПО и операционной среды, что приводит к большому объёму незапланированной, реактивной работы.
Кластер 3: Ограниченные процессами
Эти команды словно бегут по беговой дорожке. Несмотря на работу со стабильными системами, их усилия поглощаются неэффективными процессами. В итоге — высокий уровень выгорания и низкое влияние на продукт и бизнес.
Доля респондентов: 17% участников опроса относятся к кластеру 3.
Показатели эффективности: ключевые метрики отражают низкую результативность и ограниченную способность создавать бизнес-ценность или пользу для пользователей.
Благополучие команды: данные показывают высокий уровень выгорания и значительное трение в работе. Это указывает на то, что текущие рабочие процессы создают для команды сложную и несбалансированную среду.
Стабильность системы: программная и операционная среда команды стабильна и надежна. Это означает, что техническая нестабильность не является источником проблем с эффективностью и благополучием.
Кластер 4: Высокий эффект при низком ритме
Эти команды создают работу с высоким влиянием — это видно по отличным продуктовым метрикам и высокой индивидуальной эффективности. Однако их стиль работы — низкочастотная поставка: низкая пропускная способность и высокая нестабильность релизов.
Доля респондентов: 7% участников опроса относятся к кластеру 4.
Показатели эффективности: команда стабильно достигает высоких уровней продуктивности. И метрики индивидуальной эффективности, и показатели продуктовой ценности — на сильной стороне.
Благополучие команды: данные показывают низкий уровень трения, что указывает на эффективные и хорошо согласованные процессы.
Стабильность системы: операционная среда отличается высокой нестабильностью. Такой уровень волатильности создает серьезные риски для надежности сервиса и его долгосрочной устойчивости.
Кластер 5: Стабильные и методичные
Эти команды — словно надёжные мастера своего дела. Они создают качественный и ценный продукт, работая в размеренном и устойчивом темпе.
Доля респондентов: 15% участников исследования относятся к кластеру 5.
Показатели эффективности: ключевые метрики качества продукта и создания ценности стабильно высокие.
При этом пропускная способность поставки находится в нижних процентах — что говорит о более спокойном, осознанном ритме работы.
Благополучие команды: данные показывают низкий уровень выгорания и трения — это признак здоровой и устойчивой рабочей среды.
Стабильность системы: программная и операционная среды команды отличаются высокой стабильностью и надежностью.
{{cta}}
Кластер 6: Прагматичные исполнители
Эти команды стабильно показывают высокую скорость и надёжность поставки, даже если рабочая среда еще не достигла максимального уровня вовлеченности.
Доля респондентов: 20% участников исследования относятся к кластеру 6.
Показатели эффективности: ключевые метрики поставки ПО сильные — пропускная способность выше среднего, нестабильность низкая. Команда поддерживает устойчивый ритм и регулярно выдает ценную работу, надежно оправдывая ожидания.
Благополучие команды: главное отличие этого кластера от абсолютных лидеров — показатели благополучия. Данные показывают средний уровень выгорания и трения. Это говорит о том, что рабочая среда функциональна и устойчива, но, возможно, не даёт достаточно факторов, повышающих вовлеченность.
Стабильность системы: программная и операционная среда стабильны и надежны, обеспечивая прочную основу для высокой эффективности команды.
Кластер 7: Гармоничные высокоэффективные команды
Так выглядит подлинное мастерство: устойчивый рабочий цикл, где стабильная среда без лишних препятствий позволяет команде создавать высококачественный продукт без выгорания и в долгосрочной перспективе.
Доля респондентов: 20% участников опроса относятся к кластеру 7.
Показатели эффективности: команда показывает сильные результаты во всех ключевых областях — от благополучия сотрудников до продуктовых метрик и качества поставки ПО.
Благополучие команды: рабочая среда отличается низким уровнем выгорания и минимальным количеством факторов, мешающих работе.
Стабильность системы: команда работает на надежной, устойчивой технической основе, которая поддерживает и скорость, и качество.
Уровни эффективности поставки ПО
Рисунок наглядно подтверждает один из ключевых выводов исследований DORA: мифа о выборе между “скоростью и стабильностью” не существует.
Лучшие команды (кластеры 6 и 7) одновременно демонстрируют и высокую скорость, и высокую стабильность.
На противоположном конце спектра картина резко иная. Команды, сталкивающиеся с базовыми трудностями (кластер 1), испытывают проблемы и со скоростью поставки, и со стабильностью.А команды с высоким влиянием, но низким ритмом (кластер 4) показывают, что скорость без стабильности — опасная и нежизнеспособная стратегия.
Отличные результаты достижимы. Кластеры 6 и 7 составляют почти 40% выборки. Сам факт существования таких команд служит убедительным доказательством того, что подобная модель работы реальна и достижима — это ориентир, к которому могут стремиться организации. Хотя прийти к этому уровню сложно, эти команды демонстрируют: быстрая и качественная поставка ПО — не теория, а наблюдаемая реальность.
Как сравнить себя с другими?
Возможно, вы хотите понять, как ваша команда выглядит на фоне остальных участников исследования этого года. Важно помнить, что измерения проводятся на уровне приложения или сервиса. Такой подход помогает формировать совместную ответственность и вовлеченность разных функций в улучшение результатов.
Кроме того, самое полезное сравнение — это сравнение одной и той же системы во времени. Цель — не обязательно выйти в топ по метрикам поставки, а выстраивать постоянное обучение и улучшение.
Данные ниже показывают, как распределились ответы участников опроса DORA 2025, и помогают лучше понять общую картину.
Распределение времени выполнения изменений
Вопрос в опросе:
Каково ваше время выполнения изменений — то есть сколько проходит от момента коммита до момента успешного запуска кода в продакшене?
Частота развертываний
Вопрос в опросе:
Как часто ваша организация развертывает код в продакшн или выпускает его для конечных пользователей?
Распределение времени восстановления после неудачного развертывания
Вопрос в опросе:
Сколько обычно занимает восстановление сервиса после того, как изменение в продакшене или выпуск для пользователей приводит к ухудшению работы сервиса (например, сбою или недоступности) и требует исправления — хотфикса, отката, исправления “вперёд” или патча?
Распределение доли неуспешных развертываний
Вопрос в опросе:
Какой приблизительный процент изменений в продакшене или релизов для пользователей приводит к ухудшению работы сервиса (например, к сбоям или недоступности) и требует последующего исправления — хотфикса, отката, фикса “вперёд” или патча, если такие случаи происходят?
Распределение доли переделок
Вопрос в опросе:
Какой приблизительный процент развертываний за последние шесть месяцев был незапланированным и выполнялся для устранения ошибки, влияющей на пользователей?
Как применять метрики производительности поставки ПО на практике
Метрики производительности дают общее представление о том, как работает весь процесс доставки. Если отслеживать их в динамике, можно понять, улучшаетесь вы или нет. При этом способы улучшения для каждого приложения будут разными, хотя иногда встречаются общие проблемы — например, затянутые циклы ревью и согласований.
Представим пример. На регулярной ретроспективе команда обсуждает свои показатели и замечает, что lead time — время от коммита до продакшена — начал расти.
Команда могла увидеть это на дашборде, но чаще всего такие вещи ощущаются в процессе работы. Для этих метрик не всегда нужна точность до секунды — команды обычно хорошо понимают, движутся они в правильном направлении или нет.
Чтобы повернуть тренд, нужно понять, что именно его вызывает. Команда смотрит данные в репозитории и аналитических инструментах и видит: код-ревью стали занимать больше времени.
Команда решает, что именно с этим стоит поработать в первую очередь, и обсуждает конкретные шаги:
— поднимать код-ревью в приоритет в ежедневной работе;
— делать изменения меньшего размера, чтобы их было легче и быстрее проверять.
После выбора действий команда договаривается через месяц пересмотреть время согласования изменений и все ключевые метрики доставки, чтобы оценить, дало ли это результат.
Каким бы ни был текущий профиль команды — «Ограничены процессами» или «Стабильные и методические» — цель одинакова: развивать культуру постоянного улучшения, которая со временем приводит к более устойчивой, продуктивной и гармоничной работе.
Читайте третью часть исследования, посвященную применению и использованию ИИ в разработке. В этом разделе мы разбираем, как именно разработчики внедряют ИИ в повседневную работу, какие задачи автоматизируют, какие выгоды получают и с какими ограничениями сталкиваются. Эта часть дает практичное понимание того, как ИИ реально меняет процессы разработки и почему его влияние становится критически важным для команд и компаний.
{{cta}}
.avif)
