고객이 가장 큰 리스크다

  프로젝트 진행에 있어서 고객이 가장 큰 리스크인 이유는 그를 만족시켜야하는 의무가 있기 때문이다. 고객이 만족해야 우리는 보수를 받을 수 있다. 문제는 잘 알고 있듯이 고객이 발주를 내었음에도 불구하고, 그들은 자기의 요구사항을 모른다는 것이다. 다라서 개발팀에게 가장 훌륭한 고객은 요구사항 뿐마 아니라 SI 의 전반적인 것에 잘 알고 있어서 개발자와의 의사소통이 원할하고, 기술적 제약에 대해 충분히 이해해 주는 것이다.

 

  그 다음으로 개발팀이 도움이 되는 고객은 전혀 모르는 고객이다. 이 경우 보통 고객은 개발팀을 매우 신뢰하고 전문가 집단으로 대우한다. 알아서 '잘' 해주기를 바란다. 물론 프로젝트가 진행될수록 고객도 지식이 생겨서 더 많은 것을 요구하는 위험이 있긴하다.

 

 가장 문제가 되는 고객은 아이러니 하게도 해당 업무나 SI 기술에 대해 어설픈 지식을 갖고 있는 고객이다. 이들의 대체적인 특징은 본인도 전문가라고 생각하고 있기 때문에 처음부터 개발팀을 의심한다. 그래서 사사건건 진행에 간섭을 하고 별로 도움도 되지않는 괜한 절차를 만들어낸다. 개발팀의 스트레스 지수는 가파른 기울기를 그리면서 올라가기 마련이다. 더욱이 어떤 결정이 처음 개발팀이 제시된 안으로 다시 되돌아 오게 되면, 그 개발팀의 사기는 더이상 기대하기 어렵다.

 

 

  따라서 사실 고객이 SI 프로젝트를 시작하기 전에 관련 지식으로 무장하는 것이 매우 중요하긴 하지만, 올바른 지식과 경험이 쌓이기 전에는 개발팀에 깊은 영향을 주는 것은 오히려 프로젝트에 이롭지 못하다.

PM 역시 이런 경우 초반에 반드시 해결하고 가야한다. 내가 썼던 방법은 그 고객보다 더 확실한 지식및 기술 우위에 서서 대하는 것이다. 고객이 제시한 방법이 잘 못 되었다는 것을 근거있는 자료로써 대응하여야 한다. 프로젝트 진행이 조금 지연된다고 해도 반드시 고객을 설득시키고 가는 것이 이후에 훨씬 안정된 수행을 할 수 있을 것이다.

 

  가장 큰 리스크는 앞서 말한 적당히 아는 고객 즉, 선무당 고객이 어디서 주워듣고는 프로젝트 시작 전에 고려되지 않았던 기술이나 솔루션 또는 방법론을 제시하여 변경을 유도하는 것이다. 이는 너무나도 위험하여 절대 수용해서는 안된다.

 

  과거 수행했던 프로젝트 사례인데, 수행사가 제안한 솔루션을 못 믿겠다는 이유로 솔루션 하나가 변경되었고 생산성을 높이자는 이유로 X-internet Tool 를 신제품으로 선정했다. - 공교롭게 이 제품의 추천은 PMO가 하였고 사용하기를 강력 주장하였다 - 전자의 솔루션의 경우는 고객의 간단한 요구조건 조차 변경할 수 없는 경우가 많았으며, 후자의 경우 웹접근성과 여러가지 기능이 제공되지 않아 수행팀에서 반대를 했음에도 고객의 강력한 요구로 도입하여, 기능구현에 상당한 어려움을 겪었고, 사업이 끝나고도 한동안 유지보수에 개발인력들이 고생하였다.