프로젝트관리 SW 버젼관리와 콤포넌트 분석

[도미니크]

제품 개발의 기술 관리활동 중에서 표준화된 모듈의 재활용성을 높이는 일은 개발 생산성 증진에 매우 중요한 일이다.  하드웨어의 경우는 그룹테크놀로지(GT)가 화두가 되었지만, 솔루션의 경우는 소프트웨어 아키텍처링이다.   솔루션 기업의 경우 소프트웨어 아키텍처링을 잘 하지 못하면 고객이 증가함에 따라 투입되는 소프트웨어 유지보수 비용은 기하급수적으로 증가하게 된다.   결국은 고객에게 "부르면 달려오던 기업"에서 "배불러서 불러도 오지도 않는 구먼!"이라는 소리를 듣는 회사로 전락한다.  많은 고객은 이탈하게 되고, 유지보수 업무의 과중한 업무부하로 개발자의 사기도 떨어지고 결국 직원 이탈과 수익감소로 이어져 회사는 쓰러지게 된다.  IT 업계에서 이러한 일을 여럿 보았다.

이러한 현상은 결국 3가지의 원인으로 귀결된다.  1) 개발자 리더 그룹이 아키텍처링이나 소프트웨어 공학에 관하여 훈련 받지 못했다.<교육의 문제>  2) 개발 팀장과 리더 그룹이 관리 역량이 떨어진다. <기술관리 역량>  3) 복잡도가 높은 개발 일을 도와줄 적절한 Tool이 제공되지 않았다. <자본장비도 빈약>.   아래의 차트는 이중에서 #2의 기술관리 역량에 도움이 될 좋은 템플레이트가 되겠다.

첫번째 그림은 회사가 개발한 솔루션의 콤포넌트별 버전관리의 유용성을 설명해 주는 시각화 도구이다.   각 콤포넌트를 구슬로 비유할 때, 구슬을 실로 꿰는 과정이 결국은 목걸이(완성품)을 통합하는 과정이 될 것이고, 가장 많은 실이 관통한 모듈의 활용성이 제일 높다 할 것이다.   제품의 경우에도 활용성이 높은 모듈이 많이 있다는 뜻(아래의 DB 2.0처럼)은 유지보수 부품의 수가 적고 표준화 되어 있다는 의미가 된다.  결국 적은 공수로 제품을 만들 수 있고, 많은 제품이 판매되었다고 하더라도 유지보수 비용은 최적화된다.  이를 해결하지 못하여 많은 업체들이 고객수가 늘어감에 따라 아이러니하게도 더욱 어려워지고 결국 무너진다.  아래 그림은 모듈화와 아키텍처링에 대한 좋은 설명 그림이 될 것이다.  가능하다면 자사의 제품에 대하여 적정한 추상화 레벨에서 이러한 시각툴을 그려보고 활용해 보기를 권고한다.  

두번째 그림은 첫번째 그림의 제품 2.0의 구슬들을 꿰어 연결한 실을 들어 올려 펼쳤을 때의 그림이 된다.  실을 올려 늘어놓는 것처럼 완제품의 콤포넌트를 늘어 놓고 전체를 살필 수 있는 이미지를 만들 수 있다.   기구설계, 회로 설계에서는 이러한 부품의 전개를 엔지니어링 부품표(engineering bill of material 약자 e-BOM)를 전개한다고 한다.  수많은 부품이 있을 수 있지만 역시 적절한 추상화 레벨에서 관리대상, 개발 대상 제품을 A 4 용지 한눈에 볼 수있는 관리툴을 만든다면 의사소통과 의사결정에 많은 도움이 될 것이다.   새로운 제품이나 서비스를 개발하려는 사업계획서를 작성할 때는 이러한 문서가 반드시 들어가야 한다.  필자도 개발 팀장에게 이러한 문서를 반드시 상품/개발 발의시 넣도록 강제하고 있다.  계획 단계에 비용%를 산출하기 어렵겠지만 "침을 발라"서라도 추정하는 것은 중요한 일이다.  개발난이도, 코스트 비율, 내재가치(경쟁력 관점)등을 고려하여 외부에 아웃소싱할지, 내부에서 개발할지 의사결정하고 전반적인 리스크를 고려할 수 있다.  

중요한 것은 MECE(상호배제,전체포괄)의 관점에서 1) 리스크포인트를 누락하지 않도록 카테고리별로 콤포넌트을 축약한 1줄 설명이라도 기재하여 모든 부분을 포함하여야 하며  2) 목적물 자체와 목적물을 만드는 개발행위를 병기하지 말아야 한다.   목적물을 만드는 행위는 Work Breakdown Structure(WBS)를 통해 공정비용을 산출할 때 유용하지만, 아래의 차트는 목적물 Object Breakdown Structure(OBS)자체를 구분한 것으로 조립도와 같은 것이다.  그러므로 코스트%도 개발인건비가 반영된 양산 부품의 비용 관점으로 산출해야 한다. 

기술 관리자들에게 도움이 되었으면 좋겠다.