第1章 PRD变更触发场景识别
1.1 适用场景
- 硬件产品开发过程中，已发布基线PRD因客户新需求、生产缺陷或成本目标调整而需要修订。
- 变更请求（ECR）进入评审前，需要对变更来源进行结构化分类与优先级初判。
- 多项目并行时，快速判断哪些变更必须立即响应、哪些可以排入下一迭代。
1.2 前置条件
- 已存在经过审批的基线PRD文档（版本号、变更记录完整）。
- 变更请求单（ECR/CR）已创建，包含申请人、变更描述、预期影响范围。
- 成立变更控制委员会（CCB）或授权评估小组，成员包括产品经理、系统工程师、项目经理、硬件负责人。
- 已定义“触发条件判断矩阵”模板及优先级等级（P1~P4）。
1.3 操作步骤
- 步骤1：接收变更请求 – 确认ECR信息完整，标记来源字段（需求/缺陷/成本）。
- 步骤2：归类变更来源 – 对照分类表确定来源类型。
- 步骤3：应用触发条件判断矩阵 – 根据来源类型、影响范围、紧急度查表得到触发级别。
- 步骤4：判定变更优先级 – 综合触发级别与业务影响，输出P1~P4等级。
- 步骤5：记录并挂载标签 – 在变更管理系统中更新来源分类与优先级字段。
1.4 输入输出物
| 输入 | 输出 |
|---|---|
| 变更请求单（ECR） | 变更来源分类结果（需求/缺陷/成本） |
| 基线PRD文档 | 触发条件判断结果（级别A/B/C） |
| 项目排期与资源计划 | 变更优先级标签（P1~P4） |
1.5 责任边界
- 产品经理：提供需求、缺陷、成本背景；确认变更来源分类的合理性。
- 系统工程师：执行触发条件判断矩阵的工程维度分析（技术可行性、接口影响）。
- 项目经理：组织优先级评审会议，协调资源排期。
- 硬件负责人：给出硬件可实现性评估，参与矩阵判定。
1.6 记录材料
- 变更来源登记表（字段：ECR编号、来源类型、来源描述、登记人、日期）。
- 触发条件判断记录（矩阵打分卡或审批意见）。
- 优先级决策日志（包含争议点、最终裁定人）。
1.7 异常处理
常见异常及应对：
• 来源模糊（既像需求又像缺陷）→ 组织专题分析会，以“原始触发事件”为准。
• 多来源冲突（同一变更同时涉及需求与成本）→ 取影响最大的来源作为主要分类，并备注次要来源。
• 优先级争议（PM与工程师判定不一致）→ 升级至CCB投票，记录否决意见。
• 矩阵条件不匹配（特殊场景未覆盖）→ 暂定常规级别，并在下次矩阵迭代时补充条件。
• 来源模糊（既像需求又像缺陷）→ 组织专题分析会，以“原始触发事件”为准。
• 多来源冲突（同一变更同时涉及需求与成本）→ 取影响最大的来源作为主要分类，并备注次要来源。
• 优先级争议（PM与工程师判定不一致）→ 升级至CCB投票，记录否决意见。
• 矩阵条件不匹配（特殊场景未覆盖）→ 暂定常规级别，并在下次矩阵迭代时补充条件。
1.8 验收标准
- 每份ECR在1个工作日内完成来源分类与优先级判定。
- 来源分类准确率≥98%（以季度审计为准）。
- 触发条件矩阵覆盖所有已发生的变更场景（覆盖率100%）。
- 优先级标签与后续变更执行动作（紧急/常规/暂缓）一致。
1.9 触发条件判断矩阵
| 变更来源 | 紧急度 | 影响范围 | 触发级别 | 典型优先级 |
|---|---|---|---|---|
| 需求变更 | 高（客户强制要求） | 硬件接口/核心功能 | A | P1 |
| 需求变更 | 中（可协商） | 非核心参数 | B | P2 |
| 缺陷修复 | 高（功能不可用/安全风险） | 整机/关键子系统 | A | P1 |
| 缺陷修复 | 低（偶发/可绕行） | 单模块 | C | P3 |
| 成本优化 | 高（BOM降本目标强制） | 核心物料/工艺 | A | P2 |
| 成本优化 | 低（建议性） | 辅助物料 | C | P4 |
实战提示： 优先级P1需在24小时内启动变更评估；P2可排入当前迭代；P3进入下一迭代；P4纳入远期规划。首次应用矩阵时，请对齐产品线实际紧急度定义。