요구사항 정의는 고객이 하는 것이다

  프로젝트 수행 중 가장 큰 리스크 중에 하나가 바로 고객이다. 이유나 원인은 여러가지가 있겠지만 그 중 가장 큰 것은 고객 자신이 발주를 냈음에도 정작 본인들이 무엇을 원하는지 모른다는 것이다. 즉 요구사항이 불분명하다. 해서 자주 그 요구사항이 바뀐다. 그것도 끝날 때 까지.

이는 개발에 대한 방법론만 강조하고 중요시 했지 정작 고객이 발주를 내기위한 방법론이나 가이드가  전혀 없어서 일어나는 현상이다. 그나마 한다는 것이 ISP 이다. 일반적인 비즈니스가 통용되는 민수기업의 경우는 모르겠지만, 공공기관은 대한민국에 딱 하나밖에 없는 경우(어떤 것은 전세계에 하나밖에 없다)가 대부분이다.

 

  그런데도 뻔뻔스럽게 대부분의 ISP 업체는 일반적인 비지니스 프로세스의 템플릿을 갖고 ISP 를 수행한다. 따라서 개발자 입장에서 보면 그 ISP 보고서는 거의 쓰레기인 경우가 다반사다. 시간과 비용을 낭비한 셈이다. 

따라서 뜬구름 잡는 ISP 보다는 목적하는 시스템에 대한 각 분야 전문가로 팀을 구성해 컨설팅을 받는 것이 낫다. 그 결과로 요구사항만이라도 정확히 정의된다면 더할 나위 없겠다. 요구사항이 정확히 정의되면 Function Point 가 어느정도 신뢰성 있게 도출되고, 그렇게 되면 예산과 투입인력, 기간이 산출되기 때문이다. 프로젝트의 위험이 확 줄어드는 순간이 될 것이다.

 

 

  결론부터 말하자면, 발주낸 시스템의 임자는 고객이다. 개발업체는 어떻게든 끝내고 돈받고 철수하면 땡이다. 이후 잘 써야하는 주체는 고객인 것이다. 이 당연한 얘기를 왜하냐고?

요구사항은 고객의 몫이라는 것을 까먹기 때문이다. 개발자가 요구사항을 정의하는 것이 아니라, 요구사항에 한해서는 개발자는 고객의 그것을 듣고 그냥 문서화 할 뿐이다. 많은 고객들이 이런 것에 대해 개발업체를 닥달하면 될 것이라고 착각한다.

생각해 보자. 사용자의 요구가 명확하지 않는데 어떻게 완성품을 받아 볼 수 있는가? 엄청난 돈을 주고 만족 못하는(제 값 못하는), 그냥 만들어 주는 대로 받아서 쓰는 수 밖에 없지 않는가?

 

  얼마전 수행한 대전의 모 기관의 경우, RFP 에 개발내용을 이상하게 표현하는 데만 급급했지, 정작 자기들이 무엇을 원하는 지 모르는 세부과업이 대부분이었다. 따라서 개발기간중 무늬만 개발이지 앞서 말한 성격의 컨설팅을 요구사항 기간에 요구했다. 또는 해당 시스템에 대한 이해를 시키기 위한 교육을 실시해야 했다.

그리고 고객의 각담당자들은 각자 담당한 시스템의 명확한 개념이 없어서, 처음부터 개발된 다음 그 것을 보고 잔소리를 할 생각이었다. 그게 그들 나름대로 갖고 있는 복안이라는 것이었다.

하지만 결과는 비참했다. 그 많은 시스템에 대해 자기들의 머리속을 헤집고 들어가서, 속 시원히 해결해 줄 수퍼맨은 없었기 때문이다. 즉, 기획단계부터 멍청한 짓을 하는 바람에 프로젝트에 참여한 그 많은 인원이 모두 멍청이가 된 프로젝트였다.

 

  발주를 내기전 내부적으로 이해당사자들이 모여 요구사항을 명확히 하여 발주를 내야한다. 담당 부처 심지어 정보화기관도 이런 근본적인 문제에 대해서는 아예 생각도 안하고 있는 것 같다.