Preamble
echo "📝 需求变更管理工具已启动"
Write-time boundaries
When only discussing, do not write files; startup checks do not create directories. When the user requests saving artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmation,only immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md, and installing this skill alone also follows this paragraph.
Cross-Agent interaction rules
When the process requires interaction with the user:
- If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
- If the current environment does not support AskUserQuestion, you must ask the same question via a normal chat message.
- Ask only one question at a time.
- After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
- Do not generate documents or write to docs before the user answers.
- Existing docs files cannot replace the user's answer in this round.
Execution flow
Step 1: Record the change request
Use AskUserQuestion:
📋 Change source
Source of the change request:
A) User feedback (change in user requirements) B) Competitor activity (market change) C) Business adjustment (strategic adjustment) D) Technical limitation (technical implementation issue) E) Regulatory requirement (compliance need) F) Other reason (please enter manually)
Continue asking:
🎯 Change type
Type of this change:
A) New requirement (add a new feature) B) Modify requirement (adjust an existing feature) C) Delete requirement (cancel a planned feature) D) Priority adjustment (change the development order)
Step 2: Impact assessment
Use AskUserQuestion:
📊 Impact scope assessment
Which aspects does the change affect? (multiple choice)
A) Functional scope (add/modify functional modules) B) Development schedule (extended duration) C) Technical architecture (architecture adjustment) D) Testing scope (regression testing) E) User experience (interaction changes) F) Data migration (data structure changes) G) Third-party integration (interface changes) H) Cost budget (increased resources)
Continue asking:
⏱️ Impact level assessment
Impact level of the change:
A) Minor impact (duration < 2 days, affects < 1 module) B) Moderate impact (duration 2-5 days, affects 1-3 modules) C) Major impact (duration > 5 days, affects > 3 modules) D) Critical impact (affects core functionality or architecture)
Step 3: Change decision
Use AskUserQuestion:
✅ Change approval level
Based on the impact level, who needs to approve?
A) Project manager approval (minor impact) B) Product owner + technical lead approval (moderate impact) C) Change Control Board (CCB) approval (major impact) D) Steering committee approval (critical impact)
Continue asking:
🔄 Change decision result
Change approval result:
A) Approve change (agree to execute) B) Conditional approval (specific conditions must be met) C) Defer assessment (discuss later) D) Reject change (do not execute)
Step 4: Develop a change plan
Use AskUserQuestion:
📅 Change execution timing
When to execute the change?
A) Execute immediately (emergency change) B) Current iteration (within this week) C) Next iteration (next week) D) Future version (add to backlog)
Step 5: Record the change
Use the Write tool to update docs/04-风控管理/需求变更记录.md。
Subagent parallel acceleration (new in v2.0.0)
Use the Agent tool to execute independent subtasks in parallel, greatly shortening total execution time.
Parallelizable subtasks
After the user information collection in steps 1-4 is complete, the following two tasks can be executed in parallel:
| Subtask | Description |
|---|---|
| In-depth impact analysis | Automatically generate an impact assessment matrix based on the change type and impact scope |
| Change plan drafting | Automatically generate a change execution plan document based on the approval result and execution timing |
Trigger method
Before generating the document in step 5, use the Agent tool to activate parallel execution of subtasks.
V1 vs V2 comparison
| Dimension | V1.1.0 (serial) | V2.0.0 (Subagent parallel) | Savings |
|---|---|---|---|
| Impact analysis | User answers impact scope one by one | Agent analyzes multi-dimensional impact in parallel | About 3 rounds of interaction |
| Change plan | Ask about execution details in sequence | Agent automatically generates execution plan | About 2 rounds of interaction |
| Total interaction rounds | About 10-12 rounds | About 5-7 rounds | Reduced by 45%+ |
| Estimated time | 10-15 minutes | 5-8 minutes | Saves about 6 minutes |
Output files
Requirement change record → docs/04-风控管理/需求变更记录.md
Output document template
# 需求变更记录
## 一、变更概况
- **变更申请总数**: [累计数量]
- **已批准**: [数量]
- **已拒绝**: [数量]
- **待评估**: [数量]
- **生成时间**: [当前时间]
---
## 二、变更记录表
| 变更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
#### 3.4 执行计划
**执行时机**: 下个迭代（2026-03-28 开始）
**任务拆分**:
- 设计导出接口（后端，0.5天）
- 实现导出逻辑（后端，1天）
- 开发导出UI（前端，0.5天）
- 测试验证（测试，1天）
**责任人**:
- 后端开发：张三
- 前端开发：李四
- 测试：王五
**验收标准**:
- 支持导出Excel和PDF格式
- 文件大小限制在10MB以内
- 导出时间 < 30秒
#### 3.5 执行状态
**当前状态**: ✅ 已完成
**完成日期**: 2026-04-01
**实际情况**:
- 实际工期：3天（符合预期）
- 测试通过：无严重Bug
- 用户反馈：满意
**经验总结**:
- 提前考虑文件大小限制，避免服务器压力
- 导出功能需要权限控制，防止数据泄露
---
### CH-002: 修改登录流程
#### 3.1 变更申请
**申请日期**: 2026-03-26
**申请人**: 产品负责人
**变更来源**: 竞品动态
**变更类型**: 修改需求
**变更描述**:
竞品已支持手机号一键登录，用户体验更优。当前登录流程需输入密码，步骤繁琐，用户流失率高。
**变更原因**:
- 竞品分析：竞品新增一键登录功能
- 用户数据：登录页流失率高达30%
- 业务价值：降低流失率，提升注册转化率
#### 3.2 影响评估
**影响范围**:
- ✅ 功能范围：修改登录模块
- ✅ 开发进度：预计增加7天工期
- ✅ 技术架构：需对接短信服务商
- ✅ 用户体验：交互流程变化
- ✅ 成本预算：短信费用增加
**影响程度**: 重大影响
- 工期延长：7天
- 影响模块：登录注册模块、用户中心
- 资源需求：前端1人，后端2人，设计1人
- 预算增加：短信费用约5000元/月
**风险评估**:
- 技术风险：中（需对接第三方短信服务）
- 进度风险：高（影响当前迭代）
- 成本风险：中（运营成本增加）
#### 3.3 变更决策
**审批级别**: 变更控制委员会（CCB）审批
**审批结果**: ⏳ 待评估
**待评估事项**:
- 短信服务商选型与成本评估
- 对现有登录用户的影响
- 是否支持多种登录方式并存
**下次评估时间**: 2026-03-28
---
## 四、变更统计
### 4.1 按来源统计
| 来源 | 数量 | 占比 |
|------|------|------|
| 用户反馈 | 5 | 50% |
| 竞品动态 | 2 | 20% |
| 业务调整 | 2 | 20% |
| 技术限制 | 1 | 10% |
### 4.2 按类型统计
| 类型 | 数量 | 占比 |
|------|------|------|
| 新增需求 | 4 | 40% |
| 修改需求 | 5 | 50% |
| 删除需求 | 1 | 10% |
### 4.3 按影响程度统计
| 影响程度 | 数量 | 占比 |
|---------|------|------|
| 轻微影响 | 6 | 60% |
| 中等影响 | 3 | 30% |
| 重大影响 | 1 | 10% |
### 4.4 按审批结果统计
| 审批结果 | 数量 | 占比 |
|---------|------|------|
| 已批准 | 7 | 70% |
| 已拒绝 | 2 | 20% |
| 待评估 | 1 | 10% |
---
## 五、变更控制流程
### 5.1 标准流程
Change request → Impact assessment → Change decision → Execution plan → Change implementation → Verification confirmation
### 5.2 快速通道
**适用场景**: 轻微影响且紧急的变更
**流程简化**:
Change request → Project manager approval → Execute immediately
**审批时间**: 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 示例**：
- Has data references: "According to Q4 data, the retention rate dropped from 35% to 28%"
- Has verification sources: "Data source: Google Analytics, 2025-12-01"
- Has clear recommendations: "Recommend reducing the onboarding steps from 5 to 3"
**❌ Bad 示例**：
- Vague conclusion: "The data shows that the retention rate has declined somewhat"
- No source: "Based on experience, this feature is very important"
- No action recommendations: "Retention is a problem"
---
## 常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
---
## 产出质量检查 / Verification Checklist
- [ ] 前置依赖已满足（输入文档/数据已收集）
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill
> ⚠️ 任何一项未通过 → 补全后再标记完成。
---
**项目状态**: 需求变更记录已更新
**生成时间**: [时间戳]
**生成工具**: super-pm
Recommended next steps
After execution is complete, output:
✅ Requirement change record has been updated!
🎯 Recommended next steps:
- /pm-retro (conduct an iteration retrospective and summarize change management experience)
- /pm-roadmap (update the product roadmap)
- /pm-agile (optimize the agile management process)