Head First PMP
책 소개
1달 책한권 2021년 7월에 읽을 예정이었지만 너무 두꺼워 8월달까지 읽은
Head First PMP을 소개한다.
이 책은 회사에 비치되어있는 책 정리 중 관심이 생겨 빌려왔다. Head First JAVA를 본적이 있어 쉽게 익힐것을 기대하고 있다.
책 설명을 읽어보면 PMP 시험용으로 읽는책 같은데 기본적으로 PMP란 프로젝트를 관리하는 시험을 의미한다. 인터넷을 찾아보니 4년제 대학졸업 후 3년의 프로젝트 매니져 경력이 필요하고 35시간의 관련수업을 들어야 한다고 하니 쉽지는 않을 것 같다.
올해 초에 과목의 변경점도 있다고 하여 현재 보고있는책이 07년도 출판된걸 생각하면 이 책으로는 자격증 취득은 힘들어 보인다.
현재 대학교과 연계하는 피텍도 진행중이고 고등학교와 연계하는 도제학습도 있어 프로젝트 관리에 관심이 많았기 때문에 이책을 선택했다.
책후기
이 책은 결국 읽는걸 포기하기로 했다. 우선 검색해봤을때 PMBOK 자체가 21년 8월 현재 7번째 버전이 미국에서 나오고 있어 시험을 준비하려 해도 추후 발매할 책을 기다리는것이 현명하고 7번째 버전에서 이제 애자일 기법이 어느정도 포함되었다는 걸로 보아 내가 원하는 내용이 아닌 좀 올드한 방식을 많이 다룰것 같아 4번째 PMBOK을 기준으로 작성한 책은 읽는것을 포기헀다. 이 책이 너무 두껍기 때문에 변경했던 함께 자라기 책을 통해 현업과 PMBOK이 과연 비슷한지 의문이 생겼고 함께 자라기 저자도 이런 PMBOK에 따라 업무를 하는것에 부정적이었기 때문에 과연 읽을 필요가 있을까 싶었다. 결정적으로 읽은 부분까지가 개발이 아닌 여행사를 기준으로 진행되기 때문에 읽으면서도 공감되거나 얻는것이 없었다. 다른곳에 봐도 PMBOK같은 경우 개발 뿐이 아닌 모든 프로젝트와 연관된 자격증인지라 개발쪽에선 이미 국내에서도 한물 갔다는 애자일마저도 다른 직종들과 공통적인게 나오는라 적용을 못시키고 있다고 들었기 때문에 당장 개발 3년차인 내가 PMP시험을 칠 수 있는것도 아닌데 공부할 필요가 있나 싶었다. 이번 기회에 PMP라는 시험의 존재를 알았고 개발을 쭉하다보면 자격증 취득요건도 맞춰지고 기회가 왔을때 시험준비를 위해 보면 몰라도 당장 우리회사 업무에 적용시킬 가능성은 보이지 않았다.
PMP 소개
PMBOK 지침서는 4개의 책임영역 프로젝트 요구사항 식별, 성취 가능한 목표 세우기, 범위 시간 원가의 균형 유지하기, 요구사항 충족과
5개의 프로젝트관리 실무관행을 5개의 프로세스 그룹의 44개 프로세스로 구분한다.
9개의 지식영역
- 조달 : 계약을 정의하고 프로젝트를 수행할 계약자 선정
- 통합 : 모든 이들이 동일한 목표를 향해 일하도록 유지하고, 변경사항들을 정리
- 원가 : 프로젝트의 예산을 편성하고, 비용을 추적하기
- 인적자원 : 작업자들을 모으고, 이들이 동기를 부여 받을 수 있게 유지
- 리스크 : 긍정적으로나 부정적으로나 일어날 수 있는 일에 대해 예비하여 처리할 수 있도록 대비한다.
- 품질 : 최대한 효과적으로 일하여 정확한 제품을 만들고 있는지 확인한다.
- 의사소통 : 프로젝트상 모든 사람들이 동일성산에 있도록 누가 누구에게 말을 해야 하는지를 알아내기
- 시간 : 프로젝트를 끝낼 수 있는 시간을 산정하고, 납기일을 맞출 수 있게 작업을 확인한다.
- 범위 : 프로젝트에서 끝내야 할 작업들을 정의한다.
조직, 프로세스, 그리고 프로젝트
조직에는 3가지 유형이 있다. 기능조직, 프로젝트 전담조직, 매트릭스 조직이 있다.
- 기능 : 프로젝트관리 경정은 기능관리자와 같이하고 PM이 기능조직 관리자의 보조 역할로서 행정 업무를 주로하게 된다.
- 프로젝트 전담 : 프로젝트를 중심으로 팀이 구성되고 PM은 예산, 일정, 품질, 자원에 대한 모든 결정을 한다.
- 매트릭스 : 둘의 중간 정도로 PM과 기능조직 관리자들이 권한을 공유한다.
프로젝트에는 3가지가 있다. 일과성, 고유한 결과, 점진적 구체화이다.
- 일과성 : 프로젝트에는 항상 시작과 끝이 있다.(프로세스는 계속된다.) 무엇을 할 것인지 결정할 때 시작되고 서비스를 창출하면 종료된다.
- 고유한 결과 만들기 : 예전에 생성된 소프트웨어와 구별되는 점이 있어야 한다.
- 점진적 구체화 : 프로젝트를 많이 진행할수록 더 이해할 수 있게 된다.
범위, 원가, 시간의 균형을 지켜야 한다.
- 목표 프로젝트의 시작과 종료일이 장 정으된 출시들로 나눠준다.(WBS를 생각하면 될듯하다.)
- 범위목표를 설정하기 위해서 이해관계자와 함께 체크리스트를 작성(요구사항 정의서를 생각하면 될듯하다.)
- 예산을 하나하나 관리하고 원가를 제한한다.(현실적으로 개발에서 예산은 맨먼스이기 때문에 몇명의 개발자를 얼마의 기간동안 투입하는지가 중요해 보인다.)
프로세스 프레임워크
프로젝트에서 처리되는 모든 일에는 패턴이 있다. 계획한 다음 일을하고 일을 하는동안은 계획과 비교를 한다. 계획에 차질이 생기면 이것들을 수정하고 원상복귀 시키는 일이 PM이 해야할 일이다.
프로세스 그룹들과 지식영역들로 구성된 프로세스 프레임워크는 이런 모든 과정들을 부드럽게 한다.
프로젝트는 요리와 비슷한다.
- 필요한 요리를 구상한다.(여자친구에게 해줄 요리라던지 가족끼리 먹을 음식이라던지)
- 해당 이벤트를 위해 어떤 음식들을 상에 올릴건지 고민한다.
- 해당 음식들에 필요한 재료들을 분석하고 새로 구입해야할 식재료들을 작성하여 들어가는 비용을 계산한다.
- 요리를 한다.(하면서 계속 레시피대로 진행되는지 확인과정을 한다.)
- 요리를 완성하고 보상을 받는다.
프로젝트 통합관리
프로젝트에서 거의 매일 사용되는 프로세스 몇 가지를 살펴본다.
7개의 통합관리 프로세스
- 프로젝트 헌장 개발: 헌장은 작업을 할 수 있게 권한을 부여하는 문서, 항상 관여하는건 아니고 스폰서가 전달하기도 한다.
- 예비 프로젝트 범위 기술서 개발: 프로젝트 목표를 설계하는 문서, 프로젝트를 기확하기 전에 만들기 때문에 예비라고 한다.
- 프로젝트 관리계획 개발 : 프로젝트에서 발생하는 모든 것에 대한 지침서
- 프로젝트 실행지시 및 관리 : 기획이 끝나고 작업을 수행할 때 모든 이들이 할 일들을 잘 하고 있는지, 제품이나 서비스가 요구들을 충족시키는지 확인해야 한다.
- 프로젝트 작업감시 및 통제: 프로젝트에서 진행되는 모든 것들을 하나하나 끊임없이 감시한다.
- 통합변경통제 : 프로젝트상의 문제가 발생했을 경우 어떻게 처리할 것인지 이행관계자 및 고객과 함께 알아내도록 하고 계획을 갱신하여 프로젝트를 완료할 수 있게 해야한다.
- 프로젝트 종료 : 모든 것을 문서화 했는지 확인한다.
프로젝트헌장 개발 프로세스
만약 혼합조직에서 일하고 있다면, 팀은 평소에 PM에게 보고하지 않는다.
팀은 기능 관리자들에게 보고를 하며 해야할 기능단위의 일들이 있을 것이다.
하지만 프로젝트가 시작되었을 때 여러 조직의 상관은 PM이 되며 이런 권한을 주기 위해 프로젝트헌장이 필요한 것이다.
프로젝트헌장에 들어가는 내용은 프로젝트 수행에 대한 승인(팀원들의 작업 배정, 회사의 자원 사용)과 왜 프로젝트에 배정되었는지 나타나 있다.
이런 혼합조직이 아니라 하더라도 PM에게 어느정도 자원과 권한지 주어지는지 아는것은 정말 중요하다.
프로젝트 선정 방법으로는 편익층정모델과 수학적 모델이 있다. 편익층정모델은 가장 보편적으로 각 프로젝트가 얼마나 회사에 이득이 되는지를 알아내어 비교한다. 비용, 리스트, 지역사회에 기여 같은 요소들을 기준으로 계산한다.
수학적 모델의 경우 공식을 이용하여 성공률을 예측하므로 복잡한 수학공식들이 포함되어있다.
프로젝트헌장 개발 프로세스의 산출물은 헌장으로 여기에는 프로젝트에 대한 설명, 프로젝트 주요 요구사항들, 프로젝트 관리자의 권한 수준, 외부 가정 및 제약사항, 비지니스 케이스(이 프로젝트로 인해 투자수익, 인프라, 고객관리 등 얼마나 타당한 사업인지) 들이 들어갈 수 있다.
예비 프로젝트범위기술서 개발 프로세스
예비 프로젝트범위기술서의 내용으로는 프로젝트의 목적, 서비스 요구사항과 특성, 제품 인수기준(고객과의 프로젝트 성공 기준을 정한다.), 프로젝트 경계(프로젝트의 일부가 아닌것을 명시), 프로젝트 인도물, 프로젝트의 제약사항, 초기 프로젝트 조직, 초기에 정의된 리스트, 일정 마일스톤(모두가 아는 팀이 반드시 지켜야하는 일정), 원가 산정 규모(프로젝트에 들어가는 비용산정), 프로젝트 형상관리 요구 사항, 승인 요구사항(프로젝트를 승인하는 사람, 결과가 요구를 충족시켰다고 확인하기 위해 무엇을 할것인지를 정한다.)
프로젝트 관리계획 개발
프로젝트 기획은 정말로 통제를 취할 때이다. 프로젝트를 진행하면서 일어나는 모든 것을 어떻게 처리 할 것인가를 정확하게 기술하는 계획서를 작성한다.
즉 프로젝트에 관한 모든 정보를 한 곳에 정리한다.
프로젝트관리계획은 단일문서로 여러 개의 보조 계획으로 나누어져 있다. 이런 보조 계획에는 범위관리, 시간관리, 원가관리, 품질관리, 인적자원관리, 의사소통관리, 리스트관리, 조달관리가 있다.
- 범위관리 : 범위 변경들을 어떻게 처리할 것인지 기술한다.(프로젝트가 개발하는 서비스에 누군가 기능을 추가 또는 삭제해야 할 때 무엇을 해야 하는지 기술한다.)
- 일정관리 : 갱신된 마감 시간이나 마일스톤처럼 일정의 변경들을 어떻게 처리하는지 보여준다.
- 원가관리 : 어떻게 예산을 만들고, 프로젝트에 금전적인 문제가 생겼을 때 무엇을 해야 하는지 적어준다.
- 품질관리 : 제품이 고객의 표준을 충족시키지 못해서 발생하는 문제에 대해 적는다.
- 인력관리 : 인력이 변경되거나 특정 프로젝트에 추가 인력이 필요하다든지 할 경우 제약사항들을 식별하고 처리하기 위한 내용들을 적는다.
- 의사소통관리 : 프로젝트 팀, 관계자, 스폰서 등 프로젝트에 관련된 주요 관계자들과 의사소통할 수 있는 모든 방법들을 적는다.
- 리스트관리 : 발생할 수 있는 모든 나쁜 일을 상세히 하는 것과 이런 일이 발생할 경우 각각의 리스크를 다루는 계획을 적는다.
- 조달관리 : 회사 외부의 판매자들을 관리하는 내용을 적는다.
프로젝트 실행지시 및 관리
프로젝트 관리계획은 가장 중요한 투입물로 무엇을 어떻게 만들지, 언제 제품을 인도해야 하는지 적혀있다.
이를 기준으로 변경요청이나 결함수정, 예방조치, 시정조치등의 작업이 일어날 수 있다.
프로젝트 실행지시 및 관리 프로세스가 진행되고 나면 인도물과 작업성과정보에 대한 산출물이 생긴다.
인도물은 프로젝트가 계획에 있는 무엇인가를 산출한다면 그것을 인도물이라고 한다.
작업성과정보는 작업을 지시하면서 팀이 얼마나 작업을 잘 수행하는지 추적한 내용을 의미한다.
프로젝트 시행지시 및 관리 프로세스의 3대 구성요소
- 인도물을 만들기 위해 계획을 이용한다.
- 인도물에 있는 결함을 수정한다.
- 인도물에 승인된 변경들과 승인된 시정을 하라
통합변경 통제
감시 및 통제 순환
- 프로젝트 실행지시 및 관리 : 어떻게 작업이 수행되고 있는지에 대한 정보를 가지고 시작한다.
- 프로젝트 작업 감시 및 통제 : 계획변경, 인도물 수정에 대한 생각을 해보아야 하는데 이는 이혜관계자와 의사결정과 관련된 모든 사람들에게 이를 알려야 한다.
- 통합변경통제 : 변경과 수정이 승인된다면 팀에게 다시 해당 내용을 알려준다.
결함 : 원래 의도는 맞으나 실수를 하여 서비스에 문제가 생긴것이다. 시정조치 : 만약 계획되지 않은 변경내용이 생긴다면 이건 처음 계획한 프로세스가 잘못된 것으로 일하는 방식을 수정해야 한다.
프로젝트 종료
프로젝트 종료는 돈을 지불받아야 하고 프로젝트가 요구사항을 충족시켰는지 확인할 수 있도록 산출물이 나와야 한다.
프로젝트가 진행되면서 주도받았던 문서들을 정리하고 프로젝트 결과물(소스코드, DB데이터 등)을 인도해야 하며 이런 과정이 끝난후 고객들로 부터 공식적인 인수 문서를 받아야 한다.
또한 가장 중요한건 이런 프로젝트 진행과정에서 발생한 결함이나 시정조치등을 통해 조직의 프로세스에 추가할 사항들을 정리하여 조직 프로세스 자산에 추가해주어야 한다.