7장: PRD와 User Story
프로덕트의 방향을 잡는 지침서 만들기
서론:
모름지기 서비스 기획자/프로덕트 매니지먼트는 제대로 된 기획 산출물을 도출시킬 수 있어야 한다. 진짜 문제정의, 가설 설정, 방향성 정립, 우선순위 결정 등 기존 장에서 다루었던 부분이 이 기획 산출물을 만들기 위해 노력한 것이라고 생각한다.
건물을 만들기 위해서는 제대로 된 설계서가 필요 하다다. 만약 설계서가 제대로 작성되지 않은 채 건물을 짓는다면 어떻게 될까? 자재는 뒤죽박죽 치수가 맞지 않은 채로 주문되어 올 것이고, 통일되지 않은 색상과 자재로 심미적인 부분을 충족시킬 수 없을 것이다. 또한, 실제 건물을 짓는 인부들과 건축가의 간극이 발생하여 제대로 된 건물이 탄생할 수 없을 것이다.
프로덕트/서비스를 만드는 것도 건축물을 짓는 것과 같이 구체적인 설계 도면이 필요하다. 개발자와 디자이너 분들이 기획자와 같이 고민한 서비스를 정확하게 만들 수 있도록 하기 위해서다. 스토리보드 Story Board(=화면 설계서), PRD (Product Requirement Document)가 바로 프로덕트가 실제 구현될 수 있도록 하는 지침서, 설계도면이 된다. 서비스 기획자/ 프로덕트 매니지먼트로서 이제는 구체적인 기획 산출물을 만들 수 있는 법을 배울 것이다.
본론:
조직에 따라 주로 도출해야 하는 기획 산출물이 다를 수 있다. 기능 조직의 경우, 이미 전략적 차원에서 무엇을 만들어야 할까를 정해 놓은 경우가 많을 것이다. 그래서 보다 프로덕트/서비스를 구현하는 데 초점이 맞춰진 산출물을 도출할 필요가 있다. 그리고 프로젝트 범위가 광범위한 경우가 많고, 다양한 외부 아웃소싱 조직과 협업하여 이를 진행하는 경우가 존재하다. 그래서 기능 조직은 RFP(입찰 제안서), 요구사항 정의서, 스토리보드를 도출하는 경우가 많을 수 있다.
7장과 8장에서는 하지만 목적 조직에서 주로 사용하는 PRD와 User Story에 대해 초점을 맞춘 채 글을 작성할 것이다. 아직 서비스 기획 부트캠프의 교육생으로서 보다 복잡하고 구체적인 기능 조직의 산출물을 이야기하는 것이 어렵기도 하며, PRD와 User Story가 '애자일'을 추구하는 지금 산업 환경에서 보다 알맞은 방법이라고 생각하기 때문이다.
PRD (Product Requirement Document)
한글로 직독직해는 요구사항 정의서이지만, 앞서 언급한 요구사항 정의서와 다른 기획 산출물이다. PRD는 프로젝트 기간 동안 팀과 계속해서 수정하며 작성하는 프로덕트 팀의 지침서, 나침반이 되는 문서이다. 기능 조직의 요구사항 정의서는 SI 업체에게 프로젝트를 발주하고 어떤 것을 만들어야 하는지 우리의 요구사항을 정리해 놓은 산출물로 서로 성격이 다른 산출물이다.
만드는 데 복잡하고 시간이 오래 걸리는 화면 설계서보다 효율적으로 MVP를 구분하여 만들 수 있으며, 쉽게 가변 할 수 있는 장점이 있다.
PRD는 팀이 프로젝트를 진행하면서 기준이 되는 규칙을 정리한다. 비즈니스 임팩트와 의미 있는 대안인지를 검토하고 효과적으로 전달하는 데 초점을 맞춘다. PRD은 대체로 아래와 같은 문서 구조를 가지고 있다. (PRD의 문서 구조는 실제 기획서를 작성하는 기획자와 팀에 따라 달라질 수 있다!)
1. 배경 background: 비즈니스, 기술적 환경, 회사의 상황 등 프로젝트를 하기 위해서 알아야 하는 점을 작성하여 팀에 프로젝트 배경을 명확하게 공유한다.
2. 목적 goal/ objective: goal은 목적이자 실현하고자 하는 일, 나아가는 방향을 의미한다. objective은 목표, 목적을 이루기 위해 추구하는 PRD의 실제 대상을 의미한다. 목표는 되도록 수치화할 수 있도록 적는 것이 좋다.
3. 대안 설정 및 이유: 필수 항목은 아니지만, 대안 선택에 대한 의문을 잠재울 수 있고 팀이 동일한 인식을 가질 수 있도록 할 수 있다. 기존 시스템의 한계를 포함하여 개발 가능성, feasibility, usability, profit, 비용 등의 요소를 통해 왜 이런 대안을 선택했는가 이야기할 수 있다.
4. 가설과 검증 매트릭 Metrics: 원하는 방향대로 가는 것을 체크하기 위한 수치화된 지표이다.
5. 구현 원칙 guiding principle: 프로덕트 팀이 자유롭게 얘기를 할 때 방향에 벗어나지 않을 중요한 제약적 가이드라인이다. 목적 조직은 개발자, 디자이너가 구현하는 자율성을 부여하기에 다양한 구현 방법이 나올 수 있다. 이때 방향이 흐트러지거나, 중요한 것을 놓치지 않도록 구현 원칙을 정해 놓는 것이다.
6. 기능적 요구사항 funtional requrement+추가적 SPEC 문서: 기능(function)은 개발을 통해 데이터 입력과 출력 사이에서 만들어진 행위의 상세 스펙을 설명하는 것으로 logic이나 알고리즘으로 만들어지는 것을 의미한다. 기능의 요구사항을 표현하기 위해 정책을 정리하는 형태가 될 수 있고, 필요 Spec에 대해 이해할 수 있는 플로우 차트, 인프라 구성 등에 대한 추가 스펙 문서가 들어갈 수 있다. 비기능적 요구사항도 들어갈 수 있다.
7. User Story (use case): 사용자의 use case를 통해서 기능과 프로덕트를 포함할 수 있는 계층적 구조를 가진 기능 명세 방법이다. “사용자는 무엇할 수 있다." 형태로 정의 내린다. 자세한 사항은 이후 설명할 예정이다.
8. 디펜던시 dependency: 다른 프로젝트, 다른 프로덕트 팀에게 영향을 주는 사항에 대하여 체크하는 영역이다.
9. 디자인 파일/ 개발 정리 파일: 프로덕트 팀 작업자들이 작성하는 파일을 링크 등 다양한 형식으로 정리한다. 이를 통해 PRD는 사전 기획 문서뿐 아니라 프로젝트의 최종 정리 산출물 과정에 대한 기록으로도 활용할 수 있다.
10. 일정 (milessotnes, high level work flow): 마일스톤, 간트 차트 등을 이용하여 목표 일정에 대한 정의를 업무 단위 별로 타임라인에 표현한다.
11. MVP 이후 추가 개선 플랜: 론칭 후 운영 등의 사항에서 발전시킬 수 있는 다양한 형태의 아이디어를 정리해 두는 곳이다. 누구나 의견을 낼 수 있도록 한다.
PRD는 무엇보다 프로젝트를 위해 팀이 같이 보고 이해할 수 있는 문서여야 한다. 충분히 고민과 커뮤니케이션을 거쳐 작성해야 하면, 글을 통해 문서가 잘 이해될 수 있도록 노력해야 한다.
(8장에서 User Story로 계속함...)
* 해당 게시물은 NHN 아카데이 서비스 기획 부트캠프의 학습내용을 토대로 임의로 작성한 게시물입니다. 각 내용에는 정확하지 않은 내용이 있을 수 있으니, 혹 수정이 필요한 내용은 댓글로 알려주시면 감사하겠습니다.
**노션을 이용해 부트캠프 과정을 더 간단하게 아카이 빙하고 있습니다. 방문해 주실 분은 하단 링크를 누르시면 연결됩니다. NHN 서비스 기획아카데미 (notion.so)
