과업의 범위 / 과업의 변경

요즘 건설업계는 재료비와 인건비의 상승으로 원 계약금액을 초과하는 공사비로 공사를 중단하고 시행사와 공사비 협상에 들어가는 일이 자주 발생하고 있다.

정보기술(IT) 업계도 정부를 상대로 소송을 제기하고 있다. LG CNS 컨소시엄과 CJ올리브네트웍스-KCC정보통신 컨소시엄이 각각 복지부와 국방부를 상대로 소송을 벌이고 있다. 이유는 과업의 변경으로 발생한 추가 대가를 받지 못하였기 때문이다.

최근 수백억에 달하는 OO공사 프로젝트의 오픈이 지연되면서 수행사가 걷잡을수 없는 손해를 감당하게되었고, 프로젝트을 처음부터 영업하던 상무가 부담감을 견디지 못하고 극단적인 선택을 한 사건이 발생하여 관련업계가 충격에 빠진 일이 있었다.

K국은 과업의 변경(요구사항 및 설계의 추가 & 변경)을 통상 발주자의 당연한 권리로 생각하며, 그로 인해 발생하는 비용은 수행사가 알아서 할 문제라고 간주하곤 한다.

미국의 개발업체들은 요구사항 이나 설계의 변경사항에 대핸 변경내용을 문서화하여 비용을 산정하고 상호가 결재를 한 다음에 작업에 반영한다. K국의 담당자들은 이런 조치에 대해 "누가 갑인지 모르겠네" 하는 반응을 하는 것을 본 적 있다. 갑이 되면 맘대로 할수 있다는 발상이
뿌리깊게 자리잡혀 있다.

발주자는 사업자 선정 전 제안요청서(RFP)를 통해 과업을 제시하고 이를 기반으로 기능점수(FP) 등을 산정해 사업 금액을 정한다.
문제는 소프트웨어(SW) 개발 사업은 사업자 선정 후 협의단계에서 RFP 안에 담긴 과업이 구체화되며 초기 RFP 내용의 변경되는 일이 많고 사업 수행 중/ 코딩 완료후도 설계가 변경되는 일이 자주 발생한다는 점이다.

분석설계가 완료되고 나서 기능점수를 재 산정하여 비용을 재산정해야 하며, 과업이 변경되면 비용도 그에 따라 조정되는 것이 합리적이다. 예를 들어 식당에서 메뉴를 추가하거나 변경하면 고객들은 그에 대한 비용이 추가되는 것을 알고 주문한다.

또 하나의 문제는 개발업체는 소프트웨어 개발을 개발자에게 맡겨놓고 일정에 대한 압박을 할 뿐이며, 개발 공정의 최적화와 자동화 같은 공정관리에 그다지 관심과 투자가 없다는 점이다. 제조업체의 경우 각 단위 공정의 생산성과 품질 개선에  많은 예산과 노력을 투입한다. 이렇게 하면 몇초가 단축될까 저렇게 하면 B라는 문제가 개선이 될까? 하고 지속적으로 생산인력과 소통하며 연구 개발하는 팀이 공장에 상주한다. 단위 공정에서 10%의 생산성만 향상되어도 전체적으로 보면 많은 비용이 절감된다.

최근 SI현장은 PMO, AA, DBA, 공통팀,기획,디자인,퍼플리싱팀 등이 프로젝트에 대한 베이스를 만들어 업무 개발팀의 부담을 많이 줄여주는 형태로 상당한 발전을 한것으로 보인다. 그러나 아직도 SI개발 현장은 노가다판 건설현장과  크게 다르지 않은 느낌이다.

코드생성AI의 등장은 노가다 개발자들에게 복음이 될수 있을것인가 ?