부족함이 있어야 더 채워질 수 있다.
대다수의 기업은 전산시스템을 자체적으로 구축하지 않고, 개발 전문기업을 통해 시스템을 구축한다. 이후 구축된 인프라 환경에서 내부 직원을 활용해 유지보수 및 개선과 같은 운영 업무를 수행한다.
(물론 시스템 개발 전문기업들은 그렇지 않을 수 있다.)
대규모 시스템 구축 사업을 수행하는 경우에는 사업비가 큰 만큼 참여하는 회사 또한 기술력이 검증된 사업자를 선정하여 진행하게 된다. 이런 대규모 SI(System Integration, IT 시스템 개발 요소를 통합해 발주사가 요구하는 기능을 수행하도록 구축) 사업은 사업 규모와 사업비 만큼이나 표준화되고 정형화된 관리 프로세스에 의해 체계적으로 관리되며, 그에 따라 리스크 식별과 통제도 철저하게 이루어진다.
하지만 대형 사업만이 항상 추진되는 것은 아니다.
예를 들어, 회사 내 법인카드를 체계적으로 관리하고 정산하는 시스템을 도입하는 경우와 같이 비교적 범위가 좁은 경우는 소규모 인력을 투입해 단기간에 사업을 수행하는 방식이 일반적이다. 이처럼 투입 인원이 적고 기간이 짧은 사업에서는 특히 참여 인력의 숙련도가 프로젝트의 성패를 좌우하는 경우가 많다. 또한 사업 기간이 짧다는 것은 일정에 여유가 없다는 의미로, 일정 관리에 문제가 발생하면 기간 제약 때문에 이를 바로잡기도 쉽지 않다. 그 결과 규모, 기간, 리스크 측면에서 더 복잡해 보이는 대형 SI 사업보다도 소규모 사업에서 일정 지연이나 품질 저하로 인해 제때 납품하지 못하는 사례가 오히려 빈번하게 발생하곤 한다.
(대형 SI 사업에서 문제가 덜 발생한다는 뜻이 아니라, 전체 사업 규모에 비추어 보았을 때 상대적으로 소규모 프로젝트에서 문제 발생 비율이 높게 나타나는 경향이 있다는 의미이다.)
하드웨어나 솔루션을 단순 도입하는 프로젝트보다, 메인 업무와 연계되는 단위 업무 프로젝트는 신경 써야 할 요소가 더 많다. 예를 들어 메인 업무의 고객 정보를 단위 업무 프로젝트에서 활용하는 경우, 개발이 완료되었다고 판단한 시점 이후에 문제가 발생하기도 한다. 메인 업무 쪽에서 고객 정보 프로그램을 수정한다면, 단위 업무 프로젝트에서는 그 사실을 알지 못한 채 오류가 발생하는 상황을 맞이하게 되기 때문이다.
물론 소프트웨어 개발 과정에서 형상관리(Configuration Management, 개발 산출물의 버전과 변경 이력을 관리)를 통해 소스가 관리되지만, 변경 여부 자체를 인지하지 못하는 경우 이러한 문제가 발생하게 된다.
따라서 프로그램 변경 시 영향도 분석은 매우 중요한 점검 포인트가 된다.
진행 중이던 단위 업무 프로젝트의 이행 시점이 얼마 남지 않은 상황이었다. 정확하게는 한 차례 이행 일정을 맞추지 못해 2주일을 연기한 상태였고, 연기된 이행 시점이 다음 주로 다시 예정되어 있었다. 다행히 수행 업체에서 일정 지연에 대한 페널티 성격으로 1개월간 무상 안정화 지원을 제공하겠다고 약속하였으나, 문제는 남아 있는 며칠 동안 처리되지 않은 결함과 검증 대상 항목을 모두 조치해서 오픈을 해야 한다는 점이었다.
더 이상 일정 지연은 있을 수 없었기 때문에 나는 두 가지 방안으로 대응하였다.
첫째, 수행 업체 본사에 현재 상황을 공유하고 적극적인 지원과 인력 투입을 요청하였다. 다행히 상황의 심각성을 인지하고 추가 인력을 확보해 지원하기 시작하였다. 사실 이 방법은 수행 업체 PM(Project Manager)의 리더십에 대한 평가로 이어지고, 인사 평가등에 불리하게 작용을 할 수 있어 조심스러운 부분이었다.
둘째, 일정과 처리 현황을 촘촘하게 관리하기 위해 하루 2회 진행 상황 점검 겸 대책 회의를 운영하였다.
예를 들어 오전 회의에서는 확인된 결함과 보완사항을 식별하고, 오후 회의에서 그 조치 결과를 다시 점검하는 방식으로 관리하였다.
사실 이러한 진행 방식이 수행 인력에게 일정과 진척에 대한 심리적 압박을 주는, 바람직하지 않은 방법이라는 점은 잘 알고 있었기에 적용을 망설였다. 그러나 프로젝트의 성공은 무엇보다도 일정 준수가 전제되어야 했기 때문에 다른 선택지가 없었다. 예상대로 하루 2회의 점검·대책 회의 방식은 단기간에 높은 개선 효과를 보였으나, 동시에 수행 인력의 피로도도 눈에 띄게 증가하였다. 그럼에도 불구하고 약 일주일간 집중 대응을 한 결과 인지된 대부분의 결함을 정리할 수 있었고, 이후 1주일의 이행 준비 기간을 거쳐 시스템을 큰 문제없이 오픈할 수 있었다.
우여곡절은 있었지만 프로젝트는 결국 성공적으로 마무리되었다. 다만 일정 준수를 위해 구성원들을 압박했던 일이 마음에 남아 미안함과 아쉬움을 쉽게 잊을 수가 없었다. 특히 수행 PM(Project Manager)이 나보다 연배가 더 많았고, 프로젝트에 참여한 인력들도 대부분 나와 비슷하거나 오히려 연배가 많았던 점을 생각하면, 며칠 동안 밤샘 작업까지 요청했던 사실에 마음에 편치 않았다.
외형적으로는 성공적인 프로젝트였지만, 진행 과정을 생각해 보았을 때 여러 가지를 반성하게 하는 계기가 되었다. 크고 작은 프로젝트를 다수 수행하면서 자신감에만 가득 차 있었던 내 모습을 돌아보게 되었고, 그 과정에서 나를 성찰하는 시간을 갖게 된 순간이었다.
