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

주요 시사점

• 제품 요구 사항 문서(PRD)는 제품의 목적, 기능 및 동작을 정의하여 이해 관계자를 정렬하고 개발을 안내합니다.

• 애자일 PRD는 지나치게 상세한 사양을 피하면서 공통된 이해, 고객 요구 사항 및 유연성에 중점을 둡니다.

• 효과적인 PRD에는 목표, 가정, 사용자 스토리, 디자인 및 명확하게 범위를 벗어난 항목이 포함되어 공동 작업을 촉진하고 적응성을 높여줍니다.

• 팀과 공동 작업하여 간결한 PRD를 만들고 정기적으로 업데이트하여 프로젝트 전반에 걸쳐 명확성 및 정렬을 보장하세요.

성공적인 제품을 만드는 것은 명확한 방향 및 정렬에서 시작됩니다. 바로 여기에서 제품 요구 사항 문서(PRD)가 필요합니다.

PRD는 제품의 핵심 특징, 목표 및 기능을 설명하며, 팀이 아이디어를 현실로 만들 수 있도록 제품 로드맵 역할을 합니다. 이것은 팀, 이해 관계자 및 전체 목표를 정렬해야 하는 모든 제품 관리자에게 중요한 단계입니다.

이 문서에서는 제품 요구 사항 문서의 정의, 제품 요구 사항 문서가 중요한 이유 및 제품 요구 사항 문서를 통해 효과적인 제품 개발의 기반을 마련하는 방법을 알아봅니다.

제품 요구 사항 문서(PRD)란 무엇입니까?

제품 요구 사항 문서(PRD)는 만들려는 제품의 목적, 특징, 기능 및 동작을 명시하여 제품을 정의합니다.

제품의 목적, 주요 제품 기능, 사용자 요구 사항 및 성공 기준을 정의하여 교차 기능 팀을 위한 단일 정보 출처를 제공합니다.

PRD는 요구 사항 및 기대치를 명확하게 문서화하여 디자이너 및 개발자부터 이해 관계자까지 모두가 제품 개발 프로세스 전반에 걸쳐 정렬된 상태를 유지하도록 합니다.

애자일 작업을 위한 제품 요구 사항 문서

애자일 환경에서 요구 사항 수집 과정은 어떻게 진행될까요? 어렵게 들리겠지만(실제로 그렇지만) 걱정하지 마세요.

Atlassian은 애자일 환경에서 제품 요구 사항 문서를 만드는 방법에 대해 잘 알고 있습니다. 애자일 요구 사항은 제품 소유자에게 매우 유용합니다.

애자일 요구 사항을 활용하지 않는 제품 소유자는 적합한 소프트웨어를 제공하기 위해 모든 세부 사항을 명세화하는 데 매달립니다. 그리고 자신이 제대로 명세화했기를 간절히 바랍니다. 반면 애자일 요구 사항은 또한 고객에 대한 공통된 이해를 바탕으로 합니다.

제품 소유자, 디자이너 및 개발 팀은 고객에 대한 공통된 이해를 갖춥니다. 대상 고객에 대한 공통된 이해 및 공감은 제품 소유자에게 숨겨져 있던 작업 수용량을 끌어냅니다.

이들은 더 높은 수준의 요구 사항에 집중하고 구현 세부 사항을 개발 팀에 맡길 수 있습니다. 공통된 이해를 갖추고 있기 때문에 개발 팀은 세부 사항을 구현할 수 있습니다.

효과적인 제품 요구 사항 문서를 만들기 위한 팁

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

• 고객을 인터뷰할 때 설계 및 개발 팀원을 포함시켜서 제품 소유자의 메모에 의존하지 않고 고객의 의견을 직접 들을 수 있도록 합니다. 또한 고객의 마음 속에서 주제가 선명할 때 더 깊이 알아볼 수 있는 기회를 제공합니다.

• 고객 페르소나를 개발하고 사용하는 것은 팀이 함께 노력하는 것입니다. 각 팀원은 고유한 관점과 인사이트를 가지고 있으며 페르소나가 제품 개발에 어떤 영향을 미치는지 이해해야 합니다.

• 업무 항목 분류 및 백로그 그루밍도 팀 활동으로 만듭니다. 이것은 모든 팀원이 같은 정보를 공유하는지 확인하고 제품 소유자가 작업의 우선 순위를 지정한 방식을 이해할 수 있는 좋은 기회입니다.

사용해 보시겠습니까? Confluence에 가입하세요.

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

• 통찰력 있는 고객 인터뷰 페이지 만들기

• 고객 인터뷰 피라미드로 정보를 인사이트로 전환

엔지니어 및 디자이너와 함께 일련의 사용자 스토리를 논의했습니다. 몇 차례 논의하고 몇 번의 화이트보드 세션을 진행한 끝에, 현재 작업 중인 이 기능에 대해 고려해야 할 몇 가지 추가적인 측면이 있다는 결론을 내렸습니다.

몇 가지 가정을 구체화하고 전반적인 구성에 적합한지 숙고하고 답해야 하는 해결되지 않은 질문을 확인하고 추적해야 합니다. 다음 단계는 무엇입니까?

PRD에는 무엇이 포함되어야 합니까?

요구 사항 문서를 작성할 때 팀 전체에서 일관된 템플릿을 사용하여 모든 팀원이 따라오고 피드백을 제공할 수 있도록 하는 것이 좋습니다. Atlassian에서는 Confluence를 사용하여 제품 요구 사항 문서 템플릿으로 제품 요구 사항을 만듭니다.

아래 섹션에서는 프로젝트의 요구 사항과 프로젝트가 사용자에게 미치는 영향을 이해하기에 '겨우 충분한' 컨텍스트를 제공합니다.

1. 프로젝트 세부 사항 정의

다음과 같이 페이지 상단에 개략적인 방향을 포함하는 것이 좋습니다.

• 참가자: 누가 관여합니까? 제품 소유자, 팀, 이해 관계자 포함

• 상태: 프로그램의 현재 상태는 어떻습니까? 목표 이내, 위험, 지연, 연기 등

• 목표 릴리스: 언제 제공할 것으로 예상됩니까?

2. 팀 목표 및 비즈니스 목적

요점만 간단히 기술하세요. 정보를 제공하되 지루한 내용이어선 안 됩니다. 이 목표를 읽기 쉬운 형식으로 자세히 기술해 주는 적합한 소프트웨어를 갖추면 모든 관계자에게 도움이 됩니다.

비즈니스 목표는 명확하고 간결해야 할 뿐만 아니라, 이해 관계자를 정렬할 수 있을 만큼 충분한 정보를 제공해야 합니다. 다른 사용자가 추측할 여지를 주지 마세요.

3. 배경 및 전략적 적합성

배경 섹션에서는 제품 또는 기능의 개발 배경 및 그것이 회사의 전반적인 목표와 어떻게 부합하는지를 설명합니다. 프로젝트가 중요한 이유 및 해결하려고 하는 문제에 대한 컨텍스트를 제공합니다.

전략적 적합성을 자세히 설명하면 이 작업이 조직의 비전 및 우선 순위를 어떻게 뒷받침하는지 모든 구성원이 이해할 수 있습니다. 이 명확성은 팀이 중요한 가치를 제공하는 데 집중할 수 있도록 돕습니다.

4. 가정

이 섹션에서는 팀이 기술, 비즈니스 요구 사항 또는 사용자 행동에 대해 가정하고 있는 내용을 설명합니다. 가정을 명확히 명시하면 잠재적 위험 및 검증이 필요할 수 있는 영역을 식별하는 데 도움이 됩니다.

또한 모든 구성원이 의사 결정 및 계획에 영향을 미치는 요인을 인지할 수 있게 합니다. 프로젝트 전반에 걸쳐 이 가정을 재검토하면 새로운 정보가 나타날 때 팀이 대응하는 데 도움이 됩니다.

5. 사용자 스토리

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

6. 사용자 상호작용 및 디자인

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

7. 질문

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

8. 하지 않는 일

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

잘 작성한 제품 요구 사항 문서의 이점

이 블로그에서 배울 점이 있다면 "무엇"이 아니라 "이유"를 이해하는 것입니다. "이유"는 팀에 가장 적합한 것을 탐구할 수 있도록 지원합니다.

한 페이지 대시보드 접근 방식을 통해 관찰한 이점과 과제는 다음과 같습니다.

1. 한 페이지, 하나의 소스

단순하게 유지하세요. 제품 요구 사항 문서는 특정 에픽 내의 일련의 문제와 관련된 모든 항목에 대한 '방문 페이지'가 됩니다.

편리한 중앙 집중식 위치가 있으면 팀원이 정보에 액세스하는 시간을 절약해 주고, 팀원에게 간략한 보기를 제공할 수 있습니다.

2.추가 민첩성

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

3. 충분한 컨텍스트 및 세부 정보

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

자세한 리소스 연결에는 다음이 포함될 수 있습니다.

• 기능에 대한 배경, 유효성 검사 또는 추가 컨텍스트를 위한 고객 인터뷰

• 유사한 아이디어를 제안하는 페이지 또는 블로그

• 이전 토론 또는 기술 설명서 및 다이어그램

• 제품 데모 비디오 또는 외부 소스의 기타 관련 콘텐츠

4. 살아있는 스토리

스토리를 대략적으로 고려하여 Jira에서 업무 항목으로 입력했으면 페이지에서 스토리에 연결합니다. 이렇게 하면 편리하게 업무 항목에서 페이지로 돌아가는 링크도 만들어집니다.

Confluence 및 Jira 간의 양방향 동기화는 요구 사항 페이지에서 바로 각 업무 항목의 현재 상태를 자동으로 확인할 수 있다는 것을 의미합니다.

5. 집단 지성

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

대규모 조직이 소규모 팀처럼 느껴질 수 있습니다.

6. 매력적인 '부가 요소'

Confluence 화이트보드와 같은 도구로 만든 다이어그램을 사용하면 팀에 문제를 더 효과적으로 커뮤니케이션할 수 있습니다. 외부 이미지, 비디오 및 동적 콘텐츠를 포함할 수도 있습니다.

7. 공동 작업

이 모든 것의 가장 중요한 측면은 모든 팀원을 참여시키는 것입니다. 제품 요구 사항 문서를 혼자서 작성하지 마세요. 항상 개발자와 함께 작성해야 합니다. 팀과 페이지를 공유하고 피드백을 받으세요.

댓글을 추가하고 질문하고 다른 팀원들이 생각과 아이디어에 기여하도록 유도하세요. 특히, 프로젝트를 직접 논의할 기회가 많지 않은 분산된 팀에게 특히 중요합니다.

제품 요구 사항 문서의 도전 과제

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

1. 오래된 문서가 될 가능성

스토리를 구현하고 피드백을 받은 다음 솔루션을 수정하면 어떻게 됩니까? 누군가 돌아가서 요구 사항 페이지를 최종 구현으로 업데이트합니까?

이것은 모든 유형의 문서에서 어려운 과제이며, 이러한 절충이 가치가 있는지 항상 의문을 제기할 가치가 있습니다. 이와 같은 시나리오에서 무엇을 할 것인지에 대해 팀과 이야기하세요.

2. 참여 부족

"팀원들이 댓글을 추가하도록 장려하려면 어떻게 해야 합니까?", "팀원들이 인트라넷에 더 많은 사양과 스토리를 작성하도록 유도하려면 어떻게 해야 합니까?"

이것은 쉽지 않은 일로, 조직은 다양한 위키를 도입하게 됩니다. 여기에 도움이 되는 리소스가 많이 있습니다. 여기에는 더 깊은 문화적 이슈도 있을 수 있습니다.

Jira 및 Confluence로 PRD 작업 시작

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

프로젝트의 요구 사항을 적절하게 준비했으면 위 섹션 5의 사용자 스토리를 개발 팀의 업무 추적기의 해당 스토리에 연결하는 것이 좋습니다.

이렇게 하면 개발 프로세스가 더욱 투명해집니다. 각 작업의 상태를 쉽게 확인할 수 있으므로 제품 소유자는 물론 마케팅 및 지원과 같은 다운스트림 팀이 더 많은 정보에 기반하여 의사 결정을 내릴 수 있습니다.

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