DORA 2025, Часть 2. Определение эффективности поставки ПО: взгляд на семь профилей команд

Nathen Harvey - руководитель DORA, Google Cloud

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

Мы можем многое сделать заранее, чтобы быть уверенными, что продукт будет работать как задумано, но именно момент релиза показывает, превращаются ли ожидания в реальность - или нет. Запуск нового софта - это не просто выпуск приложения или сервиса. После релиза пользователи начинают давать обратную связь, и она будет либо побуждать, либо прямо вынуждать вас вносить улучшения.

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

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

Мы провели кластерный анализ, чтобы понять человеческие и системные факторы, стоящие за эффективностью поставки ПО, и выявить повторяющиеся модели поведения команд. Статистический анализ выделил семь типов команд, учитывая следующие параметры: 1. Командная эффективность Оценивает, насколько эффективно работает ближайшая команда человека и насколько хорошо она сотрудничает. 2. Эффективность продукта Измеряет качество и успешность продукта или сервиса, над которым работает команда.

Учитываются такие характеристики, как способность помогать пользователям выполнять важные задачи, безопасность данных и метрики производительности (например, задержки). 3. Пропускная способность поставки ПО Показывает скорость и эффективность процесса поставки. 4. Нестабильность поставки ПО Отражает качество и надежность процесса развертываний. 5. Индивидуальная эффективность Самооценка сотрудником своей продуктивности и чувства достижения в работе. 6.

Ценность работы Доля времени, которую человек считает действительно полезной и значимой. 7. Трение в процессе Оценивает, насколько препятствия мешают выполнению работы. Меньше трения - лучше результат. 8. Эмоциональное выгорание Оценивает чувство истощения и цинизма, связанное с работой. Более низкий уровень - позитивный признак.

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

Они сталкиваются с серьезными проблемами, связанными с фундаментальными пробелами в процессах, рабочей среде и результатах. Доля респондентов: 10% участников опроса относятся к кластеру 1. Показатели эффективности: ключевые метрики, связанные с результативностью команды, качеством поставки продукта и созданием ценности, стабильно низкие. Благополучие команды: по данным исследования, у сотрудников наблюдаются высокие уровни выгорания и значительные препятствия в работе. Стабильность системы: заметны серьезные проблемы со стабильностью программного обеспечения и операционной среды.

Кластер 2: Узкое место наследия Команды в этом кластере постоянно работают в режиме реакции. Нестабильные системы определяют их повседневную работу и подрывают моральный дух. Доля респондентов: 11% участников опроса относятся к кластеру 2. Показатели эффективности: ключевые метрики качества продукта низкие. Команда регулярно выпускает обновления, но их ценность значительно снижается из-за постоянных проблем с качеством. Благополучие команды: данные показывают тяжелую рабочую среду.

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

В итоге - высокий уровень выгорания и низкое влияние на продукт и бизнес. Доля респондентов: 17% участников опроса относятся к кластеру 3. Показатели эффективности: ключевые метрики отражают низкую результативность и ограниченную способность создавать бизнес-ценность или пользу для пользователей. Благополучие команды: данные показывают высокий уровень выгорания и значительное трение в работе.

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

Однако их стиль работы - низкочастотная поставка: низкая пропускная способность и высокая нестабильность релизов. Доля респондентов: 7% участников опроса относятся к кластеру 4. Показатели эффективности: команда стабильно достигает высоких уровней продуктивности.

И метрики индивидуальной эффективности, и показатели продуктовой ценности - на сильной стороне. Благополучие команды: данные показывают низкий уровень трения, что указывает на эффективные и хорошо согласованные процессы. Стабильность системы: операционная среда отличается высокой нестабильностью. Такой уровень волатильности создает серьезные риски для надежности сервиса и его долгосрочной устойчивости. Кластер 5: Стабильные и методичные Эти команды - словно надёжные мастера своего дела.

Они создают качественный и ценный продукт, работая в размеренном и устойчивом темпе. Доля респондентов: 15% участников исследования относятся к кластеру 5. Показатели эффективности: ключевые метрики качества продукта и создания ценности стабильно высокие.

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

Кластер 6: Прагматичные исполнители Эти команды стабильно показывают высокую скорость и надёжность поставки, даже если рабочая среда еще не достигла максимального уровня вовлеченности. Доля респондентов: 20% участников исследования относятся к кластеру 6. Показатели эффективности: ключевые метрики поставки ПО сильные - пропускная способность выше среднего, нестабильность низкая.

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

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

Кластер 7: Гармоничные высокоэффективные команды Так выглядит подлинное мастерство: устойчивый рабочий цикл, где стабильная среда без лишних препятствий позволяет команде создавать высококачественный продукт без выгорания и в долгосрочной перспективе. Доля респондентов: 20% участников опроса относятся к кластеру 7. Показатели эффективности: команда показывает сильные результаты во всех ключевых областях - от благополучия сотрудников до продуктовых метрик и качества поставки ПО. Благополучие команды: рабочая среда отличается низким уровнем выгорания и минимальным количеством факторов, мешающих работе. Стабильность системы: команда работает на надежной, устойчивой технической основе, которая поддерживает и скорость, и качество.

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

Данные ниже показывают, как распределились ответы участников опроса DORA 2025, и помогают лучше понять общую картину. Распределение времени выполнения измененийВопрос в опросе: Каково ваше время выполнения изменений - то есть сколько проходит от момента коммита до момента успешного запуска кода в продакшене?

Частота развертыванийВопрос в опросе:Как часто ваша организация развертывает код в продакшн или выпускает его для конечных пользователей?

Распределение времени восстановления после неудачного развертыванияВопрос в опросе: Сколько обычно занимает восстановление сервиса после того, как изменение в продакшене или выпуск для пользователей приводит к ухудшению работы сервиса (например, сбою или недоступности) и требует исправления - хотфикса, отката, исправления "вперёд" или патча?

Распределение доли неуспешных развертыванийВопрос в опросе:Какой приблизительный процент изменений в продакшене или релизов для пользователей приводит к ухудшению работы сервиса (например, к сбоям или недоступности) и требует последующего исправления - хотфикса, отката, фикса "вперёд" или патча, если такие случаи происходят?

Распределение доли переделокВопрос в опросе:Какой приблизительный процент развертываний за последние шесть месяцев был незапланированным и выполнялся для устранения ошибки, влияющей на пользователей?

Метрики производительности дают общее представление о том, как работает весь процесс доставки. Если отслеживать их в динамике, можно понять, улучшаетесь вы или нет. При этом способы улучшения для каждого приложения будут разными, хотя иногда встречаются общие проблемы - например, затянутые циклы ревью и согласований. Представим пример. На регулярной ретроспективе команда обсуждает свои показатели и замечает, что lead time - время от коммита до продакшена - начал расти.

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

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

Каким бы ни был текущий профиль команды - "Ограничены процессами" или "Стабильные и методические" - цель одинакова: развивать культуру постоянного улучшения, которая со временем приводит к более устойчивой, продуктивной и гармоничной работе. Читайте третью часть исследования, посвященную применению и использованию ИИ в разработке.

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