1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지 2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
저라면, 10의 속도를 가진 개발자(B)에게 귀찮은 단순작업량을 늘리지 않을까 합니다. 그러면 50의 속도를 가진 개발자(A) 의 입장에서도 내가 하긴 불편한 일을 대신 B 가 해 주는 것에 대해서는 인정하지 않을 까 싶네요. 팀 전체 입장에서도 A 의 능력을 최대한 끌어낼 수 있을 거 같구요. 적절한 업무분담은 리더가 잘 이끌어 줘야 하는 부분이라고 생각합니다.
B 가 스스로 노력하게 하는 가장 확실한 방법은 평가밖에 없을 거 같네요. 일관된 기준으로 최대한 공정하게 평가할 수 있다면(모두를 만족시키는 건 불가능할 거 같지만) 서로 경쟁하면서 개개인의 능력을 최대한으로 만들 수도 있지 않을까 생각됩니다.
> 1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지 > 2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
> 저라면, 10의 속도를 가진 개발자(B)에게 귀찮은 단순작업량을 늘리지 않을까 합니다. > 그러면 50의 속도를 가진 개발자(A) 의 입장에서도 내가 하긴 불편한 일을 대신 B 가 해 주는 것에 대해서는 인정하지 않을 > 까 싶네요. > 팀 전체 입장에서도 A 의 능력을 최대한 끌어낼 수 있을 거 같구요. > 적절한 업무분담은 리더가 잘 이끌어 줘야 하는 부분이라고 생각합니다.
> B 가 스스로 노력하게 하는 가장 확실한 방법은 평가밖에 없을 거 같네요. > 일관된 기준으로 최대한 공정하게 평가할 수 있다면(모두를 만족시키는 건 불가능할 거 같지만) > 서로 경쟁하면서 개개인의 능력을 최대한으로 만들 수도 있지 않을까 생각됩니다.
애자일의 초보로써 문제에 대해 제가 충분히 경험하지 못한 상황이지만 생각난 바가 있어서 적어보겠습니다. 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를 높일 필요가 있다고 봅니다. 팀을 이끄는 사람, 속도가 빠른 사람, 느린 사람, 평균적인 사람 등 각자의 욕구를 서로 알 수 있도록 하고 지금 상황에 대한 인식을 높여서 스스로 가감을 조절할 수 있는 노력을 할 수 있도록 팀의 문화를 형성하면 좋을 것 같습니다.
또한 그 가고자 하는 방향으로 갈 때의 과정도 작은 단위로 짧게 끊어가며 기민하게 하면 좋겠죠.
그 과정을 통해서 빠르게 달려가고 있는 사람은 살짝 살짝 브레이크를 밟고 그 중간중간 확보된 시간으로 다른 맥락에서 스스로의 동기부여도 되고 결과적으로 팀을 더 건강하게 할 수 있는 일을 하고, 가장 느리게 하고 있는 사람은 팀에 어떤 기대와 욕구가 있고 자신의 그 것과 빗대어 측정하며 그 차이를 줄일 수 있도록 움직일 수 있도록 도울 수 있거나 혹은 그 차이를 줄이기가 굉장히 어려운 일이라는 것을 모두가 알 수 있도록 하여 보다 더 문제에 대해 근원적인 생각에 그 에 따른 적절한 접근이 뭔지에 대한 질문을 떠올리게 할 수 있을 가능성이 있을 것 같습니다.
해당 문제를 이슈화 하여 함께 나눌 수 있는 여력의 확보와 충격이 발생할 때 이를 완화할 수 있는 포지션과 이를 시도하고자 하는 용기 등이 필요하지 않을까 짐작해 봅니다. 그러면 팀은 스스로를 보완하며 해결방안을 스스로 찾을 수 있지 않을까요?
> Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다. > 11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다. > 1. 코드의 공동 소유 > 2. Story Point 추정시 고객 포함 전원 참여 > 위와 같은 기법을 사용하고 있는 상황에, > 각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.
하나의 스토리는 개발자 한 명이 작업하나요?
> 4차례에 Sprint 를 이미 진행 했고요.
> 문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.
그 불만 이면에는 진실로 어떤 욕구가 있는지 대화(및 공감)해 보겠습니다. 그와 동시에 속도가 느린 사람은 이 상황을 충분히 인식하고 있는지, 어떤 느낌을 받는지, 어떤 욕구가 있는지 대화(및 공감)해 봅니다.
> 함께 추정한 포인트들에 대해 > Pair Programming을 할 수 없는 상황에서, > 특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 > 있습니다.
우선 50정도로 작업하는 개발자와 짝을 해보거나 혹은 관찰하거나 합니다. 소스코드를 훑어보기도 합니다.
이번에는 20정도 일을 수행하는 개발자들 몇 명에 대해서도 정보를 얻습니다.
마지막으로 10 정도의 속도를 가진 개발자와 짝을 해봅니다.
이렇게 해서 속도가 10인 사람이 왜 10인지, 그 사람의 태도 때문인지, 습관 때문인지, 특정 지식이 부족해서인지, 도구 사용법이 잘못되어서인지 등을 구체적으로 알아냅니다. 그와 동시에 50인 사람과 가장 대조적으로 차이가 나는 부분이 무엇인지, 혹시 50인 사람이 하는 것 중에서 이 10인 사람에게 도움이 될만한 것은 무엇일지 알아냅니다.
여기까지 알게 되면 이제 어떻게 할지 생각해 봐야겠죠(아마도 다른 팀원들의 의견을 많이 참고할 듯).
> 쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠. > 이슈는 두 가지인데요 > 1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지 > 2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지 > 에 대해 의견을 듣고 싶습니다. > 감사합니다.
수행능력 개선방법은 차후 문제이고 팀원끼리 해낸 일의 분량을 서로 비교하고 불만을 갖게되는 상황을 개선하는 것이 우선이지 않을까 싶습니다.
60, 40, 30 으로 각자 수행능력이 개선되서 프로젝트 기한을 만족해도 불만은 여전히 남고 시간이 지날수록 심화될테고 팀워크 분열이나 어떤형태로든 분출될테니까요..
협력이 성과로 연결되는 상황을 만들어보면 어떨가요.. 1. 팀이 더 많은 일을 할 수 있도록 돕는 것을 성과목표로 부여하기 2. 해내는 일의 분량과 별도로 '개선된 정도'도 성과목표로 부여하기 3. 성과가 있다면 비록 작은 것이라도 자주 보상해 주기.(ex,반차+문화상품권)
저라면 우선 50또는 50에 가까운 분들 중에서 지원을 받아 다른 팀원을 돕는 롤을 둘 생각입니다. 50그룹에서 반나절 10~20그룹에서 반나절씩 짝프로그래밍을 반복하는 것이죠.
해당 롤을 수행하는 분이 패턴과 안티패턴을 발견하고 팀 공통적인 기술셋, 아키텍처, 커뮤니케이션, 관리 등과 관련지어 문제를 바라보고 이를 집약해서 개개인, 팀단위로 피드백이나 회고, 주기적인 교육을 통해 개선하도록 하는 것이죠.
일단 이와 같이 시작을 하고 추이를 보고 팀에 가장 도움이 되는 것이 무엇인지에 따라 롤을 수행하는 분을 바꿔나가면 좋지 않을까 생각해 봅니다. 10~20에서 50으로 향상된 분이 있다면 그 분이 팀에 가장 많은 도움을 줄 수 있는 분이 될 가능성이 높겠죠.
길었네요.. 간추리자면 '경쟁관계를 협력관계로 유도하자' 정도가 되겠습니다. 좋은 주말 되세요~
저는 속도 50의 맥락이었는데요. '정말 뛰어나게 잘하는 사람'의 맥락이라면 비슷하지만 약간 다를 수 있을 것 같습니다.
퍼포먼스와 개발의 실력만이 정말 뛰어나기만 한 사람이라면 팀의 건강함에는 부정적인 영향을 끼칠 가능성이 비교적 크다고 생각합니다.
하지만 그 사람이 정말 뛰어나서 커뮤니케이션 및 서로 배우고 함께 상생하는 것 까지 포함한 뛰어남을 보여준다면 긍정적인 영향이 훨씬 많겠죠.
전자의 경우는 팀 또는 회사의 퍼포에 대한 단기적인 안목으로는 확실히 도움이 된다고 생각합니다. 하지만 장기적으로는 어떨까요?
제 경험에서도 굉장히 우수한 교사가 있었는데 교사들의 문화에서 그 분이 살아가는 것이 아마 실력의 차이와 그에 대한 관리자의 인정이 두드러지게 높았기 때문에 잠재적인 낙차를 형성했고 결국 그로부터 얻어진 포텐셜 에너지는 다양한 현상(특히 문제)들을 야기하기도 했는데요. 가장 아쉬웠던 것은... 결국 개인의 발전(석박사진학 등)을 위해서 그 분을 놓아드려야 했을 때... 빈 공간이 발생했고 대야에서 물 한바가지 크게 퍼낸듯이 시간이 흘러감에 따라(꽤 오래 걸렸지만요) 그 자리가 메꿔지긴 했지만, 수면이 꽤 낮아진 상황이 발생했습니다.
아주 뛰어난 사람으로 부터 발생되는 낙차를 어떤 순에너지로 전환시키냐는 리더의 몫이리라 생각합니다. 실제로 제가 팀을 운영하던 중에 이런 비슷한 사례로 힘들어 한적이 있는데 낮은 성과를 내던 인력도 어떤 재교육없이 꾸준한(이게 몹시 중요합니다) 관심만으로도 개선이 되더라는 것입니다. 물론 그의 개선을 기다리는 동안 피마름의 압박을 팀장으로서 이겨내야 하는 것도 큰 숙제이지만, 보통 어떤 문제가 있음을 가장 잘 아는 것은 팀장이나 동료가 아니라 본인이고 본인 스스로 그것을 개선하도록 도와야 하기 때문이더 군요. 주변의 충고나 도움은 별로 도움되지 않는 다는 것이 일관된 경험이었습니다. 견디고 이겨낼 용기와 꾸준한 인내가 없다면 그 친구를 다른 곳에서 더 큰 역량을 내도록 하는 것이 좋지 않을까 합니다. 그리고 아주 뛰어난 성과를 내던 친구가 있었는데 그의 지적호기심을 채워 줄 만한 환경과 문제를 제공하는 동안에는 아무런 문제가 없었습니다. 그러는 동안에는 이친구가 문제를 해결하고 그것을 동료들과 나누고 하는데 뭐랄까 행복감을 느끼는 것을 봤습니다. 아쉽게도 그 친구가 퇴사를 결심한 배경의 첫번째가 "좋은 코드를 만드는 것은 내 삶의 질과 같다"는 그의 철학을 지켜주지 못했 기 때문입니다. 뛰어난 사람을 뛰어나게 인정을 하고 그가 그 뛰어남을 한번 더 뛰어넘게 하는 리더가 팀에 있다면 장/단기적으로 문제가 없지 않을 까 하네요...
On 2월13일, 오후1시25분, Seung Joon Choi <eruc...@gmail.com> wrote:
> 저는 속도 50의 맥락이었는데요. > '정말 뛰어나게 잘하는 사람'의 맥락이라면 비슷하지만 약간 다를 수 있을 것 같습니다.
> 퍼포먼스와 개발의 실력만이 정말 뛰어나기만 한 사람이라면 팀의 건강함에는 부정적인 영향을 끼칠 가능성이 비교적 크다고 생각합니다.
> 하지만 그 사람이 정말 뛰어나서 커뮤니케이션 및 서로 배우고 함께 상생하는 것 까지 포함한 뛰어남을 보여준다면 긍정적인 영향이 훨씬 > 많겠죠.
> 전자의 경우는 팀 또는 회사의 퍼포에 대한 단기적인 안목으로는 확실히 도움이 된다고 생각합니다. 하지만 장기적으로는 어떨까요?
> 제 경험에서도 굉장히 우수한 교사가 있었는데 교사들의 문화에서 그 분이 살아가는 것이 아마 실력의 차이와 그에 대한 관리자의 인정이 > 두드러지게 높았기 때문에 잠재적인 낙차를 형성했고 결국 그로부터 얻어진 포텐셜 에너지는 다양한 현상(특히 문제)들을 야기하기도 했는데요. > 가장 아쉬웠던 것은... 결국 개인의 발전(석박사진학 등)을 위해서 그 분을 놓아드려야 했을 때... 빈 공간이 발생했고 대야에서 물 > 한바가지 크게 퍼낸듯이 시간이 흘러감에 따라(꽤 오래 걸렸지만요) 그 자리가 메꿔지긴 했지만, 수면이 꽤 낮아진 상황이 발생했습니다.
> 2009/2/12 Hubert Shin <hubert.s...@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인 사람에게 도움이 될만한 것은 무엇일지 알아냅니다.
> 여기까지 알게 되면 이제 어떻게 할지 생각해 봐야겠죠(아마도 다른 팀원들의 의견을 많이 참고할 듯).
>> 쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠. >> 이슈는 두 가지인데요 >> 1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지 >> 2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지 >> 에 대해 의견을 듣고 싶습니다. >> 감사합니다.
저의 경험으로는 개인의 가진 역량은 그가 속해있는 팀에 따라 유동적이었던 것으로 생각됩니다. 소위 말하는 개인의 생산성 보다는 팀의 생산성이 좀 더 중요하다고 믿고 있기도 하지요. 정말 아무런 차이 없이 생산성만 5배가 높다면 저라면 잽싸게 채용할 것 같습니다. 우리 팀에 오고 나서 그가 1혹은 5배 중 어떤 생산성을 가질지는 우리팀의 그릇의 문제니까요...
근데 한가지 궁금한것은 그 사람의 생산성이 5배가 높다는 것과 그의 능력이 5배가 높은 것이 같은 건지요? 그리고 면접을 보는 저는 그의 개발능력을 혹은 개발 생산성을 어떻게 파악할 수 있는건지요?
On 2월13일, 오후3시08분, Youngrok Pak <pak.young...@gmail.com> wrote:
어느 회사고 숙련도에 차이가 있고 이에 따라 개발자의 능력도 차이가 나기 마련이라고 생각됩니다.
결국에는 공정한 인사 평가와 이에 따른 보상 체계가 마련되면 50 의 속도를 내는 개발자의 불만이 없어질 것이라 보입니다.
승진이 빠르거나, 연봉 협상에서 연봉을 높게 받거나, Incentive가 차별이 있든가...
이러한 보상 체계중에서 회사전체적으로 보았을 때 팀 평가 항목이 있고, 팀 간 평가에서 특정 팀이 다른 팀 대비 성과가 높을 경 우 성과금등이 차별 지급된다면, 전체 팀간 경쟁에서 50 숙련자가 속한 팀의 성과를 위해서 자연스럽게 10 짜리를 도와주는 협력 도 일어날 것이라 보여집니다.
흠....분류방법자체가 좀 어폐가 있지않을까요? 순수하게 개발능력만 5배인 사람이라....
제 개인적인 경험으로는 개발능력 5배인사람은 긍정적인 면에서는 개발능력 5배를 위해서 많은 정보들을 수집,공부하고 시간관리또한 잘하여 업무시간외에도 시간을 내어서 공부하는 식의 옆에 인원에게 긍정적인 혹은 자극을 주기 때문에 당연히 뽑아야할 분이라고 생각됩니다.
순수하게 개발능력만 5배인 사람이 있을까요?
부족한 경험으로는 잘모르겠네요.
@포동28
From: xper@googlegroups.com [mailto:xper@googlegroups.com] On Behalf Of Youngrok Pak
Sent: Friday, February 13, 2009 3:08 PM
To: xper@googlegroups.com
Subject: Re: 개발자의 개발량의 편차가 매우 큰 경우
만약, 정말로 개발 생산성이 5배 높은 뛰어난 팀원이 있다고 가정해 봅시다. 하지만 이 팀원의 팀웍은 다른 팀원에 비해 더 낫지도, 낮지도 않은 상황입니다. 말 그대로 순수하게 개발 능력만 5배가 높은 팀원이고 나머지 능력은 같습니다.
자신의 팀에 이런 팀원이 있으면 좋을까요? 나쁠까요? 면접에서 이런 사람이 지원했다면 채용하시겠습니까?
1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
=>일반적으로 빠른 업무소화 속도를 가진 개발자가 손해보고 있다라는 느낌을 갖는 이유는
자신의 능력에 비해 대우(평가)를 받지 못하고 있다고 느끼기 때문입니다.당연히 그에 맞는 대우를 해줄 수 있으면 됩니다.
그렇지 못하면 결국 팀을 떠날 가능성이 높겠지요
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
=>프로젝트 중간에 10의 속도를 가진 개발자의 속도를 3배이상 향상시키는 일은 거의 불가능에 가깝다고 봅니다.
(혹시 단기간에 가능한 방법을 아시게 된다면 부디 알려주시기 바랍니다)
다만 50의 속도를 가진 개발자와 비교했을 때 10의 속도를 가진 개발자의 가치가 1/5라고 볼 수는 없겠지요.
개인적인 의견입니다만 페어프로그래밍을 할 수 없는 상황에서
개개인의 스토리 처리 속도에 대해서 공개적으로 알 수 있는 상황은
그다지 좋은 분위기일 것이라고 생각되지 않습니다.
개개인의 가치가 오로지 업무속도로만 평가되는 분위기가 되고
서로간의 협력과 유대는 더욱 힘들어 질 것입니다.
또한 10의 속도를 가진 개발자 역시 50의 속도를 가진 개발자보다 더욱 큰 불만과 박탈감을 느끼고 있을지 모릅니다. (다만 본인은 불만을 토로할 자격이 안 된다고 생각할 수 있습니다)
현재 정보만으로는 제가 더 이상 어떤 말씀을 드리긴 힘들지만
만약 정말로 50의 속도를 가진 개발자와 10의 속도를 가진 개발자가 5배 수준의 가치를 지닌다면(다른 능력은 같고 버그발생율도 같음)
저는 10의 속도를 가진 개발자를 내보내고 50의 속도를 가진 개발자에게 내보낸 개발자의 임금을 더 주겠습니다.
그럼 50의 속도를 가진 개발자가 60의 속도를 낼 수 있을지도 모르겠군요.
(손해보고 있다고 생각하는 개발자는 보통 페이스 다운을 하는 경우가 많습니다)
비약이 조금 심한 말이었을지도 모르겠습니다만 이쪽이 더 효율적이지 않을까요?
_____
From: xper@googlegroups.com [mailto:xper@googlegroups.com] On Behalf Of Hubert Shin
Sent: Thursday, February 12, 2009 6:53 PM
To: xper@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 정도로 높일 수 있을지
일단 저는 50의 속도와 10의 속도가 실제 그 개발자의 '실제 능력'이라고 보고 논의를 진행하겠습니다. (김창준 님이 지적하신대로 인지된 속도를 실제 속도나 실제 능력이라고 오해하지 않도록 주의해야 한다고 생각합니다.) 오해를 방지하기 위해 '뛰어난' 개발자와 '부족한' 개발자라고 하겠습니다.
제 생각은 다음과 같습니다.
1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
1.1 기본적으로 (금전적, 사회적, 감정적인 측면 등 여러 측면에서) 충분한 보상을 주어야 합니다.
1.2 능력이 뛰어나다고 해서 업무가 몰려서 너무 과중하지 않도록 신경써주어야 합니다.
성공의 경험이 동기부여를 해준다고 하면, 업무가 계속 밀리는 것은 실패의 경험이라고 볼 수 있으므로 주의해야합니다. 일반적으로 뛰어난 개발자는 스스로 동기부여도 잘하는 사람이라고 볼 수 있고,
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
2.1 그 개발자가 가장 잘할 수 있는 업무를 주어야 합니다.
여기에는 두가지 가정이 있는데요. - 어떤 개발자라고 하더라도 스킬이나 분야에 따라서 능력의 차이가 나고, - 업무에 따라 필요한 스킬이 다르다는 것입니다.
그럼에도 불구하고 부족한 개발자가 가장 뛰어난 분야에서의 능력이 여전히 뛰어난 개발자보다 떨어지는 경우들이 자주 있습니다. 설령 그렇다고 해도, 뛰어난 개발자가 (1.2의 이유에 의해서) 모든 업무를 맡아서 할 수는 없기 때문에, 부족한 개발자가 잘하는 업무를 하는 것이 뛰어난 개발자가 다른 더 중요한 업무를 희생해서 하는 것보다 더 효율적인, 무역에서의 비교우위와 같은 현상이 발생합니다.
결과적으로는 위에서 지적하신대로, 뛰어난 개발자가 하기 싫어하는 어느 정도는 반복적인 업무지만 팀의 성과에는 중요한 업무 등이 될 수는 있다고 봅니다.하지만, 그런 업무를 하더라도 자동화라는 더 높은 목표를 제시하거나 해서 동기 부여는 물론 팀의 성과를 꾀하는 것이 필요합니다.
2.2 성장할 수 있도록 적극적으로 도와야 합니다.
위에 여러분들이 말씀하셨듯이 부족한 개발자가 갑자기 보통 개발자나 뛰어난 개발자가 되는 일은 없습니다. 부족한 개발자라고 해서 반복적이고 쉬운 업무만 맡기는 것이 아니라 조금씩 더 도전적인 업무를 맡기고, 사수를 붙여주고, 교육 기회를 제공하고, 면담을 통해 성장에 대한 동기 부여를 함으로써, 성장을 도와주는 것이 리더의 중요한 책임 중 하나라고 봅니다.
부족한 개발자의 업무를 항상 뛰어난 개발자에게 몰아주고 해고해버릴 수 없습니다. 1.2의 이유도 있지만, 다른 이유는 뛰어난/보통 개발자 모두가 영원히 여러분의 팀에 있으리라는 가정을 할 수는 없기 때문입니다. 따라서, 계속 해서 부족한 개발자들을 성장하도록 도와서 팀 전체의 능력을 유지 또는 성장할 수 있도록 것도 중요한 일 중의 하나 입니다.
1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
=> 저역시 대우의 문제가 아닐까요? 50의속도를 내는 개발자에게 연말 인센티브라도 더 챙겨줄려면 어떤 프로세스를 갖춰야할까요?
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
=>10의 개발자를 내보내고 그 돈을 50개발자에게 얹어줄것이냐,10의개발자를 30으로 될수있는 방법을 찾을것이냐의 선택을 해야한다면 전 후자를 택할것같습니다. 왜냐하면 그 속도라는건 경우에 따라서 유동적일수있으니깐요. 장기간 10의 속도밖에 못낸다면 당연히 바꿔야하는게 맞지만 그 속도라는게 변동이 생길경우가 크다는 것입니다.
그리고 대부분 10의 개발자는 교육시키기에 따라 30정도는 해내지 않을까요? 그럼...10개발자를 어떻게 속도를 올리느냐? 관리가 더 들어가야할것같습니다.
너무 낙관적인 생각인지는 모르지만 그러면 머...조금이라도 올라가지 않을까 하는 생각입니다.
@포동28
_____
From: xper@googlegroups.com [mailto:xper@googlegroups.com] On Behalf Of Hubert Shin
Sent: Thursday, February 12, 2009 6:53 PM
To: xper@googlegroups.com
Subject: 개발자의 개발량의 편차가 매우 큰 경우
Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.
11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.
1. 코드의 공동 소유
2. Story Point 추정시 고객 포함 전원 참여
위와 같은 기법을 사용하고 있는 상황에,
각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.
4차례에 Sprint 를 이미 진행 했고요.
문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.
함께 추정한 포인트들에 대해
Pair Programming을 할 수 없는 상황에서,
특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 있습니다.
쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠.
이슈는 두 가지인데요
1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
역시 사람관리가 가장 어렵다는 것을 다시 한번 일깨워주는 질문이 아닌가 합니다. 이것은 애자일을 떠나서 어느 분야에서도 가능한 시나리오가 아닐까 생각합니다.
이 문제에 대한 제 의견은 이렇습니다.
위에서 많은 분들께서 말씀하셨듯이 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
> _____
> From: xper@googlegroups.com [mailto:xper@googlegroups.com] On Behalf Of Hubert Shin > Sent: Thursday, February 12, 2009 6:53 PM > To: xper@googlegroups.com > Subject: 개발자의 개발량의 편차가 매우 큰 경우
> Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.
> 11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.
> 1. 코드의 공동 소유
> 2. Story Point 추정시 고객 포함 전원 참여
> 위와 같은 기법을 사용하고 있는 상황에,
> 각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.
> 4차례에 Sprint 를 이미 진행 했고요.
> 문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.
> 함께 추정한 포인트들에 대해
> Pair Programming을 할 수 없는 상황에서,
> 특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 있습니다.
> 쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠.
> 이슈는 두 가지인데요
> 1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
> 역시 사람관리가 가장 어렵다는 것을 다시 한번 일깨워주는 질문이 아닌가 합니다. 이것은 애자일을 떠나서 어느 분야에서도 가능한 > 시나리오가 아닐까 생각합니다.
> 이 문제에 대한 제 의견은 이렇습니다.
> 위에서 많은 분들께서 말씀하셨듯이 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
> > _____
> > From: xper@googlegroups.com [mailto:xper@googlegroups.com] On Behalf Of > Hubert Shin > > Sent: Thursday, February 12, 2009 6:53 PM > > To: xper@googlegroups.com > > Subject: 개발자의 개발량의 편차가 매우 큰 경우
> > Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.
> > 11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.
> > 1. 코드의 공동 소유
> > 2. Story Point 추정시 고객 포함 전원 참여
> > 위와 같은 기법을 사용하고 있는 상황에,
> > 각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다.
> > 4차례에 Sprint 를 이미 진행 했고요.
> > 문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.
> > 함께 추정한 포인트들에 대해
> > Pair Programming을 할 수 없는 상황에서,
> > 특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 > 있습니다.
> > 쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠.
> > 이슈는 두 가지인데요
> > 1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
개인간 수행능력 차이는 생길 수 밖에 없습니다. 그것은 그리 큰 문제가 되지 않는다고 생각합니다. 집중해야 하는 것은 '서로 비교를 하는 상황' 이 아닐까요?
부모가 자식들에게 하지 말아야 할 것들 중에 '비교'란 것이 있습니다. '자식들간 비교', '내 아이를 남의 아이와 비교하는 것' 비교는 아이에게 인격적 모멸감을 주고 비교당하는 약한 아이에게는 열등감을 심어주고 비교당하는 형제들간 경쟁과 분열을 조장하기 때문이죠.
가령 자식이 둘이 있는데 형은 70점 동생은 50점을 받았습니다. 형이 공부를 잘하니 용돈을 더 준다고 하면 동생이 과연 분발할까요. 두 아이들이 점수가 나아지기 위해서 서로 격려하고 돕고 노력할까요? 70점 맞은 큰 아이는 옆집에 100점 맞은 아이 얘기를 들으면 분발하고 더 열심히 할까요? 아이들이 공부를 잘하도록 유도하는 것에도 우애에도 올바르게 성장하는 것에도 전혀 도움이 되지 않습니다.
또 성적만으로 동생에게 '넌 형이 공부를 할 수 있게 다른 일을 도와주렴..' '공부대신 체육이나 예능쪽을 해보는게 어때..' 이와 같이 하는 것도 아이에게 도움이 되지 않겠죠. 성적만으로 아이의 취향, 가능성, 적성, 환경, 문제점 을 알 수 없으니까요. 전혀 바람직하지 않습니다.
팀도 그다지 다를 바가 없다고 생각합니다. 50의 생산성을 가진 분은 팀의 축복입니다. 10의 생산성을 가진 분은 개발결과 수치만으로는 알 수 없지만 어쩌면 팀워크를 다져서 팀원 모두의 생산성에 +5가 되도록 기여를 하고 있을지도 모릅니다.
하지만 미팅에서 팀장이 'OOO씨는 50점을 개발했습니다. OOO씨는 10점을 개발했네요..' 발표하는 순간 10점 맞은 개발자는 모멸감에 몸을 떨고 50점 개발한 사람은 불만에 빠지겠죠. 측정된 결과치가 팀워크나 개발생산성 기여에 대한 진실이 될 수 있을까요..
그리고 이러한 내용들이 서로 비교되도록 하는 것이 팀원이 분발하고 노력하고 협력하도록 하는데 도움이 되는 방법일까요.. 또 팀장이 선택한 측정방법으로 좋지 않은 결과를 획득한 팀원은 도태되도 그만일까요? 열등감을 갖기 쉬운 수줍음을 잘타는 팀원들은 특정한 방법에 적응하도록 성격을 개조해야 할까요?
방법은 배우면 그만이지만 그러한 방법을 선택하고 행하게 하는 동기는 전혀 공학적이지 않은 각자의 선한 생각이라던가 만족과 목표 같은 것에 달려있고 이것은 인격이라던가 개성에 대한 것이지 공학적인 방법을 우선해서 바꿀 수 있는 것과는 거리가 멀다고 생각합니다. 방법과 결과에 우선하고 몰두하다 보면 보이지 않는 것은 쉽사리 지나치기 마련이죠. 공학적인 방법이나 수치보다 존중과 같은 기본적인 것에 대해 좀 더 주의를 기울여봐야 하지 않을까요.
남을 도움으로써 팀이 보상받고 나도 더 큰 보상을 받고 모두가 행복해질 수 있다..란 것을 팀원과 팀이 배울 수 있도록 개인을 위한 목표와 보상체계나 문화를 만들어 나가는 게 필요하다고 생각합니다. (기법이 무엇이든 그것이 큰 문제는 아니잖아요..
글솜씨가 없어 당연한 말들을 너무 길게 쓴게 아닌가 싶네요. 좋은 하루 되시기 바랍니다.
p.s 팀내에서 상대적으로 개발생산성이 높은 팀원에게 보상하는 것도 고민해야 합니다. 50의 불만을 해소하기 위해 팀워크간 상대적인 생산성 이란 자대를 들이대며 50에 보상을 해주고 이러한 사실이 공유되면 자칫 나머지 팀원들의 괴리감을 증폭시킬겁니다.
|
