PM의 A to Z (macbethi 님의 PM 오프라인 강의 후기)

강의개요

강의 일시/장소 - 2021. 7. 3 12:00 ~ 19:00 (7시간), 홍대 4번 출구 근처 홍대 한빛미디어 1층 리더스홀

강의 내용 - 에이전시 PM 기준 PM A to Z 강의

강의 진행자 - macbethi (맥비)

* 7.10 (토) PM 산출물 관련 강의로 이어짐

* macbethi 님께서 강의내용 무한 수정, 무한 배포 가능하다고 하셔서 강의 내용 들으면서 열심히 기록했던 자료 블로그에 남깁니다.

* 큰 범주의 내용만 기록, 그 안의 세세한 샘플 산출물 진행 과정 등의 내용은 기록하지 말고 머리로 따라가 이해하고 넘기기, 중간 중간 이해하려다가 기록 못하고 빠진 큰 범주 내용도 많음

* 내 포지션에 필요한 것은 취하고 불필요한 것은 버리기. 두 세번은 더 보고 지식 내꺼로 만들기. 기록 남기기

 

<< 12:00 ~ 13:20 >>

(macbethi님 개인적 경험을 바탕으로)
제안-구축-운영 프로젝트의 프로세스를 A부터 Z까지 훑으면서 (에이전시 위주)
그 안에서 PM의 역할을 살펴보고(PC사이트 위주)
그들이 무엇을, 어떻게, 왜 그러한 역할을 수행하고 산출물을 내야 하는지를 중점으로

프로젝트의 시작 (아폴로 달탐사 계획)

'1957 소련이 최초로 인공위성 발생
'1958 미국이 NASA를 설립
'1961 소련이 최초로 대기권 밖 유인 비행(유리 가가린)
'1962 미국의 케네디 대통령이 아폴로 계획을 발표(70년대가 오기 전에 달에 사람들을 착륙시키고 귀환 시키겠다)
'1969 미국이 최초로 유인 우주선을 달에 착륙

어떤 기술을 가진 사람들이 몇 명 투입되어야 하는지의 인력관리
비용지급, 예산확보를 어떻게 해야 하는지의 비용(예산)관리
연도별 일정을 어떻게 진행할 것인지의 일정(진척률)관리
품질을 어떻게 확보하고 검증할 것인지의 품질관리
각 단계별 어떤 산출물이 나와야 하는지의 산출물 관리 등의 체계화를 하기 시작

'1961 RFI(Request For Information)
'1962 RFP(Request For Proposal), 착수보고
'1963 요구사항 확인, 파트별 설계, 파트별 구현
'1966 개발완료
'1967~68 검수, 테스트, 수정, 보완
'1969 사이트 오픈

프로젝트의 3가지 특성 : 일정 / 비용 / 품질(인력) 3가지의 제한성 (의사 결정 판단 요소)
프로젝트란 : (하기로 한 일을) 정해진 기간에 제한된 비용으로 한정된 자원을 활용하여 진행되는 업무
프로세스 = 하기로 한 일 → 착수 | 설계 | 구현 | 검수 | 종료 → 한 일
하기로 한 일 = 수행범위
요구사항과 수행범위, 고객의 요구사항을 분석해 주어진 기간 안에 계약된 비용으로 할 수 있는 일을 확정해 진행하는 것
수행범위 → 착수 | 설계 | 구현 | 검수 | 종료 → 오픈
프로젝트 착수 시 가장 먼저 할 일 = 요구사항 분석

웹사이트 만드는 것이 건축하는 과정과 유사하다 (미국) → PMBOK (Project Management Body Of Knowledge, 프로젝트 방법론 참고 서적) 

착수 - PJT의 수행범위를 정의
설계 - 정의된 수행범위를 어떻게 만들것인지 설계
구현 - 설계된 수행범위를 파트별로 구현
검수 - 구현된 수행범위가 정상적으로 만들어 졌는지 검수
종료 - 검수한 수행범위를 납품

제안
제안을 할 수 있는 환경을 만들고 고객의 요구사항을 정확히 파악하여 고객이 원하는 것을 명확히 분석한 후 전략적으로 제안을 하는 단계

제안범위
RFP분석 - PJT의 수행범위를 정의
제안전략수립 - 정의된 수행범위를 어떻게 만들것인지 설계
제안서(시안)제작 - 설계한 수행범위를 파트별로 구현
제안서(시안)리뷰 - 구현된 수행범위가 정상적으로 만들어 졌는지 검수
PT(제출) - 검수한 수행범위를 납품

폭포수 방법론 기반 계약의 근거, 설계의 근거, 구현의 근거, 검수의 근거 (수행범위)

애자일 선언(방법론) - 스크럼 회의, 페어 프로그램, 개발자 친화적
에이전시 쪽에서는 애자일 보다는 폭포수 방법론이 많이 사용

요약
우리가 진행하는 것은 요구사항이 아닌 수행범위다.
수행범위는 우리한테 주어진 일정, 비용, 인력 3가지를 가지고 고객의 요구사항 안에서 뽑아내는 것이다.
프로젝트는 3가지 특성이 있다.
일정, 비용, 인력이 한정적이다.

 

<< 13:35 ~ 14:30 >>

착수
"프로젝트를 수행할 환경을 만들어 수행범위를 정의하고 고객과 합의하여 계약을 완료시키는 단계"
수행할 환경을 어떻게 만들거냐? 수행범위를 어떻게 정의할거냐? 계약을 어떻게 완료할거냐?

준비 (수행환경을 만들고)
1. 구축환경 구성
 - 인력배치(PM/TF선정, 선정인력에게통보)
 - 협업도구 선정
 - (내부)킥오프 미팅(킥오프 자료준비, 킥오프)
2. 1 (CASE A, 수행범위 확정 후 계약) 요구사항 분석 ((고객)요구사항파악, 고객확인)
 - 수행범위 정의(WBS설계, 고객확인, 수행범위확정)
2. 2 (CASE B, 계약 후 수행범위 확정) 계약범위 정의 
 - 요구사항 분석(요구사항분석, 고객확인)
 - 수행범위 정의
3. 프로젝트 계약
 - 견적산출
 - 계약서 작성
 - 고객확인
 - 계약서 날인

구축환경구성 (프로젝트를 진행하기 위한 최적의 환경[인력,시스템 등]을 구성한다.)
인력배치
- 프로젝트를 진행하기에 적합한 인력을 구성한다.
- 모든 문제의 시작은 사람이다. 해당 프로젝트에 최적화된 인력들로 구성되어야 PM의 '맘고생'이 최소화 된다.
협업도구 선정
- 체계적인 프로젝트 진행을 위한 인프라를 만든다.
- 프로젝트에 적합한 협업도구를 선정하면 PM의 손과 발이 편해진다.
(내부)킥오프
- 프로젝트 스펙을 정확히 파악해서 구축TF와 공유한다. (수행할 프로젝트의 이해도를 높이기 위해 구축에 관련된 자료들을 분석하여 프로젝트 기간/범위/요구사항 등)
- 결과를 만드는 것은 팀원들이고 PM은 팀원들이 한 곳을 보고 달려갈 수 있게 해야 한다.

요구사항분석 (고객이 프로젝트를 통해 얻고자 하는 것이 무엇인지 빠짐없이 파악한다. 고객의 요구사항을 명확하고 정확히 파악해야 PM이 프로젝트를 제어할 수 있다.)
(고객) 요구사항파악
- 고객이 프로젝트에서 얻고 싶은 목적, 기능 등이 무엇인지 고객의 입장에서 파악하는 것
- PM+파트별 Director / 제안서, 요구사항분석서 샘플, 요구사항분석 가이드
고객확인
- 분석된 요구사항을 고객과 공유하여 확인하는 것
- PM+기획자 / 요구사항 분석서, Use Case Diagram

요약
계약 하기 전에 요구사항을 파악하는 것이 좋다. (CASE A, 수행범위 확정 후 계약)

 

<< 14:45 ~ 15:45 >>

요구사항도출 회의
- 정의 : 고객의 개발요구사항을 도출해 내기 위한 고객-수행사 간의 미팅
- 목적 : 고객의 개발요구사항을 명확히, 정확히 파악
- 참석자 : 고객(의사결정권자, 실무진행자), 수행사(PM, 기획자, 개발자)
- 사전준비 : 고객에게 회의 내용을 알리고, 고객이 준비해야 하는 사항이 있을 경우 요청
- 주의 : 고객에게 워크숍에서 도출된 사항이 모두 개발되어지는 것이 아니라는 것을 주지시킴
- 진행기간 : 회의 시작일로부터 1~3일 이내

요구사항도출 회의 진행순서
→ 수행사는 기존 서비스 또는 신규 서비스에 대한 이해를 선행
→ 고객-수행사 간 인사, 고객의 비즈니스 요구사항(개요(배경)/목적/목표)를 리뷰
→ 이용자를 정의하고, 이용자가 핵심 서비스를 이용하는 프로세스를 메뉴별 또는 기능별로 UseCase Diagram을 이용하여 파악
→ 하드웨어/소프트웨어/네트워크 요구사항과 진행 시 주의사항 파악
→ 관리자 요구사항 파악
→ 미결사항 파악 및 요구사항 최종정검

요구사항에서 수행범위 추출과정 (7단계)
- 요구사항 도출 - 고객이 구현 및 개발하기 원하는 사항이 무엇인지 파악하는 것 (listing) → 고객으로부터 전반적인 핵심기능과 서비스를 도출하고 사용자의 이용흐름을 파악한다.
- 요구사항 분석 - 도출된 요구사항을 분석기준에 맞춰 분류 하는 것 (grouping) → 도출된 요구사항의 이해도를 극대화 한다.
- 고객확인 - 분석된 요구사항을 고객에게 공유하여 확인하는 것 (checking) → 고객의 요구사항을 명확히 한다.
- WBS 작성 - 확인된 요구사항을 관리 가능한 최소단위로 나누어 개발소요기간(개발공수)을 산정하는 것 (making WBS) → 파트별 실무자가 요구사항을 분석하여, 정확도가 있는 개발소요기간을 산정한다.
- 수행범위 협의 - 고객의 요구사항 중 프로젝트 기간 내에 수행할 요구사항을 조율하는 것 (re-checking) → 프로젝트 환경(목적/예산/일정.인력)을 고려하여 실제 수행 가능한 수행범위를 정의한다.
- 수행범위 정의 - 고객과 수행사가 프로젝트 기간 내에 완료할 요구사항을 확정하는 것 (define) → 확정된 수행범위를 문서화하여 서로 sign-off 한다.
- 수행범위 관리 - 확정된 수행범위가 프로젝트 기간내에 정상적으로 구현될 수 있도록 관리하는 것 (managing) → 고객의 수행범위 변경사항이 프로젝트 (목적/예산/일정/인력)에 방해되지 않도록 관리 및 방어한다.

Use Case Diagram 작성 중 피해야 하는 용어들
- 수용가능, 적합, 가능한 한, 최소한, 적어도, 초과하지 않도록, ~사이, ~에 따라, 효율적인, 빠르게, 신속하게, 유연하게, 더 좋게, 더 빠르게, 우수하게, 포함하여, 등등, 와 같이, 그 밖에, 최대로, 최소한, 최적화, 일반적으로, 선택적으로, 여러 가지, 기존의 지원하는, 가능한 간단한... 등

WBS(Work Breakdown Structure) 작성
우리가 해야 될 일을 분해해 놓은, 쪼개어 놓은 구조
W - (우리에게 주어진 일정/비용/인력으로) 해야 될 일을
B - (더 이상 나눌 수 없을 때까지)분해해 놓은, 쪼개어 놓은
S - 구조

 

<< 16:00 ~ 17:15 >>

수행범위 정의
목표 - 고객의 요구사항 중 실제 프로젝트 조건(기간/인력/견적)에서 수행가능한 사항들을 정의한다. (고객의 요구사항을 명확하고 정확히 모두 파악해라. 그래야 PM이 프로젝트를 제어할 수 있다.)
요구사항 분석 - 고객의 요구사항을 명확하고 정확하게 파악
WBS 작성 - 파악한 요구사항을 구현하기 위한 개발일정을 산정 (Hell 프로젝트가 되는 가장 직접적인 원인은 잘못된 WBS설계. Hell 프로젝트 PM 되기 싫으면 WBS설계 방법을 알아야 함)
수행범위 정의 - 고객의 요구사항 중 수행사에게 주어진 기간과 예산에 실제적으로 할 수 있는 것을 확정 (프로젝트는 수행범위의 계약으로 시작해 수행범위의 검수로 끝난다.)
- 고객 협의 : WBS를 근거로 개발기간, 예산, 투입인력, 추가예산을 고려해 실제 프로젝트 기간 내에 수행할 범위를 조정(PM, 요구사항분석서/WBS/개발우선순위표)
- 수행범위 정의 : 고객과 프로젝트 기간 안에 완료할 수행 범위를 합의하는 것 (PM, 요구사항분석서/WBS→수행범위정의서)

프로젝트 계약
목표 - 계약 내용을 명확히 하고 정확한 견적을 산출해 계약한다.
견적산출 - 수행범위/일정/투입인력계획을 명확히 파악하여 정확하게 비용계산을 한다. (견적산출내역을 확인해라. 그래야 프로젝트 조정변수(인력/기간/범위)를 선택할 수 있다.)
- 수익률 계산 : 해당 프로젝트의 전체 진행비용과 수익율을 계산하는 것 (PM, 수익율관리표 샘플 → 수익율관리표)
- 견적서 작성 : 수행범위/일정/투입인력계획을 기초로 프로젝트 수행비용을 문서화 하는 것 (PM, 수익율관리표,견적서샘플 → 견적서)
직접인건비(Man/Month, 등급별로 많이 진행) - 등급별(특/고/중/초급), 내부(부장/차장/과장/대리/주임/사원), 직무별(직무별SW평균임금)

본인 회사 쪽에 최적화된 표준계약서를 보유하고 제시하면 문제를 최소화할 수 있음
ex) [납기 부분]
1. 납기란 "을"이 본 계약을 통하여 수행한 본건 업무를 "갑"이 지정하는 장소에서 "갑"에게 납품하여야 할 기한을 말하며, 납기 기간은 오픈일을 포함한 프로젝트 기간과 동일하다.
2. 위 제5조 1항의 계약 내용의 변경, "갑"의 제반 자료 제공의 지연 및 프로젝트 주요 안건에 대한 의사결정의 지연 및 변경, "갑"의 요청으로 인해 정의된 수행범위의 변경 및 추가사항 발생, "갑"의 부대 시설 및 설치장소 미비, 통신선로의 불량 원인과 같이 "갑"의 귀책사유로 인한 납기 지연이 발생한 경우 본 조 제1항의 납기를 연기하며, 비용이 발생할 시 "갑"과 "을"이 상호 협의한다.
3. "갑"과 "을"이 상호 요구에 의하여 부득이 하게 납기일을 변경할 시에는 이를 협의하여 제5조 1항에 따라 계약내용을 변경하도록 한다.
4. "을"이 계약범위의 개발을 완료한 후 "갑"의 사정으로 인해 검수가 이뤄지지 않거나 완료일이 연기되었을 때 "갑"은 개발 완료시점에서 남은 잔금 중 50%를 우선 지급하고 차후 검수가 완료되었을 때 나머지 잔금을 지급한다.

 

<< 17:30 ~ 19:00 >>

프로젝트계획
수행계획서 작성 - 프로젝트 수행에 필요한 계획을 문서화
착수보고 - 프로젝트 시작의 공식화로 고객을 포함한 프로젝트 관련자들이 공동체의식을 갖게 한다. (프로젝트 관련자들과 프로젝트 시작을 공유, PM+TF+고객 / 수행계획서)
- 고객에게 착수보고가 필요한지, 필요하면 오프라인으로 진행할 것인지, 보고서로 갈음할 것인지 미리 확인
- 착수보고를 진행할 경우 별도의 보고서를 만들기보다 기 작성된 수행계획서를 활용
- 프로젝트 성격에 따라 수행계획서 제출로 착수보고를 대체하는 경우도 있으나 가급적 프로젝트의 전반적인 내용을 공유한다는 의미에서 오프라인으로 착수보고를 진행할 것을 권고
- 오프라인 착수보고 시에는 고객-수행사의 프로젝트 관련자들을 모두 참석시킨 후 양사의 업무정의 / 리스크 요소 등을 공유하는 것이 좋고, 해당 시점에서 미결사항을 언급해 빠른 처리가 되도록 유도하는 것도 좋음

프로젝트 관리도구 설계
프로젝트 관리도구는 착수단계에서 설계할 것을 권고하며, 상황에 따라 설계단계 초기에 진행할 수 있다.
- 리스크 관리 : 프로젝트 성공의 KEY, PM이 리스크관리를 못하거나 하지 않는다면 스스로 Hell 프로젝트를 만드는 것
- 보고 관리 : 고객이 보고받고 싶어하는 것을 확인. 그래야 두 번 작업하지 않음
- 일정 관리 : 일정관리(=진척률관리) 방법을 설계할 것. 그렇지 않으면 허위보고를 하게 된다.
- 수행범위 관리 : 수행범위 변경 시 대처방법을 설계해 고객과 합의. 고객의 요구사항과 수행범위는 언제나 변경된다.
- 미결사항 관리 : 미결정된 사항을 확인할 것. 지금까지도 결정이 안 된 것이라면 프로젝트를 롤백시킬 수도 있다.

설계
- (파트별로)수행범위의 이해도를 높인다. (파트별로 수행계획서에 포함된 파트별 수행범위를 리뷰, TF / 수행계획서)
- 리뷰 시, 수행범위의 변동사항이 있는지 확인. 변경 사항이 있으면 반드시 관련문서를 업데이트 할 것을 권고
- 미결사항에 대해 PM은 고객에게 미결사항이 프로젝트에 주는 영향을 주지시킴. 언제 미결사항을 해결할 것인지 협의

→ 메뉴설계 - 사이트의 정보구조 설계 (기획자, 메뉴설계서 샘플 → 메뉴설계서)
→ 고객확인 - 설계된 메뉴를 고객과 공유하고 확인받기 (PM+기획자, 메뉴설계서, 공유 후 고객의 의견 반영 업데이트, 확정 사항은 고객의 사인을 받을 것)
→ 콘텐츠설계 - 사용자에게 보여지는 화면을 기준으로 콘텐츠 수급사항을 정의 (기획자, 메뉴설계서, 신규 문서가 아닌 메뉴설계서에 콘텐츠 수급일정/담당/기존 콘텐츠 재활용 여부/신규제작여부/소스경로 등을 표시)
→ 프로토타입 설계 - (사이트 디자인 가이드 위해) 메인과 서브메인에 들어갈 메뉴, UI, 콘텐츠 샘플을 설계 (기획자, 메뉴설계서, 프로토타입 제작가이드 → 프로토타입, 본 Task가 기획인지 디자인인지 업체마다 다르기 때문에 지원 범위 사전에 협의할 것)
→ WBS 고도화 - 메뉴설계와 콘텐츠설계를 진행하면서 추가/수정/삭제된 사항을 착수단계에서 도출된 WBS에 업데이트 (PM, WBS → WBS) * 해야 될 일을 항상 최신으로 업데이트 할 것 (수행 범위의 완성)
→ 화면설계 - 개발사항을 문서 화면상에 visual 하게 표현하는 것 (기획자, 메뉴설계서, 콘텐츠수급계획, 화면설계서 샘플 → 화면설계서)
→ TF리뷰 - 설계된 기획을 내부 TFT와 공유해 기획의 타당성을 검증 (PM+TFT, 화면설계서, 기획내용 공유로 타 파트에서 무엇을 준비해야 하는지 알려주기 위함)
→ 고객확인 - 화면설계서를 고객과 공유하고 내용을 확인받는 것 (PM+기획자, 화면설계서)
* 설계 산출물을 고객에게서 승인받아라. 

→ (고객) 개발환경분석 - 고객의 하드웨어 사양, 소프트웨어 스펙, 네트워크 구성 등의 개발 환경 파악 (개발자)
→ (내부) 개발환경셋팅 - 고객의 개발환경과 유사 또는 동일하게 내부 개발환경을 구성하는 것 (개발자)
→ 개발표준 정의 - 개발의 진행가이드 및 방법론을 정의 (개발자, 개발표준 정의서 샘플 → 개발표준 정의서)

→ 디렉토리/파일명 정의 - 파일을 저장할 디렉토리 구조를 설계하고 파일 이름 명명규칙을 정의하는 것 (개발자 or 퍼블리셔, 파일명세서 샘플 → 파일명세서)

→ ERD설계 - 데이터 간의 상관도를 정의 (개발자, ERD정의서 샘플 → ERD정의서)
→ Table 정의 - 데이터 구조를 정의 (개발자, Table정의서 샘플 → Table정의서)
→ Interface 정의 - 기능을 구현하기 위해 요구되는 시스템간 / DB간 / 프로그램간 상관관계와 상관관계를 이해하는데 필요한 사항을 정의 (개발자, Interface정의서 샘플 → Interface정의서)

→ 퍼블리싱 가이드 정의 - 퍼블리싱에 필요한 규칙들을 정의하는 것 (퍼블리셔, 퍼블리싱 가이드 샘플 → 퍼블리싱 가이드)

구현
파트별 설계된 수행범위를 개발하고 TF가 프로젝트에 전념할 수 있게 관리하는 단계

프로젝트 관리
리스크 - 각 리스크별 대안을 실행. 프로젝트를 계획대로 완료할 가능성이 높다.
보고 - 허위보고 하지마라. 바닥으로 떨어진 신뢰는 되돌리기 어렵다.
일정 - 완료는 PM이 직접 확인한 것을 기준으로 할 것. 허위보고를 방지
수행범위 - PM의 프로젝트 관리능력 지표 (PM의 내공)
수익률 - 1개월 단위로 계획대비 실행을 점검. PM의 성과측정 지표

(파트별) 설계산출물 리뷰 → 화면설계서 확인 → 화면 디자인 → 디자인 검수 → 검수프로세스 → 퍼블리싱 → 퍼블리싱 검수 → 검수프로세스 → 메뉴별 개발 → 메뉴별 검수 → 검수 프로세스

검수 프로세스 (검수결과 전달 → 검수결과 처리 → 처리결과 확인 → 완료 → 검수 종료)
- 검수 기준을 마련하여 수행범위가 올바르게 개발 되었는지 확인하는 단계

착수 → 수행범위 만듬
설계 → 어떻게 만들건지 설계
구현 → 구현
검수 → 수행범위대로 잘 만들었는지 체크하는 단계

검수 계획서 작성 - 검수범위, 검수일정, 검수환경, 검수방법, 검수담당 등을 정의하는 것 (PM+기획자, 검수계획서 샘플 → 검수계획서, 필수는 아니나 검수계획을 세우면 사용자 테스트 환경에 따른 오류를 최소화 할 수 있다. 운영체제, 브라우저, 모바일기종 사용자 환경 등. 특히 모바일)
검수 시나리오 작성 - 개발이 완료된 모든 기능들을 테스트할 수 있도록 검수방법을 문서화 하는 것 (PM+기획자, 화면설계서, 수행범위 변경요청서, 검수시나리오 샘플 → 검수시나리오, 사용자가 이용할 수 있는 모든 경우의 수를 찾아내어 검수함으로써 기능의 오류를 최소화하는 것이 좋다. 이용자가 행동할 수 있는 모든 경우의 수를 찾아내 시나리오로 만들 것. 그래야 오류를 최대한 잡을 수 있다.)

개발 검수
* 수행사 자체적으로 수행범위에 정의된 모든 기능이 정상적으로 작동하는지 여부 확인
(개발서버에서) 검수 - 메뉴 별로 완성된 기능이 정상적으로 구현되었는지 확인하는 것 (기획자+검수자, 검수시나리오 → 검수결과)
검수결과 취합/전달 - 검수자로부터 검수결과를 취합해 실제 오류를 확인하고 오류로 판명된 것을 실무담당자(디자인/개발/퍼블리싱)에게 전달 (기획자, 검수결과)
검수결과 처리 - 검수 결과서에 기재된 오류를 수정하여 처리결과를 확신하는 것 (처리 담당자, 검수결과)
처리결과 확인 - 오류가 개선 되었는지 확인하는 것 (기획자+검수자, 검수결과)

고객 검수
* 고객이 접수자가 되어 요청한 기능이 정상적으로 작동하는지 여부 확인
고객검수 - 메뉴 별로 완성된 기능이 정상적으로 구현 되는지 확인 (고객, 접수시나리오 → 접수결과)
접수결과 취합/전달 - 검수자로부터 검수결과를 취합하여 실제 오류 확인하여 오류 판명된 것을 실무담당자에게 전달 (기획자, 검수결과)
검수결과 처리 - 검수 결과서에 기재된 오류를 수정하여 처리결과를 회신하는 것 (처리담당자, 검수결과)
처리결과 확인 - 오류가 개선 되었는지 확인 (고객+기획자, 검수결과)

설치 검수
* 고객의 서비스운영 환경에 맞게 데이터를 안전하게 이전
(운영서버로) 데이터 이전 - 실제 서비스할 고객의 운영서버로 개발서버의 데이터를 이전 (개발자, 데이터이전 계획서 샘플 → 데이터 이전 계획서, 검수시점은 사이트 오픈 바로전, PM이나 기획자는 데이터 이전 후 누락 데이터가 없는지 확인)
운영서버 검수 - 고객의 운영서버에서 기능의 이상유무, 완료여부를 테스트 하는 것 (TFT+고객, 검수시나리오, 테스트 전 테스트를 위한 기초데이터를 미리 입력해두는 것이 좋다.)
검수결과 취합/전달 - 검수자로부터 검수결과를 취합하여 실제 오류를 확인하고 오류로 판명된 것을 실무담당자에게 전달 (기획자, 검수결과, 고객검수 후 고객으로부터 합의된 기능 외에 추가/삭제/변경의 요청사항이 있을 경우 PM은 견적/일정/투입인력 등을 고려해 수락여부를 결정한다.)
검수결과 처리 - 검수 결과서에 기재된 오류를 수정하여 처리결과를 회신 (처리 담당자, 검수결과)
처리결과 확인 - 오류가 개선 되었는지 확인 (TFT+고객, 검수결과)

산출물 확인
* 검수단계에서의 산출물이 빠짐없이 도출되었는지 확인
산출물 확인 - 정의된 검수단계의 산출물이 도출되었는지 확인 (PM, 수행계획서>산출물정의 부분 → 파트별 산출물, 정의된 일정에 산출물이 도출되지 않았을 때 바로 도출하도록 유도할 것인지 특정 시점에서 한번에 도출하도록 유도할 것인지는 프로젝트 상황에 맞게 실시할 것)

종료 - 수행범위를 오픈하고 고객과의 합의를 통해 프로젝트 종료를 공식화하는 단계
외부 서비스 오픈 - 개발된 기능들을 고객의 요청일에 맞게 외부 서비스 (개발자)
오류 모니터링 - 외부 서비스 오픈을 한 후 발생되는 오류, 수정사항을 파악하는 것 (PM+기획자+고객, 오류리포트 샘플 → 오류리포트, 오류사항 발생 시 오류 사항이 내부 개발로 인한 것인지 아닌지를 판단하여 해당 실무자에게 바로 알려주고 수정함)
* 오류 발생을 확인. 오류가 없어야 프로젝트를 종료할 수 있다.

사용자매뉴얼 작성 - 관리자와 사용자가 개발기능을 원활히 사용할 수 있도록 도움말(이용가이드) 작성 (기획자+개발자, 사용메뉴얼 샘플 → 사용메뉴얼)
고객교육 - 고객 담당자에게 개발된 사용자 기능과 관리자 기능을 알기 쉽게 설명 (기획자+개발자, 사용메뉴얼)

산출물 검수
* 정의된 산출물이 모두 도출되었는지 확인하고 고객에게 전달
산출물 취합, 고객 전달본 제작, 산출물 전달

완료보고/검수확인
* 프로젝트 완료되었음을 고객과 공식적으로 공유하고 확인
완료보고서, 검수확인서, 검수확인서 sign

행정종료 * 프로젝트와 관련된 행정절차의 완료를 확인 - 세금계산서 발행, 잔금 수금

프로젝트 종료
* 프로젝트 완료 후 TFT가 프로젝트 진행사항을 Review하고 프로젝트 관련 파일을 정리하고 백업한다.
프로젝트 리뷰 - 착수단계부터 종료단계까지의 진행사항을 REVIEW (PM+TFT, 프로젝트 리뷰서 샘플 → 프로젝트 리뷰서, 해당 프로젝트를 진행하면서 나타난 장점은 다음 프로젝트에 적용하고 단점은 개선하기 위함. 리뷰는 TFT가 모두 참석하는 것이 좋음. TF와 프로젝트 리뷰를 해야 PM 스킬을 적립해 노하우를 쌓을 수 있음)
구축자료 정리&백업 - 구축폴더와 고객 및 TF와의 커뮤니케이션 자료 중 유의미한 프로젝트 자료를 판단하여 백업하는 것 (PM, 프로젝트산출물, 유의미한 산출물, 프로젝트 산출물 외에 진행산출물 중 유의미한 산출물을 추가해 백업하는 것이 좋음. 산출물을 구분할 것 진행산출물은 프로젝트가 진행되면서 도출되는 산출물이고 프로젝트 산출물은 고객에게 전달하는 공식적인 산출물)
고객만족도 설문, 고객카드 작성

 

<< 한줄 후기 >>

macbethi님이 진행하셨던 프로젝트들의 경험과 노하우를 바탕으로 에이전시 프로젝트의 A to Z의 전체적인 흐름, 그 안에서의 PM의 역할, 실제 샘플 산출물 기반으로 강의를 해주셔서 정말 값진 시간이었다.