TDD로 유명한 켄트백 아저씨가 쓴 맥킨지 글(https://careerly.co.kr/comments/92455?utm_campaign=self-share)에 대한 반박글입니다!

• 맥킨지는 결과와 영향이 아닌 노력과 산출물을 측정함. 노력과 산출물은 측정하기 쉽지만 어뷰징하기도 쉬워서 개발 문화에 부정적 영향을 미침

• 실제로 페이스북에서 맥킨지 설문을 진행했고, 처음 일 년 동안은 개발자 경험에 대한 의미있는 피드백을 받았음. 하지만 측정하는 점수를 높이는 것이 목표가 되면서 관리자들이 평가를 위해 어뷰징하기 시작함

• 개발팀의 결과와 영향은 DORA 지표나 SPACE 프레임워크을 통해 측정할 수 있고, 여기에 더해 1) 팀이 일주일에 한 번 고객을 만족시키는지, 2) 팀이 약속한 비즈니스 임팩트를 전달하는지를 볼 수 있음

https://tidyfirst.substack.com/p/measuring-developer-productivity

• 결과와 영향만 측정하면 회사의 목표를 무시하고 개인적인 이익만 쫓기 쉬움. 회사의 목표에 부합하는 올바른 노력을 하도록 하는 견제가 필요함

• 개인 성과만으로는 팀 성과를 예측할 수 없고, 팀 성과만 봐서는 개인의 기여를 알기 어려움. 가장 좋은 건 팀 성과에 영향을 주는 개인 성과를 보는 것이지만 이는 측정하기 어려움

• 그러면 경영진이 개발팀에 얼만큼의 투자를 해야 하는지 어떻게 의사결정 할 수 있는가? 개발팀에 비용을 아예 안 쓰는 경우와 개발팀에만 비용을 쓰는 경우를 상상해보고, 현재 우리가 지출하는 개발팀 비용의 비율을 조절해보면서 어떤 일이 벌어질지를 결정하는 방식이 더 유익함

https://tidyfirst.substack.com/p/measuring-developer-productivity-440

개인적으로는 켄트백 아저씨 반박글의 논리나 결론이 좀 아쉬웠습니다..🤔 개발자 생산성 측정은 부작용이 있을 수 있으니 지금 하던대로 하라는 논조로 읽히더라고요. 차라리 DORA처럼 개발자 생산성 측정 결과를 평가에 사용하지 말고 개선에 사용하라던가, 콜라보한 Gergely Orosz처럼 팀의 영향을 중심으로 측정해야 하고, 가능하다는 사례를 보여주는 게 더 가치있다는 생각이 들었습니다. 여러분은 어떻게 읽으셨나요?