В ночь подопечный проект прислал занятный запрос о помощи:

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

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

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

Сам ответ не процитирую, там есть чувствительные нюансы, а вот матчасть можно и выложить:

В принципе есть методология DORA. Она легко гуглится и по ней некоторые компании публикуют свои достижения / метрики

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

что там есть:

Cycle Time – время от старта задачи до продакшна. Это реальная скорость работы команды.
Deployment Frequency – как часто выкатываются релизы. Хорошие команды работают с CI/CD и выкатываются минимум раз в неделю.
Change Failure Rate – сколько изменений приходится откатывать из-за багов. Если команда пишет код быстро, но с кучей багов – это плохая команда.
Mean Time to Recovery (MTTR) – время на исправление ошибок после обнаружения.
Lead Time for Changes – сколько времени проходит от первой строки кода до продакшна.

формально по методологии там смотрят на:
Pull Request'ы — сколько кода разработчик реально пишет (но без фанатизма).
Cycle Time на задачу — как быстро задачи проходят через него.
Code Review Participation — насколько активно он участвует в ревью.
Качество кода — насколько его код потом не падает.
Частота релизов и багов — если он постоянно фиксит баги, значит пишет некачественный код.

Опыт, текущий вклад и будущие задачи

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

1. ретро
Какая доля кода написана при его участии или он уже вникал в нее и оптимален для поддержки этого кода.
Какая доля проектировки проходила с его участием и какая доля недокументированных знаний в его владении

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

3. горизонт
Насколько перспектива разработки соотносится с его квалификацией и профилем разработчика

по этим критериям можно отсортировать штат на хуже/лучше

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

НО

что важнее в личной оценке - это бизнес-логика, завернутая в управление разработкой:

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

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

в общем, спорно это.

при этом никто не отменял «эффект сисадмина» - чем лучше сисадмин, тем меньше он работает )