09 PM이 알아야 할 일정 관리
"시간을 지배하는 자, 모든 것을 지배한다!“
어벤저스에서 가장 좋아하는 캐릭터가 닥터 스트레인지인것은 우연의 일치일까? 개인적인 삶에서도 시간을 통제하는 것은 매우 중요하다. 세상 불공평해도 세상 공평한 것이 모두에게 똑같이 주어진 24시간이기 때문이다. 24시간을 48시간처럼 쓰는 사람이 있는가 하면 24시간을 채 반도 제대로 쓰지 못하는 사람이 허다하다. 회사에서도 마찬가지다. 8시간 근무 시간 내에 엄청난 효율을 내고 칼퇴근을 하는 직원이 있는가 하면 더 많은 일을 하는 것도 더 높은 퀄리티를 내는 것도 아닌데 야근을 밥 먹듯이 하는 사람이 있다. 게다가 지각도 밥 먹듯이 한다. 내 시간 관리도 못하는 사람이 다른 사람들의 시간을 관리할 수 있을까?
일정 관리를 하는 이유는 여러가지 업무가 동시 다발적으로 일어나고 여러 사람들이 팀을 이루어 작업을 하기 때문에 효율적으로 업무를 진행할 수 있는 일의 우선순위와 세부 일정을 수립하여 작업의 진척을 관리하고, 진행 사항을 모니터링하면서 필요할 경우 계획을 변경하고, 일정이 지연될 만한 리스크가 감지되면 사전에 조치를 취하여 약속된 시간에 프로젝트를 완료하기 위함이다. PM은 전체 일정을 꿰고 몇 발작 앞서 나가 있어야 한다. 적을 알고 나를 알면 백전백승이라고 했듯이 일정을 전략적으로 컨트롤할 수 있는 PM이 기한 내에 프로젝트를 성공적으로 완료할 수 있다.
PM의 일정 관리라고 하면 모두가 WBS를 외쳐댄다. WBS를 일정 관리표로 흔히 알고 있는데 WBS, Work Breakdown Structure는 업무 세분화한 구조도를 의미한다. 이 구조도에 업무 담당자와 진행 일정을 기입하고 진척 관리를 하는 용도로 사용하기 때문에 일정 관리표라 생각하기 쉬운데 WBS의 목적은 업무를 세분화하는 것이고 일정 관리는 그 다음에 부수적으로 따라오는 것이다. 그러므로 프로젝트를 착수하자마자 완성된 WBS가 절대 나올 수 없다. 따라서 단계별 마일스톤을 먼저 계획하고 단계 진입 전, 그리고 단계 진입 이후로도 WBS는 계속 업데이트 되고 관리되어야 한다.
자, 그럼 지금부터 차근차근 일정 관리를 시작해 봅시다.
일정 관리 범주는 크게 다섯 가지로 분류된다.
1. 계약서상에 표기된 프로젝트의 공식 시작일과 종료일
2. 업무 진행 단계 마일스톤 (단계 일정)
3. 업무 세분화 계획 (WBS)
4. 프로그램 목록 (화면명세 기준 진척 관리)
5. TFT 내부 상세 일정 관리
1.
일정은 계약서에 표기된 공식 프로젝트 시작일과 종료일을 가장 큰 기준으로 설정한다. 계약서상에 표기된 일정이 아닌 다른 일정으로 협의가 된 경우 해당 협의 일정을 별도 협약 문서 또는 이메일을 통해 반드시 공유하고 공식화해야 한다. 공식화하지 않은 경우 프로젝트 말미에 항상 계약서대로 하시죠로 끝나게 되는 경우를 여럿 보았기에 깔끔하게 계약서대로 하는 것이 가장 좋겠지만 별도 협의를 진행하는 상황이 발생하더라도 반드시 근거를 남기고 공표하고 중간중간 확인하는 절차를 거치도록 한다. 또 한가지 놓치면 절대 안되는 중요한 일정 관리가 있는데 계약금 지금(선금/중도금/잔금)에 대한 일정 관리이다. PM은 계약서에 명시된 입금 기준일과 검수 산출물을 확인하고, 해당 시점에 관련된 제반 사항들을 진행한다. 작업 일정이 지연되면 산출물 완료 일정이 지연되는 것이고, 이는 곧 계약금 지급 지연으로 직결된다. 이 또한 계획 대비 일정이 지연되면 안되는 이유이고 일정 관리를 철저히 해야 하는 중요한 이유이다.
2.
프로젝트 착수 전 마일스톤 단위의 일정과 분석 단계 WBS를 먼저 수립한다. PM은 프로젝트 착수 전 이미 머리 속에 일정표가 그려져 있어야 하고 프로젝트가 시작되면 바로 업무에 착수할 수 있도록 사전 준비를 하고 있어야 한다. 사전에 공유받은 일정이 있다면 해당 내용을 검토하고 변경이 필요한 부분은 협의를 통해 조정하는 작업을 거친다. 구축 프로젝트인 경우 일반적인 마일스톤은 다음과 같다.
착수(착수보고) - 분석 - 전략(중간보고) - 설계 - 디자인 - 퍼블리싱(웹 또는 하이브리드 앱인 경우) - 개발 - 테스트 - 오픈(종료보고) - 산출물정리/안정화 - 종료
3.
단계별 일정을 세분화한 일반적인 WBS는 다음과 같다. 그리고, 각 단계는 병렬 진행으로 상세 일정을 수립하고, 매주 업데이트와 보고를 진행한다.
착수: 킥오프, 착수보고
분석: 요구사항정의/분석(사전에 AS-IS 분석이 진행되지 않았을 경우 함께 진행), 전략수립을 위한 조사/분석
전략: 상위 전략 수립, 상세 전략 수립, 디자인 시안(시나리오 포함), 프로토타입, 중간 보고
설계: 정보 설계, 네비게이션 설계, 화면설계 가이드, 화면 설계 작업 세분화
디자인: 디자인 가이드, 디자인 작업 세분화(보통 화면 설계 세분화 기준으로 진행)
퍼블리싱: 퍼블리싱 가이드, 퍼블리싱 작업 세분화(보통 화면설계 세분화 기준으로 진행)
** 개발은 생략 **
테스트: 단위 테스트 시나리오, 테스트/결함 수정, 통합 테스트 시나리오, 테스트/결함 수정
오픈: 이행, 인수테스트, 오픈
산출물정리/안정화: 공식/워킹 산출물 목록 작성, 산출물 파일 수집, 산출물 제출
종료: 철수
4.
화면설계 단계로 돌입하면 프로그램 목록 작업을 하고 본격적인 진척 관리가 시작된다. 전체 본수를 기준으로 화면 ID, 화면명, 화면별 작업자, 게획 시작일/계획 종료일을 기입하고, 업무가 실제로 착수되면 실제 시작일을, 업무가 실제로 종료되면 실제 종료일을 기입한다. 진척 관리의 핵심은 계획 대비 실제 작업 진행 현황을 관리하는 데 목적이 있으므로 계획 시작일/계획 종료일은 협의를 통해 계획이 조정되는 경우가 아니면 절대 수정하지 않는다. 프로그램 목록도 WBS와 함께 매주 업데이트하고 해당 내용을 기반으로 매주 진척 관리 보고를 한다. 프로그램 목록과 WBS 업데이트를 팀원들에게 시키는 PM들이 있다고 하는데 문서에 일정만 기입하는게 일정 관리가 아니고 작업이 착수되었는지 완료되었는지 직접 확인하고 시작과 완료 여부를 기입하는 것이 일정 관리를 하는 것입니다. 그러니 본인의 일을 남에게 시키지 말고 PM님들 직접 하세요!
5.
지금까지 언급한 일정 관리도 중요하지만 무엇보다도 중요한 일정 관리는 TFT 내부 일정 관리다. TFT 일정 관리를 위한 별도 세부 일정표를 만들고, 수시로 관리한다. 내부 일정 관리표는 공식 WBS보다 더 업무를 세분화(내부 리뷰 일정 포함)하고 기본은 일 단위, 필요할 경우 시간 단위로 관리를 한다. 그리고, 만약의 경우 본인이 직접 업무를 진행하거나 디렉팅 지원을 받거나 담당자를 교체하거나 인력을 교체해서 업무를 진행하는 일정까지 감안한 내부 일정을 생각하고 있어야 한다. 내부적으로 꼼꼼한 일정 관리가 이루어지면 진척 관리나 WBS 관리는 절로 된다.
시간 관리가 일정 관리이고, 일정 관리는 약속이고, 이는 또한 돈으로 직결된다. 시간은 돈이라는 말이 그냥 하는 말이 아닌 게 단계별 일정이 지연되면 일정 내에 산출물을 완료하기 위해 추가적인 인력이 투입되야 한다. 일정 지연이 누적되서 오픈일이 연기되면 투입 기간 연장으로 인한 지출이 발생한다. 원인의 제공이 우리가 아니면 추가 비용을 당당하게 요청할 수 있지만 원인의 제공이 우리인 경우 연장으로 인한 지출뿐만 아니라 추가적인 손해 배상으로까지 확대될 수 있다. 그리고, 일정에 대한 약속을 지키지 않으면 당연히 신뢰는 바닥으로 떨어질 수 밖에 없다.
마지막으로, 가장 기본이지만 가장 지켜지지 않는 근태. 출근은 하루 일정의 시작이니 시작부터 지각하면 안되겠죠? 프로젝트 기간 중 휴가는 미리 계획하고, 리더들과 협의하에 진행하며, 업무 대무자를 정하고, 인수인계가 필요할 경우 인수인계까지 진행하고, 필히 휴가 당사자는 휴가 하루 전 내부 TF에 휴가와 대무자에 대한 공지를 해 주시기 바랍니다. 팀원들을 관리해야 하니 PM은 당연히 이른 출근을 해야겠지요? 현업과 공유가 필요한 관련자들에게 팀원들의 휴가를 공지하는 것은 PM의 역할이구요. 이런 것까지 공유해야 하나 싶지만 기본이라 생각하는 것들이 지켜지지 않는 상황들을 많이 목격하다 보니 잔소리가 절로 나오네요.
새해에는 모범적인 PM님들이 많아졌으면 좋겠습니다.
새해 복 많이 받으세요!!
