3. 变更发起流程

变更发起是PRD版本管理的入口动作,决定后续评审、审批和版本锁定的方向。本章聚焦变更申请人如何规范提交变更、如何填写结构化的变更描述、如何评估变更对已有需求、接口、数据模型和交付计划的影响范围。通过标准化发起流程,降低遗漏检查项导致的返工风险。

核心目标:确保每一份变更在进入评审前已具备可追溯的申请人身份、无歧义的变更描述和明确的影响边界。

适用场景

  • PRD已进入版本基线管理,新增、修改或删除任一需求项时。
  • 因市场/用户反馈、技术方案调整或资源变更需要修改已锁定版本的需求时。
  • 修复已发布版本中的缺陷需同步更新PRD内容时。
  • 跨版本回溯、需求翻译或合规性调整等非计划性变更时。

前置条件

  • 当前PRD已处于有效版本管理范围内,版本号明确。
  • 变更申请人已开通对应PRD文档库或需求管理系统的提交权限。
  • 存在至少一个经过评审的基础版PRD作为变更基准。
  • 产品经理已定义变更申请的必填字段模板并维护在知识库中。

操作步骤

  1. 确定变更申请人
    • 变更申请人必须是该需求的直接负责人,不得代提或背对背提交。
    • 角色范围:产品经理、需求分析师、技术经理、业务方代表(经产品授权后)。
    • 系统或变更单上必须记录申请人实名、工号/邮箱、所属团队。
  2. 填写变更描述
    • 变更描述必须包含:变更动机 + 变更内容 + 变更类型(新增/修改/删除) + 关联需求ID。
    • 不允许出现模糊描述如“优化体验”、“修复Bug”;应具体到功能点、逻辑规则、数据字段。
    • 示例模板见下方代码块。
  3. 评估影响范围
    • 从以下维度逐一排查:
      1. 需求依赖:被关联的前置、后置、并行需求清单。
      2. 接口与数据:新增/修改的API、字段、枚举值、数据流变更。
      3. UI/UX:页面布局、交互流程、文案变动。
      4. 交付计划:是否影响已排期的开发、测试、验收节点。
      5. 合规与安全:涉及隐私数据、权限模型、审计日志的部分。
    • 评估结论必须给出影响等级(高/中/低)以及对应的应对建议。
  4. 提交变更申请
    • 将上述内容汇总至变更申请表,并附上变更后PRD的diff或改动标注稿。
    • 提交至版本管理委员会或产品经理指定的评审入口(如Jira、Confluence、TAPD等)。

常见陷阱:变更描述中遗漏受影响的外部系统名称,导致下游团队在评审时才发现集成问题。必须强制填写“关联系统 / 接口清单”字段。

输入输出物

方向物名称格式生产者
输入基础版PRD(基线文档).docx / .md / 在线文档产品经理
输入变更需求原始描述(用户反馈、会议纪要等)文本、邮件、录音需求方
输出变更申请表(含申请人、描述、影响范围)结构化表单 / 系统工单变更申请人
输出影响范围评估报告.xlsx / 在线表格变更申请人 + 相关技术代表
输出PRD Diff标注版文档 / Git diff产品经理

责任边界

  • 变更申请人:对变更内容的真实性、完整性负责;完成影响范围初步评估。
  • 产品经理 / 版本管理员:审核变更描述规范性;确认变更影响等级;分配评审资源。
  • 开发 / 测试 / 运维代表:在影响范围评估中提供技术风险反馈。
  • 业务方(可选):确认变更不会引入合规或商业风险。

记录材料

  • 变更申请表(含审批记录)
  • 影响范围评估工作底稿(包含排查清单、风险标注、应对措施)
  • 变更描述与基线版本之间的差异对比图
  • 申请人认证信息快照(系统日志记录)

异常处理

异常场景处理方式责任方
变更描述缺少关键模块退回申请人补充,直至满足模板必填项版本管理员
影响范围评估遗漏系统依赖启动补充评估流程;延迟变更触发技术代表
紧急变更(生产缺陷修复)跳步:申请人先描述变更,评估后置至评审环节并行完成产品经理(特批)
变更申请人身份不符拒绝申请;要求权限申诉或转交负责人版本管理员

验收标准

  • 变更申请表完整:申请人、描述、影响范围等级三个主要字段无空值。
  • 影响范围评估至少覆盖:需求依赖、接口数据、UI/UX、交付计划、合规安全五个维度。
  • 变更描述中无模糊词汇,每个变更点均标识了关联的需求ID或模块路径。
  • 评估报告已获相关技术代表确认签字或系统审批。
  • PRD Diff已生成并被附加至变更工单中。

实践建议:在需求管理系统(如Jira)中创建变更发起检查清单插件,每次提交前自动校验必填项,并触发影响范围提醒。

变更发起流程总图

变更发起流程图 1. 变更申请人 2. 填写变更描述 3. 影响范围评估 4. 审核变更申请 5. 提交评审 退回 → 申请人修改 不通过 退回修改 说明:审核节点可同时通过/不通过;退回修改后重新从申请人节点开始。

变更描述模板(参考)

------------------------------------------------------
变更标题   :订单列表页“已取消”状态筛选条件调整
变更类型   :修改
变更动机   :用户反馈无法区分“用户主动取消”和“超时取消”
变更内容   :
  1. 在订单列表筛选栏新增“取消原因类型”下拉框(值:用户取消/超时取消/全部)
  2. 查询接口 /api/orders 增加参数 cancel_type(string)
  3. 列表展示中,取消状态的订单行背景色调整为浅灰色
关联需求ID :REQ-2025-ORD-0337
影响范围   :
  - 接口:订单查询API(v2.4)需增加字段映射
  - 前端:订单列表页筛选组件更新
  - 数据:订单状态枚举需扩展子类型(建议不改数据库,仅逻辑区分)
  - 测试:需覆盖全部取消原因组合的筛选+排序
------------------------------------------------------