PM 컨버팅 #13
2. 프로젝트 : 통합관리
#13. 통합관리 및 요구사항 정의
프로젝트를 가장 단순히 표현하자고 하면
비즈니스 프로세스를 기능으로 구현하여 UI로 표현하는 것이다라고 정리할 수 있을 것 같다.
이 모든 것을 관리하는 게 통합관리이다.
PMI의 관리프로세스에 의하면
프로젝트 차터작성(착수)-> 프로젝트 관리계획수립(계획수립)-> 프로젝트 작업지시 및 관리(실행)->프로젝트 모니터링 및 통제->통합변경통제(감시 및 통제)->프로젝트(종료)의 순이고 이 프로젝트 관리프로세스 하에서 소프트웨어 개발 생명주기인 요구사항정의, 분석, 설계, 개발(구현), 테스트 및 이관의 주기를 거치게 된다.
PMP를 공부하다 보면 제일 먼저 난관에 봉착하는 게 프로젝트 차터이다. 사기업이나 금융 같은 경우에는 내부에서 프로젝트를 진행하기 위한 기본적인 사업계획서 및 예산설계서와 대표이사의 품의문서 정도로 규정하면 될 것이고 작성의 주체는 꼭 PM이 아니어도 된다.
공공의 경우에는 사업계획서와 예산설계내역서 그리고 과업내역서 까지라고 생각하면 이해가 쉬울 것 같다.
프로젝트 관리계획 수립은 과업수행계획서로 보면 될 것 같고 나머지는 수행, 통제, 관리의 프로세스로 보면 될 것이다.
정리는 간단한데 실제 프로젝트의 사업관리가 녹녹하지 않다.
이 파트에서 가장 중요한 것은 프로젝트 관리계획 수립이다. 관리계획 수립의 전반적인 내용들은 사업수행계획서에 그 내용들이 반영되어 있어야 하고 소프트웨어 개발 생명주기에서는 요구사항 정의를 수행하여야 한다.
요구사항 관련하여 핵심은
선택과 집중이고 선택할 수 있는 능력과 집중할 수 있는 역량이 있어야 한다.
고객의 모든 요구사항을 충족한다는 것과 그리고 그 뒤에 닥칠 변경까지도 모두 수용한다는 것은 가히 신의 영역이라고 할 수 있다.
좀 더 구체적으로 들어가면 요구사항 분석을 통하여 고객이 궁극적으로 이 프로젝트를 통하여 얻고자 하는 것이 무엇인가를 가장 먼저 파악해야 한다. 이 프로젝트 관리 계획이라는 것은 결국 고객의 목표에 최대한 다다를 수 있게 하는 계획을 수립하는 것이라고 보면 된다.
예를 들면 요구사항분석 단계에서 다양한 이해당사자들을 만날 것이다. 물론 같은 팀원들인 경우도 있고 다른 팀원들 또는 다른 조직의 사람들일 수도 있다. 만약 요구사항 분석에서 개별적인 이해당사자들의 이야기를 모두 수용할 것인가? 여기에는 실질적인 필요성도 있겠지만 조직의 논리 즉 정치적인 함수도 배제할 수 없을 것이다. 즉 프로젝트를 할 때 이 프로젝트의 궁금적인 목적에 대하여 이해를 못한다면 수 많은 이해당사자들의 요구사항에서 무엇이 중요한지 무엇이 중요하지 않은지 분별할 방법이 없는 것이다. 그럼 모두 수용할 것인가?
프로젝트의 목적과 목표를 알아야 그 의사들의 우선순위와 중요도를 정하고 필요 없는 것은 과감하게 배제할 수 있는 것이다.
두 번째로 프로젝트에 들어갔는데 고객이 무엇을 해야 할지 모르는 경우다. 아마도 대부분 이런 경우가 많을 것이다. 이런 경우 제일 먼저 고객이 의사 결정할 수 있는 무언가를 만들어 주어야 한다. 이때 가장 좋은 수단이 벤치마킹이다. 이때는 커뮤니케이션에 상당한 스킬이 필요하다. 고객은 어려운 내용에 대하여 본인이 이해를 못했을 경우에도 고객은 끄덕일 것이고 또는 벤치마킹을 통하여 얻어진 지식을 바탕으로 수많은 아이디어를 제안해서 프로젝트에 반영하길 원할 것이다. 그리고 역시 우선순위를 가지고 치열하게 싸울 것이다. 앞장에 언급했듯이 고객의 진화는 필연이고 PM의 역할은 고객을 가장 빨리 최고 수준으로 진화시키는 능력을 발휘하는 것이다.
요구사항을 분석할 때 기능 정의만 하면 절대 안 된다. 동시에 비기능정의에 대한 부분도 요구사항 정의를 하여야 한다. 비기능정의 부분은 분석 부분에서 자세히 언급하겠다.
좀 더 디테일하게 들어가면
1. 사업에 대한 개념 정의 : ISP, 사업추진계획서, RFP, 설계내역서 등을 참조
2. 이해관계자 정의 : 기본적으로 고객사를 통하여 조직도를 받아서 활용하고 이때 파워레벨도 함께 파악
3. 사업 추진 범위 및 방향성 : 기본 문서와 이해당사자들의 요구 개념을 통합하여 수립
4. 내외부의 환경 분석(인프라, 업무, 신기술, 법적 준수사항, 보안, 외부 사례 등)
5. 시사점 및 개선사항 도출
<소프트웨어사업 요구사항 분석 적용 가이드. 2012.12, 지식경제부, 정보통신산업진흥원. p17 참조>
결국 요구사항분석 단계에서 도출된 내용들을 기반으로 프로젝트에 실질적인 첫발을 디디게 된다.
다음회에 계속
지금 읽으신 글은 책으로 출판되어 있습니다.
내일부터 Project Manager가 되어야 한다.
