需求管理规范

需求准入、优先级排序、需求评审、变更管理

需求准入条件

规则：进入研发排期的需求必须满足”可理解、可验证、可拆分、可度量”四项基本要求，缺少任何一项的需求不得纳入迭代。

[Requirement] 需求必须包含明确的用户角色、使用场景、期望结果三要素；仅含功能描述、缺乏用户与场景的需求不允许进入需求池。

[Requirement] 需求必须可量化验收，至少包含一条可执行的验收标准（GIVEN/WHEN/THEN 格式，见验收标准编写规范）。

[Standard] 需求需标注来源（业务方/数据反馈/技术债务/合规要求）与目标用户群，避免”拍脑袋”需求。

[Suggestion] 新需求在评审前需附上竞品分析或用户调研摘要，降低设计与开发返工概率。

准入检查清单：

检查项	要求	不满足时
用户角色	明确”谁”在用	退回补充
使用场景	明确”在什么情况下用”	退回补充
期望结果	明确”做完后什么算好”	退回补充
验收标准	≥1 条 GIVEN/WHEN/THEN	退回补充
依赖说明	标注外部依赖（接口/数据/权限）	评审时确认

反模式：

❌ “优化一下用户体验”——没有角色、没有场景、没有度量。
❌ “把这个功能做得更智能”——“智能”无定义，无法验收。
❌ 需求只有标题没有正文，靠口头沟通传达细节。

优先级排序方法

规则：统一使用 RICE 或 MoSCoW 方法量化优先级，禁止使用”高/中/低”这种模糊标签直接排期。

[Requirement] 所有进入需求池的需求必须打分，打分结果须记录在需求文档中。

[Standard] 默认采用 RICE 评分：Reach × Impact × Confidence ÷ Effort，得分越高优先级越高。

[Standard] 紧急需求（线上故障、合规红线）可使用 MoSCoW 的 Must 级别直接插队，但需经负责人签字确认。

[Default] 团队未指定评分方法时，默认使用 RICE。

RICE 评分示例：

需求	Reach(月活)	Impact(1-3)	Confidence(%)	Effort(人日)	RICE 得分
支付页改版	50000	2	80%	20	50000×2×0.8÷20 = 4000
新增消息推送	20000	1	90%	10	20000×1×0.9÷10 = 1800
后台权限优化	50	3	100%	5	50×3×1÷5 = 30

Impact 评分标准：3=巨大提升（如转化翻倍），2=明显提升，1=小幅改善，0.5=微弱影响，0.25=极小影响。

Confidence 评分标准：100%=有数据支撑，80%=有用户调研，50%=纯猜测。

[Caution] Effort 是粗估（人日/人时），不要求精确，但同一迭代内所有需求须由同一人估算以保证尺度一致。

反模式：

❌ 领导说”这个很重要”就排第一，没有量化依据。
❌ 把”必须做”和”很重要”混为一谈，忽略工作量与收益比。
❌ 一次性给 20 个需求都打满分，等于没打分。

需求评审流程

规则：需求评审是需求从”概念”到”可开发”的必经关卡，评审通过后方可拆分任务。

[Requirement] 评审会议需包含产品、研发、测试三方角色；任意一方缺席，评审结论无效。

[Requirement] 评审材料须至少提前 1 个工作日发出，参会人需会前阅读，会议聚焦讨论而非宣读文档。

[Standard] 评审输出必须包含：需求结论（通过/有条件通过/打回）、遗留问题清单、负责人与截止时间。

[Standard] “有条件通过”的需求，遗留问题必须在开发启动前解决，否则自动转为打回。

[Suggestion] 评审会议时长控制在 60 分钟内；超过则说明需求文档质量不足，应先补文档再评审。

评审流程：

需求文档初稿 ──→ 会前分发(T-1) ──→ 评审会议 ──┬─ 通过 ──→ 进入任务拆分
                                              ├─ 有条件通过 ──→ 解决遗留问题 ──→ 进入任务拆分
                                              └─ 打回 ──→ 产品修改后重新评审

评审要点：

完整性：三要素（角色/场景/结果）是否齐全，验收标准是否可测试。
可行性：技术上是否可实现，是否存在不可控外部依赖。
一致性：是否与现有业务规则、数据模型冲突。
边界：异常路径、空状态、并发场景是否覆盖。
范围：是否存在需求蔓延，是否需要拆分为多个迭代。

反模式：

❌ 评审会变成需求讲解会，研发现场才第一次看到需求。
❌ 评审无结论、无记录，会后”凭印象”开发。
❌ 测试缺席评审，上线前才发现验收标准不清晰。

需求变更管理

规则：已进入开发的需求发生变更，必须走变更流程，禁止口头改需求直接编码。

[Requirement] 需求变更必须提交书面变更申请，说明变更内容、原因、对工期/成本/质量的影响。

[Requirement] 开发进度超过 50% 的需求发生变更，须重新评估工作量并更新排期，不得默认”顺手改一下”。

[Standard] 变更影响评估表必须包含：原工作量、变更后工作量、增加工作量、是否影响交付日期。

[Caution] 同一个需求在一个迭代内变更超过 2 次，须升级到项目负责人决策是否移出当前迭代。

变更影响评估表示例：

字段	内容
需求名称	支付页改版
变更内容	新增优惠券叠加规则
变更原因	运营活动要求
原工作量	20 人日
变更后工作量	28 人日
增加工作量	+8 人日
是否影响交付	是，延期 3 天
申请人	产品-A
审批人	研发负责人-B

变更等级与处理：

变更等级	定义	处理方式
轻微	文案/样式微调，不影响逻辑与工期	研发确认即可
一般	逻辑调整，增加工作量 ≤20%	研发+产品确认
重大	增加工作量 >20% 或影响交付日期	项目负责人审批
紧急	线上问题/合规要求，必须立即改	走紧急通道，事后补流程

反模式：

❌ “这个小需求，加个字段的事，不用走流程了。“——结果牵出 5 个接口改动。
❌ 需求变更只通知研发，不更新文档，导致测试验收标准失效。
❌ 迭代内频繁变更，最终交付物与最初需求面目全非。

交付物清单

规则：每个需求从提出到交付，必须产出以下文档，缺一不可。

[Requirement] 需求交付物须随需求流转，最终归档至项目知识库，不得散落在聊天记录中。

[Standard] 所有文档采用 Markdown 格式，统一存放于 docs/requirements/ 目录。

交付物清单：

交付物	产出阶段	负责人	必备内容
需求文档（PRD）	需求提出	产品	角色、场景、期望结果、流程图
验收标准	需求评审前	产品	GIVEN/WHEN/THEN 用例集
需求评审记录	评审后	产品	结论、遗留问题、负责人/截止时间
变更记录（如有）	变更发生时	产品	变更内容、影响评估、审批
任务拆分清单	评审通过后	研发	子任务、负责人、估算、依赖

目录结构示例：

docs/requirements/
└── 2024Q4/
    └── 支付页改版/
        ├── PRD.md
        ├── acceptance-criteria.md
        ├── review-notes.md
        ├── change-log.md          # 无变更可不创建
        └── task-breakdown.md

[Suggestion] 使用需求 ID（如 REQ-2024Q4-001）作为文件夹命名，便于检索与追溯。

反模式：

❌ 需求文档写在飞书文档里，链接过期后无人能找到。
❌ 变更记录只在群里说一句，没有留痕。
❌ 验收标准散落在 PRD 各处，测试要逐字找。