第2章 需求变更管理的前置条件：团队共识、变更定义、工具准备

适用场景

• 团队首次建立需求变更管理流程时，需要一次性完成前置条件搭建。
• MVP迭代中发生较大范围的变更请求，现有流程被质疑或失效时，需回头检查前置条件。
• 新人加入或团队重组后，需重新对齐变更共识与工具使用规范。
• 评估团队变更管理成熟度时，前置条件是评分基线。

前置条件

本章本身是后续所有变更处理章节的前置模块，因此本章的“前置条件”特指开始执行本阶段任务前必须满足的基线状态：

• 已有MVP阶段的需求基线文档（至少是确认过的用户故事列表）。
• 产品经理与核心开发已明确变更流程的决策权归属。
• 协同平台（如 Jira / Notion / Trello）已开通且团队成员均可登录。

操作步骤

1. 组织团队共识工作坊
   • 由产品经理主持，邀请开发、测试、UI/UX、业务方代表参加。
   • 明确变更管理的目标：不是阻止变化，而是减少无效变动、控制范围蔓延。
   • 投票确定变更分类（紧急/常规/微调）及对应处理时限。
   • 形成书面共识纪要，全体签字或在线确认。
2. 制定变更定义模板
   • 定义“需求变更”的边界：任何对已进入开发或已验收的需求的修改、替换、删除、新增。
   • 模板包含字段：变更编号、提出人、关联需求ID、变更描述、影响范围（功能/数据/UI/风险）、优先级、期望完成时间。
   • 模板需附带填写示例和边界判断规则（例如：文案调整是否算变更？50%以上重写才算等）。
3. 配置协同工具
   • 创建变更申请专用空间或看板（如 Jira 变更请求项目）。
   • 设置触发器：当变更单状态变为“待评审”时，自动通知评审组。
   • 配置权限：仅产品经理和技术负责人可修改“影响范围”和“状态”。
   • 测试一条模拟变更，验证通知、流转、归档正常。

输入输出物

责任边界

• 产品经理：主持共识会、定义变更边界、维护模板并定期升级。
• 技术负责人：评估工具可行性、分配权限、保证工具可用性。
• 全体成员：遵守已确认的变更定义和流程，不私下修改基线。
• 业务方代表：在共识会上确认变更处理时限和优先级判断原则。

记录材料

• 会议签到/录屏（文件形式）
• 变更定义说明书（PDF + 在线协作链接）
• 工具配置截图（权限列表、看板样式）
• 测试变更单的历史记录（演示用）

异常处理

验收标准

1. 团队所有成员（含业务方）均能说出“什么是变更”“变更分几类”“第一步怎么做”。
2. 变更模板在工具中可正常发起，并自动通知评审组。
3. 工具中至少存在一条已关闭的测试变更记录，流转路径完整。
4. 共识会议纪要、变更定义说明书、工具配置文档均已归档至项目知识库。