[아티클 카타] PRD(제품 요구사항 정의서)의 모든 것

https://brunch.co.kr/@sparkplus/566

PRD(제품 요구사항 정의서)의 모든 것

 

개인 아티클 정리

아티클 정보

제목: PRD(제품 요구사항 정의서)의 모든 것

작성자(저자): 스파크플러스

 

 

핵심 내용 요약

이 아티클의 주요 메시지:

PRD: 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로, 제품 개발 프로세스 전반에 걸쳐 필수적인 중요 문서

 

 

PRD 작성 방법

1. 사용자 문제 및 비즈니스 우선순위 결정의 근거를 포함
   • 개발 프로세스를 고려하여 사용자 문제와 개발 목표를 검토하고, 해결 방안에 대한 내용을 작성
   • 사용자 조사 결과, 다양한 옵션에 대한 토론과 평가, 기술적 한계, UX 고려 사항, 리소스 및 예산, 타임라인 요구 사항 등
2. 해결 방안의 세부 정보
   • 사용자 조사 결과를 확인할 수 있는 문서, 다양한 옵션이나 아이디어에 관해 토론한 회의 내용, 기술적 한계, UX 고려 사항, 리소스 및 예산 제약, 타임라인 요구 사항 등
   • 종속성 관련 링크, 협업하는 팀원들이 이해할 수 있도록 작성
3. UX 및 개발 설계 문서 참조
   • 개발, UX 디자인 문서를 포함하여 기능이 구축되는 방식
   • 옵션 피드백 제공, 우선순위 검토
4. PRD를 업데이트하여 기능 범위를 결정
   • 기능 범위에 대한 결정, UX 및 개발 설계 문서와 중복되지 않도록
   • 중요한 결정과 절충안, 기술적 고려 사항, 다른 팀에 대한 종속성, 사용자 개인정보 보호 또는 법적 문제 등
   • 향후 특정 버전의 기능을 구축하기로 한 경우에도 기록
5. 다른 사람과 공유
   • PRD와 필수 변경 사항을 자주 공유하여 다른 사람들의 의견을 구하는 것이 중요
6. 개발 중에도 계속 업데이트
   • PRD를 계속 업데이트하고 타임라인 및 범위에 대한 중요한 업데이트를 다른 팀과 공유

 

 

PRD 구성 요소

1. 제품 개요(요약과 배경)
   • 제품의 목적, 해결해야 할 문제에 대한 요약, 왜 이 문제를 해결해야 하는지 근거
   • 기획, 개발의 중요성을 강조할 수 있는 근거 데이터(설문조사, 인터뷰, 지표)를 참고
2. 비즈니스 목표 혹은 지표
   • 비즈니스 목적 분석: 먼저 비즈니스가 달성하고자 하는 목표를 분석. 매출 증가, 시장 점유율 확대 등
   • 키 성과 지표(KPI): 비즈니스 목표에 따라 측정 가능한 KPI를 식별. 매출 증가를 목표로 한다면 매출 증가율, 고객 당 평균 거래 금액, 신규 고객 유입 비율 등
   • 목표 수치 설정: 각 KPI에 대해 목표 수치를 설정
3. 핵심 고객 또는 사용자 정의
   • 우리 제품을 사용할 사용자에 대해 정의
4. 핵심 사용자 여정(Critical User Journeys, CUJ)/사용자 스토리(User Story)
   • 신규 개발 후 3번에서 정의한 사용자가 목표한 달성할 수 있는지. 중요한 건 사용자 요구에 집중하며, 해결 방안에 집착하지 않는 것
   • 사용자 스토리: 사용자가 제품 또는 서비스를 이용할 때 생기는 상황, 목적, 요구사항 등을 간결하고 명확하게 표현한 문장
5. 기능적 요구 사항
   • 대상 사용자, Must Have, Should Have, Could Have
6. 프로젝트 일정 및 배포 계획
   • 함께 개발해야 하는 팀원들과 이해관계자, 의사 결정권자와 소통하며 일정 세우기
7. 기타 참고 문서
   • 래퍼런스, 와이어 프레임, 스토리보드, UX 리서치 결과 등 첨부

 

핵심 키워드:

PRD, KPI, Must Have, Should Have, Could Have

 

 

흥미로운 점/새롭게 알게 된 점

읽으면서 가장 흥미로웠던 부분:

기획 단계에서는 제품의 비전과 전략을 정의하고,

디자인 단계에서는 제품이 사용자 요구 사항을 충족하는지 확인하고,

개발 단계에서는 기능의 목적과 구현을 확인하고,

테스트 단계에서는 제품이 기술 요구 사항을 충족하는지 확인하고,

출시 단계에서는 제품이 시장 혹은 사용자의 요구 사항을 충족하는지 확인하는 데 사용

 

이전에는 알지 못했거나 새롭게 배운 내용:

해결 방안에 세부 정보 추가 항목에서, 다른 팀(혹은 기술)에 대한 종속성 및 관련 링크도 포함시켜야 한다는 것.

 

나의 한 문장 요약

이 아티클을 한 문장으로 요약하면?

PRD는 다른 팀과 협업하기 위한 도구로, 신중하게 작성해야 한다.

 

 

인사이트

실제 업계에서 PRD를 작성할 때 어떤 툴을 쓰는지, 어떻게 공유하고 협업하는지 궁금.

 

 

---

 

 

오늘 논의했던 아티클 주제를 정리

1. 아티클 제목:

PRD(제품 요구사항 정의서)의 모든 것

 

 

2. 팀 전체 논의 요약:

1 : PRD는 작성 후 여러 환경 제약, 이해관계자들의 의견 등으로 변경될 수 있다. 업데이트 사항을 공유하는건 당연한데, 버전관리는 어떻게 하는게 좋을까? 해당 의사결정의 백그라운드와 히스토리를 알려면 버전관리가 중요할 것 같다. 하지만 사소한/규모가 작은 변경사항들이 점점 많아질 경우, 모두 버저닝을 해야할까? 어떤 기준으로 어떻게 관리를 하는게 효율적이고 효과적일지 고민이 된다.

• 2 : 버전이 너무 많아지게 되면 복잡성이 높아지니 아카이브를 틈틈이 해주며 버전관리를 하면 좋을 것 같다.

1 : 사소한 기능 업데이트에도 PRD가 필요할까?

• 나: 기능이 얼마나 큰지에 따라 PRD의 상세사항 작성도 크거나 작아질 것 같아요. 정확히는 모르지만…

나 : 실제 업계에서 PRD를 작성할 때 어떤 툴을 쓰는지, 어떻게 공유하고 협업하는지 궁금.

• 1 :
  • 툴
    • 노션 / 피그마 / 피피티 ?
  • 공유 / 협업
    • 문서 먼저 슬랙으로 공유하고 이해관계자들이 미리 읽어볼 수 있도록 하여 코멘트로 질문을 받아놓고 → 대면 미팅을 통해 발표를 하며 내용을 공유 → 질문에 대해 답변, 협의, 대안 논의 → 추가적으로 알아봐야할 것, 다음 단계까지 액션아이템 정해서 해산
    • 이런 방식으로 했던 것..같습니다.

3 : 신규 서비스의 경우 기존 데이터가 없고 사용자 데이터가 없는데 어떻게 논리적으로 작성하지?

• 1 : 로드맵을 수립하고, 가설 기반의 내용으로 작성했던 것 같은데 .. 정답은 저도 잘 모르겠습니다 ..

 

3. 팀 공통 인사이트 or 느낀 점 요약:

• PRD를 작성하는 목적은 단순히 기능 요구사항을 정리하는 것이 아니라, 제품이 해결하려는 사용자 문제와 비즈니스 목표를 모든 이해관계자가 동일하게 이해하도록 만드는 것이라는 점을 다시 한번 느꼈습니다.
• 특히 기능이나 솔루션 자체보다 사용자의 근본적인 니즈에 집중해야 한다는 점이 인상 깊었으며, 이를 위해 User Journey와 User Story를 활용한 문제 정의가 중요하다고 생각했습니다.
• 또한 PRD는 개발 시작 전에 완성되는 문서가 아니라 개발 과정에서 지속적으로 업데이트되는 살아있는 문서라는 점을 알게 되었고, 협업과 의사결정의 기준이 되는 만큼 더욱 체계적으로 관리해야 한다고 느꼈습니다.

 

4. 튜터님 피드백 :

PRD 작성에는 정해진 형식이 없으며, 회사와 프로젝트에 맞춰 유연하게 작성해야 함 전임자의 문서를 참고하는 것이 가장 효과적이며 유저 스토리 기반 작성법을 익히는 것이 중요함 Confluence가 업계 표준 도구로 가장 많이 사용됨

 

PRD 작성 가이드

• PRD 작성 원칙: 회사별 전임자 문서 형식을 기준으로 작성
• 도구 선택: Confluence(70-80%), Notion(20%), 또는 Asana 중 하나 사용
• 유저 스토리 적용: 다음 개인 프로젝트부터 유저 스토리 형식으로 작성 연습 진행

 

버전 관리

• 회의 종료 후 새로운 요구사항 반영 시 버전 업데이트 ("회의 날짜 + 회의 내용 업데이트" 형식으로 버전 표기)

 

유저 스토리 작성법

• 핵심: 구체적인 유저 롤 정의가 필수
• 형식: As a [유저 롤], So that [목적]
  • 예시: "번개장터에서 특정 문제를 겪는 20% 유저는 검색 동의어 기능을 사용할 수 있다"
  • 데이터 분석과 유저 문제 파악이 선행되어야 함

 

유저 정의

PRD의 유저는 해당 기능의 타겟 유저 기준으로 작성 (제품 전체 타깃 유저 X)

 

플로우 차트 작성 기준

작성이 필요한 경우: 유저 동선과 경로, 경로별 데이터 값 전달이 필요한 경우 (예: 호텔 예약 관리 시스템)

불필요한 경우: 검색 엔진 동의어 시스템 등 단순 기능 추가 프로젝트

 

태도와 자세

• 호기심과 질문을 많이 하는 태도 유지
• 스타트업 문화의 IT 회사에서는 탐구적 태도를 주니어의 중요한 자질로 평가
• 궁금하지 않더라도 적극적으로 질문하고 관심 표현