Цифровой тимлид: можно ли измерить эффективность разработчика по коду

Иван начинал программистом и дорос до компании, которая работает в моделях outsource и outstaff; два года назад в DEX открыли продуктовое направление, и UpCore родился как внутренний инструмент. Логика такая: в команде из трёх-четырёх человек тимлид всё видит сам, а на 150 разработчиках, проектах разной сложности и постоянной ротации прозрачность пропадает. Единой формулы грейда на рынке нет — в одной компании человек мидл, в другой сеньор, — и оценка держится на субъективных отчётах. Иван ссылается на старые исследования, которые называет работами Сэкмана, и на более свежие цифры McKinsey: по ним эффективность двух разработчиков одного грейда различается в десять раз. Слово «цифровой» означает, что сравнение делает машина: человек не сопоставит вручную маленький MVP-лендинг и enterprise-проект пятилетней давности на миллион строк с горой легаси.

Искусственного интеллекта в оценке нет: по описанию Ивана, это запатентованная математика, где каждая строка кода получает вес. Задача и merge request превращаются в часы: если у среднего разработчика MR занял бы четыре часа, а в отчёт списано шестнадцать, эффективность равна 25%. Инструмент, который Иван называет «глазом», показывает разбор любого MR построчно. Учитываются язык, переименование класса парой кнопок в IDE — тысяча изменённых строк за десять минут — и архитектурная сложность: проект делится на ядро, средний уровень и периферию, а правка в ядре тянет за собой проверку двух десятков мест, отладку и тесты. Отдельные формулы переводят оценку кода в оценку решения задачи: у фичи больше времени уходит на код, у бага — на поиск. Грейд система выводит минимум за три месяца и больше чем по пятидесяти факторам. За основу взята модель COCOMO II, дальше — эмпирическая настройка на объёме кода, который, по словам Ивана, суммарно превышает сто лет работы.

Александр задаёт провокационный вопрос: чем набор эвристик лучше, чем просто попросить сильную LLM оценить дифф? Иван отвечает, что с этого и начинали — кусок кода отправляли в ChatGPT, — но точность сильно плавала; самых новых моделей он не пробовал, а на тестах, которые помнит по январю-февралю, разброс сохранялся. При этом три живых разработчика дадут четыре, шесть и восемь часов, а совпадение системы с оценкой тимлида Иван заявляет на уровне 80%. Следующий вопрос из чата — про то, что код лишь часть работы инженера. Иван отвечает, что мидлы — основная боевая единица и их дело писать код, а архитектору или тимлиду система засчитывает только время, списанное на задачи: тридцать часов из Jira, отчётов или истории коммитов — и смотрит, во сколько часов кода они превратились. Остальное закрывает косвенный сигнал: если лид не пишет код, но его команда эффективна, вопросов нет.

Свой контраргумент Александр выводит на экран — white paper Google, который он называет Measuring Developer Goals и датирует, по памяти, двадцать вторым или двадцать третьим годом: логи со всего инструментария режутся на события, события собираются в сессии, SDLC делится на этапы, а внутри этапов выделяются цели инженера — аналог jobs to be done: понять, над чем работать, скоординироваться с коллегами, пройти дизайн-ревью, разобраться с требованиями. Сам он привык оперировать верхнеуровневыми метриками вроде DORA и time to market и, когда Иван обещает вырастить TTM в четыре раза, поправляет: его надо уменьшать. Отдельный спор — про требования: если аналитик поставил задачу неполно, доработка вернётся как правка собственного кода и ударит по разработчику. Иван считает слово «штрафует» слишком жёстким — зато проблема становится видимой, а ретроспектива в системе отдельно оценивает качество аналитики. Связки кода с деньгами в продукте нет, и Иван соглашается: это метрика другого уровня.

Зрительские вопросы сходятся к закону Гудхарта. Александр вспоминает и закон Кэмпбелла: у руководителя есть целевые метрики и уравновешивающие их контрметрики, любой показатель — лишь одна из осей, и даже прибыль акционерного общества уязвима, потому что отчёты инвесторам нужны сейчас. Иван признаёт, что подстроить можно любой KPI, но комплексный — сложнее. Его пример искажения — инфляция оценок: разработчик называет восемь часов, тимлид накидывает риски до шестнадцати, менеджер удваивает, наверх уезжают шестьдесят четыре — в сроки команда попадает, а эффективность выходит восемь из шестидесяти четырёх. Самый жёсткий кейс Иван рассказывает без названия компании: коммерческий директор попросил разобрать полгода кода и уволить двадцать процентов отстающих. Из чата прилетает вопрос про мораль такой «двойной децимации». Иван отвечает, что система делает ревью, которое тимлид должен был сделать сам, отчёты открыты самим разработчикам, а в интерфейсе есть окно апелляции: несогласный отмечает спорные merge request, и их разбирает живой человек.

Демо показывает, как это выглядит на одном из проектных офисов самой DEX: общая эффективность в июле — 58%, доля задач с ИИ — 23%, то есть 91 merge request из 396. Компания работает на Claude: сначала купили несколько десятков аккаунтов и раздали желающим, вышел хаос, потом подключили аккаунты к UpCore и стали видеть по каждому человеку долю таких задач, его промпты и их эффективность, а удачные и неудачные паттерны складывать в общую базу обучения. У «вайб-кодеров» эффективность 86% против 58% в среднем, а цель квартала — довести долю merge request, решаемых с Claude, до 80% по компании. Александр просит убрать слово «вайб-кодинг»: то, что описывает Иван, — инженерия с требованиями, проверками и контролем архитектуры, и доверие к агенту требует куда больше доказательств, чем доверие к коллеге, который проработал с тобой пятнадцать лет. Финальная аналогия — Moneyball: Иван видит в фильме победу статистики над взглядом скаута, Александр — сборку команды, где сильные стороны дополняют друг друга. Следующий шаг UpCore Иван видит в обучении людей.