개발자 생산성을 측정할 때 저지르는 실수
(thenewstack.io)- 개발자 생산성을 측정할 때 흔히 저지르는 실수
- 투입량 측정 문제
- ‘근무 시간’과 같은 투입물 또는 노력에 의존하면 잘못된 행동을 조장함
- 예를 들어, 기업 문화가 화면 앞에서 보낸 시간을 가치 있게 여기고 보상하는 것이라면, 개발자가 여기에 시간을 쏟아부을 수 있는데 작업의 품질을 장담하기는 어려움
- 더 독한 환경에서는 ‘가장 일찍 출근해서 가장 늦게 퇴근하는’ 경쟁으로 변질될 수 있음
- 결과 측정 문제
- 코드 줄 또는 커밋 수와 같은 최악의 지표가 이 카테고리에 속함
- 개발자는 코드 줄을 매우 빠르게 대량으로 작성하기에 이를 측정하는 건 쉬움
- 모든 결과 지표는 맥락에 따라 이해해야 함
- 결과와 영향 측정 문제
- 이 두 가지 지표의 과제는 ‘DevOps 팀이 얼마나 책임이 있는지’ 파악하는 것
- 비즈니스 수익 증가를 측정할 때, 이를 개발자 책임으로만 돌리는 건 불가능함
대안이 없는 글이라 전달하고자 하는 의미가 퇴색되는 측면이 있습니다. 산출물의 양을 결과 측정에서 제외해야 한다는 주장에는 동의하지만, 근무시간을 투입량 측정에서 완전히 제외해야 한다는 것은 현실과 맞지 않기 때문에 동의할 수 없습니다. 어찌됐건 지식노동을 하는 동안 시간은 흐르기 때문에 의사결정에는 시간을 반드시 고려해야 한다고 생각합니다
전체 진행률 = (충족 요구사항 수 / 근무시간) 같은 선행 지표를 측정한 후 개발자 생산성을 논하는 것이 이해하기 쉽고 효율적이라 생각합니다
저는 최근에는 이런 류의 글에 대해서 좀 비판적으로 보는 것이 사람들이 결국 이러한 글을 보고 내리는 결론이 아무 관리도 안하는 것을 선택하는 것이라고 생각합니다. 어떤 지표로 관리하던간에 결국 비슷한 문제가 있습니다. 또한 어떤 지표를 사람이나 팀간의 경쟁이나 비교의 용도로 활용하게 되면 부작용이 발생하게 되죠. 그래서 하나의 지표로만 관리하면 안되고 상호보완적인 지표들을 같이 관리하는 것이 필요하며 지표를 활용하여 팀이 스스로 개선하는데 도움을 주는데 활용해야한다고 생각합니다.