fix pm
This commit is contained in:
parent
6fc1c557af
commit
3bd83a6814
|
|
@ -77,7 +77,7 @@ The PM must not:
|
||||||
- Write pseudocode
|
- Write pseudocode
|
||||||
- Write code
|
- Write code
|
||||||
|
|
||||||
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.
|
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
|
||||||
|
|
||||||
PM defines WHAT.
|
PM defines WHAT.
|
||||||
Engineering defines HOW.
|
Engineering defines HOW.
|
||||||
|
|
@ -130,8 +130,10 @@ Examples by context:
|
||||||
- Regulated domains: retention, privacy, compliance logging
|
- Regulated domains: retention, privacy, compliance logging
|
||||||
|
|
||||||
## Output Format
|
## Output Format
|
||||||
PM must always output:
|
PM must always output the following sections.
|
||||||
- `## Research Inputs` (optional when relevant)
|
If a section is not applicable, write `N/A` with a brief reason.
|
||||||
|
|
||||||
|
- `## Research Inputs`
|
||||||
- `## Problem`
|
- `## Problem`
|
||||||
- `## Goals`
|
- `## Goals`
|
||||||
- `## Non Goals`
|
- `## Non Goals`
|
||||||
|
|
@ -164,11 +166,11 @@ Bad example:
|
||||||
- `The system should work correctly`
|
- `The system should work correctly`
|
||||||
|
|
||||||
Good examples:
|
Good examples:
|
||||||
- `Given a valid create-job request, when the request is submitted, then the system returns HTTP 201`
|
- `Given a valid create-job request, when the request is submitted, then the API returns HTTP 201`
|
||||||
- `Given a successful job creation, when the response is returned, then the response contains job_id`
|
- `Given a successful job creation, when the response is returned, then it contains job_id`
|
||||||
- `Given a successful job creation, when the response is returned, then job_id is a valid UUID v7`
|
- `Given a successful job creation, when job_id is returned, then it must be a valid UUID v7`
|
||||||
- `Given a successful job creation, when the job is queried, then it is queryable within 1 second`
|
- `Given a job is created successfully, when it is queried within 1 second, then the job can be retrieved`
|
||||||
- `Given the same payload and the same idempotency key, when the request is repeated, then the system does not create a duplicate record`
|
- `Given the same request payload is retried with the same idempotency key, when the request is repeated, then no duplicate job is created`
|
||||||
|
|
||||||
## Context-Driven Coverage Rules
|
## Context-Driven Coverage Rules
|
||||||
The PM must decide which requirement categories are necessary for the feature. Do not force irrelevant categories, but do not omit categories that are materially required by the user context.
|
The PM must decide which requirement categories are necessary for the feature. Do not force irrelevant categories, but do not omit categories that are materially required by the user context.
|
||||||
|
|
@ -210,10 +212,6 @@ Before handing off a PRD, verify it contains:
|
||||||
- Risks
|
- Risks
|
||||||
|
|
||||||
Strongly recommended when relevant:
|
Strongly recommended when relevant:
|
||||||
- Research Inputs
|
|
||||||
- Assumptions
|
|
||||||
- Dependencies
|
|
||||||
- Open Questions
|
|
||||||
- Error handling
|
- Error handling
|
||||||
- Idempotency
|
- Idempotency
|
||||||
- Observability
|
- Observability
|
||||||
|
|
|
||||||
|
|
@ -20,7 +20,7 @@
|
||||||
- 次要輸出:GitHub Issue(僅限使用者明確要求時)
|
- 次要輸出:GitHub Issue(僅限使用者明確要求時)
|
||||||
|
|
||||||
## PRD 結構
|
## PRD 結構
|
||||||
- `## Research Inputs`(有需要才填)
|
- `## Research Inputs`
|
||||||
- `## Problem`
|
- `## Problem`
|
||||||
- `## Goals`
|
- `## Goals`
|
||||||
- `## Non Goals`
|
- `## Non Goals`
|
||||||
|
|
@ -36,6 +36,8 @@
|
||||||
- `## Dependencies`
|
- `## Dependencies`
|
||||||
- `## Open Questions`
|
- `## Open Questions`
|
||||||
|
|
||||||
|
若某段不適用,請填 `N/A` 並附一句原因。
|
||||||
|
|
||||||
## 規則
|
## 規則
|
||||||
- 驗收標準必須使用 `Given / When / Then`
|
- 驗收標準必須使用 `Given / When / Then`
|
||||||
- 每條驗收標準必須可觀察、可測試、可拒收、可衡量、不可歧義
|
- 每條驗收標準必須可觀察、可測試、可拒收、可衡量、不可歧義
|
||||||
|
|
|
||||||
|
|
@ -34,7 +34,7 @@ Before finalizing the PRD, verify that every acceptance criterion maps to at lea
|
||||||
|
|
||||||
## Research Inputs
|
## Research Inputs
|
||||||
|
|
||||||
Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. Omit this section if no research was needed.
|
Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. If no research was needed, write `N/A` with a brief reason.
|
||||||
|
|
||||||
## Problem
|
## Problem
|
||||||
|
|
||||||
|
|
@ -126,15 +126,15 @@ List product, operational, compliance, or adoption risks that could affect deliv
|
||||||
|
|
||||||
## Assumptions
|
## Assumptions
|
||||||
|
|
||||||
List assumptions this PRD depends on being true.
|
List assumptions this PRD depends on being true. If there are no material assumptions, write `N/A` with a brief reason.
|
||||||
|
|
||||||
## Dependencies
|
## Dependencies
|
||||||
|
|
||||||
List dependencies on teams, systems, policies, vendors, or external events.
|
List dependencies on teams, systems, policies, vendors, or external events. If there are no material dependencies, write `N/A` with a brief reason.
|
||||||
|
|
||||||
## Open Questions
|
## Open Questions
|
||||||
|
|
||||||
List unresolved product questions that must be answered before implementation or release.
|
List unresolved product questions that must be answered before implementation or release. If there are no open questions, write `N/A` with a brief reason.
|
||||||
|
|
||||||
</prd-template>
|
</prd-template>
|
||||||
|
|
||||||
|
|
@ -157,7 +157,7 @@ Do not:
|
||||||
- Break work into engineering tasks
|
- Break work into engineering tasks
|
||||||
- Write pseudocode or code
|
- Write pseudocode or code
|
||||||
|
|
||||||
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.
|
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
|
||||||
|
|
||||||
## Minimum Completeness Gate
|
## Minimum Completeness Gate
|
||||||
|
|
||||||
|
|
@ -175,10 +175,6 @@ The PRD must contain:
|
||||||
- Risks
|
- Risks
|
||||||
|
|
||||||
Add these when relevant:
|
Add these when relevant:
|
||||||
- Research Inputs
|
|
||||||
- Assumptions
|
|
||||||
- Dependencies
|
|
||||||
- Open Questions
|
|
||||||
- Error handling
|
- Error handling
|
||||||
- Idempotency
|
- Idempotency
|
||||||
- Observability
|
- Observability
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue