Казалось бы, волшебную ИИ-таблетку уже изобрели, и пора бы всем разработчикам выдавать в три-четыре раза больше качественного кода. Так почему этого не происходит? Может, померяем, насколько усердно они бьют по клавиатуре, возьмем количественные показатели из фреймворка DORA… и все равно не поймем, что не так. А как насчёт фреймворка SPACE? Опять чего-то не хватает. Возможно, стоит смотреть и шире, и глубже одновременно. Разработчик же не сферический конь в вакууме: он общается с коллегами, ищет документацию, ждет согласований начальства, и на все это уходят время и силы, которых уже не остается на написание кода.

Чтобы учесть скрытые хронофаги и узкие места, DORA и SPACE стоит дополнить метриками DevEx, и тогда, возможно, пазл сложится. Разберем, какие метрики за что отвечают и как ИИ-инструменты меняют измерение DevEx в 2026 году. Подробности под катом.

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

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

Если коротко…

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

Почему количественные показатели больше не работают

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

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

Как пишет компания Gartner, в 78% организаций уже есть официальная инициатива по DevEx или ее планируется внедрить, то есть это уже не дополнительная опция, а нечто само собой разумеющееся.

Три фреймворка: DORA, SPACE и DevEx

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

DORA: эффективность доставки ПО

Фреймворк DORA состоит из четырех метрик, которые по сути стали отраслевым стандартом для доставки ПО:

• Частота развертывания: как часто код доходит до продуктива.

• Время выполнения изменений: время от коммита до запуска в продуктивной среде.

• Процент отказов: Процентное соотношение развертываний, из-за которых возник инцидент

• Среднее время восстановления: как быстро команда восстанавливает все после сбоя

Метрики DORA объективны, их можно взять прямо из систем CI/CD. Единственное, что плохо: они вам расскажут, что произошло, но не расскажут, почему. Если команда реже выдает код, то это говорит о ее выгорании или о стратегическом мышлении, коль скоро она ориентируется на более крупные и лучше подготовленные релизы? Из метрик DORA вы этого не поймете.

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

SPACE: человеческий фактор

Фреймворк SPACE придумали в Microsoft в 2021 году специально как альтернативу для однобокого подхода, который сводит все к одной единственной метрике. SPACE выделяет пять аспектов: 

1. Удовлетворенность и благополучие;

2. Производительность труда;

3. Активность;

4. Коммуникация и взаимодействие, а также

5. Эффективность и состояние потока.

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

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

DevEx: петли обратной связи, когнитивная нагрузка и состояние потока

Три ключевых аспекта этого фреймворка:

• Петли обратной связи: скорость и качество ответов на выполненные действия;

• Когнитивная нагрузка: умственные усилия, которые нужно приложить для выполнения работы;

• Состояние потока: способность концентрироваться, ни на что не отвлекаясь.

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

Сравнение трех фреймворков

Далее подробно рассмотрим три аспекта фреймворка DevEx, включая конкретные метрики каждого из них.

1. Метрики состояния потока

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

Microsoft и GitHub провели исследование среди больше чем 2 тыс. разработчиков. В результате те, у кого в работе случались длительные периоды глубокой концентрации, и те, кто находил свою работу увлекательной, сообщали о росте производительности на 50% и 30% соответственно. Далее на рисунке расписан обычный день разработчика ПО, в том числе все периоды, когда ему приходилось на что-то отвлекаться.

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

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

Метрики состояния потока для отслеживания:

• Время концентрации в течение недели: периоды работы без отвлечений от 90 минут и дольше. Наличие достаточного количества дней, в которые были такие периоды глубокой концентрации, сильно влияет на продуктивность разработчика

• Время, потраченное на встречи: количество часов в неделю, которые разработчик проводит на встречах, с разбивкой встреч на плановые и внеплановые.

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

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

2. Метрики когнитивной нагрузки

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

В данном случае стоит посмотреть, с каким количеством сотрудников разработчик взаимодействует в течение недели. Если число таких сотрудников превышает 7–8 человек, производительность разработчика падает. 

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

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

Метрики когнитивной нагрузки для отслеживания:

• С каким количеством сотрудников взаимодействует разработчик. Конкретные люди, с которыми ему приходится общаться. Важно, чтобы за всю неделю их набиралось не больше 7–8 человек.

• Время на кросс-функциональное взаимодействие. Какой процент времени в неделю ушел на работу с коллегами из других команд.

• Количество сервисов, за которые отвечает разработчик. Когда это соотношение выходит за пределы комфортного, качество работы падает, а реагирование на инциденты замедляется.

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

• Сложность развертывания. Количество шагов, выполняемых вручную и необходимых для релиза. Чем больше шагов, тем медленнее доставляется ПО и тем больше инцидентов.

3. Метрики петли обратной связи

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

Многие петли обратной связи можно измерить. Например, петлю "продукт-разработка" измерить по тому, насколько быстро продуктовая команда отвечает на вопросы по заявкам, заведенным в Jira. Чем быстрее она отвечает, тем выше продуктивность разработчиков.

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

Метрики петли обратной связи для отслеживания:

• Время выполнения изменений. Классическая метрика DORA. Разбейте ее на этапы (время на проверку кода, сборку и тестирование, развертывание), чтобы выявить узкие места.

• Время реакции проверяющего код. Сколько времени проходит от открытия запроса на внесение изменений (pull request) до первой проверки по существу. В случае распределенных команд очень часто именно здесь теряется больше всего времени.

• Время и надежность CI-сборки. Сколько времени уходит на сборку и как часто происходит отказ по причинами, которые не связаны с изменениями, внесенными разработчиком. Flaky-тесты тихо обнуляют любые попытки повысить продуктивность.

• Время реакции продуктовой команды на заявки. Как быстро продуктовая команда отвечает на уточняющие вопросы по заявкам, размещенным в Jira и Linear. Это хороший показатель эффективности коммуникации между командами.

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

Измерение DevEx в эпоху искусственного интеллекта

ИИ-ассистенты для написания кода, например, GitHub Copilot, Cursor и Claude Code, изменили внутренние циклы разработки. В этой ситуации нельзя ориентироваться на традиционные количественные показатели. Они лишь только больше запутывают. Ведь разработчик, берущий на веру код от ИИ-ассистента, добавляет больше строк кода, чем мог бы сам физически написать, если бы целый час барабанил по клавиатуре. Но это не значит, что разработчик стал продуктивнее. Количество строк кода и раньше было не самым надежным показателем, а сейчас оно все больше вводит в заблуждение.

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

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

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

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

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

Как внедрить метрики DevEx и не потерять доверие разработчиков

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

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

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

• Сопоставление данных системы с данными опросов. Системные метрики показывают, что изменилось, а данные опросов – насколько эти изменения значимы. Компании Stripe и Uber дважды в год проводят опросы среди разработчиков и получают довольно высокий процент ответов.

• Одинаковые дашборды для руководства и команды. Если показывать разные данные, команда перестанет вам доверять.

• Список исключений. Стоит четко обозначить, какие метрики измеряться не будут (например, количество коммитов на человека или зарегистрированных часов работы на человека). Это повысит доверие лучше любого скрупулезно составленного регламента.

А теперь собираем метрики вместе…

Полномасштабная программа DevEx объединяет данные из четырех источников: 

1. Система управления версиями (GitHub, GitLab);

2. Система управления проектами (Jira, Linear);

3. Система сборки и тестирования (CI/CD); а также

4. Слой взаимодействия (календарь, мессенджеры). 

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

Специализированные платформы фокусируются на разных аспектах:

• DX делает акцент на опросы и Индекс опыта разработчика (Developer Experience Index).

• LinearB и Jellyfish специализируются на управлении версиями и проектами.

• Worklytics собирает анонимизированные данные о взаимодействии из календаря, чатов, GitHub и Jira и создает дашборд с данными на уровне команды, что позволяет одновременно видеть и метрики доставки ПО, и показатели работы людей.

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

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

P.S. Вопросы из курилки:

С каких метрик DevEx стоит начать небольшой команде?

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

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

Подробные опросы стоит проводить не чаще, чем раз в полгода, можно еще делать небольшие опросы (3-4 вопроса) раз в месяц. Компании Stripe и Uber опрашивают дважды в год, чтобы люди не устали от этого и обеспечили высокий процент ответов. Можно проводить и раз в квартал, но более частые опросы менее эффективны и вызывают у людей раздражение.

Можно ли измерить условия работы разработчика без опросов?

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

Метрики DORA актуальны в 2026 году?

Четыре базовых метрики DORA – по-прежнему хорошая база для измерения эффективности доставки ПО. Однако теперь одних метрик DORA недостаточно. Опытные команды комбинируют DORA с фреймворком SPACE или DevEx для учета человеческих аспектов, которые DORA не учитывает.

С чего начать?

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