pm-change

name	pm-change
description	Use when: 项目进行中出现需求变更、需要评估变更影响范围和风险、记录变更历史 Do NOT use when: 变更极小无需正式评估、变更已有明确决策无需分析
allowed-tools	["Agent","Read","Write","AskUserQuestion","Bash"]

Preamble

bash "$(dirname "${BASH_SOURCE[0]}")/../../check-update.sh" 2>/dev/null || true
mkdir -p docs/04-风控管理

echo "📝 需求变更管理工具已启动"

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 1: 记录变更申请

使用 AskUserQuestion:

📋 变更来源

变更申请的来源：

A) 用户反馈（用户需求变化） B) 竞品动态（市场变化） C) 业务调整（战略调整） D) 技术限制（技术实现问题） E) 法规要求（合规需求） F) 其他原因（请手动输入）

继续询问：

🎯 变更类型

本次变更的类型：

A) 新增需求（增加新功能） B) 修改需求（调整现有功能） C) 删除需求（取消原定功能） D) 优先级调整（改变开发顺序）

步骤 2: 影响评估

使用 AskUserQuestion:

📊 影响范围评估

变更影响哪些方面？（可多选）

A) 功能范围（新增/修改功能模块） B) 开发进度（工期延长） C) 技术架构（架构调整） D) 测试范围（回归测试） E) 用户体验（交互变化） F) 数据迁移（数据结构变化） G) 第三方集成（接口变化） H) 成本预算（资源增加）

继续询问：

⏱️ 影响程度评估

变更的影响程度：

A) 轻微影响（工期 < 2天，影响 < 1个模块） B) 中等影响（工期 2-5天，影响 1-3个模块） C) 重大影响（工期 > 5天，影响 > 3个模块） D) 致命影响（影响核心功能或架构）

步骤 3: 变更决策

使用 AskUserQuestion:

✅ 变更审批级别

根据影响程度，需要谁审批？

A) 项目经理审批（轻微影响） B) 产品负责人 + 技术负责人审批（中等影响） C) 变更控制委员会（CCB）审批（重大影响） D) 指导委员会审批（致命影响）

继续询问：

🔄 变更决策结果

变更审批结果：

A) 批准变更（同意执行） B) 有条件批准（需满足特定条件） C) 延期评估（稍后再议） D) 拒绝变更（不执行）

步骤 4: 制定变更计划

使用 AskUserQuestion:

📅 变更执行时机

何时执行变更？

A) 立即执行（紧急变更） B) 当前迭代（本周内） C) 下个迭代（下周） D) 后续版本（排入待办）

步骤 5: 记录变更

使用 Write 工具更新 docs/04-风控管理/需求变更记录.md。

---

Subagent 并行加速（v2.0.0 新增）

利用 Agent 工具并行执行独立子任务，大幅缩短总执行时间。

可并行子任务

当步骤1-4的用户信息收集完成后，以下两个任务可以并行执行：

子任务	说明
影响深度分析	基于变更类型和影响范围，自动生成影响评估矩阵
变更计划草拟	根据审批结果和执行时机，自动生成变更执行计划文档

触发方式

在步骤5生成文档前，使用 Agent 工具激活子任务并行执行。

V1 vs V2 对比

维度	V1.1.0（串行）	V2.0.0（Subagent并行）	节省
影响分析	用户逐一回答影响范围	Agent并行分析多维度影响	约3轮交互
变更计划	依次询问执行细节	Agent自动生成执行计划	约2轮交互
总交互轮次	约10-12轮	约5-7轮	减少45%+
耗时估算	10-15分钟	5-8分钟	节省约6分钟

---

输出文件

需求变更记录 → docs/04-风控管理/需求变更记录.md

---

输出文档模板

# 需求变更记录

## 一、变更概况

- **变更申请总数**: [累计数量]
- **已批准**: [数量]
- **已拒绝**: [数量]
- **待评估**: [数量]
- **生成时间**: [当前时间]

---

## 二、变更记录表

| 变更ID | 申请日期 | 变更内容 | 来源 | 类型 | 影响程度 | 审批结果 | 执行状态 |
|--------|---------|---------|------|------|---------|---------|---------|
| CH-001 | 2026-03-25 | 新增导出功能 | 用户反馈 | 新增 | 中等 | 已批准 | 已完成 |
| CH-002 | 2026-03-26 | 修改登录流程 | 竞品动态 | 修改 | 重大 | 待评估 | 待执行 |
| CH-003 | 2026-03-27 | 删除分享功能 | 业务调整 | 删除 | 轻微 | 已批准 | 进行中 |

---

## 三、变更详情

### CH-001: 新增导出功能

#### 3.1 变更申请

**申请日期**: 2026-03-25
**申请人**: 产品负责人
**变更来源**: 用户反馈
**变更类型**: 新增需求

**变更描述**:
用户反馈需要导出数据报表功能，当前系统仅支持在线查看，无法导出Excel或PDF格式。

**变更原因**:
- 用户场景：管理层需要离线查看报表
- 业务价值：提升用户满意度，降低流失率
- 紧急程度：高（已有多位用户投诉）

#### 3.2 影响评估

**影响范围**:
- ✅ 功能范围：新增导出模块
- ✅ 开发进度：预计增加3天工期
- ✅ 测试范围：需测试多种格式导出
- ✅ 数据迁移：无需迁移

**影响程度**: 中等影响
- 工期延长：3天
- 影响模块：数据报表模块
- 资源需求：前端1人，后端1人

**风险评估**:
- 技术风险：低（成熟技术方案）
- 进度风险：中（需调整迭代计划）
- 质量风险：低（功能相对独立）

#### 3.3 变更决策

**审批级别**: 产品负责人 + 技术负责人审批

**审批结果**: ✅ 已批准

**批准条件**:
- 不影响当前迭代核心目标
- 导出功能支持Excel和PDF两种格式
- 文件大小限制在10MB以内

: 产品负责人、技术负责人
: 2026-03-25



: 下个迭代（2026-03-28 开始）

:
 设计导出接口（后端，0.5天）
 实现导出逻辑（后端，1天）
 开发导出UI（前端，0.5天）
 测试验证（测试，1天）

:
 后端开发：张三
 前端开发：李四
 测试：王五

:
 支持导出Excel和PDF格式
 文件大小限制在10MB以内
 导出时间 < 30秒



: ✅ 已完成

: 2026-04-01

:
 实际工期：3天（符合预期）
 测试通过：无严重Bug
 用户反馈：满意

:
 提前考虑文件大小限制，避免服务器压力
 导出功能需要权限控制，防止数据泄露

---





: 2026-03-26
: 产品负责人
: 竞品动态
: 修改需求

:
竞品已支持手机号一键登录，用户体验更优。当前登录流程需输入密码，步骤繁琐，用户流失率高。

:
 竞品分析：竞品新增一键登录功能
 用户数据：登录页流失率高达30%
 业务价值：降低流失率，提升注册转化率



:
 ✅ 功能范围：修改登录模块
 ✅ 开发进度：预计增加7天工期
 ✅ 技术架构：需对接短信服务商
 ✅ 用户体验：交互流程变化
 ✅ 成本预算：短信费用增加

: 重大影响
 工期延长：7天
 影响模块：登录注册模块、用户中心
 资源需求：前端1人，后端2人，设计1人
 预算增加：短信费用约5000元/月

:
 技术风险：中（需对接第三方短信服务）
 进度风险：高（影响当前迭代）
 成本风险：中（运营成本增加）



: 变更控制委员会（CCB）审批

: ⏳ 待评估

:
 短信服务商选型与成本评估
 对现有登录用户的影响
 是否支持多种登录方式并存

: 2026-03-28

---





| 来源 | 数量 | 占比 |
|------|------|------|
| 用户反馈 | 5 | 50% |
| 竞品动态 | 2 | 20% |
| 业务调整 | 2 | 20% |
| 技术限制 | 1 | 10% |



| 类型 | 数量 | 占比 |
|------|------|------|
| 新增需求 | 4 | 40% |
| 修改需求 | 5 | 50% |
| 删除需求 | 1 | 10% |



| 影响程度 | 数量 | 占比 |
|---------|------|------|
| 轻微影响 | 6 | 60% |
| 中等影响 | 3 | 30% |
| 重大影响 | 1 | 10% |



| 审批结果 | 数量 | 占比 |
|---------|------|------|
| 已批准 | 7 | 70% |
| 已拒绝 | 2 | 20% |
| 待评估 | 1 | 10% |

---

变更申请 → 影响评估 → 变更决策 → 执行计划 → 变更实施 → 验证确认

### 5.2 快速通道

**适用场景**: 轻微影响且紧急的变更

**流程简化**:

变更申请 → 项目经理审批 → 立即执行

**审批时间**: 2小时内

### 5.3 变更冻结期

**冻结时间**: 迭代最后2天

**冻结范围**:
- 不接受非紧急变更
- 变更需升级至指导委员会审批

**例外情况**:
- P0级Bug修复
- 安全漏洞修复
- 法律合规要求

---

## 六、变更委员会（CCB）

### 6.1 成员组成

| 角色 | 姓名 | 职责 |
|------|------|------|
| 主席 | 项目经理 | 主持会议，推动决策 |
| 产品代表 | 产品负责人 | 评估业务价值 |
| 技术代表 | 技术负责人 | 评估技术影响 |
| 测试代表 | 测试负责人 | 评估质量影响 |
| 运营代表 | 运营负责人 | 评估运营影响 |

### 6.2 会议机制

**会议频率**:
- 常规：每周一次（周三下午）
- 紧急：重大变更随时召开

**会议议程**:
1. 审查待评估变更
2. 讨论变更影响
3. 进行变更决策
4. 制定执行计划

**决策方式**:
- 轻微影响：过半数通过
- 中等影响：2/3通过
- 重大影响：全体一致通过

---

## 七、变更管理最佳实践

### 7.1 变更申请规范

**必填信息**:
- 变更描述（清晰、具体）
- 变更原因（为什么需要变更）
- 预期效果（变更后达成什么目标）
- 影响评估（初步评估）

**附件材料**:
- 用户反馈截图
- 竞品分析报告
- 原型设计稿（如有）

### 7.2 影响评估要点

**评估维度**:
- 功能影响：涉及哪些模块
- 进度影响：工期延长多久
- 资源影响：需要哪些资源
- 成本影响：预算增加多少
- 风险影响：带来哪些风险

**评估工具**:
- 影响矩阵表
- 风险评估表
- 成本收益分析表

### 7.3 变更决策原则

**批准原则**:
- 业务价值明确且高
- 影响可控，资源充足
- 风险可接受

**拒绝原则**:
- 业务价值不明确
- 影响不可控
- 风险过高

**延期原则**:
- 价值明确但不紧急
- 当前资源不足
- 需要更多评估

### 7.4 变更执行规范

**执行前**:
- 更新项目计划
- 通知相关stakeholder
- 准备必要的资源

**执行中**:
- 按计划执行
- 及时同步进度
- 遇到问题及时上报

**执行后**:
- 验证变更效果
- 更新相关文档
- 记录实际影响

---

## 八、变更管理工具

### 8.1 变更申请表

使用在线表单（飞书表单、钉钉表单）收集变更申请：
- 变更标题
- 变更描述
- 变更原因
- 预期效果
- 申请人

### 8.2 变更跟踪看板

使用项目管理工具（Jira、Trello）跟踪变更状态：
- 待评估
- 已批准
- 已拒绝
- 进行中
- 已完成

### 8.3 变更统计报表

定期生成变更统计报表：
- 变更数量趋势
- 变更来源分布
- 变更影响程度分布
- 变更审批通过率

---

## 九、常见问题处理

### 9.1 变更申请过多

**问题**: 变更申请频繁，项目无法按计划推进

**解决方案**:
- 建立变更申请成本机制（申请需要成本）
- 设置变更配额（每个迭代限制变更数量）
- 引导需求前置确认（减少后期变更）

### 9.2 变更影响评估不准

**问题**: 变更执行后发现影响超出预期

**解决方案**:
- 建立影响评估检查清单
- 邀请多方参与评估（技术、测试、运营）
- 评估结果与实际对比，持续优化

### 9.3 变更决策效率低

**问题**: 变更审批流程长，影响响应速度

**解决方案**:
- 设置快速通道（轻微变更快速审批）
- 授权机制（项目经理一定审批权限）
- 定期召开CCB会议（集中处理）

---

## 十、下一步建议

建议执行：
1. /pm-retro（进行迭代复盘，总结变更管理经验）
2. /pm-roadmap（更新产品路线图）
3. /pm-agile（优化敏捷管理流程）

---

## 输出质量对比

**✅ Good 示例**：

• 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
• 有验证来源：「数据来源：Google Analytics, 2025-12-01」
• 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

**❌ Bad 示例**：

• 模糊结论：「数据表明留存率有所下降」
• 无来源：「根据经验，这个功能很重要」
• 没有行动建议：「留存是个问题」

---

## 常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |

---

## 产出质量检查 / Verification Checklist

- [ ] 前置依赖已满足（输入文档/数据已收集）
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill

> ⚠️ 任何一项未通过 → 补全后再标记完成。

---

**项目状态**: 需求变更记录已更新
**生成时间**: [时间戳]
**生成工具**: super-pm

---

推荐下一步

执行完成后，输出：

✅ 需求变更记录已更新！

🎯 建议下一步：

1. /pm-retro（进行迭代复盘，总结变更管理经验）
2. /pm-roadmap（更新产品路线图）
3. /pm-agile（优化敏捷管理流程）