Writing matters 구글 그룹의 발전 방향

[Steven Yoo]

오지랖 넓은 유운연입니다.

예전에 구글 그룹 만들면서 선생님께 실제로 잘 사용되는 사례를 보내드리겠다고 말씀 드린적이 있어서, 이 글의 아래에 그 사례를 붙여두었습니다.

Writing Matters 구글 그룹을 어떻게 하면 가장 효율적으로 이용할지 생각해보았습니다. 

유학 시기가 언제가 되었든 다들 유학을 할텐데, 서로 구글 그룹으로 만나고 친해지고 유학생활동안 겪게될 고민들을 아래와 같이 서로 편하게 이야기할 수 있다면, 이 구글 그룹의 가장 좋은 사용방안이 아닌가 생각이 듭니다.

먼저 유학간 분들은 나중에 오시는 분들에게 현지 사정도 알려주고 조언도 해주면 더욱 좋겠지요.

아래의 글은 제가 가입되어 있는 XP (eXtreme Programming: 소프트웨어 개발 방법론의 하나) 구글 그룹에서 이루어진 토론 중의 하나입니다. 주제는 "이상적인 작업일을 강요받을 때 어떤게 대처해야 하는가"입니다.

추가로 말씀드리면, 밑의 이메일을 살펴보시면 어떤 분들의 글은 특히

1. 짧고 간결하며,
2. 번호를 잘 매겨서 사람들이 이해하기 쉽도록 하고,
3. 글자의 크기와 색깔 조절을 통해서 중요한 부분을 적절히 강조되었습니다.

잘 살펴보시면 이메일 쓰실 때 도움이 되지 않을까 합니다.

Forwarded conversation
Subject: 이상적인 작업일을 강요받으실 때 어떻게들 하시나요?
------------------------

From: 떵꺼리 <ultr...@gmail.com>
Date: 2008/11/4
To: xper <xp...@googlegroups.com>

- Show quoted text -

다음에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
 이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오. xp...@googlegroups.com
 이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오. xper+uns...@googlegroups.com
 추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko의 그룹을 방문하십시
오.
-~----------~----~----~----~------~----~------~--~---

----------
From: Kay Kim(김기웅) <game...@gmail.com>
Date: 2008/11/4
To: xp...@googlegroups.com

김기웅입니다.

B 사업부가 그렇게 행동하는 이유는, "일정은 협상 가능하다."라고 잘못 생각하기 때문인 것 같습니다.

저의 제안은 다음과 같습니다.

1. (B 사업부의 요청에 따라) 일정과 개발 범위 중 하나를 고정하고, 거기에 따라 나머지 하나를 변경하십시는 건 어떨까요? 둘 다 고정하려고 한다면, 가급적 받아들이지 않으시길 권해드립니다. (자세한 사항은 http://betterways.tistory.com/99 참조.)

2. "한 달만 우리 방식대로 실험해보자."고 제안해보십시오. 가능하다면 사업부 A와의 실적을 (상대방이 기분 나쁘지 않게) 언급해주시면서요.

3. B 사업부에도 똑같이 그 사업부의 일정, 현재 업무 등에 대한 정보를 요청하십시요. 그 이유는 1) 변경을 미리 감지하고, 2) 동등한 상태에서 협상을 해야 하기 때문입니다. 단, 이 방법은 회사에서 개발부서와 사업부서간의 정치적 관계에 따라서 달라질 수도 있고, 주의해서 사용하십시요.

사실 가장 좋은 방법은 알다시피 상호 신뢰를 구축하는 것입니다. (Trust is cheaper!) 그 밖에도 후원자를 확보하고, 설득하는 등의 장기적이고, 간접적이고, 근본적인 해결책들이 있지만, 그냥 짤막하게 적습니다.

김기웅 드림.

2008/11/4 떵꺼리 <ultr...@gmail.com>

----------
From: 신병호 <yuz...@nate.com>
Date: 2008/11/4
To: xp...@googlegroups.com

안녕하세요? 신병호입니다.

재미난(?) 질문을 올려주셔서, 저도 한마디 올려봅니다.

--> 저라면 어쩔 수 없이...달라고 하는대로 줄 것 같네요.

 

조직구성이 어떠하고 어떤 유형의 회사인지 모르기때문에 제가 넘겨짚어 내어본 답입니다.

 

사업부가 고객(돈줄을 쥐고있는)인 상황으로 가정하고, 고객이 원하는대로 해야된다는 논리인데요.

고객이 얼토당토 하지 않은 요구를 하는데 프로젝트를 수행해야 하는 상황이라면...

원칙적으로는, 따를 수 밖에 없다고 봅니다. 책임전가가 기분나쁘긴 하지만요.

 

싸운다고 말씀하셨는데, 싸우는건 당근히 안되겠고요.

어짜피 싸움을 걸면 자신이 틀렸다고 생각해도 끝까지 맞서게 됩니다.

궁지에 몰리면 어떤짓을 할지 모르는거고요.

 

이런경우는, Power Game을 해야되는데... PowerFull한 스폰서가 있으면 좋습니다.

또는, 조직의 연구개발 프로세스에 프로젝트 계획 영역을 표준화시키는 것도 방법이 되겠습니다.

 

Engineering Process Group이 없거나 움직일 수 없고, 확실한 스폰서가 없다면

충분한 설득작업을 거친후에 설득이 안되면 포기하고 B사업부의 관례대로 해야 될 것 같습니다.

 

 

다른분들의 생각도 궁금하네요.

 

 

 

- 신병호dream 

"약속과 사죄에는 목숨을 걸어라..."

----------
From: June Kim <june...@gmail.com>
Date: 2008/11/4
To: xp...@googlegroups.com

우선 일정에 대한 부분만 생각해 봤습니다.

저라면 확률로 답을 할겁니다. 이상적인 일정을 뽑고 그 일정 안에 끝날 확률을 명기합니다. 그리고 거기에 추가로 몇가지 확률별
예상 종료일을 함께 보여줍니다.

예컨대 다음과 같이 보여줍니다:

<예문>
현재의 실제 고급인력 A명, 중급 B명, 초급 C명으로 현재 주어진 요구사항대로 최대한의 퍼포먼스를 낸다고 할 경우, 일정별
납기일 준수 확률은 다음과 같습니다.

일정    준수확률
3개월  10%
5개월  50%
9개월  80%

참고로 IT업계의 평균적 납기일 준수확률은 30%대(스탠디쉬 그룹 보고서 참조)에 이르고 있고, 평균적 일정연기율은 약
200%(초기 예상의 2배)에 달하고 있습니다.
</예문>

이렇게 이야기해주고 이걸 이해하는지 확인합니다. 이걸 받아들이지 못하면 몇가지 데이타를 줍니다(우리의 히스토리). 그것도
받아들일 수 없다, 100%가 되게 3개월 안에 해달라고 고집하면 에스칼레이션(더 높은 자리의 사람과 이야기를 시도)을
하겠습니다. 그래도 안되면 이 프로젝트에서 빠지거나 혹은 이직을 고려합니다.

2008년 11월 4일 (화) 오후 4:58, 떵꺼리 <ultr...@gmail.com>님의 말:

----------
From: June Kim <june...@gmail.com>
Date: 2008/11/4
To: xp...@googlegroups.com

한마디 빠트렸네요.

제 생각에 중요한 것은 처음에 3개월로 하겠다고(이상적 일정으로) 약속을 하냐 안하냐고 아니고, 상대가 그 선택을 했을 때
거기에 따른 리스크를 인지하고, 수용할 생각이 있냐 없냐 입니다.

2008년 11월 4일 (화) 오후 7:59, June Kim <june...@gmail.com>님의 말:

----------
From: June Kim <june...@gmail.com>
Date: 2008/11/4
To: xp...@googlegroups.com

아래 방식은 "정공"이고,

"후공"(뒤에서 돌아치기)법을 말씀드리겠습니다.

우선 B 조직에서 내가 그나마 잘 아는 사람이 누구인가, 나랑 연결점이 있는 사람이 누구인가 찾습니다. 그 사람과 식사를
하면서 속 사정을 좀 듣습니다. 그곳의 사람들은 어떤 필요와 욕구가 있는지.

이걸 토대로 B 조직의 좀 더 중요한 사람과 컨택을 하면서 그 필요와 욕구를 공감해 줍니다. 그리고 상대가 "맞아맞아
그렇지!"라고 고개를 끄덕이면서 긴장이 풀어지면 자신의 필요와 욕구, 느낌도 표현합니다. "저는 두렵고 걱정이 됩니다. 일정을
맞추고 뭔가 떳떳하고 자랑스러운 일을 하고 싶기 때문이지요" 어쩌고.

그러면서 함께 필요와 욕구를 충족시켜줄 "전략"을 찾습니다.

----------
From: ykyoon <xyz...@gmail.com>
Date: 2008/11/4
To: xper <xp...@googlegroups.com>

저의 경우와도 비슷한 경우를 당하신 것 같습니다.

저도 제 위의 프로젝트 메니져와 한참을 그것가지고 논쟁을 하다가 결국은 프로젝트 메니져가 원하는대로 하게 되어버렸는데요.

이런 경우에는 어떻게 방법을 찾지를 못하는 것 같습니다. Agile을 하려는 개발자와 자신도 그 위에서 시간에 대한 압력을 계속
해서 받고 있는 사람과는 어쩔 수 없이 평행선을 그으면서 갈 수 밖에 없는 것 같습니다.

계속해서 이런 일들이 벌어지다보니...
저는 요즘들어서는 약간은 포기하게 되더군요. -_-

다른 분들은 좀더 나은 방법을 알고 계신지요? 알고 계시면 공유좀 부탁드리겠습니다.;

----------
From: gyehong park <gyeho...@gmail.com>
Date: 2008/11/4
To: xp...@googlegroups.com

안녕하세요. 날씨가 쌀쌀한데 모두들 건강하신지요.

>> 추정하실때 스토리 완성 확률이 어떻게 되는지 궁금하네요. The Goal3(critical chain)에 보면 추정을 할때 개발자들이 추정 확률을 70~80%로 잡는다고 합니다. 이렇게 잡으면 50%로 잡았을때보다 2배는 더 길어지죠.

 >> 이상적인 작업일이 50% 정도의 추정이라면 나쁘지는 않다고 생각합니다. 50% 추정에 전체 버퍼를 2배 더 해서, 실제 일정을 추정 일정의 3배로 잡는 것도 좋을듯 보입니다.

>> 이 부분은 중요한 부분이 아닙니다. 

>> 이 부분은 개발자 상호간에도 알 수 있으면 좋을듯 보입니다. 저쪽 포멧대로 해주는 것은 귀찮은 일이 될 수 있지만, 예를 들어 trac같은 것을 사용한다면 비슷한 일을 할 수 있을듯 보입니다. 요점은 이런 부분은 서로에게 필요한 일입니다. 하지만 같은 일을 2번하지 않도록 하는 것이 중요합니다.

>> 이 부분이 견해차이가 있을 수 있는 부분입니다. 얼핏 개발자가 일정, 버퍼를 설정하는 것이 가장 좋은듯 보이지만 개발자들은 추정을 잘 못합니다. 왜냐하면 안해봤으니까요. 왜냐하면 지금 프로젝트처럼 다른 사람들이 엉터리 일정을 설정했기 때문에 그 추정이 맞는지 틀리는지 검증할 수가 없었죠.(항상 일정을 초과했으니까요) 그래서 개발자가 하는 것이 가장 좋지만, 현재 프로젝트에서 그렇게 하는 것이 가장 좋은지는 상황에 따라 다릅니다. 이 부분은 정말 개발팀이 추정을 잘 할 수있는지 검토해보고 결정을 하면 좋겠습니다.    

>> 핵심적인 문제입니다. 현 팀이 B사업부에 갖고 있는 인식이 이렇다면, B사업부는 현 개발팀을 어떻게 생각하고 있을까요? 상호 불신상태에서 자신들이 하던 일을 믿을 수 없는 개발팀에게 넘겨주려고 할까요? 일정도 자신들이 생각하는 것보다 훨씬 길게 만들어서 왔는데... 

>> 어느 한쪽만 문제가 있지는 않다고 생각합니다. 따라서 '어떻게 일정을 잡아야할까요?'전에 '어떻게 상호 신뢰를 회복할 수 있을까?를 생각해 보면 좋겠습니다.' 분명한 것은 이런 문제가 B 사업부이기때문에 발생하는 문제가 아니고, 아주 일반적으로 발생하는 문제라는 것입니다. 이 문제의 보다 근본적인 문제를 해결할 수 있다면, 앞으로 계속 원하는 방식으로 일할 수 있을 것입니다. 

이 후에 2가지 방법을 생각해 볼 수 있습니다. 하나는 자신이 옳다고 생각하는 것을 가능하면 많이 지키는 방법이고, 다른 하나는 상대방이 옳다고 생각하는 것을 가능하면 많이 지켜주는 방법입니다. 김기웅님 방법이 후자이고, 신병호님 방법이 전자인듯 합니다. 어떤 것을 선택할지는 팀의 역량이나 특성에 따라 다르다고 생각합니다.

그럼 읽어주셔서 감사합니다.

----------
From: Kay Kim(김기웅) <game...@gmail.com>
Date: 2008/11/4
To: xp...@googlegroups.com

(역시 Xper. 고수들의 의견 줄줄줄. ㅎㄷㄷㄷ.)

2008/11/4 gyehong park <gyeho...@gmail.com>

----------

From: Youngrok Pak <pak.yo...@gmail.com>

Date: 2008/11/4
To: xp...@googlegroups.com

어떻게 보면 개발자에게 숙명과 같은 과제가 아닌가 싶습니다. 저도 답은 구하지 못했고 그동안 고민했던 것들을 이야기해보겠습니다.

일단 기본적으로는 창준님 말씀에 동의합니다. 상대방에게 일정과 리스크에 대한 개념 탑재(?)를 시켜주는 것이죠. 사실 이상적인 일정과 현실적인 일정 모두 아직은 추정치일 뿐이고 어느 것으로 협상하느냐가 중요한 문제는 아니라고 봅니다. 그보다 두 일정 사이에 리스크의 차이가 존재한다는 사실, 그리고 추정은 추정일 뿐이라는 사실을 인지시키지 않으면 "개발자는 쪼아야 된다"라는 사고 방식과 맞서기 어려울 것 같습니다. The Goal 3의 논리도 도움이 될 겁니다. 세상에는 합리적인 사람이 많고, 합리적으로 잘 설명할 수만 있다면 먹히는 경우가 꽤 많을 겁니다.

하지만, 이게 가능하지 않은 경우도 많을 겁니다. 갑을병정의 트리에서 우리는 병이나 정인데 스펙은 PDF 문서로 쫙 다 뽑아져 있고 일정을 요구하는 것은 갑이라든가, 에스컬레이션을 하려면 만나야 하는 사람이 300이라든가, 제 때 기능을 완성해내지 못하면 중요한 계약이 실패로 돌아가서 커다란 손해가 발생할 수 있다든가, 용역 계약서를 쓸 때 실수!를 범해서 다 해줘야 된다든가, 소위, 무조건 일정도, 스펙도 만족시켜야 하는 요구가 들어올 때가 있습니다. 이럴 때일수록 일정은 빠듯하게 줍니다. 그리고 그 빠듯한 일정을 지키지 못했을 경우에 면죄부를 받을 수 있는 유일한 방법은 야근과 월화수목금금금입니다. 이런 상황에선 어떻게 해야 할까요?

이 생각을 할 때마다 전 The Goal을 생각합니다. 공장장인 알렉스는 3개월의 시한을 받습니다. 만년 적자에 허덕이는 공장을 금광으로 바꿔놓지 못하면 공장은 폐쇄되고 자신은 짤립니다. 추가 설비 투자도 못합니다. 일정도, 스펙도 협상 불가에 추가 인력 투입도 없는 셈입니다. 그런데 알렉스는 해냅니다. 우리는 어땠을까요? 에시당초 쟤네들이 불가능한 일정을 잡았던 거야. 어쩔 수 없어. 우리는 최선을 다했어. 일이 이렇게 많은데 일정을 그렇게 후려치면 어쩌란 말이야. 내가 노예처럼 일하려고 니들하고 계약한 줄 알어?

하지만, 지나보면 그건 최선이 아니었습니다. 쉽지는 않았겠지만 방법은 얼마든지 있었습니다. 왜 우리는 알렉스처럼 못했을까요?

소설 동의보감에 보면 허준은 늘 이렇게 말합니다. "의원은 병을 두고 다짐을 하지 않습니다." 하지만 그게 용납이 안되는 상황을 맞이합니다. 임금의 먼 친척을 치료하는데 기한을 못 박아야 합니다. 게다가 환자는 더할 나위 없는 망나니로 투약도 거부하고 식사조절도 안 지킵니다. 하지만 허준은 이 모든 것을 자신이 감수해야 하는 것으로 받아들이고 결국 해냅니다.

어쨋든 허준처럼, 알렉스처럼 해내야 하는 게 아닐까, 그런 생각을 해 봅니다. 사실 SI 업체라고 해도 이 정도까지 빡빡한 위기 상황이 매일매일 닥치지는 않을 것이고 합리적으로 협상 가능한 고객도 적지 않을 겁니다. 하지만, 불합리한 일정을 강요 받는 상황이란 것도 또다른 창의성을 발휘할 수 있는 기회가 아닐까요. 수면을 낮춰서 우리 팀의 문제를 드러내주는 기회가 될 수도 있구요. 물론, 야근도 안하고 월화수목금금금도 없이, sustainable pace로 해낼 수 있는 방법을 찾아야겠지요.

그래서, 전 앞으로 또 똑같은 상황에 부딪힌다면 "그래, 내가 다 맞춰줘보겠다. 다 맞춰주면 어떻게 나오나 한 번 보자."라는 생각을 하려고 합니다.

그리고, 만약에 정말로 다 해내고 클라이언트를 만족시켜서 클라이언트가 다음 번 일도 꼭 우리랑 하고 싶다고 그러면 그 때는 이렇게 대응하고 싶습니다. "당신들 별로라서 또 같이 일하고 싶지 않다. 우리랑 일하고 싶으면 똑바로 해라."

아직은...희망사항이죠. ^^

----------
From: 김명구 <more...@naver.com>
Date: 2008/11/5
To: xp...@googlegroups.com

별 도움은 안되실 듯 합니다만, 저 역시 비슷한 상황에서 일을 해본 경험에서 말씀드리겠습니다.

 

현실적으로 저런 인식을 바꾸려면 시간적으로든 정치적으로든 상당한 비용과 노력이 드는 게 사실이라고 생각됩니다.

따라서 저 사업부와 계속 같이 일을 해 나가야 하는 상황이라면 길게 보고, 일단 우호적 관계를 만드는데 치중하는 게 좋을 듯 싶습니다.

되든 안되든 최대한 긍정적인 반응을 보여주고, 원하는 자료는 가짜로 만들어서라도 던져 줍니다.

다만 이 과정에서 던져주는 자료가 정확도가 낮을 수 있음을 조금씩 흘리고요.

 

그 다음 1~2주 진행을 하면서 진행 속도를 측정합니다. scrum 의 burn-down chart 같은 게 이 때 많은 도움이 될 듯 싶고요.

현실적으로 무리한 일정을 잡았으면 속도가 매우 안 나올 겁니다.

그럼 이 자료를 들고가서 현 상황에서 객관적 데이타를 바탕으로 이 상황이라면 일정 준수가 어렵다는 점을 어필합니다.

그리고 빠른 진행을 위해서 이런 저런 방법을 강구해 보겠다고 얘기하는 식으로 긍정적 태도는 유지합니다.

이렇게 하는 이유는 일반적으로 초기 계획을 중시하는 사람이나 조직일수록, 객관적 데이타가 있느냐 없냐에 따라 반응이 다른 경우가 많기 때문입니다.

 

이런식으로 쌓이는 자료와 상황을 계속 보여주고, 이해 시키는 작업을 반복합니다.

이해를 못하더라도 어느 순간에 기존과 다른 반응이 나오기 시작하면 그때부터가 시작입니다.

담당 컨택 포인트가 잘 이해를 못하면, 더 윗선이나, 그도 안되면 조직 내 스폰서에게 어필을 계속합니다.

 

저의 경우 이런식으로 해서 몇개의 짧은 프로젝트를 계속하면서, 상대 조직이 어느 정도 이해하는 데까지 약 1년 정도 걸렸는데요.

어쨌든 포기하지 않고 계속한 보람은 있었습니다.

 

Half empty and half full.  :->

----------
From: Sangchel Hwang <k16...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

제가 보기에는 B사업부가 SI 프로젝트에서는 더 일반적입니다.
정상적인 계획이면 다행이죠. 가끔은 비 정상적인 계획을 주기도 하니까요.

아직 그런 경험은 없는데 저라면 스텔스 모드로 진행을 하겠습니다.
굳히 그런 고객을 설득해서 애자일을 하기 보다는 허용이 가능한 최대한의 일정을 주고
나머지는 그 일정안 에서 진행하는 방향으로 가겠습니다.

나중에 결과로 설득하는것은 해볼 수 있을거 같네요.

2008/11/5 김명구 <more...@naver.com>

-- 
http://moai.tistory.com

----------
From: 이병준 <byungj...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

마이크 콘은 이런 경우에 김창준님처럼 "확률로 대답하라"는 조언을 했습니다. 확률로 표현된 '범위' 형태의 추정치를 제시하면 리스크가 큰 것이 눈에 보이기 때문에 설득하기가 좀 더 편한것 같습니다..그리고 관련된 연구 자료나 통계 자료를 들이대면 말빨이 좀 더 잘 먹히더군요. ^^;

----------
From: Kay Kim(김기웅) <game...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

딴지는 절대 아니고, (모두에게) 질문이 있습니다.

만약 상대방이 합리적으로 생각하는 상대가 아닐 경우에는 어떻게 할까요?

확률로도, 통계나 사례로도 납득하지 않는다면요? ("그건 한국이 아니잖아!")

여기 계신 분들 중 적지 않은 분들도 "한국(혹은 우리 산업, 회사)의 특수성"을 이야기하며, 지금 오간 이야기들에 고개를 절래절래 흔드실 수도 있을 거라고 생각합니다. ("맞는 이야기이긴 하지만, 우리 회사는 좀 상황이 달라서...")

우리는 이런 반응을 어떻게 다루어야 할까요? 

김기웅 드림.

2008/11/5 이병준 <byungj...@gmail.com>

----------
From: 신병호 <yuz...@nate.com>
Date: 2008/11/5
To: xp...@googlegroups.com

안녕하세요? 신병호입니다. Xper에 가입해서 이런 대화를 함께 볼수 있는 행운을 주셔서 감사합니다.

 

 

Q)

 

A)

저의 경우에는 우리 주변의 대부분의 경우가 불합리할 것으로 생각합니다. (혼자만의 생각일수도...)

확률, 통계, 사례를 언급해도 "너는 안드로메다에서 온거 같다."라는 대답밖에는 얻을 수 없죠.

끝까지 들어주기라도 하면 다행인데, 다 듣고나서도 "좋은 정보 고맙다."로 끝나기 일수죠.

 

이런경우에는 에스컬레이션도 한계가 있습니다. 한단한단 밟아 가는 과정이 상호간에 스트레스로 다가오죠.

스트레스를 극복할 개선 의지가 상대에게 없다면 (편리한) 관례로 회귀하게 됩니다.

 

(이전 Reply에서도 이야기 했지만) PowerFull한 스폰서가 최상의 답이라고 봅니다.

이런 문제가 발생했을때, 소장이나 사장이 Push를 해주면 쉽게 해결이 될 것입니다.

 

오라클 아시아 연구센터(한국소재)의 경우에는 센터장이 애자일방법론(스크럼)을 지지하고 있더군요.

덕분에 기존의 Heavy한 연구개발 프로세스가 존재함에도 많은 수의 프로젝트를 스크럼으로 추진하고 있습니다.

 

저는 애자일 프로세스가 가지는 가장 큰 문제상황으로 '조직이 인정하지 않는 방법론'을 꼽고 있는데요.

근본적인 해결책이 조직의 표준화된 프로세스에 애자일 프로세스를 편입시키는 것이라 보고 있습니다.

 

저는 소프트웨어 프로세스를 업으로 하고 일하고 있는데요.

소프트웨어 프로세스 개선을 할때에도 가장 중요한것이 PowerFull한 스폰서입니다.

그것이 없다면 프로세스는 개선은 요원한 일이 됩니다.

 

가끔은 팀장급이 팀에 연구개발 프로세스를 도입하기도 하는데요.

이런경우에도 애자일방법론을 도입한 경우와 같은 현상이 발생합니다. 스트레스도 심하고요.

 

 

 

같은 이야기를 반복했네요. 시원한 水요일 입니다. 감사합니다.

 

 

- 신병호dream 

"약속과 사죄에는 목숨을 걸어라..."

----------
From: 서비나라 <subb...@gmail.com>
Date: 2008/11/5
To: xper <xp...@googlegroups.com>

제 짧은 소견으로는 아마도 상대가 비합리적인 사람이라기 보다는 아마도
융통성이 없거나 독불장군식의 스타일이지 않을까 싶습니다.

확률,통계,사례등을 받아들이지 못할 정도 수준의 커뮤니케이션 상대라면
기웅님이 어떤 성격의 소유자이신줄 잘은 모르겠으나 그나마 한국 사람의
특수성을 고려해본다면 조금은 비굴한 모습의 대응이 필요할 수도 있을것
같습니다.

여기서 비굴이라는 표현은 겸손과 양보의 마음을 조금 비하시킨 것입니다.

그 상대가 만약 술을 마실줄 안다면 같이 술자리나 그렇지 않다면 식사
자리라도 함 만들어서 현재 기웅씨가 고민하는 부분에 대해서 진심어린
표정과 말투로 마치 조언을 구하는 것처럼 대화를 해보는 것도 방법일 것입니다.

그러다 보면 자연스레 그 상대의 보이지 않았던 모습을 볼 수 있을수도
있게되고 혹여 사적인 관심사나 기타 문제등을 도와줄 수 있는 부분이
보일 때 적극적으로 도와줄 수 있다거나 같이 고민해주는 모습에 어쩌면
조금 움직임이 있지 않을까요?

좀 추상적인 견해인것 같아 죄송합니다.^^
쉽게 얘기해서 이런거죠~ 내가 잘못하지도 않았는데 한 대 먼저 맞았지만
사과는 내가 먼저 다가가서 한다는... ㅋㅋ

아무쪼록, 다른 여러분들의 조언 많이 참고하시어 잘 해결되시기 바랍니다.

끝으로, 그 상대에 대해 간단한 성향,나이,경력등의 기타 프로필을 알 수 있다면
좀 더 다양한 얘기가 나올 수도 있을것 같네요.

이상입니다.

> 2008/11/5 이병준 <byungjoon....@gmail.com>

> > 먹히더군요. ^^;- Hide quoted text -
>
> - Show quoted text -

----------
From: Kay Kim(김기웅) <game...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

요약하면, "(모든 것은 사람이 하는 것이니) 힘을 실어줄 후원자를 확보하라."인 거죠?

요즘 재미있게 읽고 있는 세상을 바꾼 32개의 통찰의 한 대목이 떠오르네요:

"어떤 사람들은 새로운 분야를 개척하는 것이 미친 짓이라고 했지만 나는 그럴 듯해보였다. 멘토중 한 명이었던 빌 던이 가장 훌륭한 조언을 해주었다. 그는 내 아이디어가 미쳤다고 생각하지 않는 사람들이 있는 곳으로 가라고 했다. 아주 단순했지만 현명한 조언이었다.

브루스터 카힐, WAIS, Internet Archive 및 Alexa Internet의 창업자

김기웅 드림.

2008/11/5 신병호 <yuz...@nate.com>

"약속과 사죄에는 목숨을 걸어라..."

----------
From: June Kim <june...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

1) NVC 적으로 상대/나의 필요와 욕구에 집중합니다
2) 세상은 넓고 할 일(및 고객)은 많습니다. 규모 슬림화를 해서 몸집을 줄이면 나랑 죽이 맞는 상대를 찾아서 일할 수
있습니다. 프로젝트를 성공시키는 것만으로도 쉽지 않은데, 다른 사람들 설득하고 싸우고 하는 것에 에너지를 소비하기까지 하면
더더욱 힘듭니다.
3) 일단 까라는 대로 까되, 정말 원하는 것이 무엇인지를 분명히 파악합니다. 그러면 의외로 유도리를 부릴 수 있는 부분이
있습니다. 그 안에서 효율화를 취합니다(단순히 일을 빨리한다가 아니라, 할 필요 없는 일을 안한다). 이를 통해 신뢰를
형성하면 내가 원하는 것을 이야기하기 시작합니다.
4) 파워를 가진 사람이 추진해주면 일이 쉬워질수는 있지만 퍼즐의 한 조각일 뿐입니다. 애자일을 추진할 수 있다는 것이지
그것이 지속할지, 성공할지는 보장되지 않습니다. 경영진이 애자일 도입을 추진해서 실패하는 사례를 겪어봤습니다. 오히려 경영진이
추진했다는 점 때문에 저항이 생겼습니다. 결국 최종적으로는 직접 일을 하는 사람들이 받아들여야 하며, 이를 위해서는 윗선에서의
지원이 있으면 유리합니다.

2008년 11월 5일 (수) 오후 12:07, Kay Kim(김기웅) <game...@gmail.com>님의 말:

----------
From: 신병호 <yuz...@nate.com>
Date: 2008/11/5
To: xp...@googlegroups.com

예. 그 이야기 맞습니다.

 

어짜피 조직은, Boss가 책임지고 이끌어야되니까요.

의견이 충돌하고 있는 B사업부와 개발실에 공통된 Boss가 후원해주는게 좋겠네요.

개발실의 Boss가 힘이있다면 그가 해줘도 좋겠고요.

 

'부르스터 카힐'의 이야기를 보니 떠오르는 것이 있네요.

P-camp라는 행사에서 나누었던 이야기 인데요.

 

"사장님이 애자일프로세스에 부정적이세요... 어떻게 설득할 수 있을까요?"라는 질문이었습니다.

저는 "회사를 옮기세요."라고 답했었는데요.

 

그런 이야기 맞나요?

김기웅 드림.

Q)

 

"약속과 사죄에는 목숨을 걸어라..."

"약속과 사죄에는 목숨을 걸어라..."

----------
From: Kay Kim(김기웅) <game...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

질문하신 떵꺼리 님은 답변들이 만족스러우신가요? 답변 내용들이 본인의 현실에서 실천가능하다는 생각이 드셨는지요? :)

김기웅 드림.

안녕하세요. 날씨가 쌀쌀한데 모두들 건강하신지요.

----------
From: 이광운 <ultr...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

- Show quoted text -

2008년 11월 5일 (수) 오후 6:09, Kay Kim(김기웅) <game...@gmail.com>님의 말:

----------
From: 이병준 <byungj...@gmail.com>
Date: 2008/11/5
To: xp...@googlegroups.com

- Show quoted text -

----------
From: gyehong park <gyeho...@gmail.com>
Date: 2008/11/6
To: xp...@googlegroups.com

좀 다른 이야기입니다. 
"왜 위에 있는 분들은 더 좋은 방법, 새로운 방법을 사용하지 않으려고 할까요?"에 대한 생각입니다

이병준님 글을 읽다가 '합리적인 개선', '새로운 방법'이라는 부분에서 더골4- 신기술 도입의 함정(Necessary But Not Sufficient)-가 생각나서 평소 가지고 있던 생각을 적어봅니다.. 이 책에서는 신기술을 도입할 때 룰도 같이 바꾸어야 한다고 이야기합니다. 그래서 신기술만 도입하면 안되고 룰을 같이 바꾸어야 하는데 이것을 하지 않다가 보니 신기술 도입이 오히려 해가 되는 경우가 많다고 나옵니다.


가만 보면 많은 회사들은 정말 구태의연한 방식으로 운영되는 곳이 많습니다.(개인도 그렇지만요, 저도 ㅜㅡ) 그래서 많은 분들은 불만을 토로하죠. 그러다가 더골4를 읽고서는 다음과 같은 생각이 들었습니다.
  '경험이 많은신 분들은 자신의 경험에서 신기술 도입의 함정을 감지하고 있는 것은 아닐까? 무엇인지는 모르면서...'
그래서, 
  '신기술 적용이 쉽지 않다는 것을 알고 있기 때문에 무엇인가 새로운 것을 시도하는 것을 꺼리는 것은 아닐까?' 
이런 관점에서 보면 새로운 것을 시도할때는 이 것이 기존의 방법보다 확실한 이익을 준다는 것을 알지 못하면 절대 도입하려고 하지 않을 것입니다. 왜냐하면 과거의 실패에서 잘 알고 있기 때문입니다. 결국은 우리가 무엇인가 새로운 요소를 도입할 때 확실하게 더 나은 결과를 보장할 수 있어야 합니다.

더불어서 또다른 문제가 발생하는데, 새로운 방법을 도입하는 사람의 '오만'입니다. 저도 이런 면에서 많이 실수를 해 왔습니다. 프로세스만 도입하면 무엇인가 좋은 결과가 나오리라는 막연한 기대를 갖고 있고(어떻게 안 갖겠어요? ㅡ.ㅡ;), 프로세스 이해도가 부족하고 그러다 보니 룰이 제대로 변경되지 않은 상태에서 진행됩니다. 물론 부분적인 성공은 있지만, 실수나 실패도 발생하고 이럴 경우 상당한 신뢰에 손상을 가져옵니다. 그럼에도 불구하고 자신의 태도는 잘 바꾸지 않게 됩니다. 왜냐하면, '나는 더 좋은 방법을 사용하고 있어'라고 확신하고 있었기 때문입니다. 그러다보니 주변 사람들을 오만하게 내려다 보곤 합니다. 이런 상태에서 프로젝트가 잘 진행되는 것이 이상할 것입니다. 더 많은 희생을 하면서도 좋지 않은 결과만이 남아 있을 뿐입니다.

요약하면, 
1. 새로운 방법을 도입할 때는 기존 방법보다 확실하게 나은 결과를 보장할 수 있어야 한다.
2. 새로운 방법에 익숙하지 않은 사람들을 배려할 수 있어야 한다.

----------
From: June Kim <june...@gmail.com>
Date: 2008/11/6
To: xp...@googlegroups.com

다른 부분은 전반적으로 동의합니다. 그런데...

일반적으로 "기존 방법보다 확실하게 더 나은 결과를 보장할 수 있는 방법"은 새롭지 않거나(혹은 않으면서) 그 결과가 그다지
인상적이지 못합니다.

2008년 11월 6일 (목) 오전 9:27, gyehong park <gyeho...@gmail.com>님의 말:

----------
From: 이광운 <ultr...@gmail.com>
Date: 2008/11/6
To: xp...@googlegroups.com

최종으로 나온 보스의 결정은

"2개월 안에 끝내라" 

분위기는 살벌해지고 서비스 기획서 대수정이 이루어지고 있습니다.

회사라는게 

여러가지 사업을 기획하고 개발하고 런칭하는게 

합리적인 의사소통으로 잘 되기도 하지만

때론 군대식의 명령도 해야하는게 현재의 상황인 것 같습니다. ^^;;;

--
Steven Yoo

Phone: 82-10-4524-4535