블로그 이미지
Every unexpected event is a path to learning for you. blueasa

카테고리

분류 전체보기 (2797)
Unity3D (853)
Programming (479)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (185)
협업 (61)
3DS Max (3)
Game (12)
Utility (68)
Etc (98)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (55)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday

업무 평가 하기

Etc / 2012. 2. 15. 13:36
 과연 개발자의 업무 평가를 제대로 하는 것이 가능할 것인가라는 주제는 논의가 많습니다. 그럼 반대로 '개발자의 업무평가를 하지 않는 것은 가능할까'라는 질문을 해보면 어떨까요? 

 아마도 초조해 하시는 분들은 관리자들일 확률이 클겁니다. 인사고과도 매겨야 되는데 어떻게 하란 말인가라고 말이죠. 반면에 일반 개발자들은 그냥 평범할 수도 있을 겁니다. 대부분 그런 것과 상관 없이 일해왔을 확률이 크기 때문입니다. 

 어떤 조직은 '일정 준수'에 대해 책임을 묻겠다는 조직이 있긴 합니다만, 하나 궁금한 것이 있습니다. 그 일정 엔지니어들이 잡은 것인가요? 책임을 진다는 것은 그 의사 결정에 참여해야 의미가 있습니다. 만약에 엔지니어가 잡지 않은 일정에 대해 책임을 지라 하고 고과를 매기겠다면 이것은 남이 변을 보다 말았으니 네가 보시라는 것과 똑같은 이야깁니다. (쾌변하세요, 꼭.)

 제가 이런 이야기를 하는 이유는 이렇습니다. 개발 업무의 특징은 집단으로 하는 공학이란 겁니다. 솔직히 다소 '집단예술'에 가까운 일입니다. 한 사람이 특출나게 뭔가 잘해서 되는 경우보다는 같이 '협력'해서 얻어지는 이익이 많습니다. 그렇다면 그 '협력'이 바로 이른바 '황금알을 낳는 거위'인데 이 거위에게 어떻게 먹이를 주시겠습니까? 
 
곶감이 잘 되려면 감나무 혼자 퇴비 많이 먹는다고 되는게 아닙니다. 날씨와 사람의 노력 모두가 잘 되어야 하는 것입니다. 


 협력을 깨는 보상/평가는 차라리 안해야 합니다. 그럼 아무것도 안하고 있으면 될까요? 아닙니다. 바로 그 협력의 '단위'를 보상하는 겁니다. 팀에 대한 보상을 키우고 팀간의 협력으로 일군 성과에 대해 더 가치있게 평가하라는 것입니다.

 그럼 누구를 승진시킬것인가를 놓고 또 머리 쓰실 분들이 있을 것입니다. 하지만 이미 팀에서는 알고 있을 겁니다. 와인버그의 말 대로 '모든 사람이 문제 해결에 참여하게 해주는 사람이 리더'입니다. 그리고 이미 팀은 그 사람을 알고 있습니다. 관리자만 모를 공산이 크지요. 

 그러한 사람들의 헌신을 무시하거나 혹은 모른척한다면 아마 인력이 썰물 빠지듯 빠질겁니다. 어떤 회사는 매년 업무실적을 평가하는데 늘 일부러 '깍아'주는 문화가 회사안에 있었습니다. 무언가 한것보다는 못한 것을 더 찾아서 고과를 깍는 식으로 평가를 준겁니다. 결과는 매년 1/4정도의 인력이 물갈이 되었고 무엇보다 이들이 나가면서 한번도 후임자에게 제대로 업무인수 인계를 한 적이 없었습니다. 모든 업무의 지연은 물보듯 뻔했습니다. 

 냉정한 평가를 내려야만 하는 순간이 있겠지요, 그렇지만 냉정한 평가는 스스로 하게 해야 합니다.인사고과를 깍는 식의 평가보다는 차라리 조직의 회고문화를 통해 스스로 교정해나가게 하는 것이 더 효과가 있습니다. 잘못한 사람은 이미 자신의 잘못을 알고 있는 경우가 많습니다. 다만 이를 스스로 부정하는 사람과 인정하고 고치는 사람이 있습니다.  

 그렇게 하지 못할 바에는 차라리 후하게 점수를 줘서 기분좋게 하는게 낫습니다. 서로 높은 에너지를 가진 상태에서 '우리 그런데 좀 개선할 바는 없나?'라고 서로 이야기 하게 해서 스스로 조직이 문제를 해결할 수 있는 힘을 길러줘야 할 것입니다. 

 이 때 반드시 필요한 것은 '다른 시선'이 필요합니다. 개인적으로는 시뮬레이션을 하되 회사 밖의 조직이라든가 혹은 다른 부서의 사람들을 놓고 팀을 관찰하는 역할을 맡겨서 하는 것도 좋은 방법일 것입니다. 


 간단히 정리하자면 이렇습니다. 
 - 개발자가 공언한 일정/계획이 아닌 것에 대해서는 고과를 매길 수 없습니다. 매기는 순간 그 개발자는 다른 회사사람이 됩니다. 
 - 협력을 증진시키는 방식으로 고과를 매기는 것이 좋습니다. 팀단위로 고과를 매겨보십시오. 그중 승진 대상자는 그 팀의 협력을 증진시키거나 효과를 높인 사람을 찾아 하면 됩니다. 
-  조직이 에너지를 얻은 상태에서 스스로를 돌아 볼 수 있는 자리를 만들어 주십시오. 시뮬레이션 같은 방법을 이용하시길 권합니다. 이 때 타 조직의 사람들이 관찰을 해주고 그 이야기를 들을 필요가 있습니다. 

 p.s: 글을 올린 이후 우연하게도 최동석 경영연구소장님의 blog인 mindprogram을 알게 되었습니다. 제가 생각했던 아이디어를 매우 '근거' 있게 만들어주실 만한 글이 올라왔네요. ^^  계량화가 유행병처럼 번지다 무엇을 계량화 해야 할 지, 혹은 하지 말아야 할지 구분을 해야 겠지요. 



반응형
Posted by blueasa
, |