RPE-VIEW
오늘의 아티클은 'PRD(제품 요구사항 정의서)의 모든 것'입니다. PRD의 정의 및 핵심 요소에 대해 배워 보겠습니다.
아티클 소개
저자 정보
저자: SPARKPLUS 스파크플러스
CEO
핵심 내용 요약
주요 포인트
1. PRD의 정의
1) PRD(Product Requirements Document)는 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로, 제품 개발 프로세스 전반에 걸쳐 필수적인 중요 문서.
- 기획 단계에서는 제품의 비전과 전략 정의. 디자인 단계에서는 제품의 사용자 요구 사항을 충족하는지 확인. 계발 단계에서는 기능의 목적과 구현의 확인. 테스트 단계에서는 제품이 기술 요구 사항을 충족하는지 확인. 출시 단계에서는 제품의 시장 혹은 사용자의 요구 사항을 충족하는지 확인하는 데 사용.
2. PRD 작성방법
1) 사용자 문제 및 비즈니스 우선순위 결정의 근거를 포함
- 우선순위를 명확히함으로써 PM은 해결 방법에 따른 기능과 디자인을 평가하고 복잡성과 사용자 가치의 균형을 맞추는데 도움을 준다. PRD에는 개발 프로세스를 고려하여 사용자 문제와 개발 목표를 검토하고 해결 방안에 대한 내용을 작성해야 한다. 여기에는 사용자 조사 결과, 토론과 평가, 기술적 한계, UX 고려사항, 리소스 및 에산, 타임라인 요구 사항 등이 표함 된다. 위 내용은 이해관계자들과 의사 결정권자에게 공유되고 체크를 받는다.
2) 해결 방안에 대한 세부 정보 추가
- 위 사항에 대한 세부 정보를 작성해야 한다.
3) UX 및 개발 설계 문서 참조
- 고려된 옵션에 대한 피드백을 제공하고 PRD에 설정된 우선순위를 다시 확인한다.
4) PRD를 업데이트하여 기능 범위 결정
- 업데이트를 통해 기능 범위에 대한 결정을 내리고, UX 및 개발 설계 문서와 중복되지 않도록 한다.
5) 다른 사람들과 공유하여 의견 구하기
6) 개발 중에도 PRD 계속 업데이트 하기
3. PRD 구성 요소
1) 제품 개요(요약과 배경)
- 제품의 목적 및 해결해야 할 문제에 대한 요약, 왜 이 문제를 해결해야 하는지 근거를 작성해야 한다. 기획, 개발의 중요성을 강조할 수 있는 근거 데이터(설문조사, 인터뷰, 지표)를 참고하면 좋다. 최근 몇 달간 사용성에 대한 이슈가 있거나, VOC에 반복적으로 나오는 키워드들을 데이터로 정리할 수도 있다. 또는 신규 개발의 경우 시장의 상황이나 변화, 경쟁사의 제품의 성장 등을 추가할 수 있다.
2) 비즈니스 목표 혹은 지표
- 현제 시점의 데이터와 예상 가능한 데이터를 비교할 수 있도록 작성하는 것이 좋다.
비즈니스 분석 목적: 비즈니스가 달성하고자 하는 목표를 분석
KPI: 비즈니스 목표에 따라 측정 가능한 KPI를 식별
목표 수치 설정: KPI에 대해 목표 수치를 설정
3) 핵심 고객 또는 사용자 정의
- 신규 개발이 되었을 때 갈증이 해소될 사용자가 어떤 문제를 겪고 있는 사용자인지 분명하게 기술
4) 핵심 사용자 여정(Critical User Journey) / 사용자 스토리(User Story)
- 3번에서 정의한 사용자가 목표를 달성할 수 있을지 작성. 이때 사용자 요구에 집중하며 해결 방안에 집착하지 않는 것이다. 특정 해결 방안이나 기능에만 집중할 경우 근본적인 문제 해결과 멀어질 수 있다
사용자 스토리
- 사용자가 제품 또는 서비스를 이용할 때 생기는 상황, 목적, 요구사항 등을 간결하고 명확하게 표현한 문장
- (고객/사용자 유형)은 (목적/목표)를 위해 (필요/욕구)를 원한다. (고객/사용자 유형) 쇼핑을 자주 하는 나는, (목적/목표) 결제 정보를 저장하여 매번 새롭게 정보를 다시 입력할 필요 없이, (필요/욕구) 빠르게 결제할 수 있기를 원한다.
5) 기능적 요구 사항
- 제품 또는 서비스에서 수행되어야 하는 특정 작업이나 기능에 대한 내용을 작성하고, 제품이 제공해야 하는 기능과 우선순위 표시. PM이 단독으로 작성하는 것보다, 개발자와 소통하며 작성하는 것이 좋다.
- 사용자 정하기 -> Must Have(반드시 구현되어야 하는 기능) -> Should Have(반드시 필요한 것은 아니지만, 해당 사용자가 매우 필요하다고 생각하는 기능) -> Could Have(사용자가 원한다면 사용할 수 있는 선택적인 기능)
6) 프로젝트 일정 및 배포 계획
- 제품 개발 및 출시 일정 작성. 이해관계자 및 의사 결정권자와 소통하며 일정을 세운다.
7) 기타 참고 문서
- 와이어 프레임, 스토리보드, UX 리서치 결과 등
'IT 서비스 기획 > PM, PO, 기획자' 카테고리의 다른 글
[PM/PO/기획자] 기획자가 활용할 수 있는 오픈 API 및 사례 (2) | 2025.02.10 |
---|---|
[PM/PO/기획자] PM이 배워야 하는 설득하는 글쓰는 법 (2) | 2025.02.05 |
[PM/PO/기획자] '팀 스파르타' - 결제 전환율 개선안 (2) | 2025.02.01 |
[PM/PO/기획자] 서비스 기획의 필수 선결조건 (0) | 2025.01.24 |
[PM/PO/기획자] PM이 Chat GPT를 업무에서 활용하는 방법 (4) | 2025.01.23 |