Comments 8
Подводя итог, стоит сказать, что производительность разработчиков действительно можно измерить.
Еще бы добавить альтернативные ответы, который дал Кент Бек в отдельной статье
Measure developer productivity? Not possible. There are too many confounding factors, network effects, variance, observation effects, and feedback loops to get sensible answers to questions like, “How many times more profit did Joan create than Harry?” or, “How much better (or worse) is Harry doing this quarter than last?” You can measure activity, but not without directing that activity away from the ends you care about. And your customers. And your investors.
Во-первых, перевод этого текста тут уже был. А во-вторых, вот смотрите:
Почему продажи и HR могут так точно измерять производительность?
Представим себе, что HR заняты наймом программистов. В чем измеряется производительность HR в этом случае? Если авторы измеряют ее в штуках нанятых программистов в единицу времени, то у меня для них неприятные новости - они могли нанять совсем не тех людей, какие были нужны (я понимаю, что это не целиком их ответственность, но все же).
То есть, чтобы как следует измерить производительность HR, мы должны оценить качество тех самых программистов, что они наняли. Таким образом задача практически сводится к предыдущей, и мы понимаем, что никакой простой оценки производительности HR в чуть менее тривиальном случае не существует. Количественно их работу оценить можно, а вот качественно - фиг.
Если авторы измеряют ее в штуках нанятых программистов в единицу времени, то у меня для них неприятные новости
Увы, такими темпами можно вообще отказаться от измерения чего-либо.
Это примерно как отказаться всех тестов и замеров производительности у отдельных компонентов сложной программной системы, в пользу исключительно e2e тестов и замеров всей системы в сборе. Правда в том, что нужно и то и другое для разных целей.
Для начала оговорим, что, судя по контексту, тут речь про рекрутеров (это лишь одна HR ролей). Они бывают штатные и внештатные. Возьмём для простоты внештатных и посмотрим на систему оплаты их труда. Общепринятая рыночная практика -- внештатный рекрутер получает деньги, если приведённый ими кандидат принял предложение о работе.
За всех остальных приведённых кандидатов внештатный рекрутер не получает ничего.
За дальнейшую судьбу сотрудника в компании внештатный рекрутер обычно не отвечает -- его задача привести кандидатов, а дальше уже ответственность перекладывается на нанимающих сотрудников компании.
Таким образом, видим, что внештатный рекрутер отвечает только за начальный этап воронки набора сотрудников. Первая наивная мысль -- раз платят за нанятых сотрудников (поштучно или взвешенно в зависимости от размера компенсации или уровня квалификации), то в интересах рекрутера навалить в эту воронку как можно больше кандидатов. Однако, такой подход по факту не работает: если внештатный рекрутер начинает приводить неподходящих кандидатов и, как следствие, конверсия кандидатов в сотрудники снижается, порожняком нагружая сотрудников компании собеседованиями, то компания перестанет сотрудничать с этим рекрутером. Похожая история может произойти и с кандидатами, которые тоже обычно не заинтересованы бесплодно собеседоваться на неподходящие роли.
Вот и видим, что у внештатного рекрутера появляются естественным образом две метрики эффективности -- число приведённых кандидатов и их конверсия.
И компания будет готова заплатить больше тому внештатному рекрутеру, который сможет показать лучшие метрики.
Вот такими метриками эффективности и разделяются границы составных частей системы. И важно из замерять -- это базовый принцип декомпозиции, активно применямый в науке для исследований и в управлении сложными системами.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы. И мы знаем, что заметная часть разработчиков -- формошлёпы и CRUD-оделы, чья работа не подразумевает значительной исследовательской работы с большихм коэффециентом неопределённости.
Видимо, осталось сделать простой шаг - определить для разработчиков две похожие метрики для расчета эффективности - воронку и конверсию. Первая, наверное, будет SLOC?
Не, я согласен что я слегка упрощаю. Да, упрощаю - чтобы яснее продемонстрировать мысль. На самом деле в оригинале же написано просто - почему HR могут так точно измерять производительность? При этом практически ничего не сказано о том, как они ее измеряют, и какова на самом деле точность. Я призываю, если угодно, таким вот утверждениям без доказательства не верить. Вполне возможно, что у HR простой KPI, и они его скажем так, "взломали". Поэтому у них все красиво. Или наоборот - программисты наловчились взламывать все KPI, которые придумывают для измерения их производительности, и поэтому все попытки измерения проваливаются - KPI растет, а работа стоит.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы.
Конечно. Вся проблема в той части разработчиков, которые занимаются другой работой.
Думаю, пример KPI HR в виде только "количества нанятых разработчиков" это все же упрощение. В реальности там еще будет и "% прохождения испытательного срока", и "текучка" и еще что-то.
Так вот у HR это что-то "в людях", у сейлз - что-то "в деньгах", а вот у технарей в чем таком, что можно также "пощупать"? Вроде — нет такого.
Вот тут МакКинзи и накинулись пытаться оцифровывать.
Предыдущий перевод и правда пропустил — буду следующий раз проверять лучше.
Как измерять эффективность разработчиков, и почему метод McKinsey может убить культуру разработки в компании