개발자의 개발량의 편차가 매우 큰 경우

[Hubert Shin]

Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.

11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.

1. 코드의 공동 소유

2. Story Point 추정시 고객 포함 전원 참여

위와 같은 기법을 사용하고 있는 상황에,

각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.

4차례에 Sprint 를 이미 진행 했고요.

문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.

함께 추정한 포인트들에 대해

Pair Programming을 할 수 없는 상황에서,

특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 있습니다.

쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠. 

이슈는 두 가지인데요

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지

2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

에 대해 의견을 듣고 싶습니다. 

감사합니다.

[Jooyung Han]

teamwork에 대한 문제같네요.
pair programing 을 못하는 상황이 더 궁금하긴 하지만..
암튼, 팀전체가 웍샵을 하든 어떻게든 방법을 찾아야 할 것 같습니다.
(단지 누군가의 속도가 느린것이 불만은 아닐거란 느낌이...)

저라면 pair programming을 못하게하는 상황을 고쳐보고 싶네요.

--
Jooyung Han

[ParkPD]

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

저라면, 10의 속도를 가진 개발자(B)에게 귀찮은 단순작업량을 늘리지 않을까 합니다.
그러면 50의 속도를 가진 개발자(A) 의 입장에서도 내가 하긴 불편한 일을 대신 B 가 해 주는 것에 대해서는 인정하지 않을
까 싶네요.
팀 전체 입장에서도 A 의 능력을 최대한 끌어낼 수 있을 거 같구요.
적절한 업무분담은 리더가 잘 이끌어 줘야 하는 부분이라고 생각합니다.

B 가 스스로 노력하게 하는 가장 확실한 방법은 평가밖에 없을 거 같네요.
일관된 기준으로 최대한 공정하게 평가할 수 있다면(모두를 만족시키는 건 불가능할 거 같지만)
서로 경쟁하면서 개개인의 능력을 최대한으로 만들 수도 있지 않을까 생각됩니다.

뭐.. 써 놓고 보니 말하는 거야 그래도 실제로 실행하기란 참 어려워보이네요.

[Jooyung Han]

"리더의 업무분장, 평가, 경쟁"은 스크럼/애자일과는 반대되는 느낌이....
업무어사인과 평가는 오히려 대부분의 조직에서 시행하고 있는 방법들입니다.

--
Jooyung Han

[영회]

비슷비슷한 생각을 하시네요.. :)

어제 밤에 이 글을 보고 생각나서 쓴 글입니다: http://younghoe.info/1095

[Seung Joon Choi]

애자일의 초보로써 문제에 대해 제가 충분히 경험하지 못한 상황이지만 생각난 바가 있어서 적어보겠습니다.

P1. OOO은 다양한 level of scale에서 자기 유사성을 같는다

P2. OOO은 자기 자신을 참조하고 포함해서 스스로 개선할 수 있도록 열려있다

OOO은 애자일일 수도 있겠죠.

속도가 50, 20, 20, 20, 10 이라면 팀의 평균은 24네요.

40, 30, 30, 30, 20 이라면 팀의 평균은 30입니다.

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지

2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

기업의 입장에서라면 포기하기 아쉬운 일이겠지만 50의 속도를 극소수만 내고 있는 것도 10의 속도로 팀의 발목을 잡는 것 못지 않게 팀의 건강에 안 좋은것이 아닌가 생각해 봅니다. 스포츠 만화 등을 보면 비슷한 패턴이 많이 나오는 것 같습니다. :-)

편차를 줄이되 전체가 상승할 수 있도록 도우면 어떨까요?

이를 위해서는 이 문제에 대해 팀 자체가 이야기 할 수 있고(비폭력 대화) 경청하고 함께 방법을 모색하는 팀의 Awareness를 높일 필요가 있다고 봅니다. 팀을 이끄는 사람, 속도가 빠른 사람, 느린 사람, 평균적인 사람 등 각자의 욕구를 서로 알 수 있도록 하고 지금 상황에 대한 인식을 높여서  스스로 가감을 조절할 수 있는 노력을 할 수 있도록 팀의 문화를 형성하면 좋을 것 같습니다.

또한 그 가고자 하는 방향으로 갈 때의 과정도 작은 단위로 짧게 끊어가며 기민하게 하면 좋겠죠. 

그 과정을 통해서 빠르게 달려가고 있는 사람은 살짝 살짝 브레이크를 밟고 그 중간중간 확보된 시간으로 다른 맥락에서 스스로의 동기부여도 되고 결과적으로 팀을 더 건강하게 할 수 있는 일을 하고, 가장 느리게 하고 있는 사람은 팀에 어떤 기대와 욕구가 있고 자신의 그 것과 빗대어 측정하며 그 차이를 줄일 수 있도록 움직일 수 있도록 도울 수 있거나 혹은 그 차이를 줄이기가 굉장히 어려운 일이라는 것을 모두가 알 수 있도록 하여 보다 더 문제에 대해 근원적인 생각에 그 에 따른 적절한 접근이 뭔지에 대한 질문을 떠올리게 할 수 있을 가능성이 있을 것 같습니다.

해당 문제를 이슈화 하여 함께 나눌 수 있는 여력의 확보와 충격이 발생할 때 이를 완화할 수 있는 포지션과 이를 시도하고자 하는 용기 등이 필요하지 않을까 짐작해 봅니다. 그러면 팀은 스스로를 보완하며 해결방안을 스스로 찾을 수 있지 않을까요?

[Seung Joon Choi]

참 팀 안에서의 속도와 질의 상관관계는 어떤 것인지 궁금하기도 했었는데 질문하는 것을 깜빡했군요.

[June Kim]

저라면 다음과 같은 작업들을 우선 해보겠습니다.

2009/2/12 Hubert Shin <huber...@gmail.com>:

> Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.
> 11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.
> 1. 코드의 공동 소유
> 2. Story Point 추정시 고객 포함 전원 참여
> 위와 같은 기법을 사용하고 있는 상황에,
> 각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.

하나의 스토리는 개발자 한 명이 작업하나요?

> 4차례에 Sprint 를 이미 진행 했고요.
>
> 문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.

그 불만 이면에는 진실로 어떤 욕구가 있는지 대화(및 공감)해 보겠습니다. 그와 동시에 속도가 느린 사람은 이 상황을 충분히
인식하고 있는지, 어떤 느낌을 받는지, 어떤 욕구가 있는지 대화(및 공감)해 봅니다.

> 함께 추정한 포인트들에 대해
> Pair Programming을 할 수 없는 상황에서,
> 특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고
> 있습니다.

우선 50정도로 작업하는 개발자와 짝을 해보거나 혹은 관찰하거나 합니다. 소스코드를 훑어보기도 합니다.

이번에는 20정도 일을 수행하는 개발자들 몇 명에 대해서도 정보를 얻습니다.

마지막으로 10 정도의 속도를 가진 개발자와 짝을 해봅니다.

이렇게 해서 속도가 10인 사람이 왜 10인지, 그 사람의 태도 때문인지, 습관 때문인지, 특정 지식이 부족해서인지, 도구
사용법이 잘못되어서인지 등을 구체적으로 알아냅니다. 그와 동시에 50인 사람과 가장 대조적으로 차이가 나는 부분이 무엇인지,
혹시 50인 사람이 하는 것 중에서 이 10인 사람에게 도움이 될만한 것은 무엇일지 알아냅니다.

여기까지 알게 되면 이제 어떻게 할지 생각해 봐야겠죠(아마도 다른 팀원들의 의견을 많이 참고할 듯).

[cavin]

수행능력 개선방법은 차후 문제이고
팀원끼리 해낸 일의 분량을 서로 비교하고
불만을 갖게되는 상황을 개선하는 것이 우선이지 않을까 싶습니다.

60, 40, 30 으로 각자 수행능력이 개선되서 프로젝트 기한을 만족해도
불만은 여전히 남고 시간이 지날수록 심화될테고 팀워크 분열이나 어떤형태로든 분출될테니까요..

협력이 성과로 연결되는 상황을 만들어보면 어떨가요..
1. 팀이 더 많은 일을 할 수 있도록 돕는 것을 성과목표로 부여하기
2. 해내는 일의 분량과 별도로 '개선된 정도'도 성과목표로 부여하기
3. 성과가 있다면 비록 작은 것이라도 자주 보상해 주기.(ex,반차+문화상품권)

저라면 우선 50또는 50에 가까운 분들 중에서
지원을 받아 다른 팀원을 돕는 롤을 둘 생각입니다.
50그룹에서 반나절 10~20그룹에서 반나절씩 짝프로그래밍을 반복하는 것이죠.

해당 롤을 수행하는 분이 패턴과 안티패턴을 발견하고
팀 공통적인 기술셋, 아키텍처, 커뮤니케이션, 관리 등과 관련지어 문제를 바라보고
이를 집약해서 개개인, 팀단위로 피드백이나 회고, 주기적인 교육을 통해 개선하도록 하는 것이죠.

일단 이와 같이 시작을 하고 추이를 보고
팀에 가장 도움이 되는 것이 무엇인지에 따라
롤을 수행하는 분을 바꿔나가면 좋지 않을까 생각해 봅니다.
10~20에서 50으로 향상된 분이 있다면 그 분이 팀에 가장 많은 도움을 줄 수 있는 분이 될 가능성이 높겠죠.

길었네요.. 간추리자면 '경쟁관계를 협력관계로 유도하자' 정도가 되겠습니다.
좋은 주말 되세요~

[Youngrok Pak]

기업의 입장에서라면 포기하기 아쉬운 일이겠지만 50의 속도를 극소수만 내고 있는 것도 10의 속도로 팀의 발목을 잡는 것 못지 않게 팀의 건강에 안 좋은것이 아닌가 생각해 봅니다. 스포츠 만화 등을 보면 비슷한 패턴이 많이 나오는 것 같습니다. :-)

편차를 줄이되 전체가 상승할 수 있도록 도우면 어떨까요?

정말 뛰어나게 잘하는 사람이 팀에 있는 것이 팀 건강에 나쁠까요?

[Seung Joon Choi]

저는 속도 50의 맥락이었는데요.

'정말 뛰어나게 잘하는 사람'의 맥락이라면 비슷하지만 약간 다를 수 있을 것 같습니다.

퍼포먼스와 개발의 실력만이 정말 뛰어나기만 한 사람이라면 팀의 건강함에는 부정적인 영향을 끼칠 가능성이 비교적 크다고 생각합니다.

하지만 그 사람이 정말 뛰어나서 커뮤니케이션 및 서로 배우고 함께 상생하는 것 까지 포함한 뛰어남을 보여준다면 긍정적인 영향이 훨씬 많겠죠.

전자의 경우는 팀 또는 회사의 퍼포에 대한 단기적인 안목으로는 확실히 도움이 된다고 생각합니다. 하지만 장기적으로는 어떨까요?

제 경험에서도 굉장히 우수한 교사가 있었는데 교사들의 문화에서 그 분이 살아가는 것이 아마 실력의 차이와 그에 대한 관리자의 인정이 두드러지게 높았기 때문에 잠재적인 낙차를 형성했고 결국 그로부터 얻어진 포텐셜 에너지는 다양한 현상(특히 문제)들을 야기하기도 했는데요. 가장 아쉬웠던 것은... 결국 개인의 발전(석박사진학 등)을 위해서 그 분을 놓아드려야 했을 때... 빈 공간이 발생했고 대야에서 물 한바가지 크게 퍼낸듯이 시간이 흘러감에 따라(꽤 오래 걸렸지만요) 그 자리가 메꿔지긴 했지만, 수면이 꽤 낮아진 상황이 발생했습니다.

팀의 건강이란 측면에서 생각해야할 정말 뛰어나다... 라는 것은 어떤 것일까요.

[변신철]

아주 뛰어난 사람으로 부터 발생되는 낙차를 어떤 순에너지로 전환시키냐는 리더의 몫이리라 생각합니다.
실제로 제가 팀을 운영하던 중에 이런 비슷한 사례로 힘들어 한적이 있는데
낮은 성과를 내던 인력도 어떤 재교육없이 꾸준한(이게 몹시 중요합니다) 관심만으로도 개선이 되더라는 것입니다.
물론 그의 개선을 기다리는 동안 피마름의 압박을 팀장으로서 이겨내야 하는 것도 큰 숙제이지만,
보통 어떤 문제가 있음을 가장 잘 아는 것은 팀장이나 동료가 아니라 본인이고 본인 스스로 그것을 개선하도록 도와야 하기 때문이더
군요.
주변의 충고나 도움은 별로 도움되지 않는 다는 것이 일관된 경험이었습니다.
견디고 이겨낼 용기와 꾸준한 인내가 없다면 그 친구를 다른 곳에서 더 큰 역량을 내도록 하는 것이 좋지 않을까 합니다.
그리고 아주 뛰어난 성과를 내던 친구가 있었는데 그의 지적호기심을 채워 줄 만한 환경과 문제를 제공하는 동안에는 아무런 문제가
없었습니다.
그러는 동안에는 이친구가 문제를 해결하고 그것을 동료들과 나누고 하는데 뭐랄까 행복감을 느끼는 것을 봤습니다.
아쉽게도 그 친구가 퇴사를 결심한 배경의 첫번째가 "좋은 코드를 만드는 것은 내 삶의 질과 같다"는 그의 철학을 지켜주지 못했
기 때문입니다.
뛰어난 사람을 뛰어나게 인정을 하고 그가 그 뛰어남을 한번 더 뛰어넘게 하는 리더가 팀에 있다면 장/단기적으로 문제가 없지 않을
까 하네요...

[Seung Joon Choi]

동감합니다.

[June Kim]

많은 문제들은 관리자/팀장이 정확한 사실과 개개인의 상황, 맥락을 이해하지 않은 채로 너무 빨리 액션을 취할 때(혹은 뭔가
빨리 조치를 취해야 한다고 생각할 때) 일어납니다.

예를 들어, "50의 속도를 가진 사람"이라는 정보로부터 알 수 있는 것은, 그 사람은 정해진 기간 동안 (아마도) 50
스토리 포인트를 끝냈다라고 주장한다는 것이겠죠.

저는 그 속을 보아야 한다고 생각합니다.

단순히 능력이 뛰어난 사람과 부족한 사람이 있을 경우의 문제가 아니고 더 큰 문제가 뿌리해 있을지도 모르는 것이거든요.

2009/2/13 June Kim <june...@gmail.com>:

[Youngrok Pak]

만약, 정말로 개발 생산성이 5배 높은 뛰어난 팀원이 있다고 가정해 봅시다. 하지만 이 팀원의 팀웍은 다른 팀원에 비해 더 낫지도, 낮지도 않은 상황입니다. 말 그대로 순수하게 개발 능력만 5배가 높은 팀원이고 나머지 능력은 같습니다.

자신의 팀에 이런 팀원이 있으면 좋을까요? 나쁠까요? 면접에서 이런 사람이 지원했다면 채용하시겠습니까?

[변신철]

저의 경험으로는 개인의 가진 역량은 그가 속해있는 팀에 따라 유동적이었던 것으로 생각됩니다.
소위 말하는 개인의 생산성 보다는 팀의 생산성이 좀 더 중요하다고 믿고 있기도 하지요.
정말 아무런 차이 없이 생산성만 5배가 높다면 저라면 잽싸게 채용할 것 같습니다.
우리 팀에 오고 나서 그가 1혹은 5배 중 어떤 생산성을 가질지는 우리팀의 그릇의 문제니까요...

근데 한가지 궁금한것은 그 사람의 생산성이 5배가 높다는 것과 그의 능력이 5배가 높은 것이 같은 건지요?
그리고 면접을 보는 저는 그의 개발능력을 혹은 개발 생산성을 어떻게 파악할 수 있는건지요?

[JinYoung]

메일링 리스트를 쭉 읽어봤습니다만, 왠지 분위기가 좀 재미있게 흘러가는 듯
합니다.

개발 속도가 50인 개발자를 "나쁜" 사람으로 몰고가는 듯한 분위기가 살짝 느
껴져서요. ㅎㅎ

사실 50 개발자가 상대 적으로 "손해" 본다라는 느낌을 받는 상황의 원인은
아주 많지 않겠습니까?

예를 들어 50인 개발자는 실제로 같은일을 시켜도 10인 개발자보다 5배 빨리

(품질은 비슷하거나 이상) 하는데 처우는 똑같다면(뭐 근무 조건

- 월급이나 휴가 등등 -) 시간이 흐르면 흐를 수록 50 개발자는 회의가 들 수
도 있겠죠.

또는 뭔가 추가적인 작업이 필요할 때(물론 스크럼에서는 스프린트 동안 원래
계획했던

일 이외에는 못하도록 하고 있지만, 세상 살이가 꼭 그렇게 되는것만은 아니
라서... -_-)

그 추가적인 작업이 50 개발자한테 할당될 수 도 있는 것이구요.

"왜 저한테만 일을 주시나요. 10도 있는데..." "응 네가 빨리 잘하잖아.... "
뭐 이런거라든가

혹은 "너 할것은 기존과 똑같이 해내면서 10도 좀 끌어 올려줘..." 라고 압박
이 있었을 수

도 있겠네요.

우리에겐 좀 더 정보가 필요하지 않을까요? :-)

[주넥]

어느 회사고 숙련도에 차이가 있고 이에 따라 개발자의 능력도 차이가 나기 마련이라고 생각됩니다.

결국에는 공정한 인사 평가와 이에 따른 보상 체계가 마련되면 50 의 속도를 내는 개발자의 불만이 없어질 것이라 보입니다.

승진이 빠르거나, 연봉 협상에서 연봉을 높게 받거나, Incentive가 차별이 있든가...

이러한 보상 체계중에서 회사전체적으로 보았을 때 팀 평가 항목이 있고, 팀 간 평가에서 특정 팀이 다른 팀 대비 성과가 높을 경
우 성과금등이 차별 지급된다면, 전체 팀간 경쟁에서 50 숙련자가 속한 팀의 성과를 위해서 자연스럽게 10 짜리를 도와주는 협력
도 일어날 것이라 보여집니다.

[Richard Kang]

흠....분류방법자체가 좀 어폐가 있지않을까요? 순수하게 개발능력만 5배인 사람이라....

제 개인적인 경험으로는 개발능력 5배인사람은 긍정적인 면에서는 개발능력 5배를 위해서 많은 정보들을 수집,공부하고 시간관리또한 잘하여 업무시간외에도 시간을 내어서 공부하는 식의 옆에 인원에게 긍정적인 혹은 자극을 주기 때문에 당연히 뽑아야할 분이라고  생각됩니다.

 

순수하게 개발능력만 5배인 사람이 있을까요?

부족한 경험으로는 잘모르겠네요.

 

@포동28

[Wonderer]

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지

=>일반적으로 빠른 업무소화 속도를 가진 개발자가 손해보고 있다라는 느낌을 갖는 이유는

   자신의 능력에 비해 대우(평가)를 받지 못하고 있다고 느끼기 때문입니다.당연히 그에 맞는 대우를 해줄 수 있으면 됩니다.

   그렇지 못하면 결국 팀을 떠날 가능성이 높겠지요

 

2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

=>프로젝트 중간에 10의 속도를 가진 개발자의 속도를 3배이상 향상시키는 일은 거의 불가능에 가깝다고 봅니다.

   (혹시 단기간에 가능한 방법을 아시게 된다면 부디 알려주시기 바랍니다)

   다만 50의 속도를 가진 개발자와 비교했을 때 10의 속도를 가진 개발자의 가치가 1/5라고 볼 수는 없겠지요.

  

 

개인적인 의견입니다만 페어프로그래밍을 할 수 없는 상황에서

개개인의 스토리 처리 속도에 대해서 공개적으로 알 수 있는 상황은

그다지 좋은 분위기일 것이라고 생각되지 않습니다.

 

개개인의 가치가 오로지 업무속도로만 평가되는 분위기가 되고

서로간의 협력과 유대는 더욱 힘들어 질 것입니다.

 

또한 10의 속도를 가진 개발자 역시 50의 속도를 가진 개발자보다 더욱 큰 불만과 박탈감을 느끼고

있을지 모릅니다. (다만 본인은 불만을 토로할 자격이 안 된다고 생각할 수 있습니다)

 

현재 정보만으로는 제가 더 이상 어떤 말씀을 드리긴 힘들지만

만약 정말로 50의 속도를 가진 개발자와 10의 속도를 가진 개발자가 5배 수준의 가치를 지닌다면(다른 능력은 같고 버그발생율도 같음)

저는 10의 속도를 가진 개발자를 내보내고 50의 속도를 가진 개발자에게 내보낸 개발자의 임금을 더 주겠습니다.

그럼 50의 속도를 가진 개발자가 60의 속도를 낼 수 있을지도 모르겠군요.

(손해보고 있다고 생각하는 개발자는 보통 페이스 다운을 하는 경우가 많습니다)

 

비약이 조금 심한 말이었을지도 모르겠습니다만 이쪽이 더 효율적이지 않을까요?

---

From: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of Hubert Shin
Sent: Thursday, February 12, 2009 6:53 PM
To: xp...@googlegroups.com
Subject: 개발자의 개발량의 편차가 매우 큰 경우

[Joseph Jang]

일단 저는 50의 속도와 10의 속도가 실제 그 개발자의 '실제 능력'이라고 보고 논의를 진행하겠습니다.
(김창준 님이 지적하신대로 인지된 속도를 실제 속도나 실제 능력이라고 오해하지 않도록 주의해야 한다고 생각합니다.)
오해를 방지하기 위해 '뛰어난' 개발자와 '부족한' 개발자라고 하겠습니다.

제 생각은 다음과 같습니다.

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지

1.1 기본적으로 (금전적, 사회적, 감정적인 측면 등 여러 측면에서) 충분한 보상을 주어야 합니다.

1.2 능력이 뛰어나다고 해서 업무가 몰려서 너무 과중하지 않도록 신경써주어야 합니다.

성공의 경험이 동기부여를 해준다고 하면, 업무가 계속 밀리는 것은 실패의 경험이라고 볼 수 있으므로 주의해야합니다.
일반적으로 뛰어난 개발자는 스스로 동기부여도 잘하는 사람이라고 볼 수 있고,

2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

2.1 그 개발자가 가장 잘할 수 있는 업무를 주어야 합니다.

여기에는 두가지 가정이 있는데요.
- 어떤 개발자라고 하더라도 스킬이나 분야에 따라서 능력의 차이가 나고,
- 업무에 따라 필요한 스킬이 다르다는
것입니다.

그럼에도 불구하고 부족한 개발자가 가장 뛰어난 분야에서의 능력이 여전히 뛰어난 개발자보다 떨어지는 경우들이 자주 있습니다.
설령 그렇다고 해도, 뛰어난 개발자가 (1.2의 이유에 의해서) 모든 업무를 맡아서 할 수는 없기 때문에,
부족한 개발자가 잘하는 업무를 하는 것이 뛰어난 개발자가 다른 더 중요한 업무를 희생해서 하는 것보다 더 효율적인,
무역에서의 비교우위와 같은 현상이 발생합니다.

결과적으로는 위에서 지적하신대로, 뛰어난 개발자가 하기 싫어하는 어느 정도는 반복적인 업무지만 팀의 성과에는 중요한 업무 등이
될 수는 있다고 봅니다.하지만, 그런 업무를 하더라도 자동화라는 더 높은 목표를 제시하거나 해서 동기 부여는 물론 팀의 성과를
꾀하는 것이 필요합니다.

2.2 성장할 수 있도록 적극적으로 도와야 합니다.

위에 여러분들이 말씀하셨듯이 부족한 개발자가 갑자기 보통 개발자나 뛰어난 개발자가 되는 일은 없습니다.
부족한 개발자라고 해서 반복적이고 쉬운 업무만 맡기는 것이 아니라 조금씩 더 도전적인 업무를 맡기고,
사수를 붙여주고, 교육 기회를 제공하고, 면담을 통해 성장에 대한 동기 부여를 함으로써,
성장을 도와주는 것이 리더의 중요한 책임 중 하나라고 봅니다.

부족한 개발자의 업무를 항상 뛰어난 개발자에게 몰아주고 해고해버릴 수 없습니다. 1.2의 이유도 있지만, 다른 이유는
뛰어난/보통 개발자 모두가 영원히 여러분의 팀에 있으리라는 가정을 할 수는 없기 때문입니다.
따라서, 계속 해서 부족한 개발자들을 성장하도록 도와서 팀 전체의 능력을 유지 또는 성장할 수 있도록 것도 중요한 일 중의 하나
입니다.

초보 관리자이긴 하지만, 제 생각을 정리해볼 겸 적어보았습니다~

[Richard Kang]

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지

=> 저역시 대우의 문제가 아닐까요? 50의속도를 내는 개발자에게 연말 인센티브라도 더 챙겨줄려면 어떤 프로세스를 갖춰야할까요?

 

 

 

2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

=>10의 개발자를 내보내고 그 돈을 50개발자에게 얹어줄것이냐,10의개발자를 30으로 될수있는 방법을 찾을것이냐의 선택을 해야한다면 전 후자를 택할것같습니다. 왜냐하면 그 속도라는건 경우에 따라서 유동적일수있으니깐요. 장기간 10의 속도밖에 못낸다면 당연히 바꿔야하는게 맞지만 그 속도라는게 변동이 생길경우가 크다는 것입니다.

그리고 대부분 10의 개발자는 교육시키기에 따라 30정도는 해내지 않을까요? 그럼...10개발자를 어떻게 속도를 올리느냐? 관리가 더 들어가야할것같습니다.

어디서 헤매고있는지 막혀서 삽질하고있는걸 어떻게 풀어줄것인지, 틈틈이 일정체크하고 페어프로그래밍을 몇차례라도 시키고 등등으로 말이죠.

 

너무 낙관적인 생각인지는 모르지만 그러면 머...조금이라도 올라가지 않을까 하는 생각입니다.

 

@포동28

---

From: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of Hubert Shin
Sent: Thursday, February 12, 2009 6:53 PM
To: xp...@googlegroups.com
Subject: 개발자의 개발량의 편차가 매우 큰 경우

Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.

 

11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.

 

1. 코드의 공동 소유

2. Story Point 추정시 고객 포함 전원 참여

 

위와 같은 기법을 사용하고 있는 상황에,

각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.

4차례에 Sprint 를 이미 진행 했고요.

 

문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.

 

함께 추정한 포인트들에 대해

Pair Programming을 할 수 없는 상황에서,

 

특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 있습니다.

쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠. 

 

이슈는 두 가지인데요

 

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지

2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

 

에 대해 의견을 듣고 싶습니다. 

 

감사합니다.

<BR

[Jake J. Kim]

역시 사람관리가 가장 어렵다는 것을 다시 한번 일깨워주는 질문이 아닌가 합니다. 이것은 애자일을 떠나서 어느 분야에서도 가능한
시나리오가 아닐까 생각합니다.

이 문제에 대한 제 의견은 이렇습니다.

위에서 많은 분들께서 말씀하셨듯이 50의 속도를 가진 개발자는 그만큼의 보상으로 '스스로 손해보고 있다'라는 느낌을 적게 줄
수 있을지 모르지만, 10의 속도를 가진 개발자를 30의 속도롤 높이는 것은 거의 불가능하다고 보여집니다. 같은 팀으로 몇년간
같은 프로젝트를 하기 전에는 말이죠.

제가 보기에 (위의 내용으로만 유추해 봤을때) 현재 프로젝트가 진행되고 있는 상황에서는 스토리를 어떻게 할당을 하느냐가 단기적
인 해결 방법일것 같습니다. 무조건 할당하는 것이 아닌 50의 개발자에게 더 많은 포인트의 스토리를 맡기고 10의 개발자에게는
가장 적은 포인트의 스토리만 맡기는 거죠. 의도적으로 속도의 균형을 맞춘다고 할까요.

가령 어려운 문제의 스토리의 경우 50의 개발자에게 '당신이 좋은 실력을 갖고 있으니 이 스토리를 맡는것이 좋겠다' 라거나, 쉬
운 스토리의 경우는 '당신은 더 경험이 필요한것 같으니 우선 이런 스토리정도를 맡는 것이 좋을것 같다' 라고 할 수 있을 것 같
습니다. 물론 저는 50의 개발자와 10의 개발자가 같은 직급의 개발자는 아닐 것이라는 가정을 합니다. 만약 그렇다면 10의 개
발자를 계속 데리고 있을 것인지에 대한 심각한 고민이 필요할지도 모릅니다.

On Feb 14, 9:25 pm, "Richard Kang" <podon...@gmail.com> wrote:
> 1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
>
> => 저역시 대우의 문제가 아닐까요? 50의속도를 내는 개발자에게 연말 인센티브라도 더 챙겨줄려면 어떤 프로세스를 갖춰야할까요?
>
> 2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
>
> =>10의 개발자를 내보내고 그 돈을 50개발자에게 얹어줄것이냐,10의개발자를 30으로 될수있는 방법을 찾을것이냐의 선택을 해야한다면 전 후자를 택할것같습니다. 왜냐하면 그 속도라는건 경우에 따라서 유동적일수있으니깐요. 장기간 10의 속도밖에 못낸다면 당연히 바꿔야하는게 맞지만 그 속도라는게 변동이 생길경우가 크다는 것입니다.
>
> 그리고 대부분 10의 개발자는 교육시키기에 따라 30정도는 해내지 않을까요? 그럼...10개발자를 어떻게 속도를 올리느냐? 관리가 더 들어가야할것같습니다.
>
> 어디서 헤매고있는지 막혀서 삽질하고있는걸 어떻게 풀어줄것인지, 틈틈이 일정체크하고 페어프로그래밍을 몇차례라도 시키고 등등으로 말이죠.
>
> 너무 낙관적인 생각인지는 모르지만 그러면 머...조금이라도 올라가지 않을까 하는 생각입니다.
>
> @포동28
>
> _____
>

[Sangchel Hwang]

우리의 SI 프로젝트 현실에서 특정 개발자가 아주 우수하다고 하더라도 그 사람에게 5배의 급여를 주지는 못하는게 현실입니다. 그러니 급여로 보상하는것은 어려울거 같아 보입니다.

애자일 프로젝트의 평가는 팀 단위로 한다고 알고 있습니다. 팀원간에 시너지를 극대화하기 위해서는 특정 팀원만을 대우하는것이 좋지 않은 영향을 미칠 수 있다고 봅니다.
그러니 한 팀이라는 사실을 서로 인지하고 일할 수 있는 분위기를 만들어 가는것이 필요하다고 생각됩니다.

말은 쉽지만 현실은 어렵죠.

2009/2/15 Jake J. Kim <drca...@gmail.com>

--
Blog URL: http://moai.tistory.com

[cavin]

개인간 수행능력 차이는 생길 수 밖에 없습니다.
그것은 그리 큰 문제가 되지 않는다고 생각합니다.
집중해야 하는 것은 '서로 비교를 하는 상황' 이 아닐까요?

부모가 자식들에게 하지 말아야 할 것들 중에 '비교'란 것이 있습니다.
'자식들간 비교', '내 아이를 남의 아이와 비교하는 것'
비교는 아이에게 인격적 모멸감을 주고
비교당하는 약한 아이에게는 열등감을 심어주고
비교당하는 형제들간 경쟁과 분열을 조장하기 때문이죠.

가령 자식이 둘이 있는데 형은 70점 동생은 50점을 받았습니다.
형이 공부를 잘하니 용돈을 더 준다고 하면 동생이 과연 분발할까요.
두 아이들이 점수가 나아지기 위해서 서로 격려하고 돕고 노력할까요?
70점 맞은 큰 아이는 옆집에 100점 맞은 아이 얘기를 들으면 분발하고 더 열심히 할까요?
아이들이 공부를 잘하도록 유도하는 것에도 우애에도 올바르게 성장하는 것에도 전혀 도움이 되지 않습니다.

또 성적만으로 동생에게 '넌 형이 공부를 할 수 있게 다른 일을 도와주렴..'
'공부대신 체육이나 예능쪽을 해보는게 어때..' 이와 같이 하는 것도 아이에게 도움이 되지 않겠죠.
성적만으로 아이의 취향, 가능성, 적성, 환경, 문제점 을 알 수 없으니까요. 전혀 바람직하지 않습니다.

팀도 그다지 다를 바가 없다고 생각합니다.
50의 생산성을 가진 분은 팀의 축복입니다.
10의 생산성을 가진 분은 개발결과 수치만으로는 알 수 없지만
어쩌면 팀워크를 다져서 팀원 모두의 생산성에 +5가 되도록 기여를 하고 있을지도 모릅니다.

하지만 미팅에서 팀장이 'OOO씨는 50점을 개발했습니다. OOO씨는 10점을 개발했네요..'
발표하는 순간 10점 맞은 개발자는 모멸감에 몸을 떨고 50점 개발한 사람은 불만에 빠지겠죠.
측정된 결과치가 팀워크나 개발생산성 기여에 대한 진실이 될 수 있을까요..

그리고 이러한 내용들이 서로 비교되도록 하는 것이
팀원이 분발하고 노력하고 협력하도록 하는데 도움이 되는 방법일까요..
또 팀장이 선택한 측정방법으로 좋지 않은 결과를 획득한 팀원은 도태되도 그만일까요?
열등감을 갖기 쉬운 수줍음을 잘타는 팀원들은 특정한 방법에 적응하도록 성격을 개조해야 할까요?

방법은 배우면 그만이지만 그러한 방법을 선택하고 행하게 하는 동기는
전혀 공학적이지 않은 각자의 선한 생각이라던가 만족과 목표 같은 것에 달려있고
이것은 인격이라던가 개성에 대한 것이지 공학적인 방법을 우선해서 바꿀 수 있는 것과는 거리가 멀다고 생각합니다.
방법과 결과에 우선하고 몰두하다 보면 보이지 않는 것은 쉽사리 지나치기 마련이죠.
공학적인 방법이나 수치보다 존중과 같은 기본적인 것에 대해 좀 더 주의를 기울여봐야 하지 않을까요.

남을 도움으로써 팀이 보상받고 나도 더 큰 보상을 받고
모두가 행복해질 수 있다..란 것을 팀원과 팀이 배울 수 있도록
개인을 위한 목표와 보상체계나 문화를 만들어 나가는 게 필요하다고 생각합니다.
(기법이 무엇이든 그것이 큰 문제는 아니잖아요..

글솜씨가 없어 당연한 말들을 너무 길게 쓴게 아닌가 싶네요. 좋은 하루 되시기 바랍니다.

p.s 팀내에서 상대적으로 개발생산성이 높은 팀원에게 보상하는 것도 고민해야 합니다.
50의 불만을 해소하기 위해 팀워크간 상대적인 생산성 이란 자대를 들이대며
50에 보상을 해주고 이러한 사실이 공유되면 자칫 나머지 팀원들의 괴리감을 증폭시킬겁니다.

[Jake J. Kim]

cavin 님의 말씀에는 원론적으로는 동감합니다. 또한 예로 드신 것처럼 '비교'라는 것은 가정구성원들 사이에서는 아주 좋지 않
습니다. 하지만 '비교'가 전혀 바람직하지 않다는 내용에 대해서는 반대입장입니다.

회사는 이익집단입니다. 비교가 필요하고 차별을 해야 하는 것이 이익집단입니다.
비인간적인 비교는 바람직하지 않겠지만 실적을 기준으로 비교를 하고 차별을 하는 것은 이익집단의 근본이라고 생각합니다.
아니, 해야한다고 생각합니다. 필요악이라고 할 수도 있겠죠.
그것이 마음에 들지 않는다면 자신도 차별화된 대우를 받기위해서 노력을 해야겠죠. 물론 그러기 위해 노력하는 개인에게는 도움을 주
어야 할테구요.

> 남을 도움으로써 팀이 보상받고 나도 더 큰 보상을 받고
> 모두가 행복해질 수 있다..란 것을 팀원과 팀이 배울 수 있도록
> 개인을 위한 목표와 보상체계나 문화를 만들어 나가는 게 필요하다고 생각합니다.
> (기법이 무엇이든 그것이 큰 문제는 아니잖아요..

이익집단에서 남에게 도움을 준다는 것은 너무 이상적인 것이 아닐까 생각합니다. 도움을 주는 것이 아니라 얼마나 기여를 하느냐가
문제라고 보여집니다.
자신이 속한 팀에 기여도가 떨어진다거나 회사에 기여도가 떨어진다는 것은 곧 조직이 이익을 내기 위한 활동에 기여를 하지 못했다
는 것을 말합니다. 자선단체가 아니고선 말이죠.

학교만 해도 성적이 나쁜 학생을 차별하는 것은 좋지 않습니다. 성적은 학생들을 구분하는 여러가지 방법중에 하나일 뿐이니까요. 학
교라는 것을 보는 관점에 따라 다르겠지만, 저는 학교는 학생들의 인성, 품성, 지식등을 고루고루 가르치는 곳이기 때문에 성적은
여러가지 잣대중 하나에 불과 하다고 생각합니다. 따라서 학교에서 성적만 같고 차별을 하는 것은 아주 잘못되었다고 생각합니다. 성
적이 나쁘다면 나아지도록 계속 가르치면 되고, 아무리 가르쳐도 성적이 나아지지 않는다면 꼭 공부가 아닌 다른 분야에 적성을 찾아
주는 것이 학교의 목적이라고 생각합니다.

하지만 회사의 일차 목표는 교육이 아닌 영리추구죠. 직원들 교육도 회사의 영리를 추구하기 위한 방편중의 하나입니다. 가정이나 학
교와의 존재 목표와는 전혀 다른 목표를 갖는 집단이기 때문입니다. 너무 비인간적으로 들릴지도 모르겠지만, 열심히 일하고 인간관계
가 좋고 하지만 회사의 영리활동에 플러스가 되지 않는 직원을 회사에서 계속 데리고 있어야 할까요?

사실 지금 제가 몸담고 있는 회사에서도 그런 직원들을 여러명 1년 넘게 데리고 있었습니다. 회사가 이윤이 나면 보너스도 다 같
이 받았죠. 사실 기여도로 따지면 마이너스를 기록한 개발자들이었습니다. 그들이 망쳐놨거나 엉망으로 개발해 놓은 작품 때문에 다
른 개발자들이 밤새고 일해야 했던게 한두번이 아니었으니까요. 교육도 시켰고 잘 하는 것을 찾기위해 이것 저것 많이 시켜봤습니
다. 하지만 결국 얼마전 모두 해고를 했죠. 가정이 있고 아이들도 있는 사람도 있었습니다. 맘이 아파도 어쩌겠습니까. 회사는 회
사죠. 영리를 추구하는 집단입니다.

저도 월급받는 직원에 불과합니다. 하지만 저는 이익집단 안에서는 차별과 보상은 반드시 있어야 한다고 생각하고 개인들도 이를 당연
하게 받아들여야 한다고 생각합니다.

[Youngrok Pak]

정말 흥미로운 주제입니다. 저도 몇 가지 생각이 있었지만 정리가 안되서 질문만 하나 던져놓고 있다가 이제 생각이 좀 정리가
되서 글을 써 봅니다.

먼저 개발 생산성 5배 개발자가 있는 상황. 전 이게 정상적인 상황이며, 바람직한 상황이라고 봅니다. 팀 내에 이 정도 생산성
차이가 없다면 그 팀원들은 전부 잘하는 개발자이기보다는 전부 못하는 개발자일 가능성이 높습니다. 잘하는 사람은 숫자가 적으니까
한 팀에 몰려 있을 가능성이 낮겠지요. 물론, 확률을 바꿀 수 있는 구글 같은 회사라면 다르겠지만, 그런 회사가 많지는
않으니까요. 만약 이렇게 비등비등한 수준의 개발자만 있는 팀과 고수가 한 명 있는 팀의 발전 속도를 비교한다면 어떨까요?

이런 면에서 전 처음 화제를 던진 분의 이슈 제기가 적절했다는 생각이 듭니다. 개발 생산성 차이라는 현실 자체는 문제가 아닐
테니, 이런 상황에 불만을 품는 개발자만 해결하면 되겠지요. 거기서 더 나아가 하수 개발자까지 고수로 업그레이드시킬 수 있다면
금상첨화일테구요.

일단은 이슈 1번, 손해보는 느낌을 없애는 것이 더 중요한 과제겠지요. 못하는 개발자가 계속 그대로 있는 것보다 잘하는
개발자가 불만을 품고 떠나버리는 것이 훨씬 더 큰 위험일테니까요.

그럼 이 문제는 보상 체계의 문제일까요? 보상에 차등을 두는 것에는 반감을 가진 분들이 많은 것 같습니다. 애자일 팀을
거론하며 팀웍을 해칠 것이라는 이야기를 하신 분도 있구요. 그럼, 회사에서 개발자들에게는 다 똑같은 보상을 해주는 게 맞는
걸까요?

참고로 우리 회사는 현재는 기여도에 상관 없이 N빵으로 가고 있습니다. 아직 보상 체계를 만드는 중이라 임시 체제로 이렇게
가고 있는데, 초기에는 아무 문제가 없었는데 좀 지나니까 생산성 떨어지는 팀원을 미워(?)하는 현상이 생기더군요. 물론 여러
가지 다른 변수들도 있겠지만요.

그럼, 성과대로 5배씩 보상하는 성과주의는 어떨까요? 작년에 읽은 책 중에 "성과주의의 허상"이라는 책이 있는데 그 책에 이런
말이 있더군요. "성과주의는 경영학 100년의 연구에도 끝내 증명되지 못했다." 그리고, 개발자의 개인 성과라는 게 참
평가하기 힘듭니다. 창준님의 지적처럼 50 : 10이 진짜 50 : 10이 아닐 가능성도 아주 많구요. 현실적으로 위에 어느
분의 지적처럼 성과주의가 팀웍을 해친 사례도 많습니다.

그래서, 이 책에서는 연공제를 대안으로 제시합니다. 그리고, 높은 성과에는 더 크고 중요한 일로 보상을 해주라고 합니다. 얼핏
공감이 가지 않는, 오히려 불만만 쌓기 쉬운 방법 같아보이지만 주변 상황만 잘 갖춰지면 가능할 수 있는 시스템이라는 생각이
듭니다. 그리고, 이게 도요타, 소니를 비롯한 일본 기업들의 경쟁력이라고 하더군요.

또, 어떤 기업은 개인에게는 팀의 성과를 기준으로 보상하고 팀장에게는 회사 전체의 성과로 보상한다는 간단한 성과주의를 도입해서
성공을 거두기도 했다고 합니다. Built to Last에 나왔던 비전 기업 중 하나였던 것 같은데 정확히는 기억나지
않는군요. 괜찮은 시스템 같아 보입니다만, 여전히 50 개발자의 불만은 해소되지 않을 것 같습니다.

성과주의가 잘 되고 있는 회사도 하나 알고 있습니다. 이 회사는 현재 주력이 소프트웨어 용역 개발인데 일거리가 들어오면 대개
개인별로 맡아서 하고 그 개발비용은 대부분 개발한 사람이 먹습니다. 여기서 누가 도와주면 도와준 비율만큼 계산해서 나눠
갖습니다. 얼핏 살벌한 시스템 같기도 하고 그 비율을 제대로 계산할 수 있을까 싶기도 하지만, 보상 체계에 대한 불만은 아무도
없고, 팀원들 모두 화기애애하다고 합니다. 시장 경제를 팀 안에까지 극단적으로 도입한 경우라고 할까요.

위에 Joseph님이 금전적, 사회적, 감정적 보상이 충분해야 한다는 말씀을 하셨는데, 전 여기에 많이 공감합니다. 보상이
있어야 하긴 하지만 그게 꼭 금전적일 필요는 없다는 관점에서입니다. 전 그 보상 중 하나가 "명예"가 아닐까 합니다. 잘하는
사람에게 잘한다고 하자는 것이지요. 못하는 사람에게도 금전적인 보상 차이는 박탈감을 줄 수 있겠지만 명예의 차이는 오히려
자극제가 될 수도 있지 않을까요? 예를 들면 LSD에서 챔피언이라는 말이 있는데 실제 LSD를 하는 팀 중에 자기 팀의 최고
실력자를 챔피언이라고 부르는 경우가 있다고 합니다. 이런 경우에 다른 팀원들은 자신도 챔피언이 되고 싶다는 생각을 하지
않을까요?

금전적 보상도 꼭 5배에 맞춰서 줄 필요는 없을 것입니다. 실제로 가능하지도 않을 꺼구요. 5배가 아니라 50%만 차이가 나도
불만 해소에는 큰 도움이 될 것입니다. 명예와 조합해서 쓴다면 말입니다.

우리 회사는 성과주의가 아니라 능력주의에 기반한 급여 체계를 구상 중입니다. 50 스토리포인트에 보상을 하는 것이 아니라,
50을 해낼 수 있는 능력에 보상을 주는 것입니다. 아직 완성되지 않아서 검증은 거치지 못했습니다만, 괜찮은 시스템이 될
것으로 기대하고 있습니다.

N빵, 성과주의, 연공제, 팀 성과주의, 시장형 성과주의, 명예, 능력주의. 보상 체계에 대한 논의는 몇일 밤을 새도
모자라겠지요. 어떤 체계를 선택하든 아무도 불만이 없는 체계를 찾아내기는 어려울 것입니다. 많이 고민해보시고 좋은 해결책을
찾아내셔서 다시 공유해주시길 기대하겠습니다.

[아조르]

논의가 평가 문제로 확대되었는데
우리 회사에서도 평가와 성과배분 문제가 이슈로 되고 있습니다.

인사문제를 다루는 부서에서 프로젝트 팀원들 간의 상호평가 방안을 제시했는데요.
그리니까 팀원들 간에 상호평가를 하게 하자는 거죠. 그래서 프로젝트에 대한 기여도를 파악해 보자는 것이죠.
평가자의 성향(엄격함, 온정적임)에 따른 편차는 통계적으로 보정하구요.

저는 펄쩍 뛰었습니다.
상호평가의 고통을 개발자 개개인에게 지우는 것은 너무 무거운 짐을 지우는 것이고, 위화감만 조성할 수 있다.
그리고 무슨 실효가 있겠느냐?
작은 집단이니 만큼 부서장이 평가의 책임과 부담을 지고 평가하는 게 마땅하다.
그리고 이런 상호평가제도를 하는 데를 본 적도 없다.
이런 논지로 반발했습니다.

사장님이 우파와 좌파의 논리가 부딪힌다며 더 이상 진전시키지 않고 논의를 중지시켰습니다.

최근에 매뉴얼 식으로 정리된 인사제도에 관한 책에서는 이렇게 정리하더군요.
초급자일 경우는 능력이나 성과보다는 태도를 중시해서 평가해 주고
고급자일 경우는 성과로 평가해 줘라.

평가에 따른 보상은
성과로 드러난 평가는 연봉이나 보너스로 반영해 주고
태도로 드러난 평가는 승진으로 반영해 줘라.
이런 식으로 가이드를 주네요.

혹시 프로젝트 팀원끼리 상호평가하는 사례가 있나요?

[cavin]

Jake J Kim님 말씀 잘 보았습니다.
기여에 대한 차별적 보상을 한다는 것은 같은 생각입니다.
회사는 영리를 위한 것이 최우선이라는 것도 물론 같은 생각입니다.

다만 저는 두가지 부분에 대해서 말씀드리고자 하는 것입니다.

1. 기여를 판단하는 기준이 팀원들간 비교에서 비롯될 수 있는 문제.
50이 가장 높은 생산성이기에 비교우위란 기준으로
높은 위치를 차지하는 분이 불만을 가진 상황을 보죠.
사실은 60이 생산성으로 보상받을만한 수치라면 어떨까요.
50을 하시는 분의 불만과 보상은 비교평가로는 당연하겠죠.
반면에 10이란 수치가 보상받을만한 수치라면 10을 하신분은 비교평가로 비판받아도 상관없을까요.

2. 팀이 아닌 자신만을 위한 성과목표 설정을 유도할 경우 개인화와 분열을 조장할 수 있는 문제
50을 개발하는 분은 비교를 통한 상대적인 성과평가라면
언제나 최고의 보상을 받지만 팀이나 회사에 극적인 성과는 나올 수 없습니다.
극적인 성과는 10을 50으로 끌어올리는 것에 있습니다만
개인별 상대적인 성과체계에서 가만두는 것이 자신에게 이득인 것을 아는 팀원 중에
누가 팀에 도움이 되지만 자신에겐 도움이 되지 않는 일을 하려 할까요.. 알아도 회피하게 됩니다.

SI에서 특히 이러한 일들이 두드러지죠.
이러한 비교 성과평가로 인한 폐해가 팀단위로 나타나곤 합니다.
협업을 하다가 특정팀에 크리티컬한 문제가 발생하게 되는데
프로젝트 전체가 지연되고 위험에 처해도 문제는 해당팀에서 해결할 때까지 방치합니다.
그것으로 인해 우리 팀이, 내 파트가 다른 팀에 비해 일정이 늦는 것을 바라지는 않을테니까요..

개발뿐만이 아니라 여러가지 방면에서도 마찬가지입니다.
문제를 해결해서 칭찬받고 인정받기보다 말려들지 않는게 이득..이란 것은
내 할일만 잘하는 것이 보상받지 못할 일로 고전하는 것보다 낫다는 생각이 깔려있어서겠죠.

각자 자기 할 일을 알아서 하고 성과를 챙기는 것은
팀내에서 50에 가까운 사람이 느슨하게 성과를 챙기면 그만입니다.
50이 나아져봐야 55.. 10~20은 방치.. 이와 비슷한 상황은 팀, 회사로 봐서 좋을게 없습니다.
언제나 문제는 문제 당사자의 것이고 방치되곤 합니다. 알아도 모른척하고 이로 인해 모두가 실패합니다.
회사와 프로젝트가 실패해도 상대적인 기준으로 나에 대한 평가는 떨어지지 않으니 책임을 느낄 수도 없죠.
그것이 일반적인 SI 프로젝트에서 이뤄지는 상대적인 비교평가의 맹점이라 생각합니다.

이러한 이유로 극적인 성과를 거둘 수 있는 부분에
미미한 향상만이 가능한 리소스를 투자하는 것이 바람직하다고 생각하고
그렇기 때문에 50이 55~60을 하게 만들고 그에 대해 보상을 해주는 것보다
다른 이를 도와서 팀 전체가 나아지는 성과목표를 정해주고 더 큰 보상을 마련하는 것이 바람직하다고 보는 것입니다.

이와같이 팀의 중요한 문제를 돕는 것으로 성과목표를 정해주면
50이 팀문제를 방치하면서도 느긋하게 45나 40을 해도 똑같이 최고의 보상을 받아가는 상황보다
20~25를 하더라도 팀의 문제를 해결하도록 돕는 것이 개인과 팀과 회사 모두의 이익에 도움이 되는 것이라 생각합니다.

팀장은 항상 피곤해지겠죠..
늘 팀의 이익을 위해 성과목표를 정하고 변경하고
다양한 측정을 통해 행위를 유도를 해야 할테니까요..
게다가 그러한 로그를 쌓고 실제로 보상이 가능하도록 인사팀이나 관리팀과 협상을 해야 할테니까요..
하지만 그것이 이익집단내에서 회사나 팀장이나 관리팀이 해야 할 일이자 책임이겠죠. 이익을 극대화하기 위해서 말이죠.

p.s 글쓰기 훈련이 안되서 글 내용만 길어지는 것 같습니다. 양해 부탁드립니다.T-T

[Wonderer]

cavin님의 글을 읽고 공감을 느꼈습니다.

다만 말씀하시는 내용 중 

남을 도움으로써 팀이 보상받고 나도 더 큰 보상을 받고
모두가 행복해질 수 있다..란 것을 팀원과 팀이 배울 수 있도록
개인을 위한 목표와 보상체계나 문화를 만들어 나가는 게 필요하다고 생각합니다.

1. 개인의 일에 집중하는 것보다 남을 도움으로 인해서 더 큰 보상을 받았다는 것을 어떻게 느끼게 할 수 있을까요?
자신이 키운 파이를 균등하게 나눠 갖는다는 느낌에 불만을 갖지는 않을까요?

2. 만약 남을 도우나 자신의 일에만 집중하나 회사에는 결국 동일한 가치를 가져다 주게 되었을 경우에는 어떻게 해야 할까요?
회사에는 더 큰 보상을 요구하기에는 힘든점이 많지 않을까요?

3. 위의 말씀하신 내용을 실현하는 좀 더 구체적인 방법이나 사례를 들을 수 있을까요?

저도 많이 고민하고 있는 내용이라 혹시 좋은 의견이 있으시면 도움을 받고 싶습니다.

[MooLim Lee]

저희 회사에서는 상호평가하고 있습니다. 저는 오히려 큰 기업일수록 이런 방법이 일반적인 것이라고 알고 있는데 더 잘 아시는 분이 있으면 실상이 어떤지 들어보고 싶네요. 

전체 팀원중 할당받은 멤버 4~5인을(아마 관리자가 지정하는것 같습니다) 평가하게 되고 거기에 관리자 자체적인 평가가 추가되어서 전체 평가가 진행됩니다.

자신의 평가가 어떻게 되었는지는 알수가 없습니다. 아마 연봉에 어떻게든 반영되겠지만 연봉은 비밀이니...(다른 분들은 동료들의 연봉을 알고 계신가요?) 스스로가 팀내에서 얼마나 되는지 알수있는 좋은 방법은 없습니다.

저도 상호평가하면 뭔가 분위기가 살벌해질거 같다고 생각했었지만 그렇지 않은 회사에서 있었을때와 분위기가 크게 다르지 않더군요...

2009년 2월 17일 (화) 오후 6:04, 아조르 <sam...@yullin.com>님의 말:

[Alan Lee]

개인적으로는 특정 1인만이 평가할 때의 폐해를 전에 겪어봤던지라
상호평가 결과를 어느정도 반영하는게 더 바람직하다고 생각하고 있습니다.

논란의 여지가 있지만 아래 글은 연봉을 공개적으로 책정하는 사례에 대한 이야기입니다.
참고하세요.
http://positivesharing.com/2006/08/why-secret-salaries-are-a-baaaaaad-idea/

2009/2/18 MooLim Lee <neti...@gmail.com>

[Richard Kang]

참으로 공감가는 부분이 많은 주제와 글들을 재미나게 보고있습니다.

 

개인의 보상에 대한 다양한 방법에 대해서 솔깃하고있습니다.

돈만이 보상의 최고지향점이냐? 회사 재무팀이나 사장님은 아주 싫어하는 테마이겠져? 명예나 가치가 높아질수있는

방법이 있다면 그리고 그걸 회사의 보상문화로 정착시킨다면....

예를들어 이런거져....

"이번에 포동씨가 2월의개발자로 뽑혔데.."

"아~ 나도 그거 한번 해보고 싶었는데....그런데.....그사람 참 일잘하더라.같이 일해보고 싶은 친구야...."

"그친구 일많이하는 친구야?"

"아니....많이한다기보다 잘해....짧은시간에 집중력있게하면서 아웃풋도 확실하지.더불어 재밌는 친구이기도 해.난 그친구랑 같이 한번 일해보고 싶더라구"

........

 

하나의 일례를 만들어본거지만.....사내에서 이련 얘기가 오고간다면 임원이든 직원이든 므흣해하면서 미소지을수있지 않을까...생각해봅니다.

 

다른사람에 인정받는다는건 자기일만 잘한다고 해서 받을수있는 건 아니라고 봅니다. 다른사람들에게도 눈에 띄는 공헌을 하든 안하든,그런 체계가 있던없던간에 긍정적인 영향을 미쳐야하는게 아닐까요?

 

제 개인적인 생각으로는 자기일 잘하는 50점짜리 직원보다 수치적으로 계산하기 힘들어도 다른사람에게 긍정적인 영향을 끼치는 40점짜리 직원을 더 높게 평가하려고 할것같습니다.

 

@포동28

om: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of Wonderer
Sent: Tuesday, February 17, 2009 10:15 PM
To: xp...@googlegroups.com
Subject: RE: 개발자의 개발량의 편차가 매우 큰 경우

.T-T
lang=EN-US>

[Sangchel Hwang]

저희 회사의 사례라고 볼 수는 없습니다만 제가 소속된 팀은 매년 상호 평가를 진행하고 있습니다.

예를 들어 한 팀에 2개 소그룹이 있다고 가정했을때

특정 소그룹에 리더와 팀원이 있다면

• 리더는 팀원들을 평가하고
• 팀원은 동료를 평가하고 리더도 평가합니다.

물론 이 상호 평가가 전체 평가에 반영되는 비율은 상대적으로 적습니다. 하지만 이런 상태평가를 몇 년전부터
계속 해오고 있으며 팀원들도 이런 상호 평가에 큰 거부감을 표하지 않습니다.

2009/2/18 Richard Kang <podo...@gmail.com>

[정선화]

각각의 평가방식에 따라 장단점이 있다고 생각합니다.

저는 평가별 보상의 격차가 꽤 큰 부서와 평가별 보상의 격차가 작은 부서에서 모두 일해보았습니다.

 

 평가의 보상 격차가 큰 부서는 입사 시의 연봉협상을 어떻게 했느냐에 따라 연봉격차가 굉장히 큰 상태였습니다. 그리고 평가 시에는 상위평가에 보조적인 동료평가만 존재했습니다. 이 때는 평가 보상 격차가 크기때문에 열심히 하면 좋게 받을 수 있다는 동기부여는 되지만, 그로인한 미묘한 경쟁 구도가 발생합니다. 또한 뒤에서 누가 평가를 잘받았다는 소문이 발생하기도 합니다. 특히 이 소문의 사람이 다른사람들이 보기에는 성과가 그리 크지 않다고 느꼈을 때는 다른사람으로 하여금 상대적 박탈감을 느끼게 하기도 했습니다. 게다가 팀원 및 타 팀간  미묘한 경쟁구도로 인해 성과와 관련한 부분에 있어서 전체적인 관점으로 보지 못하게 됩니다. 그로 인해 전체적인 비효율도 생기며 팀원간의 협력에 있어서도 문제가 발생하는 것을 보았습니다. 물론 열심히 해서 좋은 성과를 냈고, 좋은 평가를 받았다면 그 당사자는 만족하게 됩니다.

 

 그리고 평가 보상 격차가 작은 부서에서는 각각의 역량과 경력을 기준으로 연봉조정을 한차례 했고 보상의 격차가 적었습니다. 그리고 평가 시는 항상 전체 팀원을 대상으로 서로 상호 평가를 했으며 자신의 성과를 홍보하는 것은 항상 필요하며 다른 사람들이 모르는 성과는 상호평가 시 불이익을 받아도 어쩔수 없다라는 점을 강조했습니다. 이 때의 장점은 자신의 업무에 대한 커뮤니케이션을 좀더 원활하게 하는 효과가 있었으며 타 팀원과의 협업에 있어서도 경쟁구도 없이 잘 진행되는 것을 보았습니다. 다만 문제는 보상격차가 큰 부서에서는 자신의 한계 그 이상을 해내려는 욕구가 컸던 반면 보상격차가 작은 부서에서는 비교적 실력있는 사람들이 받는 만큼만 해야지(?)라는 생각이 들게 한다는 것입니다.

각 상황에 맞는 평가시스템에 대해 고민할 필요가 있을 것 같습니다. 저는 후자 쪽이 더 좋은 시스템이다라고 생각하고 있습니다만 그쪽도 완전하지는 않다고 생각합니다. 일단 팀원 모두가 생각하는 평가에 대해 취합하고 이 평가와 성과에 대해 같이 판단한다는 점은 다른 회사에서도 하면 좋을 것 같습니다.

 

2009년 2월 18일 (수) 오전 9:41, Sangchel Hwang <k16...@gmail.com>님의 말:

[Seung Joon Choi]

인센티브에 대해서는 괴짜경제학(freakonomics) 초반에 나오는 예가 뜬금없이 떠오릅니다.

어느 유치원의 방과후에 종일반 수업이 끝난 후에 부모들이 아이들을 제 때 데리러 와야 하는데 그렇지 않은 경우들이 빈번하게 발생해서, 인건비와 난방비도 아끼려는 차원에서 '벌금'을 물게 했는데 그 금액이 비교적 작은 단위였다고 합니다. 예를 들면 '만원?' 그랬더니 부모들이 이젠 미안해 하는 기색도 없이 대놓고 늦게 와서 벌금을 내고 아이를 늦게 데려가는 현상이 나타나서(충분히 그 정보 부담을 할 수 있다라는 판단하에) 벌금 제도를 폐지했더니, 늦게 데리러 오는 현상도 줄어들지 않고 이젠 미안해 하지도 않더라는(도덕적인 bar가 내려간) 연구가 있었다고 하네요.

인센티브는 좋지만 조심해서 써야할 것이라고 생각하게 되었습니다.

관련해서 어떤 극복하고 싶은 상황이 있을 때 새로운 도약을 위해서 인센티브를 도입하고 이를 바탕으로 새로운 상태를 만들었는데,시간이 조금 흐른 후에 이 인센티브가 어느새 특별한 것이 아니라 '당연한'것이 되는 상황도 생기는 것 같습니다. 조직 차원에서는 새로운 시도가 안정될 때 까지 일시적으로 운용하려 했던 인센티브 였는데 말이죠. 때문에 관리자가 해당 주제에 대해 인센티브를 더 이상 운용하지 않고자 할 때, 인센티브의 수혜 대상자들은 상대적인 박탈감을 크게 느낄 수도 있는 경우가 있더라구요.

 관리자 입장에서 항시 적용할 수 있는 인센티브에 대한 예산을 확보하는 것도 꽤 부담이 되죠. 그게 주로 돈, 시간, 권한 등에 대한 이야기라면 특히 그렇죠.

[June Kim]

처음 글을 쓰신 후 한 달이 넘었네요. 그 이후에 무슨 일이 생겼는지, 어떤 추가 정보를 얻었는지 등이 궁금합니다.

2009/2/12 Hubert Shin <huber...@gmail.com>:

[HwaJong Oh]

책 "칭찬은 고래도 춤추게 한다"에서, 먹이(돈)로 하는 유도(훈련)는 배고픔이 사라질 때까지만 유효하다는 내용과 관련 있을까
요?

[Hubert Shin]

안녕하세요? 처음에 글을 적은 신황규 입니다.

그간 개인적인 사정에 의해 매우 바빠 답장이 늦었네요.

죄송합니다.

먼저 그동안 주신 좋은 의견 감사드립니다. 관리를 위해 무엇에 초점을 맞춰야 하는지 여러분들을 통해 알 수 있었습니다. 덕분에 프로젝트는 3월 31일에 잘 끝났습니다.

그동안에 내용들을 종합하면 크게 두 가지라고 할 수 있습니다.

1)  적절한 평가를 해야 한다.

2)  잘하는 사람에 대해 적절한 보상이 있어야 한다.

일단 1)을 위해, 모든 제품 백로그와 스플린트 백로그를 적었습니다.

이를 가지고 팀 기여도(개인이 수행 스토리 포인트 / 전체  스토리  포인트 * 100) 를 평가하고 개발자간 표준편차를 구했습니다. 이를 바탕으로 지속적으로 PM과 PL에게 저사람들에게 돌아가야 할 몫에 대해 이야기 했습니다.

하지만, 쉽지 않았습니다. 모두가 함께 개발하는 곳에서 납득할만한 근거 없이 

특정 개발자에게 특혜를 줄 수는 없었습니다. 그래서 회고 때마다 특정 두 분에 대한 이야기를 지속적으로 했습니다. "서로에게 칭찬하기" 를 수행하자, 자연스레 그 분들에 대한 개발팀원들의 마음이 수면위로 떠오르더군요. 그 분들이 이 팀을 위해 얼마나 희생하고 있는지, 공감대가 형성되었다고 느낄 수 있었을때 무엇인가 했으면 좋겠다. 라는 이야기를 했죠.

하지만, 방법 또한 문제였습니다. 협력회사에서 오신 분들에 대해 

인센티브를 지급하는 것은 안타깝지만, 회사내 불법입니다. 

프로젝트 전체 인원 중 자사 인력이 20%도 안되는 현실에서 꽤나 아쉬운 부분이지요.

이번 경우도, 그 Driver(해결사) 역할을 하는 분들은 물론 협력회사 분들이셨습니다.

결국, PM님과는 휴가로 잠정 합의를 봤습니다. 

프로젝트 끝나기전 가장 힘들었던 두 분에 대해 2일간의 휴가를 주도록 했고, 그렇게 보상을 했습니다. 

하지만, 그 보상의 타이밍은 매우 늦은 느낌입니다.

횟집에 들어가  회를 다 먹고나서 주방장에게 주는 팁은 사실 그 날의 음식의 질에 영향을 미치지 못하는 것과 같습니다. 그 분들의 불만이 터지기 전에 이런 일들이 있었으면 보다 좋았으리라 생각합니다.

또 생각나는 내용이 있으면 글을 적겠습니다. 

2009년 4월 1일 (수) 오전 9:39, HwaJong Oh <dali...@gmail.com>님의 말:

[영감님]

누가 생산성이 뛰어나며 누가 팀의 발목을 잡는 존재인지는
각각의 팀원들도 이미 알고 있을겁니다.

평가 방법만 공정하다면 50을 찍은 개발자에게는 적절한 보상을 몰래! 해주는것이 최선이라고 생각됩니다.
회사 입장에서 소 잃기(불만을 품은 개발자가 팀을 떠나는것) 전에 외양간 고치는것도 중요하다고 생각되네요.

[JUNE]

비교가 적절하지않군요..

가족이라면 당연히 손해보고있다라는 생각조차 안하는경우가 더많겟죠..

공과사는 구분합시다..

사회에선 내옆자리직원은 남이구요.. 팀이긴하지만, 그 사람의 모자란 부분을 내가 감수해야할 필요가 없습니다.

그건 회사에서 걱정해야할부분이지요.. 50에게 얼마간의 돈? 보상?을 해주고, 10의 부족분을 멖구던가 하는건.

그사람의 모자란부분을 내가 감수해주는대신 그에대한 합당한? 보상이 따르지않는다면,

50의 개발자는 더이상 50의 퍼포먼스를 내는대신 쉬엄쉬엄하며 30으로 진행하거나,

그팀을 나가거나 하겠죠..

On 2월17일, 오후2시28분, cavin <cavink...@gmail.com> wrote:

[[sumer]soungno]

흠 XP에서 절대 개인의 속도나 개발 성과를 평가 하지 않습니다.

스토리 점수 라는 것이 개인의 성과를 비교 평가 할 만큼의 정밀도를 가질수 없기 때문에

단순한 구현 스토리 점수를 가지고 팀원들의 기여도를 비교 평가한다는 건 어쩌면 큰 실수를 하고 있는지 모릅니다.

가령 같은 5점 짜리 라도 실제 난이도 라던지 주변 사항에 의해 구현 시간이 틀려 질수 있겠죠?

 

구현 스토리 점수를 이용한  평가는 팀 단위로 하고, 반성 및 포상도 팀단위로 이루어 져야 할것 입니다.

물론 충분히 객관적으로 개발자간의 능력 차이가 느껴 질 정도로 같이 일해 봤다면, 어떤 조치를 해야 겠지요.

하지만 이 때도 구현 점수 보다는 팀에 대한 개인의 성실도, 참여도 정도로 기여 부분을 평가 해야 하지 않나 생각 합니다.

그리고 구현 실력이 좋은 사람은 보상을 받게 하고 구현 실려이 부족하더라도 팀에 꼭 필요 한 사람이라면 자존심과 기분이 상하지 않도록 적절하게 조치를 해야 합니다.

가령 매 반복시 발생하는 이슈 사항을 오픈하여 가장 이슈 사항을 많이 처리한 팀원에게 포상을 한다는지 하는 방법도 좋으것 같습니다.

 

어떤 수치를 가지고 사람을 판단하는건 자칫 잘못 하면, 정말 프로젝트 에 필요하지만 겉으로 들어나지 않는 인재를 버리는 결과를  초래할수 있으므로,

PM은 지속적으로 팀원 개개인에 대한 관심을 가지고 자세하고 현명하게 판단하여 프로젝트 구성원 모두가 동의 할수 있는 상벌을 끌어내야 한다고 생각 합니다.

즉 PM 상벌의 판단은 객과적 수치화 보다는 PM의 능력이라고 말하고 싶습니다.