주니어 기획자가 PM 경험한 썰
PM, 처음이 어렵지 다음에도 어려워요?
병준 님, 이번 프로젝트 한 번 리드해 보실래요?
"포브스 선정 이직하고 나서 듣고 가장 긴장했던 말 1위"
매번 사수의 그늘 아래서 할당된 업무를 하고 있었던 중 두렵지만 두근거리는 질문을 받았고, 첫 PM 업무를 맡게 되었습니다. 프로젝트가 끝난 지금에야 애써 웃을 수 있지만, 긴장의 연속이었던 프로젝트 리드. 이제 막 PM과 그 안의 기획 실무를 맡게 된 주니어 기획자가 프로젝트의 소용돌이 안에서 중심을 잃지 않고 목표까지 갔었던 경험에 대한 느낀 점들을 적어나가 보겠습니다.
1. 프로젝트 발생
문서화의 시작
프로젝트의 모든 내용은 팀원들이 눈으로 보고, 이해할 수 있어야 합니다. 따라서 아래의 요소들을 프로젝트의 첫 단추인 킥오프 미팅 전에 미리 생성해 놓을 필요가 있습니다.(회사마다, 관리자마다 다를 수 있으므로 참고 부탁드립니다)
- 개요
프로젝트가 시작된 배경을 설명함으로써 뒤에 나올 목표에 대한 이해를 돕습니다. 또한, 보통 개요에는 문제가 담겨있기 때문에 타 부서나, 다른 팀원들이 개인의 업무 우선순위 설정하기 위해 참고할 수 있어 중요합니다.
- 목표
프로젝트를 하는 진짜 이유입니다. 프로젝트가 끝났을 때 우리가 얻을 수 있는 현실적인 결과물을 정하며, 정량/정성적인 수치에 대한 이 목표는 수치화가 가능한 지표를 설정하여 달성했는가에 대해 판단하게 됩니다.
- 일정(Mile stone)
출처 : 본인킥오프 미팅을 시작으로 시작일과 완료일이 정해지고, 그 사이에 벌어지는 모든 일들은 일정에 맞춰 진행되어야 합니다. 일정은 동기부여의 원동력이 되기도 하고, 서로에 대한 신뢰와 책임감이 되기 때문입니다. 회의를 진행하며 확정된 일정들, 이슈 발생으로 조정되는 일정들을 실시간으로 반영하고, 팀원들이 파악할 수 있어야 해요.
- 참여 인원(타 부서, 팀)
참여 인원에 포함되었음을 서로가 투명하게 확인할 수 있다면 집단에 대한 소속감이 생기고, 책임감으로 이어집니다. 또한, 다른 업무 간에 필요한 인력 관리를 대략적으로 확인할 수 있다는 점에서 작성할 필요가 있습니다.
- 업무별 우선순위
모든 참여 인원이 하나의 프로젝트 또는 업무만 진행하고 있지는 않습니다. 따라서 먼저, 프로젝트 내 업무(기능, 요소별 등)들의 우선순위와 각 담당자들의 기존 업무 우선순위를 고려하여 이해상충 나지 않도록 설정해야 합니다.(이 요소는 지라를 사용하는 게 편합니다)
- 회의록
출처 : 본인제 경험상 가장 중요한 부분이라고 생각합니다. 프로젝트를 구성하는 모든 것(일정, 인력, 업무, 기능 등)은 회의를 통해 결정이 되거든요. 특히 기획자는 업무 특성상 회의만 진행하다가 하루 업무 시간이 끝나는 일도 비일비재하죠. 그래서 단순한 의견이 오가는 자리부터, 주요한 결정이 필요한 회의까지 회의록은 필수로 작성하고 수시로 보면서 이해할 수 있어야 해요. 시니어는 수많은 회의 중 필요한 내용을 머릿속에 바로 정리할 수 있는 역량이 있는 반면, 주니어는 하나의 회의에 수많은 문장 중 이해할 수 있는 내용이 손가락에 꼽을 정도로 정리가 어려울 수 있기 때문입니다.(회의록 작성에 대한 자세한 방법은 추후 다른 글에서 다뤄보도록 할게요)
- 기타 필요한 문서(정책, 정보성, 테스트 등)
출처 : 본인회사마다 다를 수 있지만, 프로젝트에 대한 모든 요소들은 한 곳에서 보기 편하게 관리되어야 한다고 생각하기 때문에 모든 작성된 문서 파일과 링크는 한 곳에 저장하여 관리합니다.
2. 프로젝트 진행
본격적인 PM 업무 시작입니다. 미리 만들어놓은 문서 체계를 기반으로 모든 팀원들이 목표까지 원활하게 도달할 수 있도록 고군분투해야 하는 상황에서 기획자가 킥오프부터 실무, 테스트를 포함한 F/U을 어떻게 해나가는지 알아보도록 하겠습니다.
- 킥오프
프로젝트의 시작을 알리는 첫 회의입니다. 따라서 구체적인 업무보다 대략적인 일정에 기반하여 어떤 것들이 필요하고, 누가 참여해야 하는지에 대해 얘기를 나누게 됩니다.
1. 개요 및 목적, 필요한 기능 리뷰
이에 대한 내용을 보통 PRD(Product Requirements Document)로 대체하는 경우도 있지만, 프로젝트 규모에 따라 작성하지 않을 수 있어요. 또한, 개괄적인 얘기들이 오갈 수 있기 때문에 회의록에 잘 담아놓고 이후 요구사항이 정해지면 PRD에 들어갈 내용들을 세분화하여 각각의 문서로 작성해도 됩니다.(회사 내부 프로세스에 따르는 게 일반적이에요)
2. 참여 인원(파트) 별 일정 및 공수 산정
파트별 결정권이 있는 담당자들이 모여 진행하고, 파트의 현재 상황을 고려하여 일정과 공수를 파악합니다. 이 단계에서 반드시 확정해야 하는 것은 아니기 때문에 공유된 내용들을 가지고 추후 회의를 통해 일정 및 공수를 확정해도 괜찮아요.
3. 질의응답의 시간
프로젝트에 대한 내용을 듣고 필요한 질문과 답변을 나누는 시간은 반드시 필요합니다. 내가 잘 말한 게 맞는지, 그들이 잘 이해한 게 맞는지 크로스 체크를 해야 이후 진행에 있어 오해가 생기지 않거든요. 이건 킥오프뿐만 아니라 모든 회의에서도 마찬가지이니 꼭 필요한 단계라고 보면 되겠습니다.
- 프로젝트 F/U
일정과 업무가 확정된 프로젝트는 이제 잘 맞물린 톱니바퀴처럼 오픈까지 어긋나지 않고 굴러가야 합니다. 어긋나지 않게 하기 위한 F/U은 어떻게 해야 할까요?
1. 기획 - 디자인 - 개발 F/U
각 파트별 Task를 수행함에 있어 발생하는 이슈를 파악하고 적절한 대응을 해야 하며, 이들이 상호 유기적인 협업을 통해 일정에 맞춰 더 나은 제품이 나올 수 있도록 지원해야 합니다. 예를 들어 디자인 - 개발 간 UI 요소의 구현에 대해 이해상충하는 부분이 발생한다면 이슈에 개입해서 원인을 파악하고, 가장 적은 risk를 안고 최선의 결과를 낼 수 있도록 조치해야 하는 것처럼요. 그러기 위해서는 설계 - 구현 단계의 각 직무(디자인, 개발 등)에 대한 이해도를 바탕으로 진행되어야 하기 때문에 어느 정도의 공부가 필요합니다.
2. 타 부서 업무 요청 F/U
프로젝트가 진행되며 제품을 구현하기까지 순전히 내부 팀의 힘으로만 되지는 않습니다. 회사 내 모든 리소스를 활용해야 더 좋은 결과물을 얻을 수 있기 때문이죠. 따라서 기술팀, 인사팀, 법무팀 등 다양한 부서에 업무 요청을 하게 되는 경우가 많아요. 요청을 할 때는 각 부서별 기존의 우선순위(KPI)를 존중하고, 일정을 짜되, 생각보다 여유롭게 설정하는 것은 물론, 내가 요청한 업무를 잘 이해했는지 확인에 확인을 해야 합니다. 생각보다 내 뜻대로 요청한 업무를 전달받지 못하는 경우도 많기 때문입니다.(저는 특히 타 부서에 업무 요청을 할 경우 '회의 - 메일 - 채널 - 구두'의 모든 전달 수단을 동원하여 못을 박아놓습니다)
3. 테스트 진행 F/U
제품이 우리가 원하는 수준에 맞게 구현이 되었는지 확인하는 단계입니다. 이 단계에서는 남은 일정의 여유 정도에 따라 오류를 발견하고 조치하는 수준에 그칠 건지, 나아가 더 좋은 제품을 위해 고민하고, 추가하며 고도화할 것인지 선택할 수 있어요. 물론, 후자의 경우 전자가 완벽하게 되었다는 전제 하에 진행되어야 되겠습니다. 이때 테스트는 외부인을 제외한 가용 가능한 모든 인원을 대상으로 해보는 게 좋습니다. 전문가보다는 일반 고객의 경험이 더 효과적이기 때문이죠.
3. 오픈 후
회고
프로젝트를 매니징 하면서 느낀 점을 팀원들과 공유합니다. 잘한 점에 대해서는 아낌없이 칭찬하며 또 다른 시작에 대한 동기부여를 주고, 아쉬웠던 점에 대해서는 투명하게 나누며 개선의식을 가꿔 나가면 됩니다. 팀원들과 회고를 하고, 나 자신에게도 한 번 더 물어보는 습관을 가져봅니다. 나는 무엇을 배웠는지.(배움에는 끝이 없어요)
또 다른 시작
긴장감 넘치는 긴 여정에 마침표를 찍었습니다. 하지만, 마침표는 동시에 새로운 시작을 의미합니다. 출시한 제품에 이상이 없는지 모니터링을 해야 하며, 생성한 이벤트 대로 쌓이는 고객 데이터를 분석해야 합니다. 그래야 고객이 진짜 원하는 것이 무엇인지 정답에 가까워질 수 있거든요.
.
.
.
이처럼 PM은 단지 프로젝트가 잘 굴러가는지 위에서 지켜보는 게 아닌, 실제 일이 이루어지고 있는 현장에 직접 투입되어 듣고, 보고, 뛰어다녀야 합니다. 이렇게 하기 위해서는 여러 역량에 걸쳐 최소한의 경험치가 있어야 하는 게 사실이며, 흔히 PM 역할을 주니어가 하기 어렵다고 하는 말의 근거가 되기도 합니다. 하지만, 처음부터 완벽한 기획은 없듯이 PM 또한 마찬가지라고 생각합니다. 실수를 겪고 이를 되짚어 보며 부족했던 점을 인정하고 개선해 나간다면 완벽에 조금이라도 가까워질 수 있을 겁니다. 저 또한 다음 프로젝트에서는 이전의 부족했던 것들을 보완하여 만족할 수 있는 결과를 낼 수 있도록 노력하고 있습니다.
이번 글은 이제 막 프로젝트들을 하나 둘 마무리해가고 있던 저에게도 좋은 회고가 되었네요. 긴 글 읽어주셔서 감사합니다.
