| 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 交互规则
当流程要求与用户交互时：
- 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
- 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
- 一次只问一个问题。
- 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
- 不得在用户回答前生成文档、写入 docs。
- 已有 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
推荐下一步
执行完成后，输出：
✅ 需求变更记录已更新！
🎯 建议下一步：
- /pm-retro（进行迭代复盘，总结变更管理经验）
- /pm-roadmap（更新产品路线图）
- /pm-agile（优化敏捷管理流程）
