Эта глава подготовлена при участии
Sarah D’Angelo, Ph.D. — исследователь пользовательского опыта, Google
Ambar Murillo — исследователь пользовательского опыта, Google AI & Infrastructure
Sarah Inman, Ph.D. — исследователь пользовательского опыта, Google
Kevin M. Storer, Ph.D. — исследователь пользовательского опыта, Google Cloud
{{cta}}
Выбор метрик под цели организации
Измерение процесса разработки помогает запускать реальные изменения. Но это сложная задача: сначала нужно понять, что стоит измерять и что вообще возможно измерить.
Главное — использовать метрики не ради самих чисел, а чтобы менять работу команды и всей организации. Для этого лучше опираться на готовые фреймворки.
Зачем нужны фреймворки?
Фреймворк разбивает широкое понятие (например, «опыт разработчика») на конкретные измеряемые элементы — скорость, качество, удовлетворенность и т.д.
Когда индустрия или академия говорят о метриках разработки, чаще всего упоминают фреймворки:
Выбрать подходящий фреймворк может быть непросто, но это ключевой шаг.
С чего начать?
Сформулируйте, какие решения вы хотите принимать с опорой на данные. Разные фреймворки служат разным целям. Обычно они сфокусированы на трёх направлениях:
- Опыт разработчика
- Качество продукта
- Эффективность организации
Каждая из этих групп задаёт свой взгляд на развитие инженерной системы и на то, как её стоит измерять.
Чтобы определить, какой фреймворк лучше подходит под цели вашей организации, полезно воспринимать фреймворки как «почему» стоящее за измерением. Они помогают понять, зачем вы измеряете и какие действия должны последовать на основе полученных данных. Фреймворки задают оптику, через которую вы смотрите на данные, и гарантируют, что ваши усилия согласованы с организационными целями.
Чтобы выбрать фреймворк, можно задать себе вопросы: почему сейчас? Что изменилось и заставляет измерять? Как вы будете использовать инсайты? Какие решения или улучшения measurement позволит сделать?
Далее идёт «что» — собственно метрики. Это ключевые концепты, которые подпитывают фреймворк, например метрики скорости или метрики использования.
Обычно существуют два основных подхода к сбору данных — это «как» вы будете получать метрики.
Self-reported data — данные, сообщаемые разработчиками
Сбор информации напрямую у разработчиков об их опыте. Это можно делать через:
- Опросы — ответы на вопросы о мнениях, удовлетворенности, восприятии различных аспектов работы.
- Интервью и фокус-группы — индивидуальные и групповые обсуждения для более глубокого изучения тем.
- Дневниковые исследования — сбор данных о действиях, мыслях и опыте в процессе работы.
Главное преимущество self-reported data — способность фиксировать субъективный опыт и вещи, которые невозможно измерить автоматизированными способами: удовлетворенность, благополучие, субъективную эффективность. Плюс — не требуется сложной инструментализации или глубокой наблюдаемости за тулчейнами.
Но существуют и ограничения: сложности стандартизации, сравнения между командами и масштабирования. Субъективность данных приводит к вариативности интерпретаций и уязвимости к смещению (например, recall bias, social desirability bias).
Logs-based measures — данные, собираемые автоматически
Это метрики, которые извлекаются из используемых разработчиками систем и инструментов. Примеры:
- Количество — подсчет артефактов: число коммитов, число пользователей.
- Время — сколько времени занимает активность: например, время кодинга или ревью.
- Частота — скорость событий: например, количество деплоев в месяц или PR в неделю.
Главное преимущество — непрерывные, стандартизированные данные в масштабе, дающие детализированную картину активности.
Ограничение — нужна достаточная наблюдаемость за тулчейном: интеграции, сбор данных, инфраструктура. Это повышает порог входа.
Также важно понимать, что логи не абсолютно объективны. Подходы к инструментализации различаются, ошибки возможны, а интерпретация всегда зависит от контекста и может быть смещенной.
Как связаны фреймворки и метрики
Фреймворк определяет, какие концепты вы хотите измерять, но выбор конкретных метрик зависит от ваших ресурсов и доступности данных.
Нужно понять:
- Есть ли наблюдаемость для logs-based метрик?
- Есть ли исследовательская команда для self-reported данных?
У разных организаций — разные возможности. Фреймворки — это руководство, но они не могут полностью описать сложное поведение. Это приближение к правде, но невозможно измерить всё.
{{cta}}
Полезная аналогия
- Метрики — это ингредиенты.
- Фреймворки — это рецепты, которые используют эти ингредиенты.
Одни и те же ингредиенты можно комбинировать по-разному для получения разных «блюд» — то есть фреймворков. Некоторые ингредиенты уникальны, но во многих случаях можно получить хороший результат, даже если часть ингредиентов отсутствует.
Фреймворки различаются, потому что ориентированы на разные цели. Но их метрики часто пересекаются. Например, метрики продуктивности (число коммитов, PR) встречаются сразу в нескольких фреймворках.
Организация может использовать эти метрики, чтобы оценить влияние новой командной структуры (организационная эффективность), понять, насколько хорошо работает инструмент для разработчиков (продуктовое качество), и оценить нагрузку на разработчиков (опыт разработчика).
В то же время часть метрик более специализирована. Например, благополучие разработчиков — важный элемент фреймворков, ориентированных на developer experience, — обычно не относится к ключевым метрикам в моделях организационной эффективности или продуктового качества.
Использование одного фреймворка помогает сфокусировать действия и может быть хорошей отправной точкой. Но этим не нужно себя ограничивать.
По мере того как цели и возможности измерения меняются, применение нескольких фреймворков позволяет получать взаимодополняющие аналитические результаты — в сумме они дают более цельную картину, чем по отдельности.
Главное — измерять то, что помогает вам и вашей организации удерживать фокус на целях и быть готовыми действовать на основе полученных данных.
Применение фреймворков измерения в эпоху ИИ
Можно задаться вопросом: меняет ли появление ИИ в процессе разработки всё? Подходят ли прежние фреймворки или нужны новые? Любая технологическая трансформация создает ощущение, что метрики нужно перестраивать с нуля. На практике изменения обычно гораздо точнее.
Если ваша цель — понять, как ИИ влияет на опыт разработчиков, достаточно обновить небольшую часть метрик, сохранив общую структуру измерений. Не нужно отказываться от всего фреймворка. Напротив, существующие метрики дают базовый уровень, относительно которого можно видеть сдвиги. Например, вы можете добавить показатели принятия ИИ-подсказок, качества модели или доверия к ней, оставив прежние метрики опыта разработчика — субъективную продуктивность, время на ревью и т.п.
По мере появления более продвинутых ИИ-инструментов изменятся сами роли и набор задач в разработке. Метрики придётся адаптировать под новые профили пользователей и измененные процессы, но цели измерения опыта разработчиков, скорее всего, останутся теми же. Если цель не меняется — не нужно менять и фреймворк, достаточно расширить набор метрик.
Даже если цели всё же меняются, это не означает, что измерение нужно начинать заново. Многие метрики подходят сразу к нескольким фреймворкам, поэтому можно быстро перераспределить их под новые задачи. Например, изучение влияния ИИ-инструментов на создаваемый код стало для компаний новой целью — и сложной задачей, поскольку технология развивается очень быстро.
Частый вопрос — как ИИ влияет на качество кода. Рост скорости разработки выглядит позитивно в краткосрочной перспективе, но если качество падает, долгосрочная скорость тоже начнет снижаться. Поэтому компания может поставить цель: поддерживать высокое качество кода при активном внедрении ИИ-инструментов. Эта цель опирается на элементы всех типов фреймворков и включает метрики, которые часто уже собираются: качество кода, вовлеченность в использование инструмента, субъективная скорость.
В этом случае можно продолжать использовать текущие метрики и добавлять новые. Например, сочетание метрик DORA для поставки ПО с фреймворком продуктового качества вроде HEART дает глубокое понимание того, как команды воспринимают ИИ-инструменты и как те влияют на процесс поставки.
Измерение процессов разработки — это сложная и непрерывная задача. Фреймворков и подходов много, но любой из них приносит пользу только тогда, когда организация способна действовать на основе полученных данных. Ключевым условием становится согласованность с целями компании и поддержка руководства — без этого измерения превращаются в отчетность без результата.
Осознанный выбор фреймворка и метрик помогает выстроить устойчивую систему измерений. Если ориентироваться на логику PDCA-цикла, то работа может выглядеть так:
- Plan (Планируйте): определите цели, выберите подходящий фреймворк, заручитесь поддержкой руководства.
- Do (Действуйте): зафиксируйте базовые показатели и попробуйте изменить часть процессов.
- Check (Проверяйте): измерьте снова и оцените движение к целям.
- Adjust (Корректируйте): адаптируйте подход с учетом новых данных.
Мы не предлагаем единый «лучший» фреймворк. Подход должен соответствовать вашим задачам: правильным будет тот, который помогает вам принимать решения и мотивирует организацию действовать.
Хотя фреймворки различаются структурой и акцентами, многие метрики в них совпадают. Это означает, что показатели, внедренные сегодня, можно переиспользовать и адаптировать, когда цели или контекст изменятся.
Заключение: от понимания к действию
Написано при участии Nathen Harvey — руководитель DORA, Google Cloud
Вот уже больше десяти лет DORA остается надежным ориентиром для инженерного сообщества, помогая командам становиться сильнее и эффективнее. Индустрия быстро меняется: в работу входят ИИ, платформенная инженерия и новые способы организации разработки. Но наша задача неизменна — исследовать и показывать практики, которые помогают создавать по-настоящему высокорезультативные команды.
Модель AI-возможностей DORA
В этом году мы представили первую версию модели AI-возможностей DORA — важный шаг в развитии нашего исследования. По мере того как компании проходят через сложный процесс внедрения ИИ, эта модель дает опорную, основанную на данных структуру. Она показывает семь ключевых возможностей, которые усиливают положительное влияние ИИ на важные организационные результаты.
Эти возможности включают:
- понятную и открытую позицию компании по использованию ИИ
- здоровую экосистему данных
- внутренние данные, доступные для работы ИИ
- зрелые практики контроля версий
- работу малыми итерациями
- фокус на пользователях
- качественные внутренние платформы
Это первая итерация модели. Мы рассматриваем ее как отправную точку для дальнейшего диалога с сообществом DORA и компаниями, которые внедряют ИИ в процессы разработки.
Мы будем рады узнать, как вы применяете эти выводы на практике, и продолжим уточнять и развивать модель в будущих исследованиях.
Фокус на пользователе
Исследование этого года выявляет важный вывод: мы всё еще на раннем этапе развития ИИ-ассистированной разработки — в периоде, когда технологии быстро меняются, а практики только формируются. Ранние попытки стандартизации здесь преждевременны. Одно лишь внедрение ИИ-инструментов не приводит к трансформации. Более того, влияние ИИ на работу команды напрямую зависит от одного критического фактора — фокуса на пользователе.
С высокой степенью уверенности мы установили:
когда команда ориентируется на пользователей, положительное влияние ИИ на ее работу усиливается. Когда же такого фокуса нет, внедрение ИИ может ухудшить результаты команды.
Этот вывод подчеркивает ключевое условие успеха: глубокое понимание конечных пользователей — не бонус, а обязательная основа для эффективного применения ИИ.
Если пользователь не находится в центре вашей продуктовой стратегии, ИИ не поможет — и в ряде случаев может даже навредить командной результативности.
Практическое применение исследования: ваша очередь экспериментировать
Результаты отчета этого года сложные и местами могут казаться противоречивыми. Это нормальное отражение быстро меняющейся среды. Мы предлагаем относиться к выводам не как к строгим инструкциям, а как к гипотезам для экспериментов внутри вашей команды.
Вот как можно применить эти идеи на практике:
- Проводите эксперименты в вашей организации
Используйте выводы DORA, чтобы формулировать гипотезы и проверять их в ваших командах. Это поможет лучше понять ваш операционный контекст и определить зоны, где улучшения дадут наибольший эффект.
- Проводите внутренние опросы
Возьмите за основу вопросы из исследования этого года и адаптируйте их под себя. Добавьте более тонкие вопросы, релевантные вашим командам и текущим проектам.
- Смотрите на платформу целиком
Улучшение одной функции не исправляет слабую платформу. Рассматривайте внутренние платформы как продукты: работайте над всей цепочкой опыта разработчика — от обратной связи до автоматизации.
- Делитесь тем, что узнали
Когда вы проводите эксперименты и собираете инсайты, распространяйте знания по организации — через отчеты, внутренние сообщества практиков или неформальные разговоры. Цель — развивать культуру постоянного обучения.
Главный риск в текущей ситуации — не отставание, а массовые хаотичные действия без значимого результата. Выбирайте подходы и фреймворки, которые соответствуют вашей организации и побуждают вас к осмысленным изменениям.
Присоединяйтесь к разговору
Спасибо, что работаете с нашим исследованием. Мы приглашаем вас продолжить путь вместе с нами. Делитесь своим опытом, учитесь у коллег и черпайте вдохновение, присоединившись к сообществу DORA: https://dora.community.
Исследование DORA — пример силы глобального сообщества, объединённого общей целью. Мы благодарны тысячам исследователей, экспертов, практиков, лидеров и агентам изменений, которые щедро делятся знаниями и опытом. Этот отчет — прямой результат коллективной работы.
Спасибо нашему читателю. Мы надеемся, что результаты исследования помогут вам и вашим командам создавать реальные изменения и выстраивать культуру непрерывных улучшений внутри ваших организаций.
{{cta}}
