*수주 계약

우리나라에서 생산되는 프로그램들의 가장 큰 문제점을 한마디로 표현하라고 하면 '졸속(拙速)'이란 말이 적당할 것이다.
졸속은 '너무 서두르다가 소용 없게 만드는 것' 이다.
우리나라의 개발 프로젝트 계약은 대개 개발 기간에 투입되는 인력에 용역 단가를 곱한 금액으로 정한다.
그러니, 제안을 할 때에 개발 기간이 무척 중요해진다.
기간이 길면 용역비가 커지고, 기간이 짧으면 용역비가 작아진다.
개발 회사 입장에서야 기간을 늘리면 좋겠지만, 경쟁 회사들이 개발기간을 줄여 낮은 금액을 제시하기 때문에, 개발 기간을 늘리지는 못하고 대체로 줄이는 편이다.
이런 상황들이 지속적으로 반복되다보니 절대로 끝내기 힘든 기간을 개발 기간으로 제시하는 업체들이 많아졌다.
'어떻게든 되겠지'하는 심정으로.
나의 경험으로는 대체로 개발 업체들이 제시하는 기간보다 약 2배에서 3배 정도가 적당한 기간인 것 같다.
계약 기간이 6개월이라면 실제로는 1년이나 1년 6개월 정도를 실제 프로젝트가 끝나는 시점으로 보면 된다.
물론, 납기를 정확히 준수하는 업체들도 있겠지만, 프로그램의 특성상 고객의 요구 사항의 변경이라든가 하는 예외적인 일들이 많아서, 대체로 납기를 지키지 못하는 면이 많다.
이럴 때에 발주 업체에서는 이행지체금이라는 것을 물린다.
그렇기 때문에 개발업체에서는 프로그램의 품질이 떨어지는 한이 있어도 일단 계약기간까지는 프로젝트를 완료한 것처럼 보이려고 한다.
나는 여기서 '완료한 것처럼 보인다'라고 말했다.
실제로 완료하는 것이 아니라, 완료되지도 않았는데 일단 완료한 것처럼 꾸미는 것이다.
매우 비참한 현실이지만 진짜 개발은 그때부터 시작이라고 보면 된다.
대충 만들어 놓은 프로그램을 뜯어 고치는 것이다.
제대로 만들어지지 않았기 때문에 오류가 여기저기서 발견된다.
상부에서는 어떻게 된 거냐며 질책하는 질문을 한다.
개발자들은 밤샘 작업을 해서라도 속히 결과를 보여주려 한다.
이럴수록 프로그램은 땜질 처방이 되고, 결국 그 땜질이 또 다른 문제를 지속적으로 만든다.
대개 이런 식으로 진행되는 프로젝트는 매끈하게 마무리 되지 못한다.
실패하거나 개발 기간이 한 없이 늘어나 개발 업체와 발주처, 양쪽에 모두 손해를 끼친다.
그렇기 때문에 이제라도 개발 기간으로 개발 비용을 산정하는 방식을 버리는 것이 좋다.
예비 분석과 예비 설계를 마친 후에 개발 공수를 산정하여 보고, 그 공수에 따라서 개발 비용을 산정하는 것이 좋을 것이다.
물론 예비 분석과 예비 설계에 따른 비용은 따로 청구하면 될 것이다.
개발 공수는 작업량을 산정하는 기준을 세워 셈하여 보면 될 것이다.
작업량을 산정하는 기준은 코드의 길이가 될 수도 있고, 생산하는 문서의 분량이 될 수도 있고, 예상되는 업무 처리 비용의 절감을 기준으로 삼을 수도 있을 것이다.
이런 형태로 개발 비용을 산정하게 되면, 개발 비용에 맞추어 개발 기간을 정하는 어리석은 행위를 하지 않아도 될 것이다.
개발 공수에 맞추어 개발 비용과 개발 기간을 정하는 합리적인 행위를 할 수 있게 될 것이다.
이렇게 되면 개발자들은, 충분히 확보된 개발 기간 덕분에, 느긋하게 일할 수 있게 된다.
느긋한 개발은 품질 향상을 가져올 것이다.

2010년 07월 18일 19시 22분 40초