라이트모드
다크모드
PM이나 경영진이 봐야할 개발자 업무평가방법
0
View 7,426 | 작성일2012.02.15 12:46
관련링크
본문
아주 좋은글을 하나 봤습니다.
제가 아는 어떤분이 봤으면 좋겠네요....
일정은 제가 만든게 아닌데 왜 자꾸 저한테 뭐라 하시는지...
-------------------------------------------------------------
아마도 초조해 하시는 분들은 관리자들일 확률이 클겁니다. 인사고과도 매겨야 되는데 어떻게 하란 말인가라고 말이죠. 반면에 일반 개발자들은 그냥 평범할 수도 있을 겁니다. 대부분 그런 것과 상관 없이 일해왔을 확률이 크기 때문입니다.
어떤 조직은 '일정 준수'에 대해 책임을 묻겠다는 조직이 있긴 합니다만, 하나 궁금한 것이 있습니다. 그 일정 엔지니어들이 잡은 것인가요? 책임을 진다는 것은 그 의사 결정에 참여해야 의미가 있습니다. 만약에 엔지니어가 잡지 않은 일정에 대해 책임을 지라 하고 고과를 매기겠다면 이것은 남이 변을 보다 말았으니 네가 보시라는 것과 똑같은 이야깁니다. (쾌변하세요, 꼭.)
제가 이런 이야기를 하는 이유는 이렇습니다. 개발 업무의 특징은 집단으로 하는 공학이란 겁니다. 솔직히 다소 '집단예술'에 가까운 일입니다. 한 사람이 특출나게 뭔가 잘해서 되는 경우보다는 같이 '협력'해서 얻어지는 이익이 많습니다. 그렇다면 그 '협력'이 바로 이른바 '황금알을 낳는 거위'인데 이 거위에게 어떻게 먹이를 주시겠습니까?
협력을 깨는 보상/평가는 차라리 안해야 합니다. 그럼 아무것도 안하고 있으면 될까요? 아닙니다. 바로 그 협력의 '단위'를 보상하는 겁니다. 팀에 대한 보상을 키우고 팀간의 협력으로 일군 성과에 대해 더 가치있게 평가하라는 것입니다.
그럼 누구를 승진시킬것인가를 놓고 또 머리 쓰실 분들이 있을 것입니다. 하지만 이미 팀에서는 알고 있을 겁니다. 와인버그의 말 대로 '모든 사람이 문제 해결에 참여하게 해주는 사람이 리더'입니다. 그리고 이미 팀은 그 사람을 알고 있습니다. 관리자만 모를 공산이 크지요.
그러한 사람들의 헌신을 무시하거나 혹은 모른척한다면 아마 인력이 썰물 빠지듯 빠질겁니다. 어떤 회사는 매년 업무실적을 평가하는데 늘 일부러 '깍아'주는 문화가 회사안에 있었습니다. 무언가 한것보다는 못한 것을 더 찾아서 고과를 깍는 식으로 평가를 준겁니다. 결과는 매년 1/4정도의 인력이 물갈이 되었고 무엇보다 이들이 나가면서 한번도 후임자에게 제대로 업무인수 인계를 한 적이 없었습니다. 모든 업무의 지연은 물보듯 뻔했습니다.
냉정한 평가를 내려야만 하는 순간이 있겠지요, 그렇지만 냉정한 평가는 스스로 하게 해야 합니다.인사고과를 깍는 식의 평가보다는 차라리 조직의 회고문화를 통해 스스로 교정해나가게 하는 것이 더 효과가 있습니다. 잘못한 사람은 이미 자신의 잘못을 알고 있는 경우가 많습니다. 다만 이를 스스로 부정하는 사람과 인정하고 고치는 사람이 있습니다.
그렇게 하지 못할 바에는 차라리 후하게 점수를 줘서 기분좋게 하는게 낫습니다. 서로 높은 에너지를 가진 상태에서 '우리 그런데 좀 개선할 바는 없나?'라고 서로 이야기 하게 해서 스스로 조직이 문제를 해결할 수 있는 힘을 길러줘야 할 것입니다.
이 때 반드시 필요한 것은 '다른 시선'이 필요합니다. 개인적으로는 시뮬레이션을 하되 회사 밖의 조직이라든가 혹은 다른 부서의 사람들을 놓고 팀을 관찰하는 역할을 맡겨서 하는 것도 좋은 방법일 것입니다.
간단히 정리하자면 이렇습니다.
- 개발자가 공언한 일정/계획이 아닌 것에 대해서는 고과를 매길 수 없습니다. 매기는 순간 그 개발자는 다른 회사사람이 됩니다.
- 협력을 증진시키는 방식으로 고과를 매기는 것이 좋습니다. 팀단위로 고과를 매겨보십시오. 그중 승진 대상자는 그 팀의 협력을 증진시키거나 효과를 높인 사람을 찾아 하면 됩니다.
- 조직이 에너지를 얻은 상태에서 스스로를 돌아 볼 수 있는 자리를 만들어 주십시오. 시뮬레이션 같은 방법을 이용하시길 권합니다. 이 때 타 조직의 사람들이 관찰을 해주고 그 이야기를 들을 필요가 있습니다.
p.s: 글을 올린 이후 우연하게도 최동석 경영연구소장님의 blog인 mindprogram을 알게 되었습니다. 제가 생각했던 아이디어를 매우 '근거' 있게 만들어주실 만한 글이 올라왔네요. ^^ 계량화가 유행병처럼 번지다 무엇을 계량화 해야 할 지, 혹은 하지 말아야 할지 구분을 해야 겠지요.