第3章：优先级定义与等级划分：P0关键路径、P1重要功能、P2次要增强、P3远期储备、P4待定
适用场景
本规范适用于以下场景：
- 新项目启动时，对初始需求列表进行优先级排序；
- 版本规划阶段，确定迭代范围与交付承诺；
- 需求评审会议中，统一团队成员对优先级的理解；
- 跨部门沟通时，对齐业务与技术对“关键”、“重要”、“次要”的判断标准。
前置条件
- 已完成需求收集与初步功能列表编制；
- 产品路线图或版本规划已基本明确；
- 核心干系人（产品经理、技术负责人、业务代表）已就位；
- 团队已理解“关键路径”与“重要功能”的业务与技术含义。
操作步骤
- 依据业务目标与用户价值，将需求按“必须-应该-可要-保留-待定”分层；
- 对每一层赋予标准等级（P0~P4），并记录对应定义；
- 使用优先级矩阵对需求进行逐条匹配，避免主观偏移；
- 组织评审会议，确认等级标注结果；
- 将标注结果写入PRD正文“优先级”字段，并更新需求管理工具。
| 等级 | 定义 | 典型示例 | 处理要求 |
|---|---|---|---|
| P0 | 关键路径：影响核心业务流程，无则版本不可发布 | 登录支付、订单提交、业务规则引擎 | 必须在本版本实现，技术资源优先保障 |
| P1 | 重要功能：显著提升用户效率或业务价值，但存在临时替代方案 | 数据导出、高级筛选、通知推送 | 在本版本实现，可协商延期至下一补丁版本 |
| P2 | 次要增强：改善体验或非关键场景，可有可无 | 界面样式优化、次要字段显示、帮助文档链接 | 争取实现，若资源不足则延至下个迭代 |
| P3 | 远期储备：有潜在价值但当前无明确需求或技术依赖未成熟 | 第三方集成计划、数据挖掘报表、跨端同步 | 列入Roadmap远期队列，不做实现承诺 |
| P4 | 待定：需求模糊、价值未验证、依赖项不确定 | 用户调研阶段待确认功能、实验性新概念 | 暂不排期，需进一步分析后重新定级 |
输入输出物
输入：
需求列表（Excel/PRD草稿/用户故事卡片）
干系人优先级评估矩阵（按业务价值、紧急度、技术风险）
输出：
标注有P0~P4等级的PRD需求表（各字段对齐规范）
评审会议纪要（含等级争议记录）
责任边界
- 产品经理：主导需求等级初评，编写PRD标注；
- 技术负责人：从实现可行性、技术债务角度审核等级合理性；
- 业务方/产品总监：确认P0/P1关键路径是否符合业务目标；
- 项目管理：监控等级标注与版本燃尽图的匹配度。
记录材料
- 《PRD优先级等级对照表》（含等级定义与示例）；
- 《需求优先级评审记录》（含每项需求的最终等级与争议备注）；
- 《版本范围承诺书》（签字确认P0/P1范围）。
异常处理
等级争议：当业务方与技术方对P0/P1认定不一致时，由产品总监与架构师联合裁定，必要时进行A/B测试或原型验证。
需求遗漏：新增需求需重新走优先级评估流程，不得跳过P0～P4标注直接进入开发。
资源冲突：若多个P0需求同时出现，需分解需求粒度，或引入风险缓冲（如提前预留储备资源）。
验收标准
- 每个需求条目在PRD中均有明确优先级字段（P0～P4）；
- 等级划分与标准定义完全一致，无自定义等级出现；
- 评审会议中等级标注无重大争议（或争议已闭环）；
- 干系人签字或电子确认版本范围承诺书。