이렇게 말하면 실망할지도 모르겠다. 필자는 그간 텍사스 홀덤 포커게임에 대해 운이나 허풍(bluffing)과 같은 것들이 있어야 이길 수 있는 게임이라고 생각해왔다. 한편으로는 IT 프로젝트 관리도 이와 크게 다를 것이 없어 보인다.
하지만 실제로 텍사스 홀덤 게임을 해보면 필요한 스킬이 분명 필요하다는 것을 알게 된다. 그리고 대부분의 상황에 있어서 명백히 옳고 그른 판단 역시 있다. 그리고 소프트웨어 프로젝트도 마찬가지다.
- 시작단계에서는 구체적으로 이용할 만한 정보를 거의 찾을 수 없다. 오로지 희망과 추정만이 가득할 뿐이다. 즉 일반적인 가능성에 근거해서 결정을 내리게 된다.
- 프로젝트 초기에 돌이킬 수 없을 정도로 약속하는 것은 카드 게임에서 카드패가 모두 주어지기도 전에 모든 판돈을 거는 것과 유사하다.
- 상황이 전개되면서 이전에 내렸던 결정은 이후 알려지는 정보로 인해 무효가 되기도 한다. 전체 프로젝트의 일부를 취소하는 등 전략상의 중요한 변화가 필요할 수도 있다.
- 상황에 따라서는, 승리를 위해 계획했던 것보다 더 많은 비용을 써야 할 수도 있다.
- 가장 많은 비용은 프로젝트의 말미에 소요되기 십상이다. 그럼에도 결과물이 그러한 투자만큼 나아질 가능성은 그다지 높지 않다.
- 개인의 고집스러움에는 대가가 따른다. 민첩함과 유연성은 항상 도움이 된다.
상기의 내용은 카드 게임과 소프트웨어 프로젝트 관리 사이의 흥미로운 유사성을 보여준다.
승리에 필요한 것이 무엇인지 알 수 있다고 확신하기
소프트웨어 프로젝트에 있어, 시작 전 자세한 요구사항 관련 문서(a detailed requirements document)를 만들고자 하는 시도가 나타난다. 소프트웨어 제품 개발 프로젝트라면 문제가 없을지도 모른다. 하지만 CRM 소프트웨어나 고객지향 경영 시스템과 같은 현업 프로젝트인 경우 자세한 요구사항 관련문서를 제작한다는 것은 불필요한 일에 그치는 경우가 많다.
왜일까? 요구사항 관련 문서가 충분히 정확할 수 없기 때문이다. 요구사항 작성 과정에 있어 우수한 직원들이 이 업무에 집중하도록 잡아 둘 수 없다. 항상 이러한 문서작성보다 더 중요한 일이 있기 마련이다. 즉 정교하지 못한 추측과 잘못된 우선순위 설정 등 쉽게 확인되지는 않는 괴리가 발생하는 것이다.
이뿐만이 아니다. 요구사항 관련 서적에 근거한 접근방법(the “requirement tome” approach)는 두 가지 가정에 근거한 것인데, 이들 가정은 많은 경우에 있어서 CRM 프로젝트 등에 있어서는 적용하기 어려운 경우가 많다.
첫 번째 가정은 프로젝트 시작 전에 정확히 어떤 것이 필요한지 알 수 있다는 것이다. 두 번째 가정은 프로젝트를 성공적으로 마무리하면 명확화된 요구사항을 달성해낸다는 것이다.
그렇다면 다음에 제시되는 상황이 프로젝트 진행에 있어 나타날 가능성이 어느 정도일지 생각해보자.
- 사용자가 완전히 정확하게 요구사항을 언급했으며 이를 여러분이 오해할 가능성은 없는 상황이다.
- 여러분은 비즈니스 프로세스, 데이터 퀄리티, 시스템 교차적 통합 이슈에 대해 잘 알고 있고 예외상황이 발생할 가능성도 없다.
- 사용자는 프로젝트 전반에 있어 세부사항과 우선순위를 변경하지 않을 것이다.
2014.01.15
David Taber | CIO
_Teamate_20230607.170x220.jpg)
추천기사