제품 요구사항 프레젠테이션은 PRD를 그대로 복사한 문서가 아닙니다. 검토에서 필요한 문제, 범위, 제외 항목, 수용 기준, 미결정 사항을 먼저 보여 줍니다. 검토한 개요로 텍스트를 프레젠테이션으로 옮긴 편집 가능한 초안을 만들 수 있지만, 요구사항과 한계는 반드시 실제 PRD에서 가져와야 합니다.
검토에서 결정할 질문 정하기
‘공유 받은편지함 기능의 첫 릴리스 범위를 승인한다’처럼 시작합니다. 결정권자, 검토 예정일, 사용자 또는 비즈니스 문제를 함께 적습니다. 프로젝트 이름만으로는 자료가 올바른 질문에 답하는지 알 수 없습니다.
관찰된 증거와 경계를 사용해 문제를 설명합니다. ‘대화가 큐 사이를 이동하면 지원 담당자가 맥락을 잃는다’는 문제이고, ‘새 라우팅 서비스를 만든다’는 구현 가설입니다. 늦게 참여한 사람도 첫 슬라이드에서 결정, 추천안, 범위와 미해결 위험을 알 수 있어야 합니다. 사용자 조사 결과 발표 가이드는 소규모 정성 조사 결과를 전체 사용자에게 일반화하지 않으면서 관찰 내용을 제품 의사결정으로 연결하는 방법을 설명합니다.
범위를 세 층으로 나누기
릴리스를 포함, 제외, 보류로 나눕니다. 포함 항목은 사용자 행동이나 관찰 가능한 결과로 씁니다. 공유 받은편지함의 예로 한 큐에 대화를 배정하고 담당자를 표시하며 인수인계를 기록하는 기능을 들 수 있습니다. 감정 기반 자동 라우팅과 모바일 클라이언트는 제외 예시입니다. 실제 약속된 기능으로 받아들이지 않도록 표시하세요.
두 요구사항이 충돌하면 트레이드오프를 보여 줍니다. 빠른 첫 버전에서 하나의 ID 공급자만 지원하고 나머지를 다음 단계로 미룰 수 있습니다. 결과와 그 타협을 받아들일 담당자를 함께 적습니다.
가장 작은 유용한 사용자 흐름 설명하기
트리거, 사용자의 중요한 선택, 예상 결과가 포함된 핵심 흐름 하나를 고릅니다. 주요 경로를 이해한 뒤에 예외를 별도로 다룹니다. 각 단계에 필요한 정보, 사용자 행동, 피드백을 넣고 정책이나 외부 서비스 의존성을 표시하세요. 화면을 채우려고 존재하지 않는 컨트롤을 만들지 않습니다.
요구사항을 바꾸는 접근성과 오류도 표시합니다. 요청이 거절되거나 연결이 끊기거나 권한이 없을 때 무슨 일이 일어나는지 적습니다. 성공 경로만 있는 흐름은 완전한 요구사항이 아닙니다.
수용 기준을 검증 가능하게
조건이 주어지고 행동이 일어났을 때 어떤 결과가 보이는지 관찰 가능한 문장으로 씁니다. 기능, 품질, 운영 준비 기준을 구분하세요. 위험이 큰 기준에는 자동 테스트, 사용성 세션, 보안 검토, 부하 테스트, 수동 점검 같은 검증 방법을 붙입니다. 검증 방법은 성공 보장이 아니라 출시 전 합의한 확인 방식입니다.
Atlassian의 PRD 가이드는 가정과 제외 범위를 명시합니다. 아직 결정하지 않은 동작도 확정된 요구사항과 구분해 보여 주세요.
공유 받은편지함 예시에서 대화는 이미 큐 Q에 있고, 첫 릴리스에서는 권한이 있는 담당자가 자신에게 배정할 수 있다고 가정합니다. 아래는 가상 제품의 수용 기준 제안이며 Presenti의 기능이나 완료된 시험 결과가 아닙니다. 범위 슬라이드에 적은 감정 기반 자동 라우팅과 모바일 클라이언트는 계속 제외합니다.
| 조건과 행동 | 관찰할 결과 또는 미결정 사항 | 방법과 책임자 |
|---|---|---|
| Q의 대화가 미배정 상태이고, Q 권한이 있는 담당자가 자신에게 배정한다 | 그 담당자가 표시되며 다시 열어도 배정이 유지된다. 인수인계 기록에는 행동한 사람과 해당 대화가 남는다 | QA가 권한 있는 계정으로 실행하고 저장된 배정과 기록을 확인한 뒤 제품 책임자에게 결과를 전달한다 |
| Q 권한이 없는 담당자가 정상 화면 밖의 직접 요청까지 포함해 같은 배정을 시도한다 | 배정이 거부되고 담당자와 인수인계 기록은 바뀌지 않는다. 응답에 보호된 대화 내용이 노출되지 않는다 | 보안 책임자가 거부 시험을 정의한다. QA는 화면과 요청 경로에서 시험하고 상태가 바뀌지 않았는지 확인한다 |
| 권한 있는 두 담당자가 같은 미배정 대화를 보고 거의 동시에 자신에게 배정한다 | 충돌 정책은 미정이다. 새로고침 안내와 함께 충돌한 배정을 거부할지, 다른 합의된 규칙을 적용할지 결정해야 한다. 마지막 쓰기를 자동으로 승인된 동작으로 취급하지 않는다 | 제품 책임자와 개발 책임자가 규칙과 피드백을 합의한 뒤 QA가 재현 가능한 동시성 시험을 만든다 |
동시 배정의 예상 결과가 정해지지 않았다면 수용 완료로 처리할 수 없습니다. 정책, 결정권자, 검토일을 결정 로그에 기록하고 PRD와 슬라이드를 함께 갱신합니다. 컨트롤을 숨겼다는 사실만으로 권한 강제를 입증할 수 없으므로 권한 없는 직접 요청도 시험해야 합니다. 각 기준에 실제 시험 결과를 연결하고 제안된 표를 시험 보고서처럼 제시하지 마세요.
각 요구사항에 우선순위와 알려진 의존성을 연결하고 명세, 사용자 관찰, 법무 확인, 기술 제약의 출처를 구분합니다. 위험이 큰 기준은 누가 언제 어떤 방법으로 확인할지 정하고, 방법이 미정이면 결정권자와 기한을 남깁니다.
다른 수용 기준의 예로는 ‘권한이 없는 사용자는 전송할 수 없다’, ‘연결이 복구되면 보내지지 않은 내용을 잃지 않는다’처럼 확인할 상태를 구체적으로 적을 수 있습니다. 대상 흐름과 제약에 맞춰 적용할 조건을 선택하고 확인 방법도 정합니다.
의존성과 선택지 드러내기
ID 공급자, 데이터 이전, 법무 검토, 디자인 시스템 구성요소, 다른 팀의 API를 담당자와 상태와 함께 적습니다. 일정에는 이 검토에 필요한 통합·테스트·결정 지점만 표시하고 불확실한 추정치를 약속처럼 쓰지 않습니다. 대안은 학습 시간, 되돌릴 수 있음, 사용자 위험과 유지보수 부담으로 비교하고 선택 기준을 밝혀야 합니다.
의존성이 있다고 해서 반드시 작업이 막히는 것은 아닙니다. 상태, 담당자, 다음 행동을 기록합니다. 담당자가 없는 의존성은 위험 또는 결정 항목으로 다룹니다.
기록할 수 있는 승인으로 마무리
범위 승인, 조건부 승인, 구체적인 수정 요청 중 하나를 선택하도록 요청합니다. 무엇을 승인했고 무엇을 제외했는지, 다음 담당자와 재검토일을 결정 로그에 남깁니다. 근거가 약하면 학습 목표가 명확한 탐색 과제나 프로토타입을 제안합니다. PRD와 버전 날짜를 함께 보내 당시 알고 있던 사실, 선택, 미해결 사항을 보존하세요.
PRD와 프레젠테이션에 버전 날짜와 변경 이유를 함께 기록합니다. 요구사항 변경이 결정에 영향을 주면 재검토 조건과 수용한 위험을 짧게 남깁니다. 슬라이드는 전체 명세나 구현을 대신하지 않습니다. 검토에서 확인된 내용과 아직 제안 단계인 요구사항을 결정 로그에서 구분합니다.
