'책소개'에 해당되는 글 2건

  1. 2008.01.03 돌부처의 심장을 뛰게 하라.
  2. 2007.12.03 소프트웨어 프로젝트에서의 리스크관리 - Waltzing with Bears
2008. 1. 3. 10:30

돌부처의 심장을 뛰게 하라.

책구경을 위해 교보문고에서 표지가 인상 깊어 들어서 쓰윽 넘기다 본 한 귀절이
2007년 마지막 책으로 기억남는 책이 되었습니다.

"내게 만약 나무를 베어 넘어뜨릴 시간으로 여덟 시간이 주어진다면, 여섯 시간을 도끼날 가는데 쓰겠다.-링컨-" 


작년에 옮긴 회사에 1년이 넘어가는데도 적응을 못하고 있는 스스로의 모습을 볼때 쉬운 문제만은 아니구나 싶었습니다. 처음에는 회사의 문제, 상대의 잘못으로 치부했는데... 시간이 지날수록 근본적인 해결책보다 스스로 풀어가는 방법이 필요하다고 생각이 들더군요.

6월부터 시작한 프로젝트에서 개발PL과의 마찰 아닌 마찰은 어떻게 보면 스스로에게 커뮤니케이션을 이뤄가는 능력 부족이 문제가 아닌가...  싶을때 많은 생각을 하게 해 주더군요.

협상과 커뮤니케이션 능력은 굉장히 중요한 부분인 것 같습니다. 그 능력은 자신를 유연하면서도 강하게 만들어 주도록 도와주는 보이지 않는 칼입니다.

"최고의 장소는 싸우지 않고 이기는 장수다 -손자-"

돌부처의 심장을.... 은 강팀장에게 남에게 이기는 것이 다르다고 말하고 있으며, "당신"이 아니라 "나"를 먼저 두드리고 낮아지고, "나"보다 "당신"을 생각하도록, 스스로 칼을 쥘 수 있는 5단계를 가르쳐 주었습니다.

목표를 달성하기 위해 인간으로서 느길 수 있는 충동을 억제하고 본능이 시키는 것과 반대로 행동해야 한다.
다시 말해 반격하고 싶을 때 공격의 본능을 억제하고, 반박하고 싶을 때 상대의 말을 경청하고, 정답을 말해주고 싶을 때 질문을 하고, 양쪽의 견해 차이를 당신에게 유리한 쪽으로 끌어오고 싶을  때 차이를 잇는 다리를 놓아주고, 상대를 이기고 싶을 때 상대를 교육 시킬 필요가 있다.

- 중략 -

장벽 돌파 협상의 5단계 전략
1. 발코니로 나가라
첫 번째 단계는 다른 사람의 행동을 통제하는 것이 아니라 당신 자신을 통제하는 것이다. 상대가 '노'라고 말하거나 공격해 오면 당신은 당황한 나머지 바로 양보하거나 반격할 가능성이 크다. 먼저 게임의 정체를 파악해서 자신의 반사적 반응을 통제하도록 하자. 그런 다음 생각할 시간을 벌자. 그 시간 동안 당신의 이해관계와 배트나에 대해 곰곰이 생각해 보자. 협상이 진행되는 동안 항상 당신이 얻을 보상에 집중해야 한다. 화를 내거나 보복하는 대신 당신이 원하는 것을 얻는 데 초점을 맞추자. 반사적으로 반응하지 말고 발코니로 나가라.
2. 상대의 입장에 서라
협상을 하기 전에 먼저 우호적인 협상 분위기를 조정할 필요가 있다. 우호적인 분위기를 만들려면 상대가 품고 있는 분노, 두려움, 적대감, 의심을 제거해야 한다. 상대는 당신이 공격하거나 거절해오기를 기대하고 있다. 그러니 반대로 행동하자. 상대의 말을 경청하고, 상대가 하는 말의 요지를 인정하고, 가능한 한 동의해 주자. 상대의 권위와 능력도 인정해 주자. 논쟁하지 말고 상대의 입장에 서라.
3. 게임의 틀을 바꿔라
다음 도전 과제는 게임 자체를 바꾸는 것이다. 상대가 강경한 입장을 취하면 거부하고 싶어질 것이다. 그럴수록 상대는 더욱 강경하게 나올 뿐이다. 상대의 관심을 쌍방의 이해관계를 충족시키는 과제로 향하도록 만들어라. 상대가 무슨 말을 하든 문제를 해결하려는 시도로 재구성하자.
"그것을 원하는 이유를 구체적으로 말씀해 주시겠습니까?"
"당신이 내 입장이라면 어떻게 하시겠습니까?"
"만일 이렇게 한다면 어떻겠습니까?"
상대를 가르치려 들지 말고 문제를 통해 상대가 스스로 깨닫도록 하라. 그리고 상대의 전순을 파악해 그 틀을 바꿔야 한다. 상대가 버티면 우회하고, 공격하면 흘려 버리고, 속임수를 쓰면 자연스럽게 노출시켜라. 거부하지 말고 틀을 바꾸어라.
4. 황금의 다리를 놓아주라
당신은 드디어 협상할 준비가 되었다. 그러나 상대는 합의의 결과나 자신에게 어떤 이득이 돌아올지 확신하지 못하고 있다. 이럴 때 당신은 강경하게 밀어 붙이고 싶은 유혹을 느낄 것이다. 그러면 상대는 더욱 강경해지고 거세게 저항한다. 정반대로 행동하라. 당신이 가고 싶은 방향으로 상대를 유도하라. 당신 자신을 상대가 '예스'를 말하게 만들 중재자라고 생각하자. 합의안을 도출하면서 상대의 아이디어를 적용해 그를 협상에 참여시키자. 충족되지 못한, 눈에 보이지 않는 상대의 이해 관계, 특히 인간이라면 누구나 갖는 기본적인 욕구를 규명하고 충족시켜 주자. 상대가 체면을 세울 수 있도록 도와주고 협상 경과가 상대의 승리로 보이도록 만들어주자. 그리고 빨리 가려면 천천히 걸어야 한다는 점을 잊지 말자. 몰아 붙이지 말고 황금의 다리를 놓아주라.
5. 파워를 이용해 상대를 교육하라
상대가 여전히 저항하면서 당신을 이길 수 있다고 생각한다면, 그렇지 않다는 것을 상대에게 가르쳐 주어야 한다. 상대가 '노'라고 말하기 어렵게 만들 필요가 있다. 당신은 위협을 가하거나 무력을 행사할 수도 있다. 하지만 그런 방법은 이로울 게 없다. 당신이 상대를 막다른 골목으로 몰아가면 상대는 전력을 다해 저항하게 된다. 몰아붙이지 말고 합의를 이루지 못했을때 치러야 할 비용에 대해 말해 주자. 현실감 테스트형 질문을 하고 위협하기보다는 경고를 하고 당신의 배트나를 시위하라. 당신의 배트나는 꼭 필요한 경우에만 최소한으로 사용하라. 당신의 목표는 승리가 아니라 상호 만족이라는 것을 상대에게 확신시켜 저항을 최소화하자. 상대 앞에 당신이 놓아 준 황금의 다리가 있다는 사실을 끊임없이 일깨워 주자. 파워는 상대를 이길 목적이 아니라 상대를 가르치는 데 써라.



화가 치밀어 오르는 순간 말을 해 보라. 당신이 평생 후회할 말을 하게 될 것이다. - 앰브로스 비어스 -

  돌부처의 심장을 뛰게 하라 - 고집불통의 NO를 YES로 바꾸는 협상 전략  윌리엄 유리 지음, 이수정 옮김
30년 이상 각종 협상을 중재한 경험자이자 하버드 로스쿨에서 협상 연구 프로젝트를 이끌어 온 저자가 제안하는 고집불통 상대를 이기는 협상 전략. 양보하거나 싸우지 않으면서도 자기와 상대의 이해관계를 모두 충족시킬 수 있는 winwin 협상의 5단계 전략을 풍부한 사례와 함께 제시한다.
2007. 12. 3. 15:01

소프트웨어 프로젝트에서의 리스크관리 - Waltzing with Bears

Project Management 관련 책의 대부분이 그들의 방법론 중심을 책을 저술하는 것이 사실입니다. 읽다보면 자신이 알는 것과는 다른 내용과 이해하기 어려운 프로세스에 대한 이야기로 일괄하다 결국 반도 못보고 책을 덮어 버리는 경우가 많았습니다.

블로그에 담아두고 있다가... 이번 프로젝트를 수행하면 꼭 읽어야 겠구나 싶어 1년 가까이 북마크만 해 놓았던 책을 구매를 하고야 말았습니다. (강팀장의 책 수집 블로그 http://blog.yes24.com/hanjum)

프로젝트 관리자 또는 리더(매니저)라면 한번 읽어 시길 추천합니다. 기술적인 방법론을 익힌기 위한 분도 괜찮겠지만 요즘 들어 왠지 답답한 분이나... 변명이 필요한 분이라면 재미있게 읽을 수 있을 것 같습니다. (^^ 제 경험일까요?? )

불확실성과 관련된 보다 중요한 원인들은 다음과 같다.

1. 요구사항(requirment) : 정확히 무엇을 하기 위한 시스템인가?

2. 정합성(match) : 사용자 및 다른 관련 시스템과 어떻게 연계할 것인가?

3. 환경 변경(chainging environment) : 개발 기간 중에 요구와 목표들이 얼마나 변경되는가?

4. 자원(resources) : 프로젝트를 위해 필요한 핵심 기술을 가진 사람을 확보할 수 있는가?

5. 관리(managerment) : 관리 조직에게 생산성이 높은 팀을 구성하며 사기를 유지하고, 인원 변경을 최소화하면서 관련 업무간의 복잡한 관계들을 풀어 나갈 능력이 충분히 있는가?

6. 공급망(supply chain) : 다른 관련 조직들이 기대대로 대응해 줄 것인가?

7. 정치(politics) : 현실을 호도하여 프로젝트의 궁극적 성공과는 상충되는 제약들을 부과하는 경우 어떤 영향이 있을까?

8. 상충(conflict) : 다양한 이해 조직 간의 상호 양립할 수 없는 목적들을 어떻게 다룰 것인가?

9. 혁신(innovation) : 이 프로젝트에만 적용된 기술이나 접근 방식이 최종 결과에 어떤 영향을 미칠 것인가?

10. 규모(scale) : 과거에 경험하지 못한 큰 규모가 프로젝트 성과에 어떤 영향을 미칠 것인가?

- 3장 덴버 국제공항 中 (45P)


 

운(Luck)

"내 생각에는 4월까지는 매우 어려워 보이네. 그래서 자네에게 이 일을 맡기는 것일세"

프로젝트가 하나의 도전으로 포장되어 주어졌을 때, 그로 인해 사람들은 어느 정도 운에 의존하는 자세를 취하게 된다. 예를 들어 사장이 당신에게 "당신과 당신 아래 8명의 직원이 4월까지 이 중요한 일을 해내는 것이 우리 회사의 마지막 희망이오. (저런, ceo가 언론에다가도 이를 말해 버렸다.)"라고 말한다면 달리 할 일이 무엇이 있겠는가? 만약 사장이 당신의 눈을 똑바로 쳐다보면서 사기를 쳐서라도 이것을 맡아 달라고 한다면, 당신은 그냥 최선을 다하면서 행운이 함께 하기를 바라는 수밖에는 없을 것이다.

중간에 특별한 행운이 없이는 4월까지 도저히 할 수 없다는 것을 인식하고, 그러한 행운을 잡는 것이 프로젝트의 아주 중요한 부분이 되어 버린다. 이는 리스크 관리와는 정확히 상반되는 것으로, 프로젝트 계획의 초점이 만약 행운이 따르지 않는다면 어떻게 할지에 맞추어진다.

개인적인 도전으로 시작된 프로젝트에서는 리스크를 합리적으로 관리하기 어렵다. 대신 행운에 의존하게 된다. 프로젝트가 그런식으로 주어진다면 할 수 있는 일은 많지 않을 것이다. 그러나 미래를 생각하면 배울 것이 없는 것도 아니다. 당신이 프로젝트를 직접 지시할 위치에 올랐을 때, 절대로 운에 의해 지배되도록 프로젝트를 포장하지 말라. 합리적이고 신축적인 목표를 제시하되, 실제 기대치는 행운이 일어나지 않으리라는 것을 고려하여 조금 여유를 두도록 하라


- 7장 운(luck) (77p)

모든 소프트웨어 프로젝트에 공통적인 리스크


여기저기 도처에서 발생하는 문제들이 꽤 있기 때문에, 모든 프로젝트에 대해, 정도는 다르겠지만, 발생하리라 예상되는 20~30개 정도의 문제에 대한 리스트를 만드는 것은 그다지 어려운 일이 아니다. 여기서는 그 중 다섯개만을 선택하여 다루었다. 그 이유는 이들을 통해 현실이 계획을 벗어나는 대부분의 상황을 설명할 수 있으며, 또 이 리스크와 업계의 유용한 데이터를 이미 확보하고 있기 때문이다. 핵심 리스크는 다음과 같다.

1. 원래 일정의 결함
2. 요구사항의 확대(시간에 따라 요구사항이 조금씩 늘어나는 것)
3. 인원의 교체
4. 설계 명세 붕괴(specification breakdown)
5. 낮은 수행능력(under-performance)

이 중 맨 마지막 것만이 수행능력과 관련된 것이다. 나머지 네 개는 당신이 얼마나 열심히 일하는가, 그리고 얼마나 경쟁력이 있고 능숙한가와는 거의 무관하다. 이를 강조하는 이유는 많은 관리자들이 리스크 관리를 수행능력의 저하에 대한 변명으로 삼기도 한다는 점을 우려하기 때문이다. 리스크 관리의 핵심은 제어불가 항목들에 대해서 합리적인 준비를 하는 것이다.
그런 중비를 통해 실패를 미연에 방지할 수 있다. 다시 말해 앞서 말한 제어불가 항목들이 당신을 문제에 빠뜨리는 경우에 대한 대비책을 마련하도록 해 주는 것이다.

- 중략 -


-  13장 소프트웨어 프로젝트의 핵심리스크 (152p)



 

우리에 대한 농담



우리 IT 사람들이 리스크 수용에 접근하는 방식이 다른 사람들과 다르다는 것에 대한 농담을 만든다면, 아마 이렇지 않을까?

IT 관리자와 보통 사람이 수요일 오후에 시카고에서 일을 하고 있고, 둘다 금요일 정오에 샌프란시스코에서 미팅에 참석해야 하며 시간을 지키는 것이 매우 중요한 것을 안다.
보통 사람은-다이안이라고 하자- 목요일 밤 비행기를 타고 샌프란시스코 사무실에서 한 블록 떨어진 조그만 호텔에 방을 잡는다.
허남이라는 식당에서 한가로이 식사를 하고 영화를 보고 유니온 스트리트 쪽으로 향한다. 다음날 여유 있는 아침식사를 하고 노트북 컴퓨터로 11시까지 작업을 한다.
11시 30분 체크아웃을 하고는 걸어서 10분 일찍 사무실에 도착한다.

반명 IT 관련자인 잭은 금요일 아침 8시 40분 비행기를 예약한다.
미드타운에서 7시 5분에 택시를 잡아타고 아이젠하워의 교통체증 속으로 들어간다. 오하라 공항까지 가는 내내 택시 운전사에게 화가 나서 불만을 토로한다.
멍청한 택시 운전사는 잭이 이 비행기를 타는 일이 얼마나 중요한지 이해하지 못하는 것 같다.
유나이티드 에어에 체크인을 하면서 직원에게 비행기가 정시에 출발해야 하고 변명은 통하지 않는다고 이야기한다.
그녀에게 어떤 이유로 인한 지연도 '매우, 매우 실망스러울 것'이라고 말한다. 탑승이 지연될 것이라는 말에 펄쩍 뛰며 반발한다.
조정된 시간이 방송되는 순간 그가 가지고 있는 관리도구들을 뒤져서 최후의 통첩을 전달한다.
"만약 내가 12시 미팅에 참석할 수 있도록 당신들이 샌프란시스코에 제때 데려다 주지 않는다면, 모자기자 날아갈 줄 아시오"


납기일자가 중요한 프로젝트는 일찍 시작하는 것이 진정한 리스크 완화다.
이는 아마도 거의 모든 프로젝트에서 지연이라는 리스크를 수용하는 가장 효과적인 방법일 것이다.
좋다. 프로젝트를 일찍 시작하기에는 너무 늦었다는 것을 알고 있다. 시작할 때 시작을 했고 이미 곤경에 빠져 있는 것이다. 그리고 어떻게 하면 곤경에 빠져 들지 않을 수 있었나를 알기 위해 이 책을 읽고 있지는 않을 것이다. 어떻게 하면 무사히 빠져 나올 수 있을지 알고 싶은 것이다. 모두 맞는 말이다. 그러나 아래에서 설명하는 것처럼 일찍 시작하는 선택은 어쨌든 가치 있는 일이다.

- 중략 -

- 17장 궁극적인 리스크 완화 전략(202p)

  소프트웨어 프로젝트에서의 리스크 관리  톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.