개발방법론의 현실
IT현장의 감리와 개발방법론의 현주소
PM들... 우리는 관공서 발주에서 감리를 받는다.
감리는 처음부터 함께하는 파트너일 것 같지만 일단 프로젝트가 시작되고 어느 정도 진행되었을 때 설계감리를 받는다. 설계감리에서 지적사항이 나오면 보완조치를 해야하고 곧 이어서 종료감리를 받는다.
이러한 감리는 완전히 허접한 프로젝트를 어느 정도 있어보이게 하는 효과가 있다.
이 감리에서 가장 많이 검토되는 개발방법론은 CBD 방법론이다.
컴포넌트 단위를 다수 개로 관리해야할 정도로 필요한 프로젝트에서는 본 방법론이 생산성을 향상시키고 통제가능한 것으로 여겨지게 할 수 있다.
그러나 조그만 프로젝트에서도 동일한 방법론을 쓰게 되어야 하는 경우가 많다.
관리를 위한 관리가 된다.
즉 건물을 하나 짓는데 있어서 필요한 것들이 환경영향평가라던가 주변 교통량 연구라던가 하는 것들이라면 100층짜리 건물을 짓는데는 반드시 해야될 평가지표들이 된다.
그러나 정자를 하나 짓는데도 동일한 방법론을 적용해야 된다면? 감리를 위한 방법론으로 전락하여 본 프로젝트에 부하를 주고 예산을 갉아먹는다.
2억 미만 프로젝트를 하면서 대상 사이트가 두 개이고 기존 사이트 리뉴얼을 하는 일이라면 실질적으로 컴포넌트에 대한 관리요소가 거의 없게 된다.(단위 수량으로 보면 1개의 사이트가 1억 미만이 된다.)
그렇다면 관련된 양식에서 계획서 항목 2~3개는 해당사항없음이라는 내용으로 작성된 문서가 되고 그와 관련된 모든 문서는 생략되거나 동일하게 적용된다.
즉... 이 방법론에서 나오는 산출물은 감리제출용으로의 목적만 갖는다.
대부분의 기업들은 산출물을 위한 개발방법론으로 개발을 하게 된다. 온전히 자신의 것이 아니므로 산출물의 목적도 모른 채로 작성을 하게 되는 것이다.
산출물을 그래도 몇 번 작성하다보면 그 간극에 들어있는 지혜가 보이기도 한다. 다만 완전히 '내재화'되는데 걸리는 시간은 상당한 수준이 요구된다.
더 큰 문제는 해당 방법론의 목적을 모르는 개발자들과 함께 일하는 순간이다.
이것이 가끔 발생하면 좋은데... 대부분 그냥 하라니까 열심히 하고 있다.
우리는 감리를 위한 방법론을 넘어서는 유연한 방법론을 어떻게 적용해야할까?
공공 프로젝트에 적용한 가능한 공공 프로젝트 개발 방법론의 연구가 소셜리서치네트워크 기반으로 제작될 필요가 있다.(PM들 협회가 있던가? 있다면 과제로 만들어서 연구해도 될 듯 한데...)
[참고정보]
사업유형 : 기획사업
- 정보기술 아키텍쳐 수립
- 정보화 전략계획 수립
감리기준 : 선택
사업유형 : 구축사업
- 정보시스템 구축(SW개발, DB/인프라 구축 등)
감리기준 : 사업비 5억 이상(의무)
사업유형 : 운영사업
- 정보시스템 운영
- 정보시스템 유지보수(유지관리)
감리기준 : 선택
공통 기준
- 대국민 서비스를 위한 행정/민원 업무용
- 다수 기관이 공동으로 구축/사용하는 경우
- 사업비 1억원 미만의 소규모 사업은 제외가능
정보화사업 감리대상 규정(전자정부법 시행령 제71조제1항)
제71조(정보시스템 감리의 대상) ① 법 제57조제1항에서 "대통령령으로 정하는 기준"이란 다음 각 호의 어느 하나에 해당하는 경우를 말한다.
1. 정보시스템의 특성이 다음 각 목의 어느 하나에 해당하는 경우<단서 생략>
가. 대국민 서비스를 위한 행정업무 또는 민원업무 처리용으로 사용하는 경우
나. 여러 행정기관등이 공동으로 구축하거나 사용하는 경우
2. 정보시스템 구축사업으로서 사업비(총사업비 중에서 하드웨어·소프트웨어의 단순한 구입비용을 제외한 금액을 말한다)가 5억원 이상인 경우
3. 그 밖에 정보기술아키텍처 또는 정보화전략계획의 수립, 정보시스템 개발 또는 운영 등을 위한 사업으로서 정보시스템 감리의 시행이 필요하다고 해당 행정기관등의 장이 인정하는 경우
감리점검체계(프레임워크)의 개념
