PM 직무교육
프로젝트 매니지먼트에 대한 가장 공신력 있는 연구 기관인
PMI(Project Management Institute)는 프로젝트를 이렇게 정의했습니다.
"고유한 제품, 서비스, 또는 결과물을 창출하기 위해서
한시적으로 투입하는 노력"
PM은 정해진 납기 일정과 한정된 리소스를 활용하여 결과물을 만들어내는 것에 그 책임을 갖습니다. 그렇기 때문에 결과물을 만들어 내는 과정 전반에서 다양한 역할을 수행해야 합니다. PM이 관리해야 하는 영역을 PMBOK(Project Management Body of Knowledge) 6판 기준으로 요약해 보면 다음과 같습니다.
- 통합 관리: PM의 권한을 획득하고, 통합 관리 계획을 수행
- 범위 관리: 요구사항을 수집하여 정의 하고 변경을 관리
- 일정 관리: 활동을 정의하고 일정을 개발하여 모니터링
- 비용 관리: 비용을 측정하고 예산을 책정하여 관리
- 품질 관리: 품질 관리 계획에 따라 품질 관리 및 보증
- 자원 관리: 자원을 확보하고, 팀을 개발하고 관리
- 의사소통 관리: 의사소통 관리 계획에 따라 관리하고 모니터링
- 리스크 관리: 리스크 식별 및 대응 계획을 수립 후 모니터링
- 조달 관리: 고객에게 결과물 조달 계획을 수립하여 확보 후 조달
- 이해관계자 관리: 이해관계자를 식별하고 관리 및 모니터링
PM과 개발의 역사
예전 개발 방식은 폭포수(Waterfall) 방법론을 주로 활용했습니다. 큰 요구 사항이 정해져 있고 WBS(Work Breakdown Structure)로 목표를 개별 개발자에게 할당할 수 있을 정도까지 세분화합니다.
이 방법론은 요구 사항이 명확하며 변경이 최소화되어야 합니다. 이를 위해 기획 과정에서 요구 사항을 명확히 파악하고자 제품 분석, 고객 인터뷰, 대안 개발, 심화 워크숍과 같은 활동이 필요하고 변경 통제를 위한 변경 관리 위원회(CCB, Change Control Board)도 운영해야 합니다. 하지만 고객의 요구 사항을 아무리 구체적으로 정의해도 외부 비즈니스 환경에 의해 변경 사항이 발생할 수밖에 없었고 개발자는 이에 대응해야만 했습니다. 이러한 상황은 일정 지연과 함께 프로젝트 팀원의 피로도를 높여 리소스를 추가로 투입하게 만들었고 결국 사업 수익성에 좋지 않은 영향을 미치게 되었습니다.
스크럼 마스터와 프로덕트 오너
개인의 소프트웨어 사용이 보편화 됨에 따라 소프트웨어 시장은 엔터프라이즈 SI 개발 중심에서 개인화된 컴퓨터와 모바일 중심의 비즈니스 시장으로 빠르게 바뀌었습니다. 그러나 전통적인 폭포수 방식으로는 빠른 개발을 통한 신속한 시장 진입이 어려워졌습니다. 변화에 좀 더 민첩하게 대응할 수 있는 새로운 개발 방식이 요구되면서 애자일 방법론이 등장했습니다.
애자일의 기본 원칙은 가치 있는 소프트웨어를 지속적으로 전달하여 고객을 만족시키는 것이었습니다. 애자일 원칙을 따르는 여러 개발 방법론 중 스크럼 방법론은 2~3주간의 스프린트 결과물을 모든 이해관계자와 같이 확인하고 다음 스프린트를 계획합니다. 피드백을 수렵하고 목표를 조정한 후에 다시 스프린트를 진행함으로써 변경에 대한 유연성을 갖고 고객의 가치에 좀 더 가깝게 다가갈 수 있게 되었습니다.
프로덕트 매니저, 프로그램 매니저
최근 소프트웨어 영역에서 등장한 큰 변화는 바로 SaaS(Software as a Service)입니다. 소프트웨어를 '설치'하는 시나리오는 점점 고려하지 않게 되었고 IaaS(Infra as a service)와 PaaS(Platform as a service) 등의 클라우드 기술이 급속도로 발전하면서 고객에게 가치를 빠르게 제공할 수 있는 SaaS 형태의 소프트웨어가 주를 이루는 시대로 전환되었습니다.
PM으로서 수행해야 할 직무 설명 및 노하우
프로젝트 사업수행 시 작성되는 가종 산출물 예시 및 작성가이드라인
프로젝트 수행단계별 PM으로서 리스크 관리방안 실제경험 사례를 통한 방안제시
일정지연의 발생소지가 보일 경우 PM으로서의 대처방안
WBS, 주간보고, 인력투입계획서 등을 통해 리스크 관리하는 방안
- 고객의 추가요구사항 때문에 일정지연이 예상될 때 PM으로서의 대처하는 방안
- 팀원과의 문제(개발속도, 타 개발자의 불협화음) 발생 시 PM으로서의 대처하는 방안
- PM으로서 어느 부분까지 업무를 파고들어야 하는지에 대한 가이드라인
- 고객과의 관계가 악화되었을 경우 PM으로서의 대처하는 방안