평가를 어떻게 해야 할까?
2011/01/18 12:37 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
개발자 여러분 평가철이 다가왔습니다. 이미 평가를 끝낸 회사도 있을 것이고 한창 평가를 하고 있는 회사도 있을 것입니다.
평가가 항상 만족스럽고 공정하다고 생각하나요? 그렇지 않은 분들이 더 많을 겁니다.
평가 시에 자주 보는 것은 개발자들 순위 매기기 입니다. 흔히 "나래비" 세운다고 하죠. (일본말에서 유래)
대부분의 개발자들은 이런 순위매기기의 결과가 공정하지 않다고 생각하고 팀워크를 깨기 일쑤입니다.
A평가를 받은 개발자와 D평가를 받은 개발자의 차이가 크지 않은 경우가 많습니다. 심지어는 더 잘한 개발자가 더 낮은 평가를 받는 경우가 흔합니다. 그런데 평가시스템에서 A는 10%, B는 50%, C는 30%, D는 30%를 할당 받아서 무조건 나눠야 하는 경우가 있습니다. 개발자가 5명밖에 안된다면 나누기도 어렵습니다. 기계적인 평가시스템 적용이 1년 동안 고생한 개발자들을 한순간에 힘을 잃게 할 수도 있다.
물론 D 평가를 받아야 할 개발자도 있을 수 있으나 열심히 일했고 성과도 꽤 잘 냈음에도 불구하고 D평가를 받는 개발자들도 있습니다. 그렇다고 평가를 관리자 마음대로 하라고 할 수도 없습니다. 그럼 더 엉망이 될 것입니다.
평가는 불공평할 수밖에 없지만 불공평하다는 의식이 너무 팽배해지면 개발자들이 진정으로 열심히 하려고 하지 않을 것입니다. 평가를 잘 받기 위한 편법이 난무할 수 있습니다.
이렇게 평가가 공정하지 못하다는 인식은 평가의 기준이 애매하거나 없기 때문인 경우가 많습니다. 팀장 또는 관리자가 맘에 내키는 대로 평가를 하면 무슨 기준으로 평가를 했는지 알 수 없는 개발자들은 평가 결과를 납득하기가 어렵습니다.
그렇다고 너무 구체적인 평가 기준(KPI)도 문제가 됩니다. 몇가지 예를 보죠.
- 개발 일정을 맞추면 평가를 잘 주겠다.
코드는 엉망으로 만들어서 유지보수를 어렵게 만들지만 일단 일정은 지킵니다. 하지만 나중에 유지보수 개발자들이 엄청난 고생을 하게 됩니다.
- 버그를 많이 찾으면 평가를 잘 주겠다.
테스터는 스펙, 설계단계의 검토를 소홀히 하여 버그가 더 많이 발생하도록 합니다. 전체적으로 프로젝트 기간이 늘어나고 비용도 증가합니다.
- 버그를 적게 만들면 평가를 잘 주겠다.
개발자는 최대한 일을 적게 하려고 하게 됩니다. 약간의 리스크가 있는 시도도 두려워하게 되며 새로운 기술도 연구하지 않게 됩니다.
이쯤 되면 개발자는 공장의 생산직 직원처럼 평가가 불가능하다는 것을 눈치채셨을 겁니다. 개발자들은 원래 돈에 그렇게 좌지우지 되지 않는데 공정하지 않은 평가를 몇번 받게 되면 기분이 나빠서라도 평가를 잘 받기 위해서 편법을 동원할 수 있게 됩니다.
흔히 하는 실수 중의 하나가 평가가 이렇게 부정확한데도 불구하고 평가에 의해서 A와 D 등급의 개발자를 엄청난 연봉 인상의 차이를 두면 개발자들이 더욱 열심히 일할 것이라고 생각하는 것입니다. 이는 착각이며 자칫하면 평가만 잘 받기 위한 편법이 난무하게 되며 평가의 결과는 불공정하다는 불만만 팽배하게 됩니다.
공정한 평가는 필요하지만 100% 공정하기는 불가능합니다. 그렇다고 평가를 하지 않을 수 없습니다. 평가는 잘못 휘두르면 안 한 만도 못하게 되고 그렇다고 안 할 수도 없는 균형잡기 어려운 줄타기입니다. 그리고 다음과 같은 기준은 세울 수 있습니다.
- 평가 기준은 회사의 비전과 일치해야 한다.
- 평가 기준은 평가자나 피평가자 모두가 납득해야 한다.
- 평가 기준은 연초에 미리 정해야 한다.
- 평가 기준은 객관적이어야 한다. 즉 평가 가능해야 한다.
- 평가 결과를 너무 믿지 말아야 한다. 적당히 활용해야 한다.
평가의 목적은 결과를 보고 상과 벌을 주기 위한 것이 아닙니다. 평가기준이 회사의 비전을 절묘하게 잘 반영하여 하나의 목표를 가지고 매진할 수 있도록 하기 위한 것입니다. 잘 만들어진 평가 기준은 평가 결과를 가지고 벌을 주지 않아도 이미 목표를 달성한 것입니다.
A를 받은 개발자는 기분이 좋고 C나 D를 받아도 별로 기분이 나쁘지 않은 그런 평가 어디 없을까요?
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
'개발문화' 카테고리의 다른 글
| 나쁜 습관 (2) | 2011/06/19 |
|---|---|
| 내가 소스코드를 몰래 고치는 이유 (13) | 2011/02/01 |
| 평가를 어떻게 해야 할까? (4) | 2011/01/18 |
| 기존 소프트웨어를 버리고 언제 새로 만들어야 할까? (16) | 2011/01/17 |
| 왜 나만의 방법이 실패하는지? (NIH 신드롬) (12) | 2011/01/09 |
| 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일) (14) | 2011/01/03 |
Trackback Address: http://allofsoftware.net/trackback/207
야구에서도 에러, 즉 수비 실수를 줄이는 방법은 간단합니다.
공이 날라올 때 뛰지말고 천천히 걸어가는거죠 ^_^
그러면 수비 할 상황 자체가 안되기 때문에, 에러로 기록되지 않습니다.
여하튼 평가라는게 기준 정하기가 참 힘들더군요.
사실 저야 겨우 대학원 프로젝트 팀장인지라 평가 기준이 그다지 필요하지는 않습니다만,
후배를 평가해야 할 일 이 있으면, 가능한 장점을 위주로 평가하려고 노력 합니다.
물론 단점을 고려해야 겠지만, 그 단점을 매워주기 위해 팀원들이 있는거고..
하지만 회사를 가게 되면,누군가 월급을 더 주어야 하고,
회사 사정이 안 좋으면 누군가 잘라야 하고..
평가라는게 서로의 장점을 파악해 시너지 효과를 내기 보다는,
부정적인 용도로 사용될 것 같기도 하네요 -_-;;
안녕하세요. csj님
우리나라 회사들은 평가에서 실패하는 경우가 매우 많습니다. 주먹구구식 개발을 하다보니 평가도 주먹구구로 하는 경우가 많더군요.
우리 회사를 보는듯 하네요.. 기준을 알 수 없는 평가를 하고 그 평가를 기준으로 인센티브나 연봉인상을 정하는.. 이러면 안되는데 하면서도 의욕이 자꾸 저하되고.. 참 암담하네요^^;
안녕하세요. 초마님
평가는 개발자가 회사를 어떻게 해볼 수 없는 부분이네요. 높은 자리에 있으시면 정책에 영향을 좀 주겠지만, 그렇지 않으신 것 같네요.