제품 요구 사항 문서를 만드는 방법(PRD)

요약: 제품 요구 사항 문서(PRD)는 제품의 목적, 특징, 기능 및 동작을 포함하여 특정 제품의 요구 사항을 정의합니다. 비즈니스 및 기술 팀이 제품을 만들거나 출시하거나 마케팅하는 데 도움이 되는 가이드 역할을 합니다.

훌륭한 제품을 만들기 위해서는 수많은 연구와 종합적인 계획이 필요합니다. 하지만 어디서부터 시작해야 할까요? 제품 매니저는 종종 제품 요구 사항 문서(PRD)로 시작합니다.

제품 요구 사항 문서는 만들려는 제품을 정의합니다. 여기에는 제품의 목적, 특징, 기능 및 동작이 요약되어 있습니다.

그런 다음 제품을 만들거나 출시하거나 마케팅하는 데 도움을 주는 이해 관계자(비즈니스 및 기술 팀)에게 제품 요구 사항 문서를 공유하고 의견을 구합니다.

모든 이해 관계자를 정렬했으면 제품 요구 사항 문서는 나침반 역할을 하여 제품의 목적에 대한 명확한 방향을 제시하는 동시에 비즈니스 및 기술 팀 간의 공동의 이해를 조성합니다.

애자일 세계에서 요구 사항 수집 과정은 어떻게 진행될까요? 어렵다고 생각하시겠지만 걱정하지 마세요. Atlassian은 애자일 환경에서 제품 요구 사항 문서를 만들기에 관한 모든 것을 이해합니다. 명심해야 할 몇 가지 사항은 다음과 같습니다.

애자일 요구 사항은 제품 소유자에게 매우 유용합니다. 애자일 요구 사항을 사용하지 않은 제품 소유자는 올바른 소프트웨어를 제공하기 위해 모든 세부 사항을 나열하고 자신이 정확하게 나열했기를 행운으로 바랍니다. 반면 애자일 요구 사항은 제품 소유자, 디자이너 및 개발 팀 간에 공유하는 고객에 대한 공통된 이해에 의존합니다. 대상 고객에 대한 이해와 공감을 공유하면 제품 소유자에게 숨겨진 대역폭을 이용할 수 있게 됩니다. 그들은 더 높은 수준의 요구 사항에 집중하고 구현 세부 사항을 개발 팀에 맡길 수 있으며 이해를 공유하는 부분이 있기 때문에 세부 사항을 구현할 수 있는 것입니다. (완벽합니다!)

공동의 이해라는 아이디어에 기대가 되지만 이러한 이해를 형성하는 방법을 모른다면 다음 요령을 시도해보세요.

• 고객을 인터뷰할 때 설계 및 개발 팀원을 포함시켜서 제품 소유자의 메모에 의존하지 않고 고객의 의견을 직접 들을 수 있도록 합니다. 또한 고객의 마음 속에서 주제가 선명할 때 더 깊이 알아볼 수 있는 기회를 제공합니다.
• 고객 페르소나를 개발하고 사용하는 것은 팀이 함께 노력하는 것입니다. 각 팀원은 고유한 관점과 인사이트를 가지고 있으며 페르소나가 제품 개발에 어떤 영향을 미치는지 이해해야 합니다.
• 이슈 분류 및 백로그 그루밍도 팀 활동으로 만듭니다. 이것은 모든 팀원이 같은 정보를 공유하는지 확인하고 제품 소유자가 작업의 우선 순위를 지정한 방식을 이해할 수 있는 좋은 기회입니다.

한번 시도해 보시겠습니까? Confluence에 가입 또는 로그인>>

고객 인터뷰 템플릿을 만들어 고객 인사이트를 문서화하세요. 자습서를 따라 소중한 고객 인터뷰를 시작하세요.

• 통찰력 있는 고객 인터뷰 페이지 만들기
• 고객 인터뷰 피라미드로 정보를 인사이트로 전환

좋습니다. 엔지니어 및 디자이너와 일련의 사용자 스토리를 논의했습니다. 몇 번의 화이트보드 세션을 진행했으며 작업 중인 이 기능에 대해 고려해야 할 몇 가지 측면이 더 있다는 결론을 내렸습니다. 몇 가지 가정을 구체화하고 전반적인 구성에 적합한지 숙고하고 답해야 하는 해결되지 않은 질문을 확인하고 추적해야 합니다. 다음 단계는 무엇입니까?

요구 사항 문서를 작성할 때 팀 전체에서 일관된 템플릿을 사용하여 모든 팀원이 따라오고 피드백을 제공할 수 있도록 하는 것이 좋습니다. Atlassian에서는 Confluence를 사용하여 제품 요구 사항 문서 템플릿으로 제품 요구 사항을 만듭니다. 아래 섹션에서는 프로젝트의 요구 사항과 프로젝트가 사용자에게 미치는 영향을 이해하기에 '겨우 충분한' 컨텍스트를 제공합니다.

1. 프로젝트 세부 사항 정의
다음과 같이 페이지 상단에 상위 수준의 방향을 포함하는 것이 좋습니다.

• 참가자: 누가 관여합니까? 제품 소유자, 팀, 이해 관계자 포함
• 상태: 프로그램의 현재 상태는 어떻습니까? 목표 이내, 위험, 지연, 연기 등
• 목표 릴리스: 언제 제공할 것으로 예상됩니까?

2.팀 목표 및 비즈니스 목표
요점만 간단히 기술하세요. 정보를 제공하되 지루한 내용이어선 안 됩니다.

3. 배경 및 전략적 적합성
이 일을 하는 이유는 무엇입니까? 이것이 회사 전체 목표에 어떻게 부합합니까?

4. 가정
기술, 비즈니스 또는 사용자 가정을 나열합니다.

5. 사용자 스토리
관련된 사용자 스토리를 나열하고, 사용자 스토리와 고객 인터뷰에 연결하고, 확인한 내용의 스크린샷을 포함합니다. 전체 스토리를 만들 수 있도록 충분한 세부 정보를 제공하고 성공 메트릭을 포함합니다.

6. 사용자 상호 작용 및 디자인
팀이 각 사용자 스토리 대한 솔루션을 구체화한 후 디자인 탐색 및 와이어프레임을 페이지에 연결합니다.

7. 질문
팀이 해결해야 하는 문제를 이해하면 질문이 있을 수 있습니다. 이러한 항목을 추적하기 위해 "결정하거나 조사해야 할 항목"이라는 표를 만듭니다.

8. 하지 않는 일
자신이 하지 않는 일을 명확하게 설명하여 팀이 맡은 작업에 집중할 수 있도록 하세요. 현재 범위에서 벗어나지만 나중에 고려할 수 있는 항목에 플래그를 지정합니다.

다음은 Confluence를 사용하여 만든 완전히 구체화된 제품 요구 사항 문서입니다. 완전히 같은 두 개의 제품 요구 사항은 없습니다. 이 예시를 통해 제품 요구 사항 문서(PRD)에 포함해야 하는 여러 요소를 이해하세요. 반드시 이런 구성을 따라야 하는 것은 아닙니다.

이 블로그에서 배울 점이 있다면 "무엇"이 아니라 "이유"를 이해하는 것입니다. "이유"는 팀에 가장 적합한 것을 탐구할 수 있도록 지원합니다. 한 페이지 대시보드 접근 방식을 통해 관찰한 이점과 과제는 다음과 같습니다.

1. 한 페이지, 하나의 소스
단순하게 유지하세요. 제품 요구 사항 문서는 특정 에픽 내의 일련의 문제와 관련된 모든 항목에 대한 '방문 페이지'가 됩니다. 편리한 중앙 집중식 위치가 있으면 팀원이 정보에 액세스하는 시간을 절약해 주고, 팀원에게 간략한 보기를 제공할 수 있습니다.

2. 추가 민첩성
간단한 페이지를 사용하여 공동 작업(전용 요구 사항 관리 도구 대비)하는 장점 점 중 하나는 문서화에 대해 민첩하게 대응할 수 있다는 것입니다. 매번 같은 형식을 따를 필요는 없습니다. 필요할 때 필요한 작업을 수행하고 민첩하게 대응하세요. 필요에 따라 편집하고 변경하세요.

3. 충분한 맥락과 세부 사항
우리는 단순한 링크가 얼마나 강력한지 잊어버리곤 합니다. 제품 요구 사항 문서에는 많은 링크가 포함되어 있습니다. 링크는 복잡성을 추상화하고 점진적으로 필요한 대로 독자에게 정보를 공개하는 데 도움이 됩니다. 자세한 리소스 연결에는 다음이 포함될 수 있습니다.

• 기능에 대한 배경, 유효성 검사 또는 추가 컨텍스트를 위한 고객 인터뷰
• 유사한 아이디어를 제안하는 페이지 또는 블로그
• 이전 토론 또는 기술 설명서 및 다이어그램
• 제품 데모 비디오 또는 외부 소스의 기타 관련 콘텐츠

4. 살아있는 스토리
많은 고객이 이것을 수행합니다. 스토리를 대략적으로 고려하여 Jira에서 이슈로 입력했으면 페이지에서 스토리에 연결합니다. 이렇게 하면 편리하게 이슈에서 페이지로 돌아가는 링크도 만들어집니다. Confluence 및 Jira 간의 양방향 동기화는 요구 사항 페이지에서 바로 각 이슈의 현재 상태를 자동으로 확인할 수 있다는 것을 의미합니다.

5. 집단 지성
Confluence에서 제품 요구 사항을 파악하면 다른 팀의 팀원들이 쉽게 기여하고 제안할 수 있습니다. 저는 다른 팀에 속한 많은 팀원이 대화에 참여해 우수한 피드백, 제안 및 유사 프로젝트에서 배운 점에 대한 의견을 제공하는지를 확인하게 되어 놀라웠습니다. 대규모 조직이 소규모 팀처럼 느껴질 수 있습니다.

6. 참여형 "추가 기능"
Visio, Gliffy 또는 Balsamiq와 같은 도구로 만든 다이어그램은 문제를 팀에 더 잘 설명합니다. 외부 이미지, 비디오 및 동적 콘텐츠를 포함할 수도 있습니다.

7. 공동 작업!
이 모든 것의 가장 중요한 측면은 모든 팀원을 참여시키는 것입니다. 제품 요구 사항 문서를 직접 작성하지 마세요. 항상 개발자와 함께 작성해야 합니다. 팀과 페이지를 공유하고 피드백을 받으세요. 댓글을 달고, 질문하고, 다른 사람들이 생각과 아이디어에 기여하도록 격려하세요. 특히, 프로젝트를 직접 논의할 기회가 많지 않은 분산된 팀에게 특히 중요합니다.

모든 접근 방식에는 단점이 있습니다. 직접 경험하고 고객이 관찰한 두 가징 주요 과제는 다음과 같습니다.

1. 오래된 문서가 될 가능성
스토리를 구현하고 피드백을 받은 다음 솔루션을 수정하면 어떻게 됩니까? 누군가 돌아가서 요구 사항 페이지를 최종 구현으로 업데이트합니까? 이것은 모든 유형의 문서에서 어려운 과제이며, 이러한 절충이 가치가 있는지 항상 의문을 제기할 가치가 있습니다. 이와 같은 시나리오에서 무엇을 할 것인지에 대해 팀과 이야기하세요.

2. 참여 부족
“팀원들이 댓글을 달도록 장려하려면 어떻게 해야 합니까?”, “팀원들이 인트라넷에 더 많은 사양과 스토리를 작성하도록 유도하려면 어떻게 해야 합니까?” 이것은 쉽지 않은 일로, 조직은 다양한 위키를 도입하게 됩니다. 여기에 도움이 되는 리소스가 많이 있습니다. 여기에는 더 깊은 문화적 이슈도 있을 수 있습니다.

요구 사항이 민첩하면 제품 소유자가 시장을 이해하고 이에 보조를 맞출 수 있는 시간이 더 많아집니다. 또한 정보를 제공하면서도 간결하게 유지하면 개발 팀이 아키텍처 및 기술 스택에 가장 적합한 구현을 사용할 수 있습니다.

프로젝트의 요구 사항을 적절하게 준비했으면 위 섹션 5의 사용자 스토리를 개발 팀의 이슈 추적기의 해당 스토리에 연결하는 것이 좋습니다. 이렇게 하면 개발 프로세스가 더욱 투명해집니다. 각 작업의 상태를 쉽게 확인할 수 있으므로 제품 소유자는 물론 마케팅 및 지원과 같은 다운스트림 팀이 더 합리적 결정을 내릴 수 있습니다.

프로젝트 요구 사항의 변화에 민첩하게 대처해야 합니다. 팀이 빌드하고 제공하고 피드백을 받으면 사용자 스토리를 변경해도 괜찮습니다. 기능을 더 적게 제공하더라도 항상 고품질 기준 및 건전한 엔지니어링 문화를 유지하세요.