기능변경은 곧 위험이다

  고객은 개발 중 기능변경은 쉽게 이루어 질 수 있다고 생각하는 경우가 많다. CBD 등 여러 방법론을 어설프게 알고있는 경우는 그 경향이 더 심해지는 것 같다. 본격적인 개발 중이거나 개발단계가 끝나고 나서 일어나는 변경은 개발팀 입장에서 볼 때 매우 치명적이다. 이런 현상이 발생되는 원인은 여러가지가 있으며, 복합적이다.

 

  우선 고객의 담당자가 이원화되었을 때이다. 공공기간의 경우 실제 사용할 부서가 있지만 보다 확실한 사업수행을 위해서 전산을 담당하는 부서와 같이 진행하거나 아예 주도하는 경우가 많다. 앞의 경우(전산부서가 옵저버인 경우)는 좀 나을 수 있으나 전산부서가 주도하는 후자의 경우, 실 컷 개바랬는데 정작 테스트 단계에서 실제 사용자들의 불만이 터져나오기 일쑤다.

 

  두 번째로 개발하고자 하는 시스템이 전산적인 것일 경우다. 이 때는 반드시 전산담당 조직 또는 어느 특정부서가 맡기는 하지만 워낙 사용자가 많아, 그 모든 요구사항을 이 조직에서 수렴하거나 결정 내리지 못하는 데서 오는 불상사이다.
따라서 시작해서 끝날 때까지 아무리 전직원을 상대로 홍보를 하여도 끊임없이 잡음이 일고, 요구사항 변경이 발생한다.

 

  세 번째로 가장 치명적인 것으로 고객의 담당자 성향이 문제인 경우다. 본인이 직접 언급하고 약속한 것에 대해 책임을 지는 성향이외의 것은 모두 문제가 된다. 사실 공공기관의 프로젝트에서 성공한 중요 원인은 바로 이 담당자의 약속이행이다. 경험상 본인이 결정한 것에 대해 최대한 내부 설득이나 대처를 책임지는 담당자를 만나면 전부 성공하였다.
개발 막바지에 치명적인 변경에 대해 난색을 표명하면, 방법론을 거들먹거리며, 설계가 유연하지 못해서 일어난 수행팀 잘못이라며, 즉시 수정할 것을 요구한다.

하지만 생각해 보자. 다 개발해 놓은 것에 결정적 변경이 가해지면, DB 및 코드의 변경이 일어날 수 있고 이는 그 프로그램의 기본을 흔들어 놓는다. 그리고 그 부분이 다른 모듈에 어떤 영향을 미치는지 고려를 해야하고, 이부분은 자칫 그 개발기간에 발견되지 않으면 최악의 경우 나중에 치명적 오류로 발생하는 복명으로 자리잡을 수도 있다. 그리고 제대로 변경되었는지 다시 모든 테스트를 하고 검증해야한다. 이 모든 것을 하려면 시간이 부족하게된다. 수행팀은 야근이나 휴일근무를 하게 되고, 팀원들은 짜증이 난다. 이때문에 팀워크가 깨질 수도 있다. 또는 적당히 처리함으로써 나중에 통합테스트나 오픈 후에 다시 수정해야 하는 경우를 발생시켜 궁극적으로는 개발기간을 지연시킨다.

 

  마지막으로 이러한 여러가지 원인이 복합적으로 섞여있는 경우다. 이에대한 해결책은 여러가지가 있을 수 있지만
가장 확실한 한 가지 방법이 있다. 단 그 실행이 어려울 수 있다. 사실 다르게 생각하면 무척 쉬울 수도 있다. 그리고 또 그렇게 해야한다고 생각한다. 

그 방법은 이런 아규가 생겼을 때, 그 기관의 장이 주관하여 회의를 하는 것이다. 2인자(표현이 옳은 지는 모르겠으나 국장, 사무총장 등을 말함)가 주관해도 어느정도 효과가 있지만, 기관장이 참석하는 것만큼은 아니다. 사실 엄청난 세금을 드려 개발을 하는데, 단지 착수나 종료보고시에만 형식적으로 참석하는 것은 문제가 있다. 그리고 보통 개발되는 정보시스템이 그 기관의 핵심 업무를 전산화하는 것인데 기관장이 당연히 개발 진행에 관심을 가져야 하는 것이다. 만약 기관장이 어떤 이슈에 대해 같이 논의를 하게 되면,

첫 번째 원인이 부서끼리의 조율을 쉽게 이끌어 낼 수 있다.
두 번째 원인의 경우 어느 시점에서 합의점을 찾는데 결정저인 역할을 할 것이다.
세 번째 원인의 경우 기관장이 함께한 결정이므로 부담을 조금이나마 벗어날 수 있을 것이다.

 

 

  전에 수행했던 프로젝트를 예를 들어 보자. 사업비는 100억이 넘어가는 상당한 금액이었고, 기관업무 프로그램을 비롯하여 ERP, 포털, EDMS, 그룹웨어 등 전사 시스템이 대부분인 사업이었다. 그런데 실제 사용자인 현업은 요구사항단계 부터 별로 참여가 없었으며, 전산 조직이 그 모든 것을 대행하였다. - 몇 명 안되는 전산조직으로 이 사업을 수행하기엔 역부족이었다. 이런 조건에서 참으로 신기한 현상이 발생했다.

첫 째, 실제로 사용할 현업의 인력들은 전산팀에서 개발되어 나오는 것을 곱지않은 시선으로 벼르고 있었다.
둘 째, 주업무시스템은 순수 개발이었으며 그 규모가 가장 컸다. 전산팀의 담당자는 요구사항 수렴후, 설계단계, 개발단계, 테스트단계 등 매 단계마다 현업의 확인을 받았다. 전사를 대상으로 교육도 4차례나 실시하였다.

  그러나 막상 오픈하여 실제 사용하게 되자 현업부서들은 들고 일어났다. 사용하기 불편하거나 잘 모르겠다는 것이 그 이유였다. 수행조직과 현업사이에 낀 전산팀은 어찌할 바를 모르고 있다가, 마침 치명적 오류가 발생하자 그 것을 꼬투리로 수행팀에게 전면 수정을 요구했다. 별로 유쾌하지 못한 프로젝트로 자리매김하는 순간이었다.