by
May 25. 2023
PM의 프로젝트 관리의 모든 것
IT 기획자는 기획만 하지 않는다
우리나라 IT회사의 기획자는 대부분 PM, 즉 Project Manager의 역할도 같이 하고 있다.
그말인 즉슨, 기획서만 쓰는 것이 아니라 디자인, 개발, 타부서 팀원들이 모인 프로젝트를 계획하고, 리딩하고, 조율해야한다는 이야기이다.
“쪼렙씨, 이 프로젝트 규모가 크긴 하지만, 전체적인 매니징 부탁드려요”
(3개 법인 합작 / 유관 부서 담당자 셀 수 없음)
특히 이렇게 다양한 팀(더나아가 다른 법인)이 모여서 하나의 프로젝트를 진행하는 경우,
생각하는 것보다 59320만배는 더 힘들고 매니징해야 할 것이 많다.
가끔은 정말 가짜 웃음도 나오지 않는 상황이다…
출처 - 최고심하지만 기획자의 역할이 다양한 이해관계자를 설득하고 세상 밖에 무언가를 선보이는 일이라는 점에서는 프로젝트 매니징도 꼭 필요한 역량이다.
다만 시중의 프로젝트 관리 관련해 아티클과 서적을 찾아보면
너무나도 방대한 이야기에 머리가 지끈지끈하다.
당연하다.
‘프로젝트 관리’는 자격증이 있을 정도로 넓고 깊은 분야이기 때문이다.
이번 아티클에서는 IT 기획자의 입장에서,
전체 프로젝트 과정에서 챙겨야 하는 것들은 무엇이 있을지 짚어본다.
이런 것을 얻어갈 수 있어요!
- 킥 오프 미팅에서 다루어야 하는 아젠다
- 프로젝트의 진행상황을 체크하는 방법
- 프로젝트 종료 후 챙겨야 하는 것들
프로젝트 시작 전
: 킥오프 미팅에서 합의해야 하는 것
1. 킥오프 미팅이 필요한 이유
본격적인 프로젝트를 시작하기 전에, 보통 프로젝트의 시작을 알리는 ‘킥 오프 회의’를 잡는다.
보통 이 회의는 가벼운 아이스브레이킹으로 시작하지만,
프로젝트 전체 방향성을 잡는 아주 중요한 시간이기도 하다.
킥 오프 미팅의 목적을 알면, 회의에서 어떤 것을 정해야 하는지도 확실해진다.
킥 오프 미팅의 목적은 크게 세 가지라고 볼 수 있다.
프로젝트의 필요성과 목표를 합의한다.
: 이 프로젝트는 왜 진행하는 것이며 우리가 얻고자 하는 것이 무엇인지
프로젝트의 영향 범위를 규정한다.
: 작업 범위, 스펙을 어느 정도로 할 것인지
라포 형성을 통해 협업의 기반을 갖춘다.
: 프로젝트도 결국 사람이 하는 것. 원활한 커뮤니테이션을 위해 좋은 첫인상을 주기.
2. 킥오프 미팅에서 다루어야 하는 아젠다
위에서 설명한 목적을 달성하기 위해, 킥 오프에서 함께 다루어야 하는 아젠다를 살펴보자.
프로젝트 개요 및 배경 (Outline & Background)
킥 오프 미팅에 참여한 각 이해관계자들에게, 프로젝트를 진행하게 되는 배경과 그 내용을 설명한다.
어떠한 맥락에서 이 프로젝트를 진행하게 되었는지에 대해 설명하고 모두가 공감하게 되면, 모두가 동일한 목표를 향해 달려갈 수 있는 확률이 높아진다.
특히 일이 많은 개발 부서의 경우 각 과제에 우선순위를 부여하고 처리하게 되는데, 프로젝트 매니저가 프로젝트의 배경을 상세히, 그리고 살짝 간절하게 설명하면 우선순위가 높아지는 기적이 일어날 수도 있다.
프로젝트 목표 (Objectives & Key Goals)
프로젝트 진행을 통해 궁극적으로 달성하고자 하는 목표가 무엇인지 설명한다.
물론 이 목표는 앞서 말한 프로젝트의 배경과 밀접한 연관이 있을 것이다.
프로젝트를 진행하다보면 분명 여러 고난과 이슈를 만나게 된다.
이때 우리 목표와 성과가 무엇인지 확실하다면, 근본적인 해결책을 찾기도 쉬워진다.
성과에 큰 영향이 없다면 노운 이슈로 정할 수도 있다.
그리고 프로젝트의 성과를 측정할 수 있는 지표는 구체적일 수록 좋다.
예를 들어서 프로젝트의 목표가 ‘네이버 PC버전에서도 모바일과 같은 사용성 제공’이라고 치자. 이때 성과 지표는 ‘모바일에서 주로 사용하던 기능의 PC 사용률 증가’이 될 것이다. (물론 수치가 중요하지 않은 프로젝트도 있다. 예를 들어 휴면고객의 개인정보를 분리보관하는 프로젝트라면, risk hedge 차원에서 일정에 맞춘 배포 자체가 더 중요한 프로젝트일 것이다.)
중요한 건, 구성원 모두가 성과 지표에 동의해야 한다는 것이다. 기획에서 중요하게 여기는 성과지표도 마케팅이나 사업부서, 또는 개발 부서에서는 다르게 생각할 수 있다. 그러므로 킥오프미팅에서 여러 부서의 의견을 종합해, 모두가 납득할 만한 성과지표를 설정하는 과정을 거쳐야 한다.
어떻게 하면 분명한 성과 지표를 정의할 수 있을지는 아래 글을 참고해보자.
주요 과업 (Scope)
배경과 목표를 명료하게 정했다면, 다음은 범위를 정해야 한다.
다른 분야에서도 마찬가지겠지만, IT 회사에서는 여러 시스템이 긴밀하게 연결되어있는 경우가 많기 때문에, 범위를 정하지 않으면 과업이 끝도 없이 넓어지게 된다 (슬프게도 경험담).
특히 이때에는 합리적인 기준을 먼저 정의하는 것이 중요한데, 프로젝트 진행 시에 마치 몬스터마냥 튀어나오는 각종 고려사항을 동일한 기준으로 판단해야 하기 때문이다.
예를 들어 네이버 PC웹 개편 논의에서, 신규로 만든 기능을 모바일 앱에도 적용하자는 이야기가 나왔다고 하자. 이왕 만든 거, 같이 적용 하자고 생각할 수도 있지만, 우리의 scope을 PC로 정의했다면, 모바일 앱은 추가 리소스가 드는 작업이다. 명확한 기준을 잡고 어디까지 작업 범위로 정해두면, 범위 밖의 이야기가 나올 때마다 치열하게 논의하지 않고, 빠르게 의사결정이 가능하다.
타임라인 (Time line)
큰 프로젝트일 수록 세부 과제가 많을 텐데, 이걸 어떻게 쪼개고 언제 진행할지를 미리 정해놓지 않으면, 대혼란이 시작된다. 여러 개가 동시다발적으로 진행되어 관리가 안되기도 하고, 아니면 다음 과제는 언제 시작해야할지 애매하게 홀딩되는 사태가 발생할 수도 있다.
그러므로 먼저 1)WBS를 작성하고 2)타임라인에 따라 정리하는 것을 추천한다.
1) WBS 작성
WBS란 Work Breakdown Structure의 약자로 업무 분업 구조를 의미한다. 프로젝트를 효율적으로 진행하기 위해 프로젝트를 실행가능한 작은 단위로 쪼갠다.
최상위 항목은 프로젝트의 목표(goal)이고, 프로젝트에 포함된 결과물(outcome), 결과물을 만들기 위한 주요 업무(task), 주요 업무를 쪼갠 세부 업무(activity)를 계층 형태로 표현하며, 각 항목에 따른 산출물(output)을 관리한다.
아래는 네이버 PC 개편 프로젝트를 WBS로 매우 간단하게 작성해본 예시이다.
2) 타임라인 작성
타임라인이란, 앞서 정리한 주요 과업을 각 부서에서 어떤 시간 순서에 따라 진행할지를 정리한 차트라고 할 수 있다.
위에서 정한 WBS들을 우선순위로 나누어 작업기간에 맞추어 배치한다. 작업 기간은 PM 혼자 산정하기 어렵기 때문에 개발자와 함께 논의해서 산정하는 것이 좋다.
여기까지 정리한 내용을 바탕으로 타임라인을 아래와 같이 그려보자.
요즘은 스프레드시트에서도 기업 계정에는 타임라인 기능을 제공하고 있다.
회사 계정으로 기깔나는 타임라인을 만들어보자.
3) 마일스톤 선정
마일스톤이란 프로젝트 계획에서 진척 상황을 나타내는 강력한 이정표이다.
단기적 사업 계획 또는 실적 목표. 장기적인 목표의 달성 과정에서, 순차적으로 세운 단기적인 목표들을 포괄한다. 예를 들어 네이버 PC 개편이라면, 5월 마지막주까지는 위젯보드 구성 기획 완료, 6월 둘째주까지는 최종 PC 디자인 확정, 7월 말까지는 API 연동 완료 등으로 마일스톤을 정의할 수 있다.
아래와 같은 시점을 마일스톤으로 잡는 것이 좋다.
중요한 작업을 표시
단계가 종료되는 때를 강조
주요 이벤트나 결과물을 집중 조명
목표와 주요 결과를 달성하는 것에 집중
중장기 프로젝트의 경우, ‘로드맵’이라는 좀 더 거창한 이름이 되기도 한다. 중장기 플랜이 필요하다면 아래 아티클을 참고하자.
운영 방식 (Operation Plan)
어떤 식으로 프로젝트를 운영할 것인지에 대해서도 합의가 필요하다.
1) 주기적으로 함께 모여 진행 상황을 체크하는 스크럼 회의는 얼마나 자주 진행할지?
2)주요 업무 협업 툴은 무엇으로 할지?
3) 각종 논의 사항 결정에 대해서는 누가 최종 검토할지? 등을 정하는 것이 필요하다.
운영 방식에 대한 합의는 사소한 것 같지만 프로젝트의 능률을 올리는 데에 큰 영향을 미친다.
많은 연구가 효율적인 커뮤니케이션의 부재가 프로젝트의 성패를 좌우한다는 것을 뒷받침한다.
프로젝트 팀 (Project Team)
귀엽지만 프로젝트 팀의 구성 역시 짚고 넘어가는 것이 필요하다.
누가 어떤 것을 담당하는지 킥 오프에서 소개하면, 추후에 혼선을 방지할 수 있다.
특히 큰 프로젝트인 경우, 과제별로는 담당자가 달라지기도 한다.
특정 과제는 어떤 담당자가 필요한지를 이야기하는 것이, 담당자의 리소스 관리도 되고 추후 혼선을 막을 수 있다.
(물론 온라인이든 오프라인이든, 서로 자기 소개도 하면서 라포 형성을 하는 것이, 긴밀하게 협업하는 데에 도움을 주기 때문이다.)
프로젝트 진행 도중
: 프로젝트가 지연되지 않게 하려면?
1. Project Status Report
실제로 프로젝트가 진행되는 동안은, 정해진 일정에 따라 프로젝트가 진행될 수 있도록 관리하는 일이 가장 중요하다. 그게 프로젝트 매니저가 하는 일이기 때문이다. 여기에는 정해진 왕도가 없다. 프로젝트에 따라 생길 수 있는 문제 상황과, 유관 부서에서 충돌하는 이슈들은 너무도 다양하기 때문이다.
하지만 프로젝트가 심각하게 지연되기 전에, 리스크를 미리 감지할 수 있는 방법은 있다.
바로 Project Status Report를 작성하는 것이다. (국내에서 잘 알려진 개념은 아니다. 필자도 솔직히 말하자면, 이번 주제를 공부하면서 처음 알게 된 용어다.)
Project Status Report는 거창해보이지만, 말 그대로 프로젝트의 현 상황을 작성하는 문서라고 할 수 있다. 상사 뿐만 아니라 프로젝트의 구성원이 모두 확인할 수 있어야 하며, 현재 봉착한 문제상황과 향후 계획까지 한 눈에 확인할 수 있어야 한다. 프로젝트에 따라 포함되는 내용은 다를 수 있으나, 보통 아래와 같은 항목들로 이루어져 있다.
프로젝트 이름 & 프로젝트 상태
바쁜 상사도 문서의 앞부분만 보고 프로젝트의 현 상태를 파악할 수 있도록, 프로젝트 이름과 함께, 프로젝트의 전체적인 상태를 기재한다.
- 프로젝트 이름: 네이버 PC웹 화면 개편
- 프로젝트 상태: 타임라인 대비 지연
전체 진행 상황 (Overall Progress)
이전 리포트와 비교했을 때 진척된 상황을 정리한다. 특히 기존에 합의했던 프로젝트의 타임라인과 비교했을 때 특이 사항을 위주로 기재한다. 세부 과업 중 끝낸 과제, 도달한 마일스톤 등이 있다면 함께 기재한다.
- 최종 디자인 시안 확정이 지연됨에 따라 마크업 작업이 대기중
- 전체 위젯 서비스 API 개발 완료
주요 성과 (Key Accomlishments)
구체적으로 이전 리포트 대비 얻은 성과 또는 완료한 과업을 기재한다. 예를 들어 주요 단계(phase)의 완료일 수도 있고, 주요 기능의 구현 등이 있다. 만약 설계서나 디자인 가이드 등 특정 아웃풋이 준비되었다면, 함께 첨부하는 것도 좋다.
- 최종 디자인 시안 확정 완료 디자인 시안 바로가기
- 인증 API 개발 완료 API 명세서 보기
주요 이슈 (Issues and Challenges)
정책이나 Spec 변경 등, Project 진행에 있어 함께 공유할 만한 이슈를 정리한다. 해결 가능한 문제라면 해결 법을 기재할 수도 있고, 함께 모여 논의가 필요한 경우라면 추후 해결 계획 등을 정리할 수도 있다.
- 기존 데이터 마이그레이션 이슈: 개인정보 보호 검수 필요
- 웹 접근성 이슈: 상세 설계 누락으로 차주 초까지 설계 예정
더 많은 예시는 아래 페이지에서 확인할 수 있다.
바쁜 와중에 Project Status Report까지 작성하는 것은 여간 번거로운 일이 아니다. 보다 효율적인 방법은, 정기적인 스크럼을 Project Status Report를 기반으로 진행하는 것이다. 정기 회의 전 까지 각 담당자가 Wiki나 노션에 이번 주에 완료한 일 및 이슈를 정리하고, 이를 기반으로 스크럼을 진행하면, 따로 Project Status Report를 새로 작성할 필요가 없다.
2. 프로젝트가 이상적으로 진행되기 위해 PM에게 필요한 Soft Skill
솔직히 말해서… 관리방법에 대한 이론적 지식을 갖추더라도 커뮤니케이션 스킬이 부족하면 프로젝트 관리는 매우 힘들다. “어떻게 하면 능숙하게 팀원들을 관리할 수 있지? 결국엔 짬바가 답인가?” 라는 고민을 한 적도 많다.
