2010년 5월말.
’10년 국토해양부 홈페이지 포털화 기반구축사업 제안팀의
일원으로 제안 작업에 참여하였다. 국토해양부 포털 홈페이지
사업은 2008년부터 현재까지 개발 및 운영사업을 당사에서
진행한 사업으로 3년간 축적된 개발 및 운영의 노하우를 얼마
만큼 제안서에 잘 녹아 들어가게 작성하여, 이를 평가위원들
로부터 좋은 점수를 이끌어 낼 수 있는가가 제안의 포인트였다.
금번 사업에서 가장 중요한 과업은 총 11개의 홈페이지(본부
및 소속기관 10개)에 대해서 웹호환성 및 웹접근성 기준에
적합하도록 개편하고, 외부전문기관을 통해 진단 및 전문가
평가를 실시하는 것과 담당자가 특히 관심 있어하는 트위터
통합관리 프로그램 구축 부분이라 할 수 있다.
이미 당사는 2008년에 국토해양부 개발사업에서 웹접근성
품질마크를 획득한 경험이 있으며, 많은 공공기관 사업을 통해
축적된 기술을 보유하고 있다는 점을 적극 부각시켜 제안서를
작성하였다.

웹접근성 사업은 개인적으로도 이전에 해 보았던 사업이라 제안서를 작성하는데 도움을 줄 수 있었다.
제안서 마감일이 코 앞이라 입사하자 마자 야근과 철야를 하게 되었다.
입찰마감결과 이컴라인 포함해서 2개 업체가 입찰에 참여했다고 한다. 이 정도 경쟁률이면 한번 해 볼만
하다는 자신감이 들었다. 입찰 결과가 발표되기 이전까지는 일체의 자만과 방심은 금물이라는 것을 다들 잘
알고 있기에 끝까지 긴장을 늦출 수는 없었다. 제안발표회를 무사히 마치고, 진인사 대천명의 자세로
결과발표를 차분하게 기다렸다. 드디어, 입찰결과 이컴라인이 우선협상자로 선정되었다는 기쁜 소식을 들었다.
기술협상은 2가지였는데, 충분히 수용할 수 있는 범위의 요구사항들이어서 난관 없이 통과되었다.
첫째는 홈페이지의 원활한 통합을 위해 부서 및 소속기관 등의 홈페이지 담당자와 유기적인 협조 체계를
맺어야 한다는 것이며, 둘째는 뉴미디어 홍보체계가 조기에 정착될 수 있도록 미니블로그(트위터)
통합관리체계를 우선적으로 개발하고 교육하여야 한다는 것이었다. 6월 18일 계약이 체결되었고, 착수계를
제출하였다.
자! 이제 6개월 간 최선을 다해서 열심히 일하는 것만 남았다!

돌이켜 생각해 보니, 이번 프로젝트는 기간은 6개월이었지만, 프로젝트 기간 동안 봄, 여름, 가을, 겨울 4계절을 모두 경험하는 프로젝트가 되었다. 아무리 계절이 바뀐다 한들 프로젝트에서 가장 중요한 요소가 품질과 일정이라는 사실은 결코 변하지 않을 것이라 생각한다.

본격적인 프로젝트가 시작되고 예상치 못한 내부의 복병(?)을 만났다. 그것은 바로 LPMS를 이용한 사업관리 시스템이었다. 기존에 사용해 본 적이 없는 나로서는 이컴라인 만의 특화된 시스템인 LPMS에의 빠른 적응이 최우선 과제로 떠 올랐다.
LPMS란 Leecom Project Management System의 약자로써 이컴라인이 자체개발한 프로젝트 관리시스템이다.프로젝트와 관련된 모든 관리요소가 이 시스템 안에 다 들어있다 해도 과언이 아닐 정도로 실로 엄청난(?) 기능으로 무장되어 있었다.
처음 접해 보는 나로서는 정말이지 도무지 적응하기가 어려웠다. 매일매일 진행 내용과 작성한 파일을 등록하고, 진행상황을 수시로 체크하고, 결재하고, 결재받고, 관리 한다는 것이 생각처럼 익숙해지기가 그리 쉬운 일이 아니었다.
표준사업관리는 크게 12가지 관리로 이루어져 있다.(요구사항관리, 변경관리, 비용관리, 품질관리, 위험관리, 인력관리, 장비관리, 장애관리, 프로젝트일지관리, 형상관리, 범위관리, 진도관리) 진도관리는 단위 프로젝트별로 구분하여 관리되어 진다.
이번 구축사례를 작성함에 있어, 표준사업관리 항목에 의거해서 작성해 보려 한다.

요구사항관리는 크게 4단계로 진행되었다.

1단계로 고객과의 6차례에 걸친 면담을 진행(기간 : 6/7~7/6)하여
면담서를 작성했고, 2단계로 면담서와 과업지시서, 제안요청서,
제안서, 기술협상안을 토대로 요구사항정의서를 작성하였다.
총 22건의 요구사항이 정의되었다.

3단계에서는 이렇게 정의된 요구사항정의서 각 항목들을 LPMS에
과업으로 등록하고, 과업이행여부에 따라 요구사항추적표를 통해
진행/미진행 으로 구분하여 진행여부를 쉽게 파악할 수 있게
관리하였다.

4단계에서는 요구사항정의 이후에 지속적으로 발생하는 고객의
요청사항에 대해서 별도로 고객요구사항관리를 통해 이슈관리로
진행하였다. 이슈관리 할 때에는 진행된 사항은 완료, 미진행된
사항에 대해서는 별도의 색상으로 표시하여 미진행 여부를 쉽게
알아볼 수 있도록 관리하였다.

이번 사업에서 요구사항정의서에 정의된 22개 요구사항은 모두
구현 완료하였으며, 별도 이슈 관리한 고객요구사항관리는 총 9건
으로 이중 7건은 본 사업에서 구현이 가능하고, 2건은 사업종류
후에도 지속적으로 변경되고 있어, 운영팀과 협의가 필요한 부분
으로 남아있다.

변경관리를 통해 프로젝트를 진행하면서, 처음 제안시점에서의
과업지시서, 제안요청서, 제안서, 기술협상안의 내용 중에서
과업내용이 변경되는 것을 관리하였다. 이는 사업 종료 시점의
최종 검수확인 과정에서 상당히 중요한 사항이므로 확실하게
관리해야 할 필요성이 있었다.
본 사업에서는 총 8건의 변경 사항이 있었으며, 7건은 모두 수용
할 수 있는 사항이었으나, 최종 검수 시에 1건이 문제가 되었다.
웹 에디터 구매건 이었는데, 이는 최초 도입과정에서 고객과
운영팀의 검토 결과 기존 FCK에디터 및 스마트에디터를 그대로
사용하는 것이 좋겠다는 의견에 의해 고객 요청으로 도입이
보류되었던 사항이었다. 그러나, 최종 검수 과정에서 고객이 도입
보류 의사를 번복하여, 결국은 도입하기로 최종 결정하였다.
이와 같이 과업이 변경될 경우에는 추후 논란의 여지가 발생할
수 있으므로, 반드시 변경내용을 문서화해서 고객의 서명날인을
받아 두어야 하며, 그래야만 나중에 불필요한 고객과의 마찰을
사전에 방지할 수 있다.
모든 문서는 고객 서명 날인을 반드시 받아 두어야 한다.

프로젝트를 진행하면서, 비용관리는 수익성 측면에서 매우 중요하다고 생각한다.
공교롭게도 프로젝트를 진행하는 동안 회사가 재정적으로 여유가 많치 않았던 시기여서 비용관리에도 신경을 무척 많이 쓸 수 밖에 없었다.
다행히 비상주로 본사에서 프로젝트를 진행하였으므로 본사에서 공동으로 이용할 수 있는 비품(프린터, 복사기, 전화, 팩스, 문구류, 종이, 커피, 생수 등)은 최대한 이용하여 비용을 절약하였으며, 야근작업을 위한 야근식대도 저렴한 본사 구내식당 식권을 이용하는 방식으로 하였다. 고객과의 협의를 위한 교통수단은 거의 대부분 지하철을 포함한 대중교통을 이용하였고, 영업팀에서 국토해양부를 방문할 경우 회사차를 함께 이용하는 방식으로 비용을 절약할 수 있었다.
또한, 솔루션 가격 협상을 통해 최초 예상했던 사업예산 대비 상당금액을 줄일 수 있었으며, 프로젝트를 진행하면서 꼭 필요한 회식자리도 가급적 회사의 지원을 받지 않고, 팀원간 십시일반 회비를 모아서 진행하거나 PM이 한 턱 내는 방식으로 진행하였다.
이렇게 진행한 결과 이번 프로젝트는 많은 어려움 속에서도 수익이 남는 사업으로 진행하였다고 생각한다. 프로젝트를 진행하면서 반드시 비용을 줄이는 것만이 바람직한 것은 아니지만 불필요한 비용지출로 인해 프로젝트 운영을 어렵게 할 필요는 더더욱 없는 것이다.

품질관리는 LPMS를 통해서 관리하였다. 팀원들이 각각 작업한 문서파일이나 개발된 소스의 URL 주소를 LPMS에 등록하면, PM이 1차로 확인하여 결재하고, 2차로 QM이 최종 승인처리하면, 진척률에 반영이 되어 전체 공정률에 나타나게 된다.
특히, 웹표준, 웹호환성, 웹접근성의 품질을 위해 외부전문기관에 의뢰해서 자동진단, 전문가 진단, 사용자 진단을 각 2회 실시하였으며, 웹취약성 점검을 위해서 외부 전문 보안컨설팅업체에 의뢰하여 모의해킹 점검을 받았다.

위험관리를 통해 프로젝트를 진행하면서 고객의 무리한 요구사항
이나 자체적으로 내재하고 있는 프로젝트의 원활한 진행을 방해
하는 요소들을 관리하였다.
이번 프로젝트를 진행하면서 도출된 위험요소는 총 6건이었으며,
관리적 위험 1건과 기술적 위험이 5건 있었다.
관리적 위험은 개발인력 투입 지연에 대한 것이었는데, 다행히 본사
기술연구소 인력의 투입과 검증된 퍼블리셔의 투입으로 프로젝트
중반 이후부터 원만히 해결되었다.
기술적 위험은 고객과의 일정 협의와 기술연구소의 지원, 외부진단
업체 및 보안업체를 통한 진단방법으로 해결할 수 있었다.
위험요소는 관리도 중요하지만 적극적으로 해결하려는 자세가 더욱
중요하다고 생각한다. 위험요소를 방치하면 프로젝트 마지막에
치명적 실패의 결과를 초래할 수 있기때문이다.

 

장비관리를 통해 프로젝트를 진행하면서 본사로
부터 승인 받은 장비들을 목록화 하여 관리하였다.
프로젝트를 장기간 진행하다 보면, 투입자와
철수자가 생기고, 여러 장비의 반입과 반출이
빈번하게 일어나게 된다.
이번 프로젝트에서는 혹시라도 발생할 수 있는
장비의 분실 및 착오를 방지하기 위해 본사 입고,
출고 시에 반드시 반입증, 반출증을 문서로 작성해서
결재를 득한 후 진행하도록 하였다.
개인적으로 아쉬웠던 부분은 1인당 모니터를 1개씩
추가로 지급해서 멀티 작업이 가능 했으면,
프로젝트를 보다 효율적으로 진행할 수 있지
않았을까 하는 생각이 든다.
많은 개발자들이 2대의 모니터로 개발하기를 원하고
있으며, 이는 충분히 검토해 볼 가치가 있다고
생각한다.

이번 프로젝트를 돌이켜 보건대, 가장 아쉬웠던 점은 개발PL의 부재가 아닌가 한다. 프로젝트 인력구성에서
PL의 중요성은 절대적이다. PL은 프로젝트의 처음부터 끝까지 PM과 늘 함께하여야 하며, 절대로 인력의
변동이 있어서는 안 되는 부분이다. 이전 프로젝트에서 하도 PL의 부침이 심해서 프로젝트가 산으로 간 적이 있다. 당연히 프로젝트가 잘 끝났을 리가 없다. 프로젝트가 잘 진행되려면 각 기획 PL, 디자인 PL, 개발 PL들이 중심이 되어서 해당 파트에 대해서 전권을 가지고 전적으로 책임 지고 일을 해 주어야 한다.
PM이 만능은 아니다. 더구나 PM이 퍼블리싱, 프로그램의 테크니컬 한 부분까지 모두 알 수는 없다.
각 분야에서는 각 PL들이 역량을 발휘해 주어야 하는 이유가 여기에 있는 것이다. 이번 프로젝트를 진행하면서 엄밀히 말하면 개발 PL이 없었다. 각 개발자들이 각자의 단위 업무만을 진행하는 형태로 진행되었다.
그러다 보니 전체적인 개발업무나 전체적인 개발일정관리, 개발품질 등을 챙기는 사람이 없었고, 이 역할까지 PM이 해야했다. PM도 개발출신 PM이 아니다 보니 여러모로 한계가 있었다. 또한, 프로젝트를 성공적으로 수행하기 위해서는 개발 PL이 프로젝트 처음 킥오프 시점 부터 투입되어야 한다고 생각한다. 처음부터 투입되어 철저하고 확실한 현행 시스템 분석이 선행되어야 하고, 모든 면담 및 회의에 PM, 기획자와 함께 개발PL이 반드시 참석해야 한다고 생각한다. 기획자가 고객과의 면담에서 요구사항을 수렴하다 보면 개발적인 이슈가 많이 도출되고 이에 대해서 정확한 판단이나 결정을 할 수 없는 경우가 많기 때문이다. 개발PL이 면담과 회의에 같이 참석한다면 그 자리에서 바로 고객에게 피드백을 줄 수 있고, 의사결정이 신속하게 이루어질 수 있으므로 훨씬 효율적으로 프로젝트가 진행 될 수 있을 것이라 생각한다.

형상관리는 프로젝트 단계별로 생산되는 산출물에 대해서 Version별로 관리하였다.
프로젝트를 진행하다 보면 수 많은 산출물과 소스들이 만들어 지는데, 이를 체계적으로 관리하지 않으면 중복된 작업을 진행할 수도 있고, 최신의 소스를 유지할 수 없을수도 있다.
이를 방지하기 위해서 Version별로 산출물에 대한 형상관리가 반드시 필요한 것이다.
산출물에 대한 관리는 모두 LPMS에 등록하여, 팀원들간 공유할 수 있게 관리하였으며, 산출물에 대한 최종적인 관리는 PM으로 일원화 함으로써 착오발생을 방지하였다.
또한, 최종 완료 후 완료보고 산출물 제출시에 별도의 정리작업으로 인한 불필요한 시간 낭비를 방지할 수도 있었다.

장애관리는 주로 운영사업에서 시스템 장애 발생시에 대처하는 관리로써 본 사업에서는 특별히 장애관리를 진행하지는 않았다.
다만, 개발 테스트 서버의 기계적 오류가 발생한 적은 있으나, 별도의 각 담당자의 로컬 PC에 백업을 받아 두었으므로 이로인한 문제는 발생하지 않았다.

LPMS를 통해 총 22개의 과업을 과업아이디를 부여하여 관리하였고, 과업아이디를 클릭하면, 해당 과업에 대한 요구사항아이디와 요구사항명을 조회할 수 있어 관리가 용이하였다.
이번 프로젝트에서 부여된 22개의 과업은 모두 수행하였으며, 그중 웹에디터 도입건은 담당자의 요청에 의해 최초에는 도입이 보류되었다가 최종적으로 번복되어 결국에는 도입하기로 하였다.
범위 관리는 PM이 관리해야 할 여러 분야 중에 가장 기본적인 항목이라 할 수 있다. 우스갯소리로 PM의
어원이 피할것은 피하고, 막을 것은 막아야 하기 때문에 PM이라 명명 되었다고 하는 말이 있다. PM은 최초의 과업범위가 늘어나지 않도록 최대한 고객을 설득해야 하고, 일정 내에 모든 과업을 완수할 수 있도록 적절한 전략과 전술을 적재적소와 적시에 능수능란하게 구사해야 한다.

진도관리는 팀원들이 직접 LPMS에 등록한 사항을 PM이 결재하고, QM이 승인함으로써 진척율에 반영되고 확인할 수 있는 방법으로 진행하였다.
LPMS를 통한 진도관리를 보완하기 위해서 매일 아침에 티 타임 형식의 팀 회의를 진행하였다. 이슈가 있건 없건 간에 회의주제가 있건 없건 간에 무조건 매일 아침 회의를 통해서 서로간에 궁금한 사항이나 문의할 사항, 조금이라도 미심쩍은 일이 있으면 반드시 풀고 넘어가도록 하였으며, 자연스럽게 진도 관리도 다시한번 확인할 수 있었다. 이로 인해 기획, 퍼블리셔, 프로그래머 사이에 불필요한 중복 작업을 미연에 방지하고, 정확한 의사결정 하에 작업을 효율적으로 진행할 수 있게 된 것 같다.
또한, 고객과도 10번 전화통화나 이메일을 통해서 의견 수렴을 하는 것보다 직접 1번 방문해서 면담을 진행하는 것이 훨씬 효과적이라는 사실을 새삼 깨달았다. 이번 프로젝트는 비상주로 진행했기 때문에 방문을 통한 고객과의 빈번한 회의는 프로젝트를 성공적으로 이끈 빼 놓을 수 없는 성공요소였던 것 같다.
40 여회에 이르는 고객 방문을 통한 면담과 회의를 진행하였고, 프로젝트와 고객 성향에 따라서는 달라질 수도 있겠지만, 이번 프로젝트에서 고객과의 회의는 많이 하면 할 수록 좋은 결과를 가져온다는 것을 깨달았다.
또한, 고객 주간업무보고를 회사 내부 결재를 먼저 진행하는 과정에서 진척율에 대한 보고나 이슈사항에 대해 회사에 다시 한번 협조를 요청하는 계기가 되었던 것 같다.

처음에 요구사항수렴을 위해 면담을 진행하면서 알게 된 사실은 국토해양부 담당자는SNS에 상당히 관심이 많다는 사실이다. 나도 SNS 얘기를 최근에 많이 들었지만 대략 트위터 정도라고 생각했다.
그러나, 고객이 요구하는 사항은 훨씬 그 이상이었다. 트위터는 기본이고, 페이스북, 미투데이, 요즘, 구글,
마이스페이스, 싸이월드 등등등… SNS 관련된 사항들은 모두 구현했으면 좋겠다고 한다. 하지만, 너무 많은 것을 요구하신다. 그래서, 일단은 과업범위에 있는 트위터 관리 프로그램만을 이번 사업에서는 구현하기로 하였다.
이번 사업에서 구현한 트위터 관리 프로그램의 업무 흐름도는 대략 이렇다. 국토해양부 직원으로 구성되어 있는 트위터 사용자가 트위터 관리 프로그램에 접속해서 트위터로 보내고자 하는 글을 등록하면, 트위터 관리자가 내용을 확인 후 검증이 되면, 승인을 해줌과 동시에 국토해양부 자체 DB에 저장되고, 등록한 글은 트위터로 전송되는 시스템이다.
주요기능은 전체글 보기, 등록한글 보기, DM받은글 보기, 맨션받은글 보기, 추천받은글 보기 등이다. 고객은 일단 현재 기능에 만족해 하지만 자꾸 더 업그레이드 된 기능을 요구하신다. 통계 기능과 함께 등록요청글이 접수되면 담당자PC에서의 알림 위젯 기능과 부재중에는 휴대폰으로의 SMS 기능까지 요구하신다. 하지만, 이는 과업범위를 초과하기도 하고 당장 내부 인력으로는 이를 개발할 수가 없으니 이번 사업에서는 구현이 어렵다고 고객을 설득하였다. 아마도 내년도 국토해양부 포털화 사업은 SNS에 기반을 둔 사업으로 진행될 가능성이 크므로 이에 대한 스터디 및 준비가 필요할 것으로 판단된다.

프로젝트와 함께 한 모든 사람들에게
세상에 노력해도 안 되는 일이 있을 수는 있다.
하지만, 내가 살아 온 40 여년의 인생을 돌이켜 보건대, 나에게 있어서나 주변의 다른 사람의 경우를 보아도 정말로 최선을 다해서 노력했을 때 안 되는 일은 거의 없었던 것 같다.
다만 얼마나 노력을 했는가에 따라 목표 달성의 기간이 길어질 수도 있고, 짧아질 수도 있는 것 같다는 생각이 든다.

국토해양부 프로젝트는 정말로 수행하기 어려운 악성 프로젝트도 아니었고, 그렇다고 어려움 없이 쉽게 쉽게 진행된 프로젝트는 더더욱 아니었다고 본다. 평가자의 잣대에 따라 성공이냐 실패냐의 다른 평가가 내려질 수 있겠지만, 나 스스로는 부끄럽지 않게 열심히 수행한 프로젝트라고 감히 자부하고 싶다.

물론 프로젝트는 PM도 중요하지만 그 구성원이 더욱 중요하다고 생각한다. 이제 프로젝트 완료보고회도 끝났고 사업도 종료된 시점에서 많은 사람들의 얼굴이 내 뇌리 속에 주마등처럼 스쳐 지나간다. 좋은 사람으로 기억되는 사람도 있고 서운한 사람으로 기억 되는 사람도 있다. 하지만, PM은 프로젝트의 총괄 책임자이다. 팀원을 탓하거나 팀원에게 책임을 전가해서도 안 되고, 프로젝트와 관련된 어떠한 사항에 대해서도 회피하려고 해서는 안 된다. 어찌되었든 모두 고마운 사람들이고, 모두 소중한 나의 팀원들이었기 때문이다.

여러분 덕분에 사업을 잘 완료할 수 있었으며, 아래와 같은 교훈을 얻었습니다.