본문 바로가기

책 이야기

소프트웨어 프로젝트에서의 리스크관리 - 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) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.