2011년 1월 18일 화요일

평가를 어떻게 해야 할까?

개발자 여러분 평가철이 다가왔습니다. 이미 평가를 끝낸 회사도 있을 것이고 한창 평가를 하고 있는 회사도 있을 것입니다.

평가가 항상 만족스럽고 공정하다고 생각하나요? 그렇지 않은 분들이 더 많을 겁니다.

평가 시에 자주 보는 것은 개발자들 순위 매기기 입니다. 흔히 "나래비" 세운다고 하죠. (일본말에서 유래)
대부분의 개발자들은 이런 순위매기기의 결과가 공정하지 않다고 생각하고 팀워크를 깨기 일쑤입니다.

A평가를 받은 개발자와 D평가를 받은 개발자의 차이가 크지 않은 경우가 많습니다.  심지어는 더 잘한 개발자가 더 낮은 평가를 받는 경우가 흔합니다. 그런데 평가시스템에서 A는 10%, B는 50%, C는 30%, D는 30%를 할당 받아서 무조건 나눠야 하는 경우가 있습니다. 개발자가 5명밖에 안된다면 나누기도 어렵습니다. 기계적인 평가시스템 적용이 1년 동안 고생한 개발자들을 한순간에 힘을 잃게 할 수도 있다.

물론 D 평가를 받아야 할 개발자도 있을 수 있으나 열심히 일했고 성과도 꽤 잘 냈음에도 불구하고 D평가를 받는 개발자들도 있습니다. 그렇다고 평가를 관리자 마음대로 하라고 할 수도 없습니다. 그럼 더 엉망이 될 것입니다. 

평가는 불공평할 수밖에 없지만 불공평하다는 의식이 너무 팽배해지면 개발자들이 진정으로 열심히 하려고 하지 않을 것입니다. 평가를 잘 받기 위한 편법이 난무할 수 있습니다.

이렇게 평가가 공정하지 못하다는 인식은 평가의 기준이 애매하거나 없기 때문인 경우가 많습니다. 팀장 또는 관리자가 맘에 내키는 대로 평가를 하면 무슨 기준으로 평가를 했는지 알 수 없는 개발자들은 평가 결과를 납득하기가 어렵습니다.

그렇다고 너무 구체적인 평가 기준(KPI)도 문제가 됩니다. 몇가지 예를 보죠.

  • 개발 일정을 맞추면 평가를 잘 주겠다. 
    코드는 엉망으로 만들어서 유지보수를 어렵게 만들지만 일단 일정은 지킵니다. 하지만 나중에 유지보수 개발자들이 엄청난 고생을 하게 됩니다.
  • 버그를 많이 찾으면 평가를 잘 주겠다. 
    테스터는 스펙, 설계단계의 검토를 소홀히 하여 버그가 더 많이 발생하도록 합니다. 전체적으로 프로젝트 기간이 늘어나고 비용도 증가합니다.
  • 버그를 적게 만들면 평가를 잘 주겠다.
    개발자는 최대한 일을 적게 하려고 하게 됩니다. 약간의 리스크가 있는 시도도 두려워하게 되며 새로운 기술도 연구하지 않게 됩니다.

이쯤 되면 개발자는 공장의 생산직 직원처럼 평가가 불가능하다는 것을 눈치채셨을 겁니다. 개발자들은 원래 돈에 그렇게 좌지우지 되지 않는데 공정하지 않은 평가를 몇번 받게 되면 기분이 나빠서라도 평가를 잘 받기 위해서 편법을 동원할 수 있게 됩니다.

흔히 하는 실수 중의 하나가 평가가 이렇게 부정확한데도 불구하고 평가에 의해서 A와 D 등급의 개발자를 엄청난 연봉 인상의 차이를 두면 개발자들이 더욱 열심히 일할 것이라고 생각하는 것입니다. 이는 착각이며 자칫하면 평가만 잘 받기 위한 편법이 난무하게 되며 평가의 결과는 불공정하다는 불만만 팽배하게 됩니다.

공정한 평가는 필요하지만 100% 공정하기는 불가능합니다. 그렇다고 평가를 하지 않을 수 없습니다. 평가는 잘못 휘두르면 안 한 만도 못하게 되고 그렇다고 안 할 수도 없는 균형잡기 어려운 줄타기입니다. 그리고 다음과 같은 기준은 세울 수 있습니다.

  • 평가 기준은 회사의 비전과 일치해야 한다.
  • 평가 기준은 평가자나 피평가자 모두가 납득해야 한다.
  • 평가 기준은 연초에 미리 정해야 한다. 
  • 평가 기준은 객관적이어야 한다. 즉 평가 가능해야 한다.
  • 평가 결과를 너무 믿지 말아야 한다. 적당히 활용해야 한다.
평가의 목적은 결과를 보고 상과 벌을 주기 위한 것이 아닙니다. 평가기준이 회사의 비전을 절묘하게 잘 반영하여 하나의 목표를 가지고 매진할 수 있도록 하기 위한 것입니다. 잘 만들어진 평가 기준은 평가 결과를 가지고 벌을 주지 않아도 이미 목표를 달성한 것입니다.

A를 받은 개발자는 기분이 좋고 C나 D를 받아도 별로 기분이 나쁘지 않은 그런 평가 어디 없을까요?

댓글 5개:

  1. 과연 개발자의 업무 평가를 제대로 하는 것이 가능할 것인가라는 주제는 논의가 많습니다. 그럼 반대로 '개발자의 업무평가를 하지 않는 것은 가능할까'라는 질문을 해보면 어떨까요? 아마도 초조해 하시는 분들은 관리자들일 확률이 클겁니다. 인사고과도 매겨야 되는데 어떻게 하란 말인가라고 말이죠. 반면에 일반 개발자들은 그냥 평범할 수도 있을 겁니다. 대부분 그런 것과 상관 없이 일해왔을 확률이 크기 때문입니다. 어떤 조직은 '일정 준수'에 대해 책임을 묻..

    답글삭제
  2. 야구에서도 에러, 즉 수비 실수를 줄이는 방법은 간단합니다.
    공이 날라올 때 뛰지말고 천천히 걸어가는거죠 ^_^
    그러면 수비 할 상황 자체가 안되기 때문에, 에러로 기록되지 않습니다.

    여하튼 평가라는게 기준 정하기가 참 힘들더군요.
    사실 저야 겨우 대학원 프로젝트 팀장인지라 평가 기준이 그다지 필요하지는 않습니다만,
    후배를 평가해야 할 일 이 있으면, 가능한 장점을 위주로 평가하려고 노력 합니다.
    물론 단점을 고려해야 겠지만, 그 단점을 매워주기 위해 팀원들이 있는거고..

    하지만 회사를 가게 되면,누군가 월급을 더 주어야 하고,
    회사 사정이 안 좋으면 누군가 잘라야 하고..
    평가라는게 서로의 장점을 파악해 시너지 효과를 내기 보다는,
    부정적인 용도로 사용될 것 같기도 하네요 -_-;;

    답글삭제
  3. 안녕하세요. csj님
    우리나라 회사들은 평가에서 실패하는 경우가 매우 많습니다. 주먹구구식 개발을 하다보니 평가도 주먹구구로 하는 경우가 많더군요.

    답글삭제
  4. 우리 회사를 보는듯 하네요.. 기준을 알 수 없는 평가를 하고 그 평가를 기준으로 인센티브나 연봉인상을 정하는.. 이러면 안되는데 하면서도 의욕이 자꾸 저하되고.. 참 암담하네요^^;

    답글삭제
  5. 안녕하세요. 초마님
    평가는 개발자가 회사를 어떻게 해볼 수 없는 부분이네요. 높은 자리에 있으시면 정책에 영향을 좀 주겠지만, 그렇지 않으신 것 같네요.

    답글삭제