Heart’s Develop Inside

고객사 담당자 분(QA 파트에서 일하신다)과 자사 솔루션(형상관리)에 대해 이야기를 하다 보니, 문득 이런 방향으로 주제가 옮겨지게 됐다.

“프로그래머의 실적 관리가 가능할까?”

형상관리가 가지는 통계 기능의 최종 목표는 팀 별, 혹은 개인 별 실적 관리일 것이다. 이는 형상관리에 국한된 것이 아니라 프로그래머가 활동하는 영역이라면 모두 고민하는 문제가 아닐까 생각한다. 그렇게 생각하는 이유는, 프로그래머는 수치화할 수 있는 무언가를 만들어내는 존재가 아니기 때문이다.

마케팅은 판매 실적이 평가에 대한 수치가 된다.
하지만 프로그래머는 직접 판매 실적을 올리는 존재도 아니며, 그가 만들어 낸 산출물에 대한 실적 평가는 결국 주관적으로 내릴 수 밖에 없다.

처음에는 소스 코드 라인 생산성이나 (영향분석을 거친)함수 생산성을 통해 객관적인 실적을 추정할 수 있지 않을까 하는 생각을 했었다. 하지만 곧 굉장히 위험한 생각이라는 결론에 도달할 수 있었다.
우선 악용의 소지가 존재한다. 한 라인에 쓸 수 있는 소스를 10라인에 걸쳐 쓴다거나 하는 방법이다. 쓸데 없이 라인 별로 주석을 다는 방법도 포함…
또한 실적을 위해 테스트를 등한시하고 무조건 생산부터 하고 볼 경향이 크다. (이 단점은 차후 QA를 통해 버그가 발견될 경우 원인 제공자를 찾아 페널티를 적용하는 방법이 있을 수 있겠다. 조금 잔인하군…)

무엇보다 궁극적인 문제는, 같은 로직이면 가독성을 해치지 않는 범위 내에서 간결하게 작성하는 것이 더 좋은 방법이라는 것이다. 즉, 라인 갯수나 함수의 갯수가 단순하게 많은 게 좋은 게 아니라는 것이다.

문서화로 평가하는 것 또한 소스 코드에 의한 평가와 같은 문제를 야기할 수 있다.

업무 처리 능력으로 평가하는 것은 평가자에 따라 다분히 주관적일 수 있다. 자신이 추정하는 필요 시간과 상사 혹은 매니저가 추정하는 필요 시간이 다를 것이기 때문이다. 자신이 경력이 모자라서 추정 능력이 떨어질 수도 있겠지만, 둘의 생산성에 대한 이념이 다름에 따를 수도 있다. 이럴 때는 상사의 추정이 무조건 옳다고는 할 수 없을 것이다.

이야기하면 이야기할 수록 우리의 생각은 ‘불가능하다’에 수렴하고 있었다.
어떻게 보면 업무 관련으로 시작한 이야기였지만 ‘결국 나의 생산성 평가는 상사 혹은 매니저 몫이군’ 이라고 생각하니 조금은 씁쓸하다.
객관적인 평가를 내릴 수 있는 참신한 방법이 개발되어, 프로그래머가 자신의 능력에 대한, 또는 성실성에 대한 제대로 된 대우를 받을 수 있기를 고대한다.