메인 컴퓨터의 파워가 돌아가시는 바람에 펜티엄-3 800Mhz짜리 서브 컴퓨터를 사용하고 있다. 256메가바이트의 메모리에서 파이어폭스를 돌릴 수도 없거니와, 메인 컴퓨터에 설치된 각종 소프트웨어를 사용하지 못하고 있으니 차·포 없이 장기 두는 기분이다. 그럼에도 불구하고 포스팅은 계속 돼야 한다.
Part I. 왜?
덴버 국제공항
Part I에서는 리스크 관리가 왜 필요한 지 설명하고 있다. 굳이 이 책을 사서 읽을 정도의 사람에게 리스크 관리의 중요성을 언급하는 게 불필요한 일 같지만, 의외로 느끼는 바가 많다. 덴버 국제공항의 프로젝트 실패는 매우 널리 알려져 있다. 하지만 대부분의 비판이 방법론의 부재 등을 실패 원인으로 꼽는 데 반해, 티모시 리스터와 톰 디마르코는 리스크 관리의 부재를 주요 원인으로 지적한다. CMMI 레벨 5의 업체가 자동 화물 처리 시스템 Automated Baggage Handling System을 개발하더라도 프로젝트가 제때 끝나리란 보장이 있는 것은 아니다. 마이크로소프트가 제품 출시일을 정하면, 사람들은 보통 그 일자에 6개월 정도를 더해버린다. 그만큼 불확실성을 제어하기 힘든 것이 현실이다.
덴버 국제공항의 경우, ABHS가 핵심 경로(크리티컬 패스)에 위치해 있었다. ABHS의 개발이 늦어지면 개항 일자가 연기되는 상황이었다. 그럼에도 불구하고 어떠한 완화 조치도 취해지지 않았다. 트럭이 지날 정도의 크기로 터널을 건설했더라면, 자동 텔레-카트 시스템이 없는 상황에서도 화물을 이동시킬 수 있었을 것이다. 전체 프로젝트 비용에 비하면 그리 크지 않은 비용만 추가 투자했으면 재앙을 피할 수 있었다.
리스크 관리는 개인 성장의 기회를 최대로 만든다.
리스크를 효과적으로 다루지 못하는 기업들은 리스크를 혐오하게 되므로, 리스크를 감수하는 일이 거의 없고, 더욱이 큰 리스크를 감수하는 일은 아예 없다. 새로운 영역에 대한 개척과 같은 일은 거의 혹은 전혀 하지 않는다고 보아도 무방하다. 이는 기업을 위해 매우 불행한 일이며(기껏해야 다른 기업에 인수되기 쉽다), 직원들에게도 마찬가지다. 기업에 새로운 방향 제시가 없다는 것은, 개인의 성장 기회도 없다는 뜻이다.
통상적인 성장 기회조차 주지 못하는 기업을 위해 누가 일하려고 하겠는가? 이로 인해 기업이 모든 사람을 잃지는 않겠지만, 적어도 우수한 인재들은 떠날 것이다.
– 4장. 리스크 관리 사례
Part II. 왜 안돼?
5장. 리스크 관리에 반하는 사례
리스크라는 것을 관리할 수는 있지만, 제거할 수는 없다.
- 최악의 조직은 납득이 가지 않는 예측은 처벌하면서, 결과에 대해서는 처벌하지 않는 조직이다. …… 사람들은 멋진 전망을 내놓는 일이 실제로 완수하는 것보다 중요하다고 생각하게 되고, 그대로 행동할 것이다.
관리가 불필요한 리스크의 조건
- 무시해도 좋을 만큼 현실화 가능성이 낮다. (O)
- 만일 현실화되더라도, 여러분이 관리하는 결과(당신이 만들고 있는 소프트웨어)와는 무관하다. (O)
- 리스크가 아주 미미한 결과를 가져오고, 완화 조치가 필요하지 않다. (O)
- 타인의 리스크이다. (O)
- 그것이 현실화된다해도, 달리 대처할 수 있는 방법이 없다. (X)
Part II. 어떻게?
극소-확률 일자 (Nano-Percent Date)
지금까지는 N(여기서는 June 17)을 납기일로 취급하는 우를 범해 왔다는 것이 문제이며, 이런 관행은 잘못된 것이다. 소프트웨어 산업 전체를 보면, 불확정 구간의 크기는 N의 약 150%~200% 정도다.
리스크에 대한 대응방법
리스크 목록을 작성했다. 그 다음은?
- 리스크를 회피한다. 즉, 프로젝트를 그만두거나, 리스크를 수반하는 프로젝트의 일부분을 하지 않는 것이다. 그와 동시에 잠재적인 이익도 놓친다.
- 리스크를 수용한다.
- 리스크를 완화한다.
- 리스크를 모면한다. 운에 맡긴다. 12개의 리스크가 있고, 각각의 발생 활률이 단 10%에 불과하다. 그래도 하나 이상의 리스크가 발생할 확률은 75%나 된다.
리스크 수용
리스크 노출 비용 = 비용 X 확률, 이 평가 방법이 과학적으로 잘 정의된 것은 아닐지라도 측정 기준을 갖는 것이 그렇지 못한 것보다 낫다.
쇼 스탑퍼(showstopper): 쇼 스탑퍼가 발생하면 프로젝트 자체가 무너진다. 이것은 다른 종류의 리스크와는 다르게 취급해야 한다. 다시 말해, 일을 계속하기 위해서는 쇼 스탑퍼는 일어나지 않을 것이라고 가정해야 한다. 이 가정이 틀렸다면 그 이슈를 상위 관리자 쪽으로 전달해야 한다.
쇼 스탑퍼의 예: 특정 데이터베이스 제품을 타겟으로 하고 있다. 그런데 만약 타겟인 데이터베이스의 벤더가 하루 아침에 사라져 버리면 어떻게 될까?
리스크 예비비: 합리적인 수용 전략은 노출비용과 같은 양을 예비비로 할당하는 것이다.
리스크 완화비: 덴버공항의 사례를 다시 살펴보자. ABHS 시스템 개발이 늦어질 때를 대비해서 터널을 추가 건설할 수도 있다. 만약 리스크(개발 지연)이 발생하지 않는다면, 터널에 투자한 돈을 절감할 수 없다.
Part III의 나머지 내용
어쩌면 이 책에서 가장 흥미로운 내용을 담고 있을지도 모른다. 리스크 계량화 모델을 제시할 뿐만 아니라, 저자들이 제공하는 자동화 도구의 활용 방법을 알려준다. 또한 점증주의(나선형 모델과 같은) 접근방법을 채택하여 불확실성에 적극적으로 대처하라고 조언하고 있다. 이와 유사한 논조의 글은 쉽게 찾아볼 수 있는데, 프로젝트 관리자의 입장에서 읽어볼만한 책으로 스티브 맥코넬의 소프트웨어 프로젝트 생존전략 등이 있다.
제약조건이론 TOC와 이 책은 모두 프로젝트의 불확실성 때문에 프로젝트 일정도 불확실하다고 말한다. 그러나 일정 추정 방법은 다르다. TOC는 프로젝트 구성원 각자가 일정 예측을 제대로 한다고 생각한다. 다만 각자의 실패 경험 등에 따라 최악의 경우를 산정한다는 것이다. 때문에 완료 예상률이 50%인 곳을 일정 완료 지점으로 삼고, 25%를 프로젝트 버퍼에 놓는다. 불확실성 또는 리스크가 실제로 발생하더라도 버퍼에 수용될 것이라고 본다. (의문은 50%, 25%의 값이 어떻게 나왔냐는 것이다.)
이 책의 저자는 실제 측정 데이터에 바탕을 두고 시뮬레이션해야 한다고 말한다. 문제는 측정 데이터가 전무하다시피 한 조직(아마도 대부분의 조직)의 경우이다. 그래서 저자들이 제공하는 시뮬레이터 Riskology에 기본값이 세팅되어 있다. TOC의 방법과 Riskology가 유사한 값을 산출해내면 문제 없겠지만, 만약 그 값이 완전히 다르다면 어떻게 해야 할까? 개인적인 생각엔 TOC 방법에 따라야 한다. Riskology는 미국 업계의 평균값을 제시할 것이다. 프로젝트 성격에 따라 예측 추정을 달리 해야 할텐데 평균값에 의존하는 것보단 실무자의 경험에 따르는 것이 낫다. 물론 맹목적으로 TOC에 의존해야 한다는 뜻은 아니다. 점증적 구축을 하고 있다면 초기 프로젝트 일정에 포함된 가정을 재검토할 기회가 올 것이다. 각 주기마다 가정의 오류나 변화가 없었는지 점검하는 것이 중요하다.
얼마나
가치 정량화
비용-이익 분석의 이익 분석 측면이 점점 약해지는 반면, 비용 측면에 대한 정밀도와 정확성에 대한 요구는 증가하고 있다.
새로운 시스템을 가져야만 한다.
경쟁력을 갖추기 위해서는 이 시스템이 필요하다.
대단하지 않습니까? 이 시스템 덕분에 우리가 살아날 수 있게 되었습니다.
비용과 이익은 동일한 정밀도로 기술되어야 한다.
죽음의 행진
죽음의 행진의 정당화는 항상 프로젝트의 중요성이라는 미명 아래 이루어진다. … 만약 프로젝트가 그렇게도 중요하다면 제대로 하기 위해서라도 필요한 인원과 돈을 투입해야 하는 것 아닌가?
- 죽음의 행진에 대한 진실은 가치가 너무 낮아서 보통의 비용을 들여 프로젝트를 했다가는 효과보다 더 많은 비용이 들어갈 것이라는 점이다.
- 회사의 이익을 위해 개인의 생활을 희생하도록 호도한다.
- 모든 사람들이 무기력과 분노를 느끼게끔 아무 결과도 내지 못한 채(보통은 평균 이상의 비용이 소요) 항상 대실패로 끝나 버린다는 것이다.
그밖의 읽을거리
- 10장. 리스크 관리 처방
- 23장. 리스크 관리에 대한 테스트
- 부록 A. 믿음의 윤리
용어 정리
- 선택적 근시 selective myopia: 큰 문제들이 눈 앞에 어렴풋이 모습을 드러내더라도 작은 문제들만 본다. 진짜 문제는 외면해버린다. 그러나 리스크는 사라지지 않는다.
- 역구축 counter-implementation, Peter G.W. Keen, Information Systems and Organizational Change: 불만을 품은 이해 당사자들이 점점 더 많은 기능을 요구함으로써 프로젝트에 부담을 주는 상황을 의미한다.
초기에 프로젝트를 반대하던 사람들은 프로젝트에 대한 반대자보다 열광적 지지자로 보이는 것이 편리하다는 것을 깨닫고는 우호 전략으로 선회한다. 과중한 업무 부담을 주어 프로젝트를 망치려는 이들의 의도로 인해 많은 기능이 추가된다.
- Showstopper: 관련된 이벤트를 모두 멈추어 버릴 정도로 주목을 끄는 사건이나 사람
- 후방 일정 계획 backward scheduling: 납기일을 정해 놓고 이로부터 시간을 계산하여 시작일을 정하는 방법
- 일반적 생산성
내가 일반적 생산성이라고 부르는 가상적인 절감의 부류가 있다. 이는
우리가 새로운 데이터 마이닝 시스템을 구축하면 직원 들은 하루에 2분 이상 시간을 절약할 수 있으며, 이를 조직 전체의 연간 절감액으로 환산하면 수억 달러가 될 것이다.
와 같은 형태다. 그런 주장이 전혀 사실무근은 아니다. 그러나 이런 것은 쓸모없는 프로젝트와 그런 것들을 제안하는 컨설턴트들에게 아주 믿음직한 은신처가 되므로, 이런 ‘일반적 생산성’의 효과를 주장하는 경우 신랄한 경멸을 받아 마땅하다. 나는 보통 기껏해야 100분의 1 정도의 가치만을 인정한다.– 18장. 가치 정량화
제약조건이론 TOC의 관점에서 다시 생각해보면, 크리티컬 패스 상의 생산성 절감이 아닌 이상 쓰루풋에 미치는 영향은 없거나 미미하다고 볼 수 있다.
- 사후 대응적 점증주의 프로젝트 관리자가 엉성하게 점증적 구축 방식이라고 주장하면서 서브세트에 대한 선택을 프로그래머들에게 맡겨놓는다. 보통은 공식적으로 점증적 인도 계획을 공표하지 않느다. 버전의 선택은 구축자의 편의에 의해 정해진다.
참고 자료
- STRIDE – Secure Systems Begin With Knowing Your Threats, Part 1
- STRIDE – Secure Systems Begin With Knowing Your Threats, Part 2
