유명 블로거 조엘 스폴스키 (Joel spolsky) - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky) - 의 글에 따르면, S/W 개발자들의 공평한 고과를 매기는 것은 무척 어려울 뿐 더러, 일반적인 사람들에 비하여 더 똑똑한 이 사람들은 어떠한 기준을 제시해도 그 기준을 피해나갈 방법을 찾기 때문에, 차라리 고과를 매기지 않는 편이 좋다고 얘기를 합니다. 예를 들어,한주에 작성한 코드의 양을 기준으로 삼는다면 일부러 코드를 늘려서 짤 것이고, 수정한 버그 수를 기준으로 삼는다면 일부러 쉬운 버그들을 양산할 것미고, 반대로 만들어낸 버그의 수를 기준으로 삼는다면 테스트를 하느라 코드 작업이 진행되지 않는다는 거지요. 프로그래머를 평가하는 방법은 그들의 짠 코드를 직접 평가하는 수 밖에 없는데, 이는 주관적이고 절대적인 기준이지, 상대적이고 객관적인 기준을 만들 수는 없습니다. 오히려 많은 역효과가 있기 때문에, 조엘은 프로그래머들의 고과를 평가하지 말 것을 권하고 있습니다. 이와 관해서 제가 최근에 겪은 이야기를 써볼까 합니다.

  최악의 프로젝트가 막 끝났습니다. 기획과 경영 파트의 잘못된 추정과 진행으로 프로젝트가 최악으로 치달았습니다. 이로 인해서 코어팀은 6개월 가까이 잔업과 특근에 시달려야 했습니다. (시달렸다는 표현은, 월 100시간 정도 잔업과 토, 일요일 모두 출근했다는 뜻입니다.) 정말 최악이었죠. 프로젝트가 끝나기 두 달 전부터는 어플리케이션 팀도 마찬가지도 시달려야 했습니다. 어플리케이션 팀도 적지 않게 고생을 했습니다.

  어쨌든, 프로젝트는 끝이 났습니다. 그리고 수확의 계절이 되었습니다. 코어팀 리더는 목소리가 큰 분이셨는데 (Big mouth), 코어팀이 가장 고생을 한 것이 명백하니, 우리 애들이 좋은 고과를 받아야 한다고 주장을 하셨습니다. 이로 인해 다른 팀은 "보통" 고과 밖에는 받지 못했는데, 회사 정책이 각 등급의 배분에 제한을 두었기 때문입니다. 코어팀 리더의 주장은, 코어팀이 가장 많은 잔특근을 했기 때문에, 그들이 좋은 고과를 받을 자격이 있다는 것이었습니다. 이 주장은 옳은가요? 충분히 공평한 것입니까?

   이래서 반대합니다.  
 

  반대의견 1. 좋은 고과는 똑똑하고 빛나는 프로그래머들에게 가야합니다. 잔업시간은 좋은 프로그래머의 능력을 나타내는 지표가 될 수 없습니다.

  반대의견 2. 어떤 프로그래머가 코어팀에 배치가 되었습니다. 그는 잔업에 시달리게 되었습니다. 그리고 좋은 고과를 받았습니다. 그런데, 이 프로그래머가 코어팀에 배치된 것은 그가 원해서 된 것도 아니고, 그가 특별한 재능이 있어서도 아닙니다. 그냥 신입사원 배치 중 "우연히" 된 것입니다. 그렇다면, 다른 팀에 배치되어 "보통"의 고과를 받은 신입사원에게는 완전히(totally) 불공평한 일입니다.

  반대의견 3. 엄청난 좌절감(depression)이 코어 외 다른 팀들에 주어졌습니다. 그리고 이는 앞으로 팀을 관리하는데 엄청난 어려움이 됩니다. 다른 팀원들도 잔업에 시달린 것은 마찬가지 였습니다. 두 달간의 시달림도 결코 재미있는 일은 아니었습니다. 그리고, 그들은 그 보상도 받지 못했습니다. 이제, 새 프로젝트가 시작되었지만, 다른 팀원들은 잔업을 거부하게 되었습니다. 더 나아가, 그들은 관리자들로부터 모욕감을 느끼고 있습니다. 이제 관리자들은 어떻게 개발자들의 사기를 북돋을 수 있을까요?

   단순한 고과 문제가 아닌, 신뢰의 문제입니다.
 

  제가 무슨 얘기를 하는 것인지 이해가 되시나요? 이건 단순히 고과 평가에 관한 이야기가 아닙니다. 이건 개발자와 관리자(팀) 사이의 거대한 신뢰 문제에 관한 이야기 입니다. 그리고 신뢰는 멀리, 저멀리 날아가 버렸습니다.

  이것은 현재 진행형의 이야기 입니다. 끔찍한 잔업과 시달림은 관리자들 - 특히 빅 보스 (Big boss) - 에 의해서 만들어졌습니다. 그러므로, 문제를 해결하는 것도 관리자들 (역시 빅 보스)의 책임입니다. 어쩌면 모든 문제를 만든 것은 회사 조직 그 자체일지도 모릅니다.

  앞으로 어떻게 진행이 될까요? 글쎄요. 문제를 해결 할 수 있는 사람이 변하지 않으면, 계속 같은 이야기가 반복되겠지요. 아마도, 끊임없이 같은 이야기가 반복될 지 모릅니다. 그리고, 진짜 쓸만한 개발자는 아무도 안남게 되겠지요.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  조엘 온 소프트웨어 (Joel on software) 에서도 여러번 다룬 이야기지만, 막상 평가를 당하는 대상이 되면 이건 전혀 다른 이야기다. 특히나 우리회사 같이 큰 회사에서 많은 수의 사원들을 대상으로 랜덤이 돌아가고 있다고 느껴진다면 이건 정말 큰 문제가 된다. 프로그래머들은 의욕을 잃고, 능력이 부족한 동료 때문에 자기에게 추가 업무가 전가되는 것에 짜증을 내기 시작한다. 불투명한 고과가 팀웍을 깬다. 그건 곳 그 고과권자가 무능함을 뜻한다.

  조엘이 자신의 글에서 실증적인 예를 들었듯이, 프로그래머를 평가하는 객관적인 방법은 없다. 어떠한 잣대를 들이대더라도 프로그래머는 빠져나갈 구멍을 만들 것이며, 어떠한 잣대도 프로그래머의 창의성을 저해할 것이다. 평가를 받는 프로그래머의 목표는 더이상 가장 뛰어난 프로그램을 만드는 것이 아니기 때문이다. 그의 목표는 당연히 고과 기준에 맞는 일을 하는 것이 될 것이다. 심지어 그것이 의도적인 버그를 숨기는 일이 될지라도 말이다.

  특히나, 우리회사 같은 곳에서는 문제가 더 심각하다. 대한민국 100대 기업 안에든다는 회사가 나 입사할 때만 해도 조엘 점수가 12점 만점에 8.5점을(매우 후하게 준 것이다) 겨우 넘기는 정도였다. 조엘은 자신의 책에서 11점 미만은 가서는 안된다고 단언을 했지만, 우리회사는 입사 경쟁률이 꽤 높았다. 지금은 많이 개선되어서 11점 정도 되었다. 하지만 아직도 가장 Critical한 문제가 남아있다. 바로 채용의 문제인데, 프로그래머를 채용하면서 프로그래밍 능력을 묻지 않는다. 하하...

  프로그래머의 고과를 객관적으로 매길 수 없다면, 처음부터 A급 프로그래머를 뽑는 수 밖에 없다. B급 프로그래머의 10배 일을 하는 A급 프로그래머들로 팀을 꾸리고 모두에게 A고과를 줘라. 그리고 그들이 마음대로 뛰어놀 수 있도록 풀어놔라. 맨먼스 미신에서 말하는 것 처럼, 300명의 프로그래머와 25명의 관리자 보다 뛰어난 25명이 그냥 일을 하는 편이 더 좋다. 내가 입사하기 전에도 제품은 출시가 되었고, 인원이 두 배가된 지금도 버그는 엄청나게 숨어있다. 결국, 인원이 늘어났지만 나아진 것은 별로 없다는 뜻이다. 아니, 문제는 더 늘어나고 있는 걸지도 모른다. 제대로된 프로그래머를 채용하지 않는다면 인원이 늘어날 수록 문제도 따라 늘어날 것이다. 제발 인사쪽에서 제조업 마인드를 버렸으면 좋겠다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
Total : 316,331
Today : 0 Yesterday : 12