[PM온보딩] 프로젝트 분석 : 기능정의서와 PRD 2
Chapter 6
PRD 작성법
PRD(Product Requirements Document)는 제품 또는 서비스의 요구사항을 정리한 문서입니다.
인하우스에서 다루는 PRD와 에이전시에서 다루는 PRD는 조금 차이가 있을 듯하여 먼저 차이점을 얘기하고 에이전시에서는 PRD를 어떻게 활용하는지 예시와 함께 안내해 보겠습니다.
인하우스 PRD의 목적 : 내부 팀과의 공통 이해 및 방향성 확립
에이전시 PRD의 목적 : 클라이언트 요구사항 이력 및 범위 관리
인하우스 PRD의 기준 : 사용자 중심 문제 해결 / KPI 기반 기능 도출
에이전시 PRD의 기준 : 클라이언트 요청 정리 / 계약 범위 명확화
인하우스 PRD의 작성 흐름 : 제품의 흐름에 따른 설계 중심
에이전시 PRD의 작성 흐름 : 요청 중심으로 기록 및 추적
인하우스 PRD의 문서 활용 : 기능 기획, 개발 지시, 내부 커뮤니케이션
에이전시 PRD의 문서 활용 : 범위 관리, 요청 이력 관리, 클라이언트 커뮤니케이션
에이전시에서는 클라이언트 요구사항이 중간에 수시로 변경되거나 추가되는 경우가 많기에 그에 따른 일정, 리소스, 기능의 변경 가능성을 염두하며 관리해야 합니다.
PRD는 요구사항 변경의 내용과 정리된 협의 기록 문서로써 활용된다고 이해해 주시면 좋아요.
그렇다면, 앞서 진행한 기능정의서와는 어떤 차이점이 있을까요?
기능정의서는 프로젝트 초기에 기능을 중심으로 작성하게 되는데요. “무엇을 만들 것인가”에 집중하여, 기능을 "어떻게 만들지"에 대해 정리된 문서라면,
PRD는 기능정의서 작성 이후 프로젝트 진행 중 변경사항을 추적하는 데에 중점을 둡니다. 따라서 PRD는 디자인과 개발이 진행되는 중에도 계속해서 업데이트됩니다.
PRD는 왜 필요할까요?
1. 변경사항 관리 및 커뮤니케이션 도구
에이전시에서는 클라이언트 요구 사항이 자주 발생하기에 이를 문서화하고 기록하여 혼선을 줄이고 소통을 원활하게 이어가는데 도움이 됩니다.
2. 범위 관리 및 기준
기능정의서에 없던 요청이 프로젝트 진행 중에 추가되었을 때, PRD는 "언제, 누가, 어떤 이유로 요청했는가"를 정리할 수 있기에 추가 견적 요청이나 일정 협의 시 기준이 됩니다.
3. 버전 관리와 히스토리 확보
프로젝트 종료 후 PRD는, 유지보수나 리뉴얼 작업 시 매우 중요한 레퍼런스 자료가 됩니다.
PM은 PRD 작성을 위해 사용자의 문제를 어떻게 정의하고, 이를 해결하기 위해 어떤 기능을 왜 넣어야 하는지를 설명할 수 있어야 하며, 사용자 중심으로 고민하고 사고를 확장시키는 노력이 필요합니다.
1. 사용자 페르소나 정의
이 기능은 누구를 위한 것일까?
사용자의 사용 목적, 서비스에 접근하는 경로 등을 설정
예시: 당근마켓의 '채팅하기' 기능 : 거래 성사를 위한 판매자와 구매자 간 1대 1 소통 창구 / 판매 리스트 > 판매 상세 페이지 > 채팅하기 클릭 / 목적은 상품 상태 확인, 가격 협의, 거래 장소 및 시간 약속
MVP 가설 검증 단계에서 클라이언트가 카카오톡처럼 이모티콘도 보낼 수 있으면 좋겠고, 그룹 채팅 기능도 가능했으면 좋겠다는 요구 사항을 줬다면?
거래 성사를 위해 도움이 되는 기능인가? 현 단계에서 필수적인 기능인가? 유사 서비스들도 제공하는 기능인가?
2. 문제 정의와 목적 정리
이 기능을 왜 만들려고 하는 걸까?
지금 이 기능이 없다면 사용자가 겪을 불편은 무엇일까?
클라이언트의 요청이라 하더라도, 그 기능이 어떤 목적을 위한 것인지를 파악하여 우선순위를 잡습니다.
3. 사용자 여정 또는 화면 흐름 파악
해당 기능이 사용자의 전체 여정 중 어디에 위치하는지
이 기능이 어디에서 시작되고, 어떤 다음 행동으로 연결되는지
4. 기존 기능정의서와의 매핑
작성 중인 PRD는 기능정의서의 어떤 기능과 연결되는지
신규 추가인지, 기존 내용 변경인지 구분을 짓습니다.
5. 기술 제약 및 외부 기능 검토
API 연동, 보안 요건, 성능 요구 등 개발 측면에서의 제약이 있다면 미리 정리
외부 API (예: PG사, 지도 API 등) 연동이 필요한 경우 사전에 범위 및 조건 확인하기
PRD 핵심 구성 요소
PRD의 요소는 기록과 추적이 용이하도록 구성하는 것이 중요합니다. 아래는 에이전시 PRD 문서에 포함되면 좋을 구성 요소입니다.
1. 화면
해당 기능이 적용될 화면 또는 페이지 이름
2. 구분
해당 항목이 신규 기능인지, 기존 기능 변경인지 명시
→ 프로젝트 범위 관리, 견적 협의 등의 기준이 됩니다.
3. 메뉴 (혹은 위치)
사용자가 이 기능을 어디에서 접근하는지
4. 요건
기능에 대한 상세 설명
가능하다면 시나리오 형태로 작성 (사용자가 어떤 상황에서 어떤 행동을 하는지)
5. 요청 유형
클라이언트 요청이 기능, 정책, UI, 콘텐츠, 문구 등 어떤 범주에 해당하는지
→ 디자이너/개발자에게 전달 시 담당 영역을 빠르게 파악할 수 있습니다.
6. 비고
협의 사항, 추가 논의 필요 여부, 특별한 고려사항 등
7. 등록일
요청이 접수된 날짜 (보통 회의일, 메일 수신일 기준)
→ 요청의 시간적 우선순위 및 누적 이력 관리에 도움
8. 출처
요청자 이름, 회의 명, 메일 제목 등
디자인(피그마), 개발(지라), 일정(간트차트), 회의록(컨플), 기능정의서 등을 연결해 놓으면 훨씬 더 유용한 문서가 될 거예요.
예시와 더불어 구성 요소를 어떻게 작성하면 좋을지 시트를 아래와 같이 좀 더 채워보았어요.
PRD는 디자이너, 개발자, 클라이언트, QA 등 모든 이해관계자가 같은 방향으로 이해하고 움직이기 위한 기준이 됩니다. 아무리 자세하게 작성했다고 하더라도 제대로 전달이 되지 않고 이해관계자들이 각각 다르게 이해하고 있다면 PRD로서의 역할을 다했다고 볼 수 없어요.
구성 요소에 따라 작성하고, 모두가 인지할 수 있도록 바로바로 공유하며, 놓치지 않고 주기적으로 관리해줘야 합니다.
프로젝트를 진행하다 보면 클라이언트의 요청, 팀원들의 피드백, 논의 내용들이 슬랙, 피그마, 이메일, 회의록 등 여기저기 흩어지기 쉬워요. 이때 PM은 주도적으로 추적하여 누락되지 않도록 한 곳에 모아 정리하고 공유하며 관리하는 것이 중요합니다.
