Change Management Request

---
name: change-management-request
title: 变更管理请求（影响分析+回滚计划）
description: 当提出需审批的系统/流程变更、为CAB变更评审准备变更记录、或上线前要写清影响、风险、回滚与干系人沟通时使用；用评估-计划-执行-巩固框架产出一份结构化变更请求（含影响分析表、风险评估表、实施与沟通计划、可触发回滚步骤、审批清单）；不适用于不需审批的琐碎改动、纯代码审计追踪或事后复盘。触发词：变更请求、change request、CAB、变更评审、影响分析、回滚计划、上线审批
domain: 协作/pm
triggers: [变更请求, change request, CAB, 变更评审, 变更咨询委员会, 影响分析, 回滚计划, rollback, 上线审批, 部署审批, 变更记录, RFC, 风险评估, 干系人沟通, 实施计划]
tags: [协作, pm, 变更管理, change-management, cab, itsm, 影响分析, 回滚, 风险评估, 审批流程]
level: 进阶
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: []
requires: []
related: [org-change-management, org-change-management-adkar, operational-runbook-writer, technical-change-tracker]
combines_with: [operational-runbook-writer, stakeholder-update-writer]
license: Apache-2.0
source: anthropics/knowledge-work-plugins
source_license: Apache-2.0
---
## 何时使用

当一项**系统或流程变更需要审批、且后果不可忽视**时，用本技能产出一份结构化变更请求（Change Request / RFC），供 CAB（变更咨询委员会）评审或决策人签批。典型场景：

- 上线/部署/迁移前，需正式记录**变什么、影响谁、风险多大、出问题怎么回滚**。
- 为 ITSM 变更工单准备内容，对接变更评审与审批流。
- 流程/工具/组织调整需要走审批，并提前规划干系人沟通。

**不该用的边界：**
- 不需审批的琐碎改动（拼写、配置微调、不影响行为）——直接改，别走流程。
- 仅需为代码改动建审计轨迹 / 会话交接——用 `technical-change-tracker`。
- 变更已发生、要做事后复盘归因——用 `postmortem-writer`。
- 只关注"如何让人改变行为"的组织变革落地——用 `org-change-management`（本技能管审批前的请求文档，那个管批准后的采用）。

## 步骤

按 **评估 → 计划 → 执行 → 巩固**（assess-plan-execute-sustain）逐段构建请求，缺一段评审会被打回：

1. **评估 Assess**：变的是什么？影响谁？量级（低/中/高）？会遇到什么阻力？
2. **计划 Plan**：沟通计划（谁、说什么、何时、用什么渠道）+ 培训计划 + 支持计划（帮助台/FAQ/对接人）+ 带里程碑的时间线。
3. **执行 Execute**：先讲清"为什么"再宣布"做什么" → 培训与支持 → 监控采用 → 处理阻力。
4. **巩固 Sustain**：度量采用与有效性 → 强化新行为 → 收尾遗留问题 → 记录经验教训。

**沟通原则（贯穿全程）：** 先讲 why 再讲 what；早讲、勤讲；多渠道；不仅说"得到什么"也**承认"失去什么"**；给出清晰的提问/反馈通道。

## 指令

按下面模板填满即为一份合格变更请求；**影响分析、风险评估、回滚计划三块必填，不可留空**。

```markdown
## 变更请求：[标题]
**申请人:** [姓名] | **日期:** [日期] | **优先级:** [紧急/高/中/低]
**状态:** 草稿 | 待审批 | 已批准 | 实施中 | 已完成

### 描述
[变什么、为什么]

### 业务理由
[为何必要——降本/合规/效率/降风险]

### 影响分析
| 范围 | 影响 | 细节 |
|------|------|------|
| 用户 | [高/中/低/无] | [谁受影响、怎样受影响] |
| 系统 | [高/中/低/无] | [涉及哪些系统] |
| 流程 | [高/中/低/无] | [哪些工作流变化] |
| 成本 | [高/中/低/无] | [预算影响] |

### 风险评估
| 风险 | 可能性 | 影响 | 缓解措施 |
|------|--------|------|----------|
| [风险] | [高/中/低] | [高/中/低] | [如何缓解] |

### 实施计划
| 步骤 | 负责人 | 时间线 | 依赖 |
|------|--------|--------|------|
| [步骤] | [人] | [日期] | [依赖什么] |

### 沟通计划
| 受众 | 信息 | 渠道 | 时机 |
|------|------|------|------|
| [谁] | [告诉他们什么] | [怎么传达] | [何时] |

### 回滚计划
[逐步说明如何撤销本变更]
- 触发条件: [何时回滚——量化阈值，如错误率>X%]
- 回滚步骤: [如何回滚，按序]
- 验证: [如何确认回滚成功]

### 所需审批
| 审批人 | 角色 | 状态 |
|--------|------|------|
| [姓名] | [角色] | 待批 |
```

**连接器可用时（ITSM / 项目跟踪 / 协同 IM）：** 接 ITSM 可自动建变更工单、拉 CAB 排期与审批流；接项目跟踪可关联实施任务与依赖、按里程碑跟踪进度；接 IM 可起草干系人通知、向相关频道发布变更更新。

## 示例

**一句话提示词：** "为下周把订单服务从单体拆出独立部署，写一份变更请求：申请人=我，优先级=高，要 CAB 评审。重点填影响分析、风险评估、回滚计划三块。"

**影响分析要写具体，不要写"所有人"：** 反例"影响所有用户"；正例"影响计费团队约 200 名坐席，结算页改版，需重新培训 30 分钟"。

**回滚触发要量化：** 反例"出问题就回滚"；正例"上线后 30 分钟内 5xx 错误率 > 2% 或下单成功率 < 99%，即执行回滚：切流量回旧版本 → 验证旧版健康检查通过 → 关闭新部署 → 通知值班。"

## 注意事项

- **影响要具体可量化**——"所有人"不是影响评估，"计费团队 200 人"才是。
- **永远准备回滚计划**——再有把握也要为失败留后路；回滚的触发条件、步骤、验证三者齐全才算数。
- **早沟通**——突袭制造阻力，预告争取支持；先讲 why 再讲 what。
- 本技能产出的是**审批前的请求文档**；批准后的落地采用、阻力管理交给 `org-change-management`。
- 高风险/不可逆变更（数据迁移、删表、改权限）必须在回滚计划中标注**不可逆步骤**与数据备份点。

## 互见

- related：`technical-change-tracker` —— 批准后追踪代码改动状态与会话交接
- related：`enterprise-project-manager` —— 把实施计划拆成可执行的项目任务与依赖
- related：`business-process-mapper` —— 流程类变更先画清现状/目标流程再评估影响
- combines_with：`org-change-management` —— 变更批准后，承接沟通节奏、阻力应对与采用度度量
- combines_with：`stakeholder-update-writer` —— 落地沟通计划，向各受众发布变更进展
- combines_with：`pre-deploy-checklist` / `release-manager` —— 部署类变更对接上线检查与发布执行
- combines_with：`postmortem-writer` —— 变更若引发事故，回滚后做事后复盘

---
*采编自 anthropics/knowledge-work-plugins（Apache-2.0 许可证），对 change-request 技能做了中文适配重写，保留评估-计划-执行-巩固框架、影响/风险/实施/沟通/回滚/审批输出模板、连接器编排与"影响要具体、永远备回滚、早沟通"等关键约束。*