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

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

Дальше разберём, почему количественные метрики кода — слабый сигнал, что вместо них давно используют два признанных инженерных фреймворка — SPACE и DORA, — и какие личные, по-настоящему локальные прокси-метрики можно измерить у себя, не залезая в содержимое кода или переписки. В англоязычной литературе эту область в целом называют developer productivity metrics — но за любым названием стоит один и тот же вопрос: как измерить работу программиста так, чтобы цифра отражала реальность, а не превращалась в мишень, под которую подгоняют поведение. Именно на этом стыке — между известными индустриальными фреймворками и тем, что реально можно посчитать без слежки за содержимым, — и стоит разбираться в метриках продуктивности разработчика.

Продуктивность разработчика ветвится так же, как история коммитов — редко по прямой.

Оглавление

• Почему строки кода и число коммитов не работают как метрика
• SPACE: пять измерений продуктивности разработчика
• DORA-метрики: инженерная эффективность команды
• Таблица: SPACE и DORA против того, что реально можно измерить локально
• Личные прокси-метрики: глубокая работа, переключения и ритм коммитов
• Как DevPace считает это технически честно
• Как использовать эти метрики на практике
• Итог

Почему строки кода и число коммитов не работают как метрика

Идея измерять работу программиста числом написанных строк кода почти ровесница самого программирования. И почти столько же лет существует контраргумент: хорошее инженерное решение почти всегда короче плохого. Удаление трёхсот строк дублирующегося кода и замена его двадцатью строками общей функции — это явно более сильная инженерная работа, чем добавление трёхсот новых строк, но по метрике “строк кода” она выглядит как отрицательный результат. Метрика поощряет многословность там, где ценность создаёт лаконичность, и это не гипотеза, а давно known issue, воспроизводимый в любой команде, которая пробовала завязать на неё оценку работы.

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

Есть и более тонкая проблема: обе метрики измеряют объём производимого артефакта, а не то, была ли решена задача. Разработчик может провести весь день в отладке сложного race condition, найти причину, исправить её тремя строками кода и одним коммитом — и по любой метрике объёма этот день будет выглядеть как почти нулевой. Другой разработчик за тот же день может нагенерировать сотни строк шаблонного кода и десяток коммитов, не продвинувшись ни в одной содержательной задаче. Метрики объёма систематически недооценивают отладку, проектирование, ревью чужого кода, менторство — то есть значительную часть реальной инженерной работы, которая не оставляет пропорционального следа в diff’е.

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

SPACE: пять измерений продуктивности разработчика

SPACE — фреймворк, описанный в статье Николь Форсгрен, Марго Стори и Крис Маддила с соавторами, опубликованной в ACM Queue в 2021 году. Его центральный тезис прямо отвечает на проблему из предыдущего раздела: продуктивность разработчика — многомерное явление, и попытка свести её к одной метрике (будь то строки кода, коммиты или что угодно ещё) неизбежно теряет часть картины и создаёт стимулы к её оптимизации в ущерб остальным измерениям. Название фреймворка — акроним из пяти измерений.

Satisfaction and well-being — удовлетворённость и благополучие. Насколько разработчик доволен своим инструментарием, командой, процессом и работой в целом, и насколько работа сказывается на его выгорании и усталости. Это измерение, которое количественные метрики объёма кода не видят вообще: можно закоммитить много кода, находясь на грани выгорания, и метрика объёма этого не покажет.

Performance — результат работы с точки зрения того, что она приносит, а не сколько её произведено: качество и надёжность кода, соответствие результата целям бизнеса или пользователя. Авторы фреймворка специально разводят Performance (результат) и Activity (объём произведённых действий) — это разные измерения, и путать их означает возвращаться к той же ошибке, что и с подсчётом строк кода.

Activity — количество произведённых артефактов и действий: коммитов, pull request’ов, задач, документов. SPACE не говорит, что Activity бесполезна как измерение — она полезна, но только в связке с остальными четырьмя, а не как самостоятельная универсальная метрика. Именно попытка использовать одну Activity в изоляции (то есть считать коммиты или строки кода единственным мерилом) и есть та ошибка, о которой шла речь выше.

Communication and collaboration — насколько хорошо налажены коммуникация и совместная работа внутри команды и между командами: качество документации, скорость и содержательность код-ревью, то, насколько легко новому человеку разобраться в существующей системе.

Efficiency and flow — способность продолжать работу с минимумом простоев и прерываний: сколько времени уходит на ожидание (ревью, деплоя, ответа коллеги) в противовес непрерывной сфокусированной работе, и насколько хорошо организованы процессы, чтобы не создавать искусственных задержек.

Ключевая практическая идея SPACE — не в том, чтобы измерять все пять измерений сразу и всегда, а в том, чтобы при выборе любой метрики продуктивности разработчика сознательно проверять, какое измерение она отражает и какие из оставшихся четырёх она может исказить, если начать оптимизировать только её. Число коммитов — это Activity. Взятое одно, без остальных четырёх измерений, оно не говорит ничего ни о Performance, ни о Satisfaction, ни об Efficiency and flow — и именно это делает его плохой самостоятельной метрикой продуктивности разработчика, но не значит, что Activity как одно из пяти измерений бесполезна в принципе.

DORA-метрики: инженерная эффективность команды

DORA (DevOps Research and Assessment) — исследовательская программа, из которой выросли ежегодные отчёты State of DevOps, а её метрики — четыре ключевых показателя, которые описывают не продуктивность отдельного разработчика, а эффективность процесса поставки программного обеспечения командой или организацией в целом. Это важное отличие от SPACE: DORA-метрики агрегированы на уровне команды или сервиса, а не на уровне человека, и именно поэтому их не пытаются использовать для оценки отдельных сотрудников.

Deployment frequency — частота развёртывания изменений в продакшн. Команды с зрелым процессом деплоят часто и небольшими порциями; редкие крупные релизы статистически связаны с более высоким риском и более долгим циклом обратной связи.

Lead time for changes — время от коммита изменения до его успешного развёртывания в продакшн. Это метрика скорости всего конвейера — от кода до пользователя, — а не скорости написания самого кода.

Change failure rate — доля изменений, которые приводят к сбою в продакшне и требуют исправления, отката или патча. Она балансирует Deployment frequency: увеличивать частоту релизов, одновременно роняя продакшн каждым вторым из них, — не улучшение, а другая проблема.

Time to restore service — время, необходимое для восстановления сервиса после сбоя, вызванного изменением. Это метрика устойчивости: не “случаются ли сбои” (они случаются у всех), а насколько быстро команда способна их обнаружить и исправить.

Все четыре метрики измеряют систему поставки, а не человека внутри неё — команда может улучшать все четыре показателя, меняя процесс код-ревью, автоматизацию тестов или инфраструктуру деплоя, без единого разговора о том, кто из разработчиков сколько закоммитил. Это прямая противоположность подходу “считать коммиты”: DORA сознательно избегает индивидуальных метрик именно потому, что их легче обмануть и легче использовать во вред команде.

В ежегодных отчётах State of DevOps, которые публикует команда DORA, эти четыре метрики также используются для того, чтобы отнести организацию к одной из категорий зрелости процесса поставки — от низкой до элитной. И здесь важна та же оговорка, что и с личными метриками: категория присваивается команде или сервису по совокупности всех четырёх показателей сразу, а не по одному из них в изоляции, и уж тем более не отдельному разработчику внутри команды.

Таблица: SPACE и DORA против того, что реально можно измерить локально

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

Из этой таблицы видно две вещи. Во-первых, ни SPACE, ни DORA не сводятся к тому, что можно посчитать одним фоновым агентом на рабочем компьютере — оба фреймворка сознательно многомерны и включают измерения, для которых нужен либо опрос человека (Satisfaction), либо данные внешних систем — CI/CD, мониторинга, трекера задач (все четыре метрики DORA). Инструмент, который утверждает, что закрывает SPACE или DORA целиком по одной лишь телеметрии активности на компьютере, либо преувеличивает, либо тайно анализирует то, что не должен.

Во-вторых, три измерения — Activity, отчасти Communication and collaboration и отчасти Efficiency and flow — действительно поддаются честному локальному измерению без анализа содержимого. Именно на этих трёх и построен следующий раздел.

Личные прокси-метрики: глубокая работа, переключения и ритм коммитов

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

Доля глубокой работы. Это прокси для измерения Efficiency and flow из SPACE: непрерывная работа в одной технической категории активности (например, в IDE) без частых переключений против раздробленного дня из множества коротких эпизодов. Метрика не оценивает, что именно человек делал внутри этой категории — только структуру времени: было ли оно непрерывным или раздробленным.

Частота переключений между категориями. Второй прокси для того же измерения Efficiency and flow, только с другой стороны: сколько раз в час происходит переход между технической категорией “IDE/терминал” и категориями вроде браузера, мессенджера или почты. Здесь же появляется частичный прокси для Communication and collaboration: доля переключений, вызванных именно коммуникационными приложениями, показывает, насколько день состоит из непрерывной инженерной работы против постоянного переключения на общение — без чтения того, что именно обсуждалось. Подробнее о том, почему универсального “правильного” числа переключений не существует и что осмысленно с этой метрикой делать, — в статье “Переключения контекста: сколько — это нормально”.

Ритм git-активности по времени суток и по дням. Прокси для измерения Activity, но с важной оговоркой: это факт из истории репозитория (был ли сделан git commit), а не наблюдение за поведением в реальном времени, и метрика полезна не как абсолютное число, а как персональный ритм — в какие дни и часы коммиты обычно случаются, а в какие — нет. День без единого коммита не равен непродуктивному дню: ревью, проектирование и отладка без финального пуша не оставляют следа в этой метрике, но могут занять весь рабочий день. Именно поэтому DevPace показывает график git-коммитов по дням как самостоятельный, отдельный график, а не смешивает его с метриками активности в одно сводное число.

Все три метрики объединяет одно свойство: они измеряют структуру и ритм рабочего дня, а не его содержимое. Отличие принципиальное. “Сколько времени было непрерывной работы в IDE” — это метаданные о категории и длительности сессии. “Что именно писал разработчик в этой сессии” — это уже содержимое, и его DevPace осознанно не собирает и не анализирует ни в каком виде.

Пример: два дня с одинаковым числом коммитов

Возьмём гипотетическую ситуацию, которая хорошо показывает, зачем нужны сразу три прокси-метрики, а не одна. У разработчика два дня подряд закончились одним и тем же результатом в истории репозитория — по одному коммиту в каждый день. По метрике “число коммитов” эти дни неразличимы: оба выглядят как ровно один пункт Activity.

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

Во второй день то же самое активное время — почти пять часов, — но раздроблено на два десятка эпизодов по 10-15 минут, между IDE и почтой с мессенджером. Доля глубокой работы низкая, частота переключений — заметно выше обычной для этого человека, и почти все переключения вызваны именно коммуникационными приложениями. Единственный коммит за день — небольшое исправление, сделанное урывками между переписками, совещаниями и переключением контекста на чужие вопросы.

Метрика “один коммит в день” в обоих случаях говорит одно и то же — и говорит неправду, потому что за одинаковым числом коммитов стоят два совершенно разных дня. Доля глубокой работы и частота переключений — это ровно те два измерения, которые различают эти дни, оставаясь при этом честными метаданными: ни в одном из трёх показателей нет ни строчки содержимого того, что обсуждалось в переписке или писалось в коде.

Как DevPace считает это технически честно

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

Git-коммиты считаются отдельно и ещё проще: агент фиксирует сам факт и время коммита — то есть те же метаданные, что видит любой участник репозитория командой git log, — но не читает содержимое диффа. Число и время коммитов — публичная информация внутри самого репозитория; DevPace лишь агрегирует её в график по дням, вместо того чтобы требовать смотреть историю репозитория вручную.

Поскольку речь идёт об агенте, который стоит в фоне на рабочем компьютере, слов “мы не читаем содержимое” не всегда достаточно — это утверждение, которое хочется проверить, а не принять на веру. Агент DevPace для этого открыт исходным кодом: любой, кто умеет читать код, может открыть репозиторий github.com/ak-alz/gla-client и увидеть ровно то место, где агент определяет категорию активного окна, какие поля он извлекает, а какие сознательно отбрасывает — включая заголовок окна и содержимое экрана. Это не декларация о намерениях в политике конфиденциальности, а факт, который проверяется чтением кода.

Как использовать эти метрики на практике

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

Не стоит превращать долю глубокой работы, частоту переключений или ритм коммитов в новый индивидуальный KPI для оценки эффективности сотрудника — это тот же самый закон Гудхарта, который сломал метрику строк кода: как только показатель становится целью, разработчик начинает оптимизировать именно его (держать IDE открытым фоном, чтобы не засчитывалось переключение), а не содержательную работу, которую показатель изначально пытался отразить.

Не стоит сравнивать эти показатели между разными людьми или ролями напрямую. У разработчика в режиме глубокой отладки одной задачи норма переключений и норма коммитов будет совсем не такой, как у тимлида, который весь день синхронизирует несколько параллельных потоков работы — и обе картины нормальны для соответствующей роли. Осмысленное сравнение — с собственными предыдущими днями и неделями, а не с чужим ориентиром: если обычно у человека 4-5 переключений в час, а сегодня 12 — это заметное отклонение именно для него, вне зависимости от того, какая цифра “нормальна” у кого-то ещё.

Не стоит читать любую из трёх метрик в изоляции. Низкая доля глубокой работы при высокой частоте переключений в коммуникационные приложения — это не “человек плохо фокусируется”, а, возможно, сигнал о неделе с повышенной координационной нагрузкой. Ноль коммитов при высоком активном времени в IDE — не “ничего не делал”, а, возможно, день, полностью ушедший в отладку без финального пуша. Именно поэтому DevPace синтезирует несколько таких сигналов в единую фразу-статус ритма дня, а не выводит шесть разрозненных цифр, которые пользователю пришлось бы сопоставлять самостоятельно.

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

Итог

Строки кода и число коммитов — плохая метрика продуктивности разработчика не потому, что цифры сами по себе неверны, а потому что метрика объёма, взятая изолированно, поощряет оптимизацию себя самой в ущерб содержательному результату — классический эффект закона Гудхарта. SPACE и DORA существуют как ответ на эту проблему: SPACE описывает продуктивность разработчика через пять измерений сразу (Satisfaction, Performance, Activity, Communication, Efficiency), явно предупреждая не сводить их к одному числу; DORA измеряет не человека, а инженерный процесс поставки через четыре метрики — частоту деплоя, время выполнения изменения, долю сбойных изменений и скорость восстановления.

Ни один из фреймворков не сводится к тому, что фоновый агент может честно посчитать на одном рабочем компьютере — для этого нужны опросы, данные CI/CD и системы мониторинга инцидентов. Но три личных прокси-метрики — доля глубокой работы, частота переключений между категориями и ритм git-коммитов — измеримы локально и технически честно, если инструмент фиксирует только категорию и длительность активности и факт коммита, а не содержимое кода, экрана или переписки. Это не замена SPACE и DORA, а дополнение к ним на уровне отдельного человека — и именно на этом принципе построена аналитика DevPace.

Смотрите также

• Глубокая работа: почему процент важнее часов
• Переключения контекста: сколько — это нормально
• Открытый код агента DevPace: не верьте на слово, проверьте сами

Ритм git-активности по дням — один из немногих сигналов продуктивности, который честно строится на метаданных репозитория, а не на телеметрии окон.

Посмотреть демо

Опубликовано: 26 июля 2026 г.