내포된 위험을 전혀 혹은 거의 모르고 있는 프로젝트 시작 초기
노련한 프로젝트 관리자라면 마치 상처의 고름을 짜내듯
문제를 미연에 파헤치는 시도가 필요하다.
노련한 프로젝트 관리자라면 마치 상처의 고름을 짜내듯
문제를 미연에 파헤치는 시도가 필요하다.
나는 아직 그러한 능숙함을 갖추지는 못했지만
적어도 이를 관찰할 수 있는 역량을 갖추게 된 것은 다행스런 일이다.
적어도 이를 관찰할 수 있는 역량을 갖추게 된 것은 다행스런 일이다.
RUP를 보면 프로젝트 관리자는 위험요소 목록(Risk List)을
도입단계(Inception Phase)부터 생성하고 관리하라고 한다.
보다 구체적으로는 비전문(Vision)으로부터 바로 위험을 식별하고 확인하라 한다.
즉, 사업 계획서(Business Case) 작성 과정에서 이미 만들어져야 하는 것이다.
어찌 보면 당연한 이야기다.
프로젝트를 실패로 끌고 갈 수 있는 위험을 조기에 파악하여
위험 관리 계획(Risk Management Plan)을 세우라는 것은
문자 그대로만 보면 너무나도 당연한 말이다.
그러나, 문제는 생각처럼 쉽게 그 모습을 드러내지 않는다.
명확해보이는 문제들은 누구나 이를 알고 있기 때문에
설사 프로젝트에 미치는 영향력이 지대하다고 하더라도 덜 위험하다.
정말 문제가 되는 위험요소들은 쉽게 눈에 띄지 않는 것들이다.
삼국지류의 책들을 보면 대패하는 경우는 뜻하지 않았던 습격에 당하는 경우가 많다.
너무나 당연하게 수행되어지리라고 믿었던 일들이 되지 않을 때
이를 보정할 수 있을 시점이 훨씬 지나서 문제를 알게 된다면
경우에 따라서는 그간의 산출물이 모두 무용해질 수 있다.
삼국지류의 책들을 보면 대패하는 경우는 뜻하지 않았던 습격에 당하는 경우가 많다.
너무나 당연하게 수행되어지리라고 믿었던 일들이 되지 않을 때
이를 보정할 수 있을 시점이 훨씬 지나서 문제를 알게 된다면
경우에 따라서는 그간의 산출물이 모두 무용해질 수 있다.
예를 들어 요구사항의 원천인 고객과 분석가가 서로 다른 인식을 갖고 있다고 하자.
또한, 고객 입장에서는 아직 결정되지 않은 요소가 너무 많아서
분석가에게 충분한 흐름을 제시할 수 없어 분석가가 나름대로 시나리오를 도출한다.
언제 결정될지 모르는 사항을 무작정 기다리는 것은 위험하기 때문에
분석가가 나름의 시나리오를 기술하여 고객에게 의견을 제시하는 것은
결정을 빠르게 할 수 있기 때문이다.
이때, 고객이 요구사항의 기술 방식 예를 들어, 액티비티 다이어그램이나
기본 흐름과 대안 흐름을 시나리오 기술 방식으로 작성하는 것들을 보는데
익숙하지 않아서 내용 파악을 어려워한다거나
요구사항 관리 도구로 사용되는 특정 툴 사용이 서툴러서
검토를 꺼리거나 제대로 수행할 수 없다고 하자.
기본 흐름과 대안 흐름을 시나리오 기술 방식으로 작성하는 것들을 보는데
익숙하지 않아서 내용 파악을 어려워한다거나
요구사항 관리 도구로 사용되는 특정 툴 사용이 서툴러서
검토를 꺼리거나 제대로 수행할 수 없다고 하자.
고객은 요구사항 정의 내역을 검토해야 하는 것을 알지만
위와 같은 문제로 검토를 차일피일 미루고 또한 본연의 업무가 있기 때문에
요구사항에 대한 검증을 이뤄지지 않은채 시간을 계속 흘러간다.
이보다 더 심한 문제는 고객이 마치 검토를 충분히 한 것처럼 인지될 때이다.
위와 같은 문제로 검토를 차일피일 미루고 또한 본연의 업무가 있기 때문에
요구사항에 대한 검증을 이뤄지지 않은채 시간을 계속 흘러간다.
이보다 더 심한 문제는 고객이 마치 검토를 충분히 한 것처럼 인지될 때이다.
사실 이런 문제는 모든 프로젝트가 갖고 있는 가장 큰 위험요소 중에 하나이다.
다만, 이렇게 명백해 보이는 문제마저 실제 프로젝트에서는 다양한 양상으로
벌어지기 때문에 이를 잡아내서 의사소통 경로나 방식의 문제를 해결하는 것은
그렇게 장담할만한 문제는 아니다.
다만, 이렇게 명백해 보이는 문제마저 실제 프로젝트에서는 다양한 양상으로
벌어지기 때문에 이를 잡아내서 의사소통 경로나 방식의 문제를 해결하는 것은
그렇게 장담할만한 문제는 아니다.
그럼 어떻게 하느냐?
라고 묻는다면 뾰족한 수는 없다. 이러한 문제는 어느 정도의 경험도 필요하지만
경험만 갖고 있다고 인식할 수 있는 요소는 아니다.
공학적 마인드, 경험 그리고 통찰력 등을 두루 갖추고 노력할 때에만 가능하다고 해야하나.
경험만 갖고 있다고 인식할 수 있는 요소는 아니다.
공학적 마인드, 경험 그리고 통찰력 등을 두루 갖추고 노력할 때에만 가능하다고 해야하나.
그렇다고 하더라도 지침이 되는 것이 있다면
적어도 내가 경험만 모든 프로젝트에서 가장 큰 문제는 의사소통 경로나 방식에서 나왔고
초기에 의사소통을 원활히 할 수 있는 환경을 만들어내는 일
그렇게 하기 위해서 프로젝트에 영향력이 큰 인물을 찾아내고
그 힘을 적절히 활용하고, 주요 실무자들을 확실한 우군(?)으로 만드는 일
정보가 물흐르듯 소통할 수 있게 하는 일들이 너무나 중요하다.
초기에 의사소통을 원활히 할 수 있는 환경을 만들어내는 일
그렇게 하기 위해서 프로젝트에 영향력이 큰 인물을 찾아내고
그 힘을 적절히 활용하고, 주요 실무자들을 확실한 우군(?)으로 만드는 일
정보가 물흐르듯 소통할 수 있게 하는 일들이 너무나 중요하다.
예전에 PM만 8년 하셨다는 분이
프로젝트는 '정치'라고 단언하셨던 말이 떠오른다.
* Younghoe.info v1(엠파스 블로그)에 2005-04-29 09:25에 작성했던 글입니다.
