안녕하세요, 꾸우._. 입니다. 이번에는 PM, 서비스 기획자가 내야 하는 중요한 산출물인 요구사항 정의서에 대해 알아보고 정리해보겠습니다.
📌 제품 요구사항 정의서 (PRD, Product Requirement Document)
제품 요구사항 정의서는 제품/서비스를 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로, 제품/서비스 개발 프로세스 전반에 걸쳐 필수적인 중요한 문서입니다.
기획 단계에서 제품의 비전과 전략을 정의하고, 디자인 단계에서 제품이 사용자의 요구사항을 충족하는지 확인하고, 개발 단계에서 기능의 목적과 구현을 확인하며, 테스트 단계에서 제품이 기술 요구사항을 충족하는지 확인하고, 출시 단계에서 제품이 시장 또는 사용자의 요구사항을 충족하는지 확인하는 데 사용됩니다.
즉, PRD를 작성하면 개발팀 및 이해관계자들에게 공유하고 제품 개발 프로세스에 참여하는 모든 사람이 제품의 요구사항을 확인 후 개발에 착수할 수 있도록 합니다.
💡 요구사항 정의 전, 워밍 업
- 왜 이 서비스를 기획하는가?
- 주요 고객은 누구인가?
- 어떻게 서비스를 제공할 것인가?
- 어떤 채널을 통해 고객에게 다가갈 것인가?
- 프로젝트 멤버는 누구인가?
- 서비스 오픈 시점은 언제인가?
- 시장 현황과 자사의 경쟁력은 무엇인가?
- 어떻게 수익화할 것인가?
💡 Why 기반의 기획안 형태
- 우리가 왜 이 기획을 해야 하는가? (Why)
- 이 문제는 어떻게 해결해야 하는가? (How)
- 가장 적합한 솔루션은 무엇인가? (What)
소프트웨어 개발은 변동사항이 많고, 우리는 고객에 대해 완벽히 이해하고 있지 않습니다. 빠른 테스트가 가능한 애자일 문화가 확산되면서 '기획서'는 주로 'How'를 완벽하게 정의한 개발 요건 문서에서 목적, 즉 Why에 초점을 맞춰 팀이 함께 How를 논의할 수 있는 토대로 변화하고 있다고 볼 수 있습니다.
📌 PRD 구성 요소
- 제품 개요 (요약 및 배경, Summary and Background)
- 문제가 무엇이며, 왜 중요한가?
- 제품의 목적, 해결해야 할 문제에 대한 요약, 왜 이 문제를 해결해야 하는지 근거를 작성
- 기획의 중요성을 검증 또는 강조하기 위해 유저 리서치의 내용 (설문조사, 인터뷰, 지표 등) 등을 포함하는 것이 좋음
- 비즈니스 목표 및 핵심 지표
- 제품을 개발하는 이유와 기대되는 비즈니스 성과, 제품이 달성해야 하는 비즈니스 목표로 사용자가 제품을 사용함으로써 달성하고자 하는 비즈니스 결과 작성
- 비즈니스 목적 분석 : 먼저 비즈니스가 달성하고자 하는 목표 분석 (매출 증가, 시장 점유율 확대 등)
- 키 성과 지표(KPI) : 비즈니스 목표에 따라 측정 가능한 KPI를 식별 (매출 증가를 목표로 한다면 매출 증가율, 고객 당 평균 거래 금액, 신규 고객 유입 비율 등)
- 목표 수치 설정 : 각 KPI에 대해 목표 수치 설정 (매출 증가율을 10%)
- 제품을 개발하는 이유와 기대되는 비즈니스 성과, 제품이 달성해야 하는 비즈니스 목표로 사용자가 제품을 사용함으로써 달성하고자 하는 비즈니스 결과 작성
- 핵심 고객 (주요 사용자 (Target Users)) 또는 사용자 정의
- 주요 사용자는 누구이며, 우리 서비스에서 이 사용자 그룹이 중요한 이유를 포함 (우선순위 강조 필요)
- 제품에 다양한 기능이 있을수록 사용자는 세분화 가능
- 핵심 사용자 여정 (Critical User Journeys (CUJs)), 유저 스토리 (User Story)
- 문제 해결 후, 우리가 정의한 사용자는 서비스(기능, 제품)를 어떻게 사용하게 될 것인지 고객 요구에 집중하여 작성
- 사용자 요구에 집중하며, 해결 방안에 집착하지 않는 것이 중요
- 핵심 사용자 여정은 문장으로 작성할 수도 있지만, 사용자 여정 지도와 같은 시각화된 자료로 만들기도 함
- 사용자 그룹 선택/핵심 시나리오 선정/사용자 시나리오 작성/문제 해결 방법 작성/추가 정보 및 대안 작성 등이 포함됨
- 유저 스토리는 제품 또는 서비스를 개발할 때 사용자 중심으로 기능을 설계하고 개발할 수 있도록 도움
- 기능적 요구사항 (Functional requirements)
- 해결 방안의 세부 기획을 작성
- 최대한 상세하게 정리하는 것이 좋음
- 다만, 특정한 솔루션을 강요하지 않도록 주의
- 우선 순위를 표시해 작성
- 대상 사용자 설정
- Must Have
- 반드시 구현되어야 하는 기능
- 해당 사용자가 해당 기능 없이는 앱을 사용할 수 없다는 것
- Should Have
- 반드시 필요한 것은 아니지만, 해당 사용자가 매우 필요하다고 생각하는 기능
- Could Have
- 선택적인 기능으로, 해당 사용자가 원한다면 사용할 수 있는 기능
- Won't Have
- 가장 덜 중요하고, 효과도 미미한 기능
- 지원 문서 (Supporting documents)
- 디자인 및 엔지니어링 담당자와 협력하여 솔루션의 상호 작용 설계 및 기술 구현 정의
- PRD의 기능 요구 사항을 유지하되, 추가 세부 정보를 위해 UX 및 엔지니어링 설계 문서에 대한 링크 추가
- 배포 계획 (Go-to-market)
- 기능이 사용자에게 어떻게 출시될 것인지에 대한 고려 사항과 마케팅, 영업, 고객 지원 및 기타 사용자 대면 기능에 대한 기대치 등을 작성
- ETC
- 간단한 와이어프레임, 리서치 자료 등 첨부
📌 정리
요구사항 정의서에 대해서 이론적인 개념은 잡혀가지만 현업에서 일반적으로, 또는 도메인 유형에 따라 어떤 형태로, 어떤 양식으로 쓰이는지에 대해 파악해봐야겠습니다. 관심있는 도메인에 적합한 형태의 요구사항 정의서를 작성할 줄 아는 것도 PM으로서 갖춰야 할 하나의 역량이라고 생각됩니다.
적극적인 피드백은 언제나 환영입니다:)
