第2章 优先级标注前置条件
在正式对PRD中的需求进行优先级标注之前，必须完成四项关键前置条件的核查。若其中任何一项不达标，标注结果都将失去可信度，导致研发资源浪费或业务目标偏离。本章将逐一拆解每项前置条件的判定标准、检查方法及责任分工。
适用场景
- 需求清单进入优先级评审环节之前，需完成前置条件自查。
- 跨团队联合评审前，由产品经理发起前置条件复核。
- 迭代规划会启动时，用于筛选进入优先级标注池的需求。
前置条件（本章所讲内容本身即为前置条件）
四项前置条件必须同时满足，缺一不可：
- 需求已明确描述 — 功能描述、验收标准、依赖关系均被完整记录，无歧义。
- 用户场景已定义 — 至少覆盖典型用户画像、使用路径、预期行为及触发条件。
- 业务目标已对齐 — 需求所支撑的OKR或KPI已通过相关方共识，优先级不与战略冲突。
- 技术可行性初评完成 — 研发侧已给出初步实现方案、预估工时及潜在风险。
操作步骤
| 步骤 | 动作 | 工具/模板 |
|---|---|---|
| 1 | 逐项核对四项前置条件检查表 | 下方《前置条件检查清单》 |
| 2 | 将不满足条件的项标记为“待补齐”，并指派责任人 | PRD备注栏/协作表格 |
| 3 | 补齐后再次复核，直至四项全部通过 | 评审会议纪要 |
| 4 | 签发前置条件通过确认，进入优先级标注阶段 | 《前置条件验收报告》 |
💡 核心原则：前置条件的检查不是一次性的，当需求发生变更时，必须重新触发检查流程，确保标注基线的实时有效性。
输入输出物
| 类型 | 名称 | 示例/格式 |
|---|---|---|
| 输入 | 原始需求条目 | PRD中的用户故事、功能描述片段 |
| 输出 | 前置条件检查清单（已填写） | 带通过/待补齐标记的表格 |
| 输出 | 前置条件通过确认书 | 含相关方签字的简版报告 |
责任边界
- 产品经理： 牵头组织自查，确保需求描述与用户场景完整，并与业务目标对齐。
- 研发负责人： 提供技术可行性初评结论，签字确认。
- 业务方代表： 确认业务目标对齐，并反馈优先级价值观。
记录材料
前置条件检查清单（示例）
需求ID: REQ-1024
需求标题: 用户订单导出功能
------------------------------
条件 状态 责任人 备注
需求明确描述 ✅ PM 含验收标准
用户场景已定义 ✅ PM 含3个场景
业务目标已对齐 ❌ 业务方 待确认季度OKR
技术可行性初评完成 ✅ 研发 预估工时16h
------------------------------
结论：1项待补齐，不可进入优先级标注。
异常处理
| 异常情形 | 处理方式 | 升级路径 |
|---|---|---|
| 需求描述存在二义性 | 产品经理重写描述，并组织二次评审 | 通知需求评审委员会 |
| 用户场景缺失 | 补充用户访谈或数据，完善场景定义 | 用户研究团队介入 |
| 业务目标未对齐 | 与业务方重新对齐OKR，必要时调整需求优先级 | 产品总监协调 |
| 技术可行性初评不通过 | 暂缓标注，由研发提出备选方案或成本评估 | 架构评审会议 |
⚠️ 注意：任何一项前置条件被跳过或伪造通过，都会直接导致优先级标注结果偏离实际业务价值，甚至引发后续开发返工。严禁在未完成技术可行性初评的情况下擅自标注P0。
验收标准
- 每项前置条件均已标记明确状态（通过/待补齐）。
- 所有“待补齐”项均有指定责任人和预计完成日期。
- 技术可行性初评必须包含研发侧签名（或会议纪要截图）。
- 完整的前置条件检查清单已归档至PRD附件或协作文档。
📌 实战建议：建议团队将前置条件检查集成到需求管理工具（如Jira、Notion）的字段模板中，设定“前置条件通过”为必填选项，从流程上杜绝遗漏。