서비스 기획이 막막할 때, 노션 PRD 작성부터 시작해보세요
지난번 소개했던 퍼블리싱 어시스턴트, 플라밍고는 사실 이번에 처음 등장한 서비스가 아닙니다. 알로하팩토리에서 사내 데이터 분석을 목적으로 사용하기 위해 처음 기획된 이후, 퍼블릭 서비스를 지향하는 지금에 이르기까지 다양한 버전으로 제작된 서비스죠.
실제로 외부 개발사로부터 플라밍고를 도입하고 싶다는 문의도 꾸준히 들어오고 있었고, 조직 내부에서도 서비스 상용화에 대한 아이데이션이 활발하게 이루어지고 있었어요. 이러한 배경을 바탕으로, 알로하팩토리는 아래와 같은 목표를 세우고 지금의 플라밍고 서비스를 준비하게 되었습니다.
첫째. 중·소규모 개발사가 스스로 게임을 퍼블리싱할 수 있는 솔루션이 필요하다.
둘째. 단순 데이터 분석이 아닌, 라이브 게임 운영 레벨의 기능을 지원해야 한다.
셋째. 전문 인력(데이터 분석가)이 없더라도, 데이터를 통해 누구나 인사이트를 도출할 수 있어야 한다.
만약 여러분이라면 이러한 목표를 달성하기 위해, 무엇을 가장 먼저 시작할 것 같나요?
저희 팀에서는 공통된 목표를 달성하기 위해 PRD를 작성하는 것부터 시작했어요. 이처럼 막연한 과업이 주어졌을 때 어떤 과정으로 구체화를 시키면 좋을지, 하나의 서비스를 구축하며 경험했던 일들을 공유하려 합니다.
•
PRD는 무엇이고, 왜 필요한가요?
서비스(또는 제품)를 처음 기획할 때 가장 먼저 무엇을 해야 할까요? 가장 대표적인 방법론은 1pager · 6pager와 오늘 글에서 소개해드릴 PRD입니다. 프로덕트를 개발하는 상황과 범위에 따라 양식이 조금씩 다르지만, 어떤 방식으로 문서를 작성하더라도 ‘프로젝트의 전반적인 개요와 가이드를 구체화한다’는 목적은 같아요.
1pager는 이름 그대로 ‘한 장 안에 프로젝트의 개요와 목적을 담는 문서’이기 때문에, 빠르게 조직원들과 프로젝트 배경을 align 시키고 목적과 수단을 구체화하기 유용합니다. 때문에 디테일한 스케줄, 목표, 달성 방법을 수립하기 보다 빠르게 현재 기획을 구체화하여 조직 내부에 공유하기에 적합한 방법이죠.
반면, PRD(Product Requirements Document)는 제품 요구사항 정의서로 사용자의 니즈, 또는 기능에 대한 요구사항을 정리한 문서입니다. 일반적으로 1pager보다 구체적인 내용을 포함하며, 전사 협업 과정에서 꾸준히 열람하는 경우도 있어요. 때문에 조직 내에서 어느정도 논의된 아젠다라면, PRD를 통해 현재까지 정리된 내용을 구체화하여 프로젝트를 본격적으로 시작하려 할 때 유용한 문서입니다.
플라밍고는 기존에 알로하팩토리 내부에서 운영하던 서비스인 만큼, 서비스를 개발하기 전부터 어느 정도 공통된 니즈가 형성되어 있었어요. 때문에 1pager 보다는 PRD를 통해 프로젝트를 보다 구체적으로 실현시키는 데 집중했습니다. 더불어 공동 작업자의 업데이트가 편리한 노션으로 PRD를 작성하여, 지속적으로 내용을 수정하면서 히스토리를 관리할 수 있도록 작업했어요.
노션 PRD 작성하는 방법
본래 PRD는 서비스(제품)의 요구사항과 기능을 정의하기 위한 문서지만, 추후 업데이트와 커뮤니케이션의 편의성을 위해 PRD에서 히스토리 관리를 같이 진행하기로 했습니다. 프로젝트 중간에 새로운 팀원이 합류하더라도 PRD 한 장만 보면 히스토리와 현재 상황을 모두 이해할 수 있도록 구성해야 한다고 판단했어요.
때문에, 아래와 같이 문서를 구성했습니다.
1. 관련 문서 모음
2. 프로젝트 개요
3. 목표 수립
4. 프로젝트 마일스톤
5. 향후 기능 개선 및 고려사항
1. 관련 문서 모음
노션으로 프로젝트를 기획한다면, 필연적으로 외부 툴을 사용하게 됩니다. 서비스 기획 과정에서 필요한 사이트맵, 화면 설계서, 정책서 등의 문서를 노션으로 모두 제작할 수 없기 때문이죠.
그런데 앞의 PRD 작성 목적을 잠시 떠올려볼까요? PRD는 프로젝트 담당자가 아카이빙하는 공간이 아닌, 팀(또는 전사)에서 공유하기 위한 문서입니다. 프로젝트를 진행하면서 작성한 문서, 또는 외부 링크를 함께 공유하는 게 중요하죠.
때문에 피그마 · psd · xlsx · pptx 등 외부 링크와 파일을 PRD에 업로드하여, 팀원 모두 최종 산출물을 확인할 수 있도록 꾸준히 버전을 관리해줘야 합니다.
2. 프로젝트 개요
PRD는 프로젝트 초기에 작성하는 문서인 만큼 현재 Pain Point를 정의하고, 조직 구성원끼리 align 시키는 과정이 반드시 필요합니다. 서로 다른 배경과 목적을 지닌 채 프로젝트를 진행하기에는 어려움이 따르기 때문이죠.
프로젝트 담당자(PM)는 PRD를 통해 아래의 두 가지를 반드시 공유해야 합니다:
•
이번 프로젝트를 통해 어떠한 문제를 해결하려 하는지
•
(대략적으로)최종 프로젝트 산출물은 어떠한 모습을 띄게 되는지
프로젝트 개요는 이러한 과정을 서술하는 섹션으로, PRD에서 가장 중요한 내용이죠. Pain Point - Solution 형태도 좋고, As-is · To-be와 같은 표현도 괜찮습니다. 중요한 것은 동료, 혹은 상사와 내 머릿속에 있는 프로젝트의 상(想)을 일치시키는 것입니다.
플라밍고는 문제점(Pain Point)과 해결 방안(Solution)을 아래와 같이 정의했어요.
As-is
•
사용자가 스스로 데이터를 해석하고, 성장 전략을 수립하는 데 어려움을 겪는다.
•
현재 다양한 분석 서비스가 있지만, 사용자는 어떤 데이터가 중요한지 판단하기 어려워한다.
•
게임 분석이 아닌, 라이브 중인 게임을 운영하는 데 필요한 리소스가 부족하다.
To-be
•
상세한 Raw Data 보다, 가공(요약)된 리포트를 중점적으로 제공한다.
•
현재 발생한 지표를 해석하여, 구체적인 Action Plan까지 제안한다.
•
공지사항, 우편함, 유저 로그 조회 등 서버 레벨의 기능을 함께 구현한다.
3. 목표 수립
우리의 리소스는 언제나 한정적이기 때문에, 더 효율적인 프로젝트에 리소스를 투입해야 하는 건 당연합니다. 특히 회사를 운영하는 경영자의 입장이라면 “이런 프로젝트 할 시간에, 다른거 하는게 어때?”라는 의문도 충분히 나올 수 있죠.
또한 단순히 오너를 설득하기 위함이 아니라, 동료들과의 목적 의식 함양을 위해서라도 목표 수립은 대단히 중요한 과정입니다. PRD에서 “우리는 이 프로젝트를 통해, 이런 성과를 달성할거야”라고 사전에 정의한다면 경영자는 보다 효율적으로 리스크를 관리할 수 있고, 담당자는 Top-down이 아니라 협의된 목표를 달성하기 위한 마음가짐으로 프로젝트를 운영할 수 있겠죠.
조직의 목표를 설정하는 방법으로 KPI와 OKR이 가장 많이 사용되는데, 플라밍고 팀은 이번 프로젝트를 통해 조직 전반의 인프라를 넓히려는 목적이 강하여 OKR을 차용했습니다. 통상적으로 KPI는 구체적인 목표(매출, ROAS, 영업이익률 등)를 달성하기에 유용한 모델이고, OKR은 거시적인 목표를 달성하는 데 유용한 방법이기 때문이었어요.
이러한 과정을 거쳐, 플라밍고가 달성하려는 조직의 목표(Objectives)는 "소규모 개발사의 퍼블리싱을 도와주는 어시스턴트 솔루션 구축”으로 정의했습니다.
4. 프로젝트 마일스톤
프로젝트의 목적과 목표를 수립했다면, 이제 프로젝트를 완수하기 위해 무엇을 해야 하는지 정의해야 합니다. “지금 당장 내일부터 프로젝트를 시작한다면, 무엇부터 할 것인가?”라는 물음에서 시작해서 프로젝트가 끝나기까지의 과정을 머릿속으로 시뮬레이션 하며 필요한 부분을 하나씩 채워갑니다.
물론 하나의 서비스를 제작하기까지는 어마어마한 리소스가 투입되고, 모든 변수를 예측한다는 것은 불가능합니다. 또한 PRD를 통해 프로젝트를 꾸준히 관리할 계획이므로, 구체적인 스케줄링을 하기보다는 ‘프로젝트를 수행하기 위해 필수적인 것들을 적는다’는 개념으로 접근하는 편이 바람직합니다. 노션을 활용하기 때문에 새로운 기능을 추가하거나, 기존의 기능을 Spec out하는 과정도 수월하죠.
플라밍고의 초창기 PRD에서는 마일스톤을 아래와 같이 설정했습니다. 또한 각 Step을 페이지로 구성해서, 해당 단계의 산출물(화면설계서 등)을 아카이빙 했어요. 조직의 누가 들어와도 해당 단계에서 어떠한 일을 했는지 확인할 수 있도록 구성하는 데 중점을 뒀습니다.
플라밍고의 초기 마일스톤
(1) 기존 플라밍고 기능 리스트업
(2) 사이트맵 작성
(3) 화면 목록 작성
(4) mvp 모델 정의
(5) 플로우 차트 작성
(6) 서비스 정책 설정
(7) 화면 설계서 작성
이후, 각각의 단계별로 필요한 산출물을 더 잘게 쪼개고 전반적인 마일스톤을 수립합니다. 조직의 리소스는 결국 시간, 인력, 자금이에요. 때문에 ‘이 프로젝트가 얼마나 오래 걸리는지’는 프로젝트를 설득하는 과정에서 필수적인 부분이고, 경영진과 조직 내부에게 “우리는 이 프로젝트를 완수하기 위해, 이만큼의 시간이 필요해”라는 정보를 공유했습니다.
5. 향후 기능 개선 및 고려사항
장기적인 프로젝트는 진행 과정에서 다양한 아이디어, 혹은 돌발적인 제한 상황이 나타나기 마련입니다. 때문에 PRD에서 아이데이션 · 이슈 라이징을 할 수 있는 섹션을 구성했어요.
프로젝트에 참여하는 누구나 작성할 수 있고, 백로그 형태의 아이디어 또는 가설을 기록합니다. 프로젝트 담당자 홀로 고민하고 결정하는 것이 아니라 조직원들이 모두 참여할 수 있는 공간이죠. 백로그 형태로 누적된 이슈는 Impact, Confidence, Ease 세 가지 항목을 기준으로 평가하는 ICE scoring 모델으로 평가하여 우선순위를 결정합니다.
실제로 플라밍고는 이러한 아이데이션을 통해 현재의 ‘게임 최적화 점수’ 시스템을 구축했고, AI 어시스턴트를 개발하게 되었어요.
마치며
PRD는 프로젝트를 시작하고 완수하기 까지 하나의 이정표 역할을 수행하는 아주 중요한 문서입니다. 특히 프로젝트의 규모가 클수록 진행 과정에서 다양한 변동사항이 생기므로, 프로젝트 중간에 ‘처음에 이 프로젝트를 왜 진행하려 했는지’를 상기하는 것이 너무 중요하기 때문이예요.
또한 문서를 통해 목적과 목표를 공유하지 않으면, 나중에 “이거 왜 이렇게 했어?”라는 말이 나왔을 때 대처하기가 굉장히 곤란합니다. 프로젝트에 본격적으로 리소스를 투입하기 전에, 미리 이번 프로젝트를 어떻게 진행할거고 어떠한 목표를 달성할 것인지 전사적으로 공유해야 끝까지 성공적으로 프로젝트를 마무리할 수 있는 기회가 주어진다고 생각해요.
지금까지 PRD의 개념과 함께, 실제로 라이브한 ‘플라밍고’ 게임 퍼블리싱 어시스턴트 서비스 구축 사례를 살펴봤습니다. 이어서 게임 데이터 분석에서 중요한 기준과 지표들에 대해 살펴보겠습니다!