DORA 2025, Часть 9. Как выбрать правильные метрики и фреймворки для измерения разработки и влияния ИИ в ИТ-организациях

Разные фреймворки служат разным целям.

Обычно они сфокусированы на трёх направлениях:

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

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

Они помогают понять, зачем вы измеряете и какие действия должны последовать на основе полученных данных.

Фреймворки задают оптику, через которую вы смотрите на данные, и гарантируют, что ваши усилия согласованы с организационными целями.

Чтобы выбрать фреймворк, можно задать себе вопросы:

Что изменилось и заставляет измерять?

Как вы будете использовать инсайты?

Какие решения или улучшения measurement позволит сделать?

Далее идёт «что» - собственно метрики.

Это ключевые концепты, которые подпитывают фреймворк, например метрики скорости или метрики использования.

Обычно существуют два основных подхода к сбору данных.

Первый - self-reported data: сбор информации напрямую у разработчиков об их опыте.

Опросы - ответы на вопросы о мнениях, удовлетворенности, восприятии различных аспектов работы.

Интервью и фокус-группы - индивидуальные и групповые обсуждения для более глубокого изучения тем.

Дневниковые исследования - сбор данных о действиях, мыслях и опыте в процессе работы.

Главное преимущество self-reported data - способность фиксировать субъективный опыт и вещи, которые невозможно измерить автоматизированными способами: удовлетворенность, благополучие, субъективную эффективность.

Плюс - не требуется сложной инструментализации или глубокой наблюдаемости за тулчейнами.

Но существуют и ограничения: сложности стандартизации, сравнения между командами и масштабирования.

Субъективность данных приводит к вариативности интерпретаций и уязвимости к смещению (например, recall bias, social desirability bias).

Второй подход - logs-based measures: метрики, которые извлекаются из используемых разработчиками систем и инструментов. Примеры:

Количество - подсчет артефактов: число коммитов, число пользователей.

Время - сколько времени занимает активность: например, время кодинга или ревью.

Частота - скорость событий: например, количество деплоев в месяц или PR в неделю.

Главное преимущество - непрерывные, стандартизированные данные в масштабе, дающие детализированную картину активности.

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

Также важно понимать, что логи не абсолютно объективны.

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

Измерение процессов разработки - это сложная и непрерывная задача.

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

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

Осознанный выбор фреймворка и метрик помогает выстроить устойчивую систему измерений.

Если ориентироваться на логику PDCA-цикла, то работа может выглядеть так: Plan (Планируйте): определите цели, выберите подходящий фреймворк, заручитесь поддержкой руководства. Do (Действуйте): зафиксируйте базовые показатели и попробуйте изменить часть процессов. Check (Проверяйте): измерьте снова и оцените движение к целям. Adjust (Корректируйте): адаптируйте подход с учетом новых данных.

Мы не предлагаем единый «lучший» фреймворк.

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

Хотя фреймворки различаются структурой и акцентами, многие метрики в них совпадают.

Это означает, что показатели, внедренные сегодня, можно переиспользовать и адаптировать, когда цели или контекст изменятся.

Заключение написано при участии Nathen Harvey - руководитель DORA, Google Cloud.

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

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

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

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

Она показывает семь ключевых возможностей, которые усиливают положительное влияние ИИ на важные организационные результаты.

Понятную и открытую позицию компании по использованию ИИ

Внутренние данные, доступные для работы ИИ

Мы рассматриваем ее как отправную точку для дальнейшего диалога с сообществом DORA и компаниями, которые внедряют ИИ в процессы разработки.

Мы будем рады узнать, как вы применяете эти выводы на практике, и продолжим уточнять и развивать модель в будущих исследованиях.

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

Ранние попытки стандартизации здесь преждевременны.

Одно лишь внедрение ИИ-инструментов не приводит к трансформации.

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

Когда же такого фокуса нет, внедрение ИИ может ухудшить результаты команды.

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

Если пользователь не находится в центре вашей продуктовой стратегии, ИИ не поможет - и в ряде случаев может даже навредить командной результативности.

Результаты отчета этого года сложные и местами могут казаться противоречивыми.

Это нормальное отражение быстро меняющейся среды.

Мы предлагаем относиться к выводам не как к строгим инструкциям, а как к гипотезам для экспериментов внутри вашей команды.

Вот как можно применить эти идеи на практике:

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

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

Проводите внутренние опросы - возьмите за основу вопросы из исследования этого года и адаптируйте их под себя.

Добавьте более тонкие вопросы, релевантные вашим командам и текущим проектам.

Смотрите на платформу целиком - улучшение одной функции не исправляет слабую платформу.

Рассматривайте внутренние платформы как продукты: работайте над всей цепочкой опыта разработчика - от обратной связи до автоматизации.

Делитесь тем, что узнали - когда вы проводите эксперименты и собираете инсайты, распространяйте знания по организации - через отчеты, внутренние сообщества практиков или неформальные разговоры.

Цель - развивать культуру постоянного обучения.

Главный риск в текущей ситуации - не отставание, а массовые хаотичные действия без значимого результата.

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

Спасибо, что работаете с нашим исследованием.

Мы приглашаем вас продолжить путь вместе с нами.

Делитесь своим опытом, учитесь у коллег и черпайте вдохновение, присоединившись к сообществу DORA: https://dora.community.

Исследование DORA - пример силы глобального сообщества, объединённого общей целью.

Мы благодарны тысячам исследователей, экспертов, практиков, лидеров и агентам изменений, которые щедро делятся знаниями и опытом.

Этот отчет - прямой результат коллективной работы.

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