프로젝트 관리 절차와 방법

□ 프로젝트 관리 절차와 방법

○ 프로젝트 관리 프로세스

프로젝트 관리 프로세스

앞에서 프로젝트 관리에 대해 간단하게 알아봤다. 이제부터 어떻게 프로젝트를 관리할지에 대해 구체적으로 알아보자. 프로젝트 관리 프로세스는 프로젝트 관리 계획서를 만드는 것에서부터 시작한다. 실제 프로젝트에서는 착수보고서라는 용어를 많이 사용하고 있다. 프로젝트 관리계획서에는 누가(비용, 인력), 언제(일정), 무엇(범위)을, 어떻게(방법론) 할 지에 대해 아주 구체적인 계획이 나와 있다. PM은 프로젝트를 잘 관리 위한 목적으로 이 문서를 작성하고 발주사에게 프로젝트를 어떻게 진행할지 설명하는 보고자료로도 프로젝트 관리계획서를 활용된다.

프로젝트 관리계획서가 작성되면 이제 본격적으로 프로젝트가 시작된다. 설계자는 제안요청서, 제안서, 도메인 관련 문서 그리고 담당자와의 인터뷰를 통해 요구사항을 분석한다. PM은 설계자가 일을 잘 할 수 있도록 환경을 만들어주고 일을 잘 못하고 있다면 원인을 파악해 문제를 해결해 준다. 고객, 설계자 그리고 개발자 사이에 원활한 의사소통이 될 수 있도록 도와주는 것도 PM의 중요한 역할이다.

프로젝트 수행은 설계자와 개발자가 진행하는 업무를 말하며 요구분석, 설계, 개발, 단위/통합테스트가 여기에 해당한다. 프로젝트 통제는 PM이 진행하는 업무로써 일정관리, 품질관리, 범위관리, 위험관리, 비용관리, 인력관리, 의사소통관리, 조달관리가 여기에 해당한다.

 

○ 프로젝트 통합관리

프로젝트 통합 관리

프로젝트 관리업무는 크게 일정, 품질, 범위, 위험, 비용, 인력, 의사소통, 조달관리 이렇게 8개로 나눌 수 있다. 프로젝트 특성에 따라 관리업무가 하나로 합쳐질 수도 있고 여러 개로 다시 나뉘어질 수 있지만 관리프로세스를 잘 살펴보면 8개의 관리업무를 모두 발견할 수 있다.

프로젝트 관리 영역 

프로젝트 통합관리는 8개의 관리업무를 계획하고 조정하는 역할을 하는데 프로젝트 관리 계획서의 형태로 조직화 된다. 프로젝트 관리 계획서에는 8개의 관리 업무를 어떻게 수행할지에 대한 세부적인 계획이 나와 있고 이에 대한 실행과 변경을 어떻게 감시하고 통제 할지에 대해 구체적으로 기술되어 있다. 범위와 일정을 관리하는 WBS(Work Breakdown Structure)의 경우에는 중요도가 높고 변경의 빈도가 잦기 때문에 관리 계획서와 별도로 관리되는 경우가 많다.

 

○ 프로젝트 범위와 일정관리

프로젝트 범위와 일정관리

프로젝트 범위를 설정하는 일은 굉장히 중요하다. 범위란 프로젝트에서 해야 할 일을 결정하는 것이다. 프로젝트의 예산과 일정을 벗어나는 범위를 설정한다면 최종 제품의 품질이 나빠지고 예정된 시간 안에 프로젝트를 마무리할 수 없다. 범위는 제안요청서를 만드는 시점에 1차적으로 결정되고 요구사항 베이스라인을 만드는 시점에 확정된다. 이것은 제안요청서를 만들 때 무엇을 만들어야 하는지가 개념적인 상태로 있기 때문이다. 제안서를 만들 때도 전문가들이 모여 개발 범위를 산정하지만 고객과의 긴밀한 커뮤니케이션이 어렵기 때문에 정확한 범위를 산정하기 어렵다.

소프트웨어 프로젝트는 결과물이 추상적이기 때문에 요구사항 또한 구체적으로 만들기 어렵다. 따라서 프로젝트 관리계획서를 만드는 시점에 다시 한번 정확한 범위를 산정하고 요구분석 과정에서 고객과의 협의를 통해 범위를 확정하는 작업이 반드시 필요하다.

이제 대략적인 범위를 확정했다면 범위를 작은 단위로 나누어야 한다. 일을 할당하고 관리하기 위해서는 관리 가능한 단위로 나누어야 하는데 이것을 WBS(Work Breakdown Structure)라 한다. WBS는 프로젝트에서 수행되어야 할 작업들을 관리 가능한 단위(2주)로 나누고 순서를 정해 담당자가 할당된 구조화된 체계를 말한다. WBS는 범위관리에도 사용되지만 일의 순서를 잘 지정해 놓으면 가장 길이 긴 업무가 프로젝트 전체 일정이 되므로 일정관리에도 사용할 수 있다. WBS는 지속적으로 수정이 이루어지기 때문에 도구를 사용해야 하며 MS Project가 WBS 작성과 관리에 많이 사용되는 대표적인 프로그램이다.

프로젝트 관리의 중심에는 WBS가 있다. PM과 고객은 WBS를 통해 범위와 일정을 관리한다. 물론 WBS도 프로젝트 진행 과정에서 지속적으로 변경된다. 하지만 프로젝트 관리 계획서 작성 시점에 가능한 정확하게 WBS를 작성할 수 있도록 노력해야 한다.

 

○ 품질관리

품질의 개념도

소프트웨어 품질은 요구 사항을 만족시키는 기능과 특성을 말한다. 기능은 영업일지 관리, 영업비용 정산과 같은 제안요청서에 나와 있는 구체적인 동작이고, 특성은 속도가 빠르다거나 프로그램 변경이 쉬운 것과 같이 눈으로 볼 수는 없지만 사용과정에서 편리함을 느낄 수 있는 것들이다.

품질을 보장하기 위해 비용이 들어가는데, 예방비용, 평가비용, 내부실패비용, 외부실패비용 이렇게 네 가지로 나눌 수 있다. 예방비용은 품질활동을 계획하는 과정에서 들어가는 비용으로써 직원을 교육한다거나 품질활동에 대한 계획을 수립하는데 소요되는 비용을 말한다. 평가비용은 형상관리, 리뷰, 테스트, 감리와 같이 품질활동에서 발생하는 비용이다. 내부 실패비용은 고객에게 최종적으로 인도되기 전에 발생한 결함을 수정하는 비용이다. 통합테스트나 인수테스트 과정에서 발생한 오류를 수정하는 것이 대표적이다. 외부 실패비용은 고객에게 인도된 후에 발생하는 비용이다. 예를 들어 온라인 게임을 론칭하고 난 후에 장애가 발생했다면 프로그램 수정뿐 만 아니라 일시적인 서비스 중단과 프로그램 재배포 과정이 추가로 필요하다. 이러한 과정에서 소요되는 비용을 외부 실패비용이라 하며 위험이 크고 회사 영업 활동에 많은 타격을 주기 때문에 가능한 프로그램 개발 과정에서 충분한 테스트를 통해 외부 실패비용을 최소화하는 것이 중요하다. 

품질관리 활동

그럼 품질을 보장하기 위한 활동에는 무엇이 있는지 살펴보자. 가장 기초적인 것이 형상관리이다. 프로그램 소스뿐 만 아니라 프로젝트에서 생산되는 모든 산출물에 대해 변경 이력을 관리해야 한다. 만일 변경이 취소되거나 왜 이렇게 변경되었는지 원인을 모를 경우 과거 기록을 살펴보면서 원인을 찾거나 원상 복구해야 한다. 규모가 작은 프로젝트에서는 SVN과 같은 툴을 사용해 형상관리를 별도의 역할분담 없이 진행하지만 프로젝트 규모가 커질수록 형상을 통제하고 감사하는 역할을 만들어 형상관리 업무를 수행해야 한다.

산출물을 혼자 만든다면 품질이 천차만별일 것이다. 1년차 개발자와 5년차 개발자가 만든 프로그램의 품질이 같을 수는 없다. 산출물의 균일한 품질을 유지하기 위해 사용하는 기법이 리뷰이다. 가장 많이 사용되는 것이 코드 리뷰(Code Review)이다. 개발자가 만든 코드를 설계자가 검토하면서 코딩 스타일을 개선해 주는 것이다. 좀 더 공식적으로는 인스펙션(Inspection)이 있는데 이것은 산출물은 다양한 사람이 다양한 관점에서 공식적인 회의 형식으로 검토하는 것이다. 인스펙션은 코드 리뷰에 비해 비용이 많이 들기 때문에 분석, 설계, 개발 단계별 산출물 최종 검토 과정에서 많이 사용된다.

프로그램을 개발할 때 제대로 만들어 졌는지 알아보는 방법이 단위테스트이다. 보통 단위 테스트는 프로그램 개발자가 직접 하는 경우가 많지만, 프로젝트에 따라 개발자와 설계자가 협업해서 단위테스트를 진행하기도 한다. 단위 프로그램 개발이 완료되면 모든 프로그램을 결합해 업무가 잘 흘러가는지 알아보기 위해 통합테스트를 진행한다. 이 과정이 완료되면 고객이 최종 점검을 위해 인수테스트를 실시한다. 게임이나, 전자상거래 프로그램과 같이 다수의 일반 고객에게 오픈하는 서비스의 경우 베타테스트를 실시해 운영환경에서 프로그램 품질을 점검하기도 한다. 이처럼 테스트는 품질을 보장하기 위해 가장 많이 사용되는 기법이다.

○ 인력관리

인력관리 개념

인력관리는 사람을 관리하는 업무다. 사람 자체를 관리하고 사람들이 서로 원활하게 업무를 할 수 있도록 관리한다. 그리고 효율적으로 업무를 할 수 있도록 사람을 어떻게 배치할지 관리하는 것이 인력관리 업무이다.

인력관리의 위험

인력관리에는 여러 가지 위험이 존재한다. 이 위험이 최소화되도록 관리하는 것이 인력관리의 목표다. 가장 문제가 되는 것이 바로 인력퇴사 문제이다. 프로젝트 후반부로 갈수록 인력 대체가 힘들기 때문에 프로젝트 종료 시점까지 근무할 수 있는 인력을 선발하는 것이 가장 중요하다. 가급적이면 수주사 자체 인력을 투입하고 여건이 안될 경우 수주사가 지속적인 거래관계를 가지고 있는 전문협력업체 인력을 투입하는 것이 좋다. 프리랜서도 수주사 내부에 인력관리 풀을 만들고 가능한 검증된 인력을 투입하는 것이 좋다.

 

○ 의사소통 관리

의사소통 관리는 프로젝트에서 생성되는 정보를 어떻게 수집하고 프로젝트 참여자들이게 어떻게 배포할지를 관리하는 활동이다. 프로젝트 수행 과정에서 다양한 정보들이 생성되며 이 중에서 핵심정보들은 반드시 참여자들에게 전달되어야 하며 이에 대한 근거를 남기고 필요하면 의사결정을 받아야 한다. 참여자 수가 늘어날수록 의사소통 채널은 기하 급수적으로 증가하기 때문에 효과적인 의사소통 관리는 프로젝트를 성공시키는 데 굉장히 중요한 역할을 한다.

의사소통 방법

의사소통 방법에는 공식적인 방법과 비공식적인 방법이 있는데 공식적인 방법에는 프로젝트 계획서를 만든다거나 주간/월간 보고서를 제출하는 방식과 같이 문서를 사용하는 것이 있고, 비공식적인 방식에는 이메일, 메모, 포스트잇과 같이 간단히 적어 공유하거나, 팀 내 간단한 미팅을 통해서 전달하는 비공식적인 방법이 있다. 커피 마시면서 팀원들간에 나누는 대화도 일종의 의사소통 방법이다. 

의사소통 참여자

프로젝트에 관련된 모든 사람이 의사소통 참여자이다. 발주사의 경영진, 업무담당자, 발주담당자가와 수주사의 PM, 설계자, 개발자가 모두 의사소통에 참여한다. PM은 발주사의 업무담당자와 경영진에게는 공식적인 채널을 통해 의사소통을 진행하는 경우가 많다. 보고서를 만들어서 보고회라는 자리를 통해 발표 형식으로 프로젝트 정보를 전달한다.

PM과 발주 담당자는 공식/비공식 채널을 모두 동원해 긴밀하게 의사소통을 하며 많은 부분을 서로 협력적으로 해결해야 한다. 하지만 중요한 의사결정의 경우 반드시 문서와 이메일을 통해 기록을 남기는 것이 좋다. 이것은 향후 발생할 수 있는 중요한 범위 변경에 대한 대응자료로 활용할 수 있기 때문이다.

PM과 설계자 그리고 개발자 사이에서는 공식적인 의사소통 방식보다는 비공식적인 의사소통 방식이 많이 사용된다. 일상적인 대화형식으로 정보를 공유하며 정보에 기반한 의사결정 또한 실시간으로 이루어 진다. 빠르고 효율적인 개발을 위해 공식적인 미팅보다는 실무회의를 통해 정보를 공유하는 것이 좋다.

프로젝트는 다양한 기법, 기술, 도구, 인력들을 사용해서 완성된다. 프로젝트는 시간이 흐를수록 구체화되며 사람이 머릿속에 있는 개념들이 하나씩 화면으로 만들어진다. 프로젝트는 후반부에 새로운 요구사항이 나오며 문제점들이 도출되고 사람들의 스트레스는 극에 달한다. 소프트웨어 프로젝트는 별도의 자재를 사용하는 것이 아니라 처음부터 끝까지 사람의 지식과 노동력에 거의 모든 것을 의존하기 때문에 기타 다른 프로젝트보다 관리가 몇 배 더 어렵다.

그래서 필요한 것이 프로젝트 관리 지식이다. 이것은 프로젝트 관리자만 알아야 하는 것이 아니라 프로젝트에 참여하는 사람 모두 알고 있어야 한다. 관리자는 프로젝트를 성공적으로 마치기 위해 알아야 하지만, 프로젝트 팀원은 내가 필요한 것이 무엇이고 다른 사람이 나에게 무엇을 해줘야 하는지 그리고 다음을 위해서 내가 무엇을 준비해야 알아야 되기 때문에 프로젝트 관리에 대한 기초 지식을 알고 있어야 한다.