Почему нельзя измерять разработчика строками кода — и что мы делаем вместо этого

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

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

Мы столкнулись с этой проблемой, когда пытались ответить на несколько внешне простых вопросов:

• сколько времени объективно требовало изменение в коде;

• соответствует ли фактическая работа сложности задачи;

• где команда теряет время на переделки и отладку;

• как меняется результат после внедрения AI-инструментов;

• какие риски проекта уже видны в данных, хотя дедлайн еще не сорван.

Сначала мы делали систему для себя

UpCore не начинался как отдельный коробочный продукт. Сначала мы разрабатывали его для собственных нужд компании DEX. Когда одновременно работают разные проектные команды, руководителю недостаточно видеть только бюджеты, сроки и закрытые задачи. Нужно понимать, что происходит внутри разработки и где проект начинает отклоняться от нормальной траектории.

У нас регулярно возникали вопросы, знакомые многим ИТ-директорам и руководителям разработки:

• почему две похожие по оценке задачи потребовали разного времени;

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

• какой проект накапливает технические риски;

• соответствует ли технологический профиль команды стоящим перед ней задачам;

• дает ли внедрение нового процесса или AI-инструмента измеримый результат.

Отвечать на них вручную означало собирать данные из Git, таск-трекера, ревью и отчетов, а затем все равно спорить о субъективности выводов. Поэтому первыми пользователями UpCore стали наши собственные руководители и тимлиды, а рабочие процессы Dex — средой, в которой мы проверяли подход и калибровали модель.

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

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

Отчет разработчика: эффективность, динамика и сравнение с командой. Данные на демонстрационном экране.

Почему один показатель не работает

Представим двух разработчиков.

Первый добавил 800 строк в новый модуль. Второй удалил 500 строк легаси, сохранил поведение системы и сократил число ветвлений. Если считать только объем кода, первый выглядит продуктивнее. Если учитывать поддержку продукта в будущем, вывод может оказаться противоположным.

То же происходит почти с любой одиночной метрикой:

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

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

С чего начинается анализ

Базовая единица наблюдения в UpCore — не строка и не коммит сами по себе, а изменение в контексте проекта.

Упрощенно обработка выглядит так:

Git-репозитории ─┐Задачи и баги ───┤Code review ─────┼──► нормализация ─► анализ изменений ─► контекст проекта ─► отчетыВоркло́ги/табели ┤Данные проекта ──┘

Система подключается к GitLab, GitHub, Bitbucket или совместимому Git-серверу, а также к таск-трекеру. В публичной документации перечислены Jira, YouTrack и Redmine, но интеграционный слой не привязан к одной системе.

Дальше начинается менее заметная, но критически важная работа: очистка данных.

1. Убираем шум

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

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

2. Смотрим глубже объема

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

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

Детализация факторов: результирующий код, контрибуция, архитектурная сложность, баги и code review.

3. Связываем код с процессом

Коммит без задачи сообщает мало. Задача без кода тоже оставляет половину картины за кадром.

Поэтому изменения связываются с задачами, merge request, ревью, багами и доступными данными о затраченном времени. Так можно различить, например:

• создание новой функциональности;

• исправление дефекта;

• повторную работу после ревью;

• рефакторинг;

• удаление легаси;

• исследовательскую задачу, результат которой не обязан выражаться большим diff.

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

4. Анализируем серию событий

Один неудачный merge request ничего не доказывает. Это мог быть инцидент, незнакомый модуль или задача с некорректными требованиями.

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

Как из технических сигналов получается управленческая картина

Система использует более 50 факторов. Мы намеренно не раскрываем их веса и внутреннюю формулу, но на уровне классов данных модель можно описать так:

сложность изменения        +контекст технологии и проекта        +качество результирующего кода        +ревью, баги и переделки        +фактическое время        +динамика на серии задач        =объяснимый набор инженерных показателей

Здесь принципиально важны последние слова — «набор показателей». Итоговый процент удобен для навигации по большому портфелю, но сам по себе он не должен быть приговором. Руководителю нужно иметь возможность провалиться до факторов, периода и конкретных изменений, которые повлияли на результат.

Иначе система повторит ошибку простой таблицы с количеством коммитов, только в более красивом интерфейсе.

Когда CTO наконец увидел стоимость технического долга в деньгах. Кадр из фильма «Духless».

Какие задачи можно решать на этих данных

Раньше замечать риски проекта

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

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

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

Сопоставлять задачи и компетенции

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

История изменений помогает увидеть over-skill и under-skill относительно проекта. Эти данные можно использовать при распределении задач, ротации и составлении индивидуального плана развития. Но корректный сценарий здесь — начало разговора на 1-1, а не автоматическое изменение грейда.

Проверять эффект AI-инструментов

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

Поэтому эффект внедрения AI лучше проверять как изменение нескольких величин до и после:

• трудоемкость сопоставимых задач;

• доля кода, сохранившегося в результате;

• объем повторной работы;

• число и характер дефектов;

• нагрузка на code review;

• динамика по команде, а не единичный удачный пример.

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

Аудировать внешнюю разработку

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

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

Как не превратить аналитику в слежку

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

Мы придерживаемся нескольких правил.

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

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

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

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

Не превращать показатель в норматив выработки. Как только команда начинает оптимизировать публичный KPI, качество самого сигнала падает.

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

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

Что с безопасностью исходного кода

Для многих компаний отправка репозитория во внешний сервис невозможна. Поэтому UpCore поддерживает два варианта эксплуатации:

• SaaS для быстрого пилота;

• развертывание внутри изолированного контура заказчика.

В on-premise-сценарии компоненты анализа, API, хранилище и интеграции работают в инфраструктуре компании. Поддерживаются ролевой доступ, корпоративный SSO и журналирование событий. Возможен и гибридный вариант, когда код обрабатывается внутренним агентом, а наружу передаются только согласованные агрегированные показатели.

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

Как выглядит пилот

Для первой проверки не требуется перестраивать процесс разработки.

1. Выбирается один проект и период истории, достаточный для сравнения.

2. Подключаются репозиторий, задачи, ревью и источник рабочих часов.

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

4. Авторы коммитов сопоставляются с пользователями и задачами.

5. Модель калибруется под стек, тип проекта и роли в команде.

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

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

Вывод

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

Полезная инженерная аналитика начинается с трех вещей:

• контекста вместо одиночной метрики;

• динамики вместо разового рейтинга;

• объяснения вместо непрозрачного вердикта.

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

Подробнее о продукте: up-core.ru

Публичная документация: up-core.ru/landing/docs

Свяжитесь с нами

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

• Телефон: +7 (499) 348-11-07

• MAX: +7 (930) 066-46-20

• Email: office@dex-it.ru

• Telegram: @pmo_dex