# Risk Management

> 识别和管理项目风险时使用。适用于项目启动、阶段评审、变更评估。优先使用 PMBOK 风险矩阵 + 缓解方案 + 触发条件。

- Skill: `zhaoxuya520/risk-management` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/risk-management`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/risk-management/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/risk-management

---


# 风险管理（Risk Management）

参考来源：PMBOK Risk Management、[Atlassian Project Risk](https://www.atlassian.com/agile/project-management/project-management-dependencies)

## 适用场景

- 项目启动时识别已知风险
- 阶段评审时更新风险清单
- 变更评估时识别新风险
- 跨工作流协作的风险点识别

## 核心原则

```text
1. 风险不是问题
   风险 = 可能发生的事件
   问题 = 已经发生的事件

2. 风险要早识别
   越晚发现的风险代价越高

3. 不能消除所有风险
   只能降低概率或影响

4. 风险要持续跟踪
   不是列一次就完了，每个阶段都要更新
```

## 风险矩阵

```text
                影响
              低    中    高
        ┌─────┬─────┬─────┐
   高   │ 中  │ 高  │ 严重 │
概   ├─────┼─────┼─────┤
率   中 │ 低  │ 中  │ 高  │
        ├─────┼─────┼─────┤
   低   │ 低  │ 低  │ 中  │
        └─────┴─────┴─────┘

行动策略：
  严重：立即处理 / 改变方案
  高：详细计划 / 预留资源
  中：监控 / 触发时响应
  低：记录 / 不主动处理
```

## 风险结构

每个风险必须包含：

```text
1. 描述
   - 风险事件（什么会发生）
   - 触发条件（什么情况下会发生）

2. 概率（低/中/高）
   - 高：>50% 会发生
   - 中：20~50%
   - 低：<20%

3. 影响（低/中/高）
   - 高：项目延期 / 上线失败 / 关键路径中断
   - 中：单个工作流延迟 / 部分功能受影响
   - 低：可恢复 / 工作量小

4. 风险等级 = 概率 × 影响

5. 缓解方案（Mitigation）
   - 降低概率：怎么避免发生
   - 降低影响：发生了怎么减少损失

6. 应急预案（Contingency）
   - 真的发生了怎么办

7. 触发条件
   - 什么信号说明风险正在发生

8. 负责人 / 工作流
```

## 项目常见风险类别

### 技术风险

```text
- 第三方 API 不稳定
- 性能瓶颈（数据库/接口）
- 技术选型不当
- 兼容性问题
- 安全漏洞
```

### 资源风险

```text
- 工作流能力不足
- 工具不可用（缺工具/版本不兼容）
- 算力不足（AI 模型）
- 外部依赖延迟
```

### 需求风险

```text
- PRD 不清晰
- 需求频繁变更
- 验收标准不可测
- 干系人意见冲突
```

### 进度风险

```text
- 关键路径延误
- 联调时间不足
- 测试覆盖不足
- 部署窗口紧张
```

### 质量风险

```text
- 测试覆盖不足
- 性能未验证
- 安全未评审
- 文档缺失
```

## 风险登记表模板

```markdown
## 项目风险清单

| # | 风险描述 | 类别 | 概率 | 影响 | 等级 | 触发条件 | 缓解方案 | 应急预案 | 负责工作流 |
|---|---------|------|------|------|------|---------|---------|---------|----------|
| R1 | 第三方支付 API 限流 | 技术 | 中 | 高 | 高 | 单分钟请求 > 100 | 实现本地缓存 + 重试 | 切换备用支付 | backend-engineer |
| R2 | API 设计完成时间延后 | 进度 | 中 | 中 | 中 | API 设计 > 30min | 提前提供 Mock | 前端先用 Mock 开发 | api-designer |
| R3 | QA 测试发现严重 Bug | 质量 | 中 | 高 | 高 | Bug 数 > 10 | 加强代码评审 | 回滚到上版本 | qa-engineer |
| R4 | 部署窗口不足 | 进度 | 低 | 高 | 中 | 凌晨部署窗口 < 1h | 提前演练 | 推迟到下次 | devops-engineer |
| R5 | 用户反馈与预期不符 | 需求 | 低 | 中 | 低 | 上线后差评率 > 10% | 内测验证 | 紧急修复 | product-manager |
```

## 工作流程

```text
1. 项目启动时：
   - 用风险类别清单做头脑风暴
   - 至少识别 5~10 个风险
   - 给每个风险评分（概率 × 影响）
   ↓
2. 高/严重等级的风险：
   - 制定详细缓解方案
   - 预留资源和缓冲
   ↓
3. 中等级的风险：
   - 监控触发条件
   - 准备应急预案
   ↓
4. 低等级的风险：
   - 记录但不主动处理
   ↓
5. 每个里程碑：
   - 复审风险清单
   - 更新概率和影响
   - 关闭已不存在的风险
   - 添加新发现的风险
   ↓
6. 项目结束：
   - 复盘哪些风险真的发生了
   - 沉淀到 field-journal
```

## 质量自检

```text
□ 是否识别了至少 5 个风险（少于 5 个说明可能漏了）
□ 每个风险是否有触发条件（不能是"可能会出问题"）
□ 高/严重风险是否有详细缓解方案
□ 是否标注了负责工作流（不能"全员负责"）
□ 应急预案是否可执行（不能"加班赶工"）
□ 是否包含了非技术风险（资源、需求、进度）
```

## 常见坑

1. **风险清单是空的**——团队太乐观，认为不会出问题
2. **风险太宽泛**——"可能会延期" → 应该是具体什么会延期
3. **缓解方案是废话**——"加强沟通" "提高质量"
4. **不跟踪风险**——列一次就放着，不更新
5. **没有触发条件**——风险发生了都不知道
6. **应急预案不可执行**——"加人加班" 不是预案
7. **只看技术风险**——忽略需求、资源、进度风险
8. **风险等级评得过低**——为了"看起来项目没风险"

## 风险监控指标

```text
项目级风险指标：
  - 高/严重风险数量（应该 ≤ 3）
  - 风险关闭率（每个里程碑应该关闭 30%+）
  - 新增风险率（不应该一直增长）
  - 实际发生的风险占比（评估识别能力）

风险自身指标：
  - 触发频率（接近触发条件的次数）
  - 缓解效果（执行缓解后概率/影响是否下降）
```

## 配套模板

- `templates/risk-register-template.md` — 风险登记表 + 风险矩阵可视化 + 风险复审模板

## 与其他 skill 的协作

```text
上游：
  wbs-decomposition → 任务拆解时识别每个任务的风险
  critical-path → 关键路径上的风险优先处理
  orchestration → 并发编排带来的资源冲突风险

下游：
  milestone-gate → 高风险任务作为门禁重点
  change-control → 变更评估时识别新风险
  progress-tracking → 监控风险触发条件
  retrospective → 复盘风险识别和应对
```