반응형

대사시스템을 가장한 정산시스템

진화하는 요구사항

 

프로젝트란 무엇일까?

고객의 요구사항을 듣고 이를 처리하기 위한 시스템/기능을 만드는 것이다.

요구사항은 실제 업무를 담당하는 현업의 needs에 의해 시작된다.

 

진화하는 요구사항

 

프로젝트의 핵심은

수작업으로 하던 대사/정산업무를 시스템화하는 것이다.

제휴사에서 수행한 할인행사의 당사분담금을 지급하는 것이 주업무다.

 

현재는

제휴사에서 시행한 행사정보를 보내주면

해당 건이 맞는지 매출정보를 확인하고, 이를 지급하고 있었다.

 

이 때, 몇가지 문제점이 있었다.

첫번째는 매출은 확인했으나 할인금액이 정확한지 여부이다.

쿠폰, 현장할인, 마일리지, 타사제휴 등

워낙 다양한 형태의 결제수단이 존재하기에 검증이 쉽지 않다.

더욱이 목록이 한두 건이랴... 많으면 80만건도 된다 한다.

 

그래서 매출 정보를 확인하여

정상 메출이고 한도만 넘지 않으면 지급하는 형태였다.

* 이중지급방지 등 일부 추가적인 검증은 하고 있었다.

 

프로젝트의 요구사항으로는

매출정보의 정상여부를 확인하고

판매금액, 할인금액, 당사분담금 등을 계약기준에 맞춰 산출하고

이를 제휴사에서 받은 자료와 매핑하는 것이다.

일치하는 정보는 지급하고, 미일치 정보는 지급대상에서 제외되는 것이다.

 

어느정도 진행되면서, 기능이 구현되고 화면이 개발되었다.

원래 눈에 보이기 시작하면서부터가 프로젝트의 시작이다.

화면이 눈에 보이고 조작이 가능하면서 요구사항은 늘어났다.

 

우선 UI/UX의 개선사항이 있었고,

표시되는 정보 항목의 다양화가 두번째였다.

그리고 서있으면 앉고싶고, 앉으면 눕고 싶은 법.

기본 대사검증이 되니 추가적인 검증을 원했다.

이때부터 프로젝트는 폭풍속을 헤쳐 나가야 했다.

 

여러 제휴사와 행사가 있다보니

제휴사마다 적용되는 기준이 다양했고, 제공해 주는 자료도 가지각색이었다.

당사의 기준만으로는 검증이 불가능한 것들이 있었고

이를 검증하기 위해 차선책과 그에 따른 대비책 그리고 보완책 등

요건이 꼬리에 꼬리를 물며 늘어났다.

수기작업처럼 안하면 모를까... 하려고 하니 끝이 없었다.

제휴사의 정보를 일부 차용하여 계산하고, 이를 다시 재검증하고

완벽한 검증이 되지 않아, 당사 계산금보다 적으면 인정하고

경우에 따라 담당자가 선택하여 당사와 제휴사중 적은 금액을 지급하는 등

세부 요건들이 넘쳐났다.

 

첫 시작은

현업해서 하고 있는 업무를 전산화하는 것이었고

두번째는 사람이 인력으로 하기 어려운 대량데이터의 단순반복작업들 전산화하는 것이었다.

그런데 현재도 못하는 것을 하려고 하면서 너무 힘들어졌다.

프로젝트를 진행하는 현업의 강력한 요구사항이었기에 안할수도 없었다.

 

어찌어찌 정리하며 하나씩 하나씩 처리해 나갔지만

앉으면 눕고 싶은 법.

꼬리를 무는 요구사항과 디테일한 부분의 개선사항까지

개발기간이 끝나고 통합테스트 단계에 들어갔지만

오류/개선이라는 명목하에 요구사항은 계속되고 있다.

전사의 보도. 원래/당연히/기본적으로...

제안 내용도 모르고, 범주도 명확치 않고

계약한 수행사는 나몰라라.. '필요한 거면 어쩔수 없잖아요.'

 

이런 고생이 당연하지  않다는 걸 알아주면 좋겠고,

프로젝트가 잘 끝나서 고생많았고, 고맙다는 얘기를 들을 수 있었으면 좋겠다.

 

끝.

반응형