Охота за призраками: как увидеть реальный вклад разработчиков

«Ghost engineers» — каждый десятый разработчик практически ничего полезного не делает, лишь имитирует бурную активность. Причём истинные причины бездействия — будь то moonlighting, выгорание или банальное безделье — долго и успешно скрываются от руководства. (Стэнфордское исследование 2024 года: исходный тред)

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

У нас в стране исторически не принято «стучать». Поэтому о проблеме часто знают многие, но говорить никто не хочет: зачем влезать в чужие разборки? Всё всплывает, только когда чаша терпения уже переполнена.

Ну и, может, бог с ними? С призраками этими. В конце концов, у компании денег не убудет.

Но есть одно но…

Под низкой эффективностью я понимаю не ситуацию, когда Вася сидит, пыхтит и делает на 10% меньше Пети. Речь о другом: на каждом стендапе вся команда слушает очередную душещипательную историю — подвели смежники, постановка мутная, звёзды не сошлись. Но завтра задача точно будет готова — «зуб даю».

Только это «завтра» уже было вчера и позавчера — и успело стать традицией.

Команда быстро замечает такие вещи. У тех, кто действительно тащит работу, возникает закономерный вопрос: зачем впахивать, если можно рассказывать небылицы — и тебе за это ничего не будет?

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

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

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

Может ли руководитель заметить проблему раньше — увидеть отклонение, запросить контекст и разобраться до того, как команда потеряет терпение, а компания — время и деньги?

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

• Успехи — мои, провалы — твои
• Превентивные оправдания провала ещё не начатой задачи
• Некомпетентность компенсируется избыточной болтливостью
• Со временем фокус смещается именно на менеджера как «виновника»
• В отличие от объективно испытывающих трудности, поведение не меняется в лучшую сторону даже после прямой обратной связи.

Но чтобы проверить подозрения, нужны цифровые следы.

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

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

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

DORA: скорость и надёжность релизов

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

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

Эти метрики удобны для KPI: в компании, где я работал, их доили с 2018 года, успешно зеленили заборы и все были happy. Актуальная модель DORA.

Тесты и дефекты: насколько хорошо сделано

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

Jira и story points: сколько задач закрыто

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

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

Тоже хороши для KPI. Данные вносятся и задачи двигаются исключительно для прохождения квалити-гейтов. Много ручного бесполезного труда.

Коммиты и строки кода: факты без контекста

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

Swarmia, LinearB и Waydev: вся разработка в одном месте

Swarmia, LinearB и Waydev объединяют Git, таск-трекер и CI/CD: руководитель видит DORA, очереди на ревью, время прохождения изменений, опросы. Хорошая картина инженерной системы — и проблема там часто находится в процессе, а не в человеке. Но сопоставимый объём работы конкретного разработчика для этих платформ не главный вопрос. Swarmia, LinearB, Waydev.

GitClear: что осталось после кодового шума

GitClear различает добавление, перенос и копирование кода, исключает сгенерированные файлы и учитывает, не был ли новый код в итоге переписан или удалён. Так рассчитывается Diff Delta — собственная единица содержательных изменений, оставшихся в кодовой базе. Скопированный или быстро выброшенный код весит меньше компактного изменения, которое продолжает работать в проде. Как устроена Diff Delta.

Diff Delta отвечает не на вопрос, сколько работы потребовалось, а сколько содержательных изменений осталось после шума и переделок. Сильная сторона GitClear — долговечность кода, качество и анализ влияния AI.

Уже теплее. Сервис публикует бенчмарки, но Diff Delta остаётся собственной единицей: число 10 000 без подходящего сравнения и знания методики мало что говорит. Точки отсчёта вроде «100% — норма» здесь нет. Бенчмарки Diff Delta.

BlueOptima: тот же вопрос в масштабе корпорации

С BlueOptima я знаком не понаслышке. Начинал работать с платформой в 2019 году. Именно этот опыт вдохновил на создание собственного продукта.

Алгоритм Coding Effort анализирует каждое изменение исходного кода по набору статических метрик, учитывает его объём, сложность и связанность с остальным кодом, а результат выражает в часах. Это позволяет сравнивать разработчиков из разных команд и технологий, в том числе с глобальным бенчмарком. Для меня это была первая убедительная попытка ответить не на вопрос «сколько строк написал разработчик?», а на вопрос «сколько содержательной работы стоит за этими изменениями?». Методика BlueOptima, глобальный бенчмарк.

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

Та же шкала, но без тендера

Когда я делал DevGhost, я не пытался собрать ещё один комбайн со всеми инженерными метриками. Хотелось того же ответа, что давала BlueOptima — сколько содержательной работы стоит за изменениями, — но чтобы владелец стартапа или небольшой команды обошёлся без тендера, внедрения и команды консультантов.

Логика такая: анализируются сами изменения — что добавлено, удалено и перестроено, насколько сложно это было создать и проверить. Форматирование, переносы, массовые автозамены и сгенерированный код отделяются от содержательной работы. Результат — в эквивалентных часах: за сколько этот код написал бы разработчик среднего уровня, который знает кодовую базу и работает без ИИ. Это не фактическое время за клавиатурой, не оценка качества или бизнес-ценности кода, а единая шкала для сравнения изменений. Подробнее о методике DevGhost.

В Ghost% эта оценка сопоставляется с нормой для разработчика среднего уровня с учётом доли его времени на разработку. 100% означает соответствие норме; ниже — повод разобраться в причинах, выше — результат, который стоит изучить и, возможно, тиражировать как лучшие практики.

Эталон намеренно предполагает работу без ИИ. DevGhost не пытается определить, кто написал конкретный фрагмент — человек, Copilot или автономный агент. Он оценивает итоговые изменения: сколько усилий потребовалось бы разработчику среднего уровня, чтобы создать и проверить их без помощи ИИ.

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

А судьи кто?

Самый очевидный вопрос: почему машинной оценке вообще надо верить? Короткий ответ — слепо не надо.

Оценка сложности работы субъективна по определению. Мы проверяли: давали одни и те же изменения нескольким опытным разработчикам — и получали заметно разные цифры. У каждого своя скорость, опыт и представление о сложности. DevGhost тоже может ошибиться. Его преимущество не в доступе к абсолютной истине, а в том, что все изменения оцениваются по одной шкале — без симпатий, усталости и заранее сложившегося мнения об авторе.

Поэтому Ghost% — не окончательное решение, а сигнал. Низкий показатель может означать слабый вклад, а может объясняться ролью тимлида, архитектурной работой, менторством, инцидентами или блокерами. Цифра показывает, где стоит задать вопрос. Ответ по-прежнему придётся искать руководителю, но уже опираясь на независимое второе мнение, а не только на интуицию.

«Я и так знаю, кто как работает»

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

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

Позже, когда разработчики стали увольняться, выяснилось, что всё это время они параллельно делали собственные продукты. DevGhost не мог знать причину. Он лишь показал то, что не было видно по количеству коммитов, пул-реквестам и ежедневному общению в Слаке: объём работы заметно отличался от ожидаемого.

Но анализ не превратился в список на увольнение. Ещё двум разработчикам низкий результат помог дать предметную обратную связь, разобраться в причинах и улучшить производительность — оба остались в команде.

Сильные разработчики тоже оказались именно там, где их ожидал увидеть техлид. Причём стало видно не только кто оверперформит, но и насколько стабильно это происходит.

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

А если разработчик выдаёт результат за троих?

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

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

Один ограничивается автодополнением. Другой умеет передавать агентам контекст, формулировать правила, вести несколько задач параллельно и тщательно проверять результат. Поэтому одинаковый доступ к ИИ даёт совершенно разный прирост производительности. Высокий Ghost% помогает найти тех, у кого эта связка уже работает, и разобраться, какие практики можно передать остальной команде.

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

Не превращайте шкалу в дубинку

У любой метрики одна судьба: рано или поздно кто-нибудь пытается сделать из неё KPI. Ghost% для этого не подходит. Если сделать Ghost% командным KPI, люди начнут оптимизировать работу под него. Если опубликовать рейтинг — исчезнет доверие. Если превратить показатель в кнопку увольнения — ошибки станут неизбежны.

Я бы зафиксировал четыре правила:

• Не делать выводы по одному измерению или короткому периоду
• Учитывать роль человека, его долю времени на разработку и работу вне кода
• Показывать результат разработчику и давать возможность объяснить контекст
• Не использовать Ghost% как единственное основание для кадрового решения

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

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

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

Ценность цифры не в том, что она выносит приговор. А в том, что сложный разговор начинается раньше и опирается на факты.

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