전개단계 요구사항 변경관리

  프로젝트를 진행하다 보면 매번 소홀히 하는 것이 있다. 그 중 하나가 메뉴얼 작업이다. 메뉴얼 작업이 소홀한 이유는 크게 두 가지로 생각된다.

첫 째, 글재주도 없고 작성 가이드가 너무나 개발자 위주이다. 작성 가이드가 얼마나 형편 없는가 하면 화면설계서에서 항목을 조그만 바꾸면 사용자 메뉴얼이 된다. 이렇게 하지 않고 무언가 그래도 마지막으로 작품(?)을 남기고 싶어서
일반적인 형태의 크라운판 메뉴얼을 만든다고 해도 실제 사용자는 알아보기 힘들게 만들어진다. 아무리 알기 쉽게 쓴다고 해도 그것은 작성자 기준이다 보니 생기는 현상이다. 그러니 설령 소홀히 하지 않았다고 해도 보는 사람은 대충 만들었다고 느낄 수밖에 없을 것이다.

 

둘 째, 대부분의 개발이 끝난 끝물에 작업하기 때문이다. 보통  SI 프로젝트는 엄청 힘이 든다. 야근도 엄청 해대고, 고객과 갈등도 심하고, 그렇게 해서 겨우 끝이 보여 힘들게 개발을 어느 정도 마무리 짓게 되면 힘이 빠지게 된다. 메뉴얼을 작성할 염두가 쉽게 나지 않게 되는 것이다. 따라서 변명처럼 들릴지 모르나 자기도 모르게 대충 만들게 뙨다.  

 

프로젝트 작업 중 매번 소홀해 지는 나머지 하나는 안정화 기간에 일어나는 작업에 대한 변경관리이다. 사실 메뉴얼 작업은 어찌 보면 크게 중요하지 않을 수 있다. 본래 잘 만든 프로그램은 메뉴얼 없이 사용자가 사용할 수 있어야 한다.
웹 프로그램이라는 게 그렇지 않는가. 하지만 시스템을 오픈하고 나서 필드에서 사용자의 의해 터져 나오는 오류나 개선요구는 다르다. 이 부분은 소홀히 하면 잘 만들고도 매우 큰 사건이 터질 수 있는 중요한 작업이다. 사소한 변경 내용으로 판단하여 적당히 그 부분만 변경 했는데, 그 것이 다른 백단의 업무에 영향을 미치기도 하기 때문에 그 변경에 다른 파급 효과를 반드시 검토하여야 한다. 

 

  그리고 안정화 기간 중에는 전체 개발자가 남아 있는 것이 아니라서, 자기 주관대로 변경을 할 수도 있고, 또 앞서 얘기한 것처럼 큰 맥락의 개발이 끝나서 지쳐있는 관계로 산출물의 수정 없이 직접 소스만 변경하는 일이 적지 않게 일어나기도 한다. 따라서 개발하고 나서 1년은커녕 오픈 후부터 산출물 현행화에 문제가 발생하는 것이다. 이런 부분에 대한 방지책은 각종 변경 사항에 대한 처리를 문서로 주고받는 것이다. 이 문서 이름을 여러 가지로 정해서 쓰고 있는데, 나는 '요구사항변경관리대장' 이라고 칭했으면 한다. 이유는 고객도 변경사항 요청시 '아! 이게 요구사항을 변경 시키는 구나!'라고 느끼게 하여 조금이라도 생각(?)하게 만들 수 있다고 보기 때문이다. 일반적으론 고상하게 WOL(Work Order List) 이라고 부르면 될 것 같다. 고객이 먼저 이 문서로 요청을 보내든가 아니면, 유선 또는 구두로 얘기하면 작업자가 듣고 이 시트에 기록을 하면서 관리가 시작된다. 거기엔 요청 내용과 처리방안, 완료예정일, 시스템 적용 여부 등을 알 수 있게 항목으로 만들어 놓는다. 그리고 진행현황을 이 시트로 고객에게 전달하고, 고객이 확인(검수) 여부도 이 시트에 기록하게 하는 것이다. 

 

  PM이 최종적으로 이 시트를 보고 후속조치(변경여부 결정, 산출물 반영, 소스배포, 완료여부 확인 등)여부를 체크하면 된다. 만약 철수했다면 안정화 조직중 책임자가 취합을 하여 주기적으로 본사 사업관리에게 보고를 하고 점검을 받도록 하는 것이 좋다. 검수가 끝나고도 마지막 변경이 발생했을 때, 그 변경된 부분에 대해 산출물에 적용을 하지 않는 것은
프로답지 못한 일이며 SI 개발에 있어 마지막 마무리를 하지 않는 마치 큰 일 보고 밑 딱지 않고 나오는 것과 같다고 할 수 있겠다.