Risk Heatmap

---
name: risk-heatmap
description: "项目风险管理工具：录入风险条目（概率、影响、类别、责任人、应对措施），自动计算风险评分并生成可交互的HTML风险热力图（5×5概率-影响矩阵）。当用户提到风险登记册、风险矩阵、风险热力图、概率影响矩阵，或请求进行风险评估、项目风险管理、梳理项目风险、做个风险分析时触发。"
license: MIT
---

# Risk Register — 项目风险登记册与概率-影响矩阵

系统化的项目风险管理工具。录入风险条目，自动计算风险评分，生成可交互的 HTML 风险热力图（5×5 概率-影响矩阵）。

## Quick Start

引导用户完成 3 步：

1. **识别风险**：列出项目中可能出现的风险事件
2. **评估风险**：对每个风险评定概率（1-5）和影响（1-5）
3. **生成热力图**：运行脚本生成 HTML 可视化报告

用户只需说：
> "帮我梳理一下这个项目的风险，生成一个风险热力图"

Agent 会引导用户逐步完成风险识别与评估，然后生成可视化报告。

---

## 一、风险评估框架

### 概率等级（Probability）

| 等级 | 名称 | 含义 | 参考频率 |
|------|------|------|---------|
| 1 | 极低（Rare） | 几乎不可能发生 | <5% |
| 2 | 低（Unlikely） | 不太可能发生 | 5-20% |
| 3 | 中（Possible） | 有可能发生 | 20-50% |
| 4 | 高（Likely） | 很可能发生 | 50-80% |
| 5 | 极高（Almost Certain） | 几乎必然发生 | >80% |

### 影响等级（Impact）

| 等级 | 名称 | 进度影响 | 成本影响 | 质量影响 |
|------|------|---------|---------|---------|
| 1 | 可忽略（Negligible） | 延迟 <1 天 | 增加 <1% | 几乎不影响 |
| 2 | 轻微（Minor） | 延迟 1-5 天 | 增加 1-5% | 局部受影响 |
| 3 | 中等（Moderate） | 延迟 1-4 周 | 增加 5-15% | 主要功能受影响 |
| 4 | 严重（Major） | 延迟 1-3 月 | 增加 15-30% | 交付物严重降级 |
| 5 | 灾难性（Catastrophic） | 延迟 >3 月 | 增加 >30% | 项目失败 |

### 风险评分与等级

风险评分 = 概率 × 影响（1-25 分）

| 评分范围 | 风险等级 | 颜色 | 应对策略 |
|---------|---------|------|---------|
| 1-4 | 低风险（Low） | 绿色 | 接受：定期监控即可 |
| 5-9 | 中风险（Medium） | 黄色 | 缓解：制定应对计划，定期复查 |
| 10-15 | 高风险（High） | 橙色 | 转移/缓解：需主动管理，分配责任人 |
| 16-25 | 严重风险（Critical） | 红色 | 规避/转移：立即行动，升级管理层关注 |

---

## 二、风险数据格式

### JSON 输入格式

```json
{
  "project": "项目名称",
  "date": "2024-01-15",
  "risks": [
    {
      "id": "R001",
      "name": "关键人员离职",
      "category": "人员",
      "description": "核心开发人员离职导致知识断层和进度延迟",
      "probability": 3,
      "impact": 4,
      "owner": "张三",
      "mitigation": "知识转移文档化、交叉培训、冗余人员配置",
      "status": "active"
    }
  ]
}
```

### 字段说明

| 字段 | 必需 | 类型 | 说明 |
|------|------|------|------|
| project | 是 | string | 项目名称 |
| date | 否 | string | 评估日期（默认取当天） |
| risks | 是 | array | 风险条目列表 |
| risks[].id | 是 | string | 风险编号，如 R001 |
| risks[].name | 是 | string | 风险名称（简短） |
| risks[].category | 否 | string | 风险类别（人员/技术/进度/成本/范围/外部） |
| risks[].description | 否 | string | 详细描述 |
| risks[].probability | 是 | int(1-5) | 概率等级 |
| risks[].impact | 是 | int(1-5) | 影响等级 |
| risks[].owner | 否 | string | 风险责任人 |
| risks[].mitigation | 否 | string | 应对措施 |
| risks[].status | 否 | string | 状态：active/mitigated/closed（默认 active） |

### 常用风险类别

| 类别 | 典型风险 |
|------|---------|
| 人员（People） | 人员流失、技能不足、沟通障碍 |
| 技术（Technical） | 技术方案不可行、性能不达标、第三方依赖 |
| 进度（Schedule） | 需求变更导致延期、依赖方交付延迟 |
| 成本（Cost） | 预算超支、汇率波动、隐性成本 |
| 范围（Scope） | 需求蔓延、范围不清晰 |
| 外部（External） | 政策法规变化、供应商违约、不可抗力 |

---

## 三、脚本工具

提供 `scripts/generate_risk_heatmap.py` 用于生成 HTML 风险热力图。

### 使用方式

```bash
# 方式 1：从 JSON 文件读取
python3 scripts/generate_risk_heatmap.py --file risks.json --output risk_report.html

# 方式 2：从命令行传入 JSON
python3 scripts/generate_risk_heatmap.py --json '{
  "project": "电商平台重构",
  "risks": [
    {"id": "R001", "name": "核心人员离职", "category": "人员", "probability": 3, "impact": 4, "owner": "项目经理", "mitigation": "交叉培训"},
    {"id": "R002", "name": "第三方 API 不稳定", "category": "技术", "probability": 4, "impact": 3, "owner": "技术负责人", "mitigation": "降级方案+缓存"},
    {"id": "R003", "name": "需求频繁变更", "category": "范围", "probability": 4, "impact": 4, "owner": "产品经理", "mitigation": "变更控制流程"}
  ]
}' --output risk_report.html
```

### 输出内容

生成的 HTML 报告包含：

1. **项目概览**：项目名称、评估日期、风险统计摘要
2. **风险热力图**：5×5 概率-影响矩阵，颜色编码，风险编号标注在对应格子中
3. **风险登记表**：完整的风险条目表格，按风险评分从高到低排序
4. **风险分布统计**：按类别和等级的饼图/统计

HTML 文件完全自包含（无外部依赖），可直接在浏览器中打开。

---

## 四、风险识别引导清单

在引导用户识别风险时，可按以下类别逐一提问：

### 人员风险
- 关键人员是否有离职风险？
- 团队是否具备所需技能？
- 是否存在沟通瓶颈或协作障碍？
- 外包/合作方人员是否可靠？

### 技术风险
- 技术方案是否经过验证？
- 是否依赖未成熟的技术或框架？
- 第三方服务/API 的可靠性如何？
- 系统性能是否能满足预期负载？
- 数据安全和合规是否有保障？

### 进度风险
- 里程碑时间线是否合理？
- 是否有外部依赖方的交付节点？
- 是否考虑了审批、测试等缓冲时间？

### 成本风险
- 预算估算是否充分？
- 是否有隐性成本（如培训、迁移）？
- 汇率/市场价格波动是否影响？

### 范围风险
- 需求是否明确、达成一致？
- 是否有需求蔓延（scope creep）的倾向？
- 验收标准是否清晰？

### 外部风险
- 是否受政策法规影响？
- 供应商/合作方是否可靠？
- 是否有自然灾害等不可抗力因素？

---

## 五、完整案例：电商平台重构风险评估

### 背景
- 电商平台从单体架构迁移到微服务
- 团队 15 人，项目周期 6 个月
- 涉及用户系统、订单系统、支付系统重构

### 风险登记

| ID | 名称 | 类别 | 概率 | 影响 | 评分 | 等级 | 责任人 | 应对措施 |
|----|------|------|------|------|------|------|--------|---------|
| R001 | 核心架构师离职 | 人员 | 2 | 5 | 10 | 高 | CTO | 架构决策文档化、双人负责制 |
| R002 | 微服务间通信延迟 | 技术 | 3 | 4 | 12 | 高 | 技术负责人 | 提前做性能测试、准备降级方案 |
| R003 | 支付接口迁移失败 | 技术 | 2 | 5 | 10 | 高 | 支付团队 | 双轨并行、灰度切换 |
| R004 | 需求频繁变更 | 范围 | 4 | 3 | 12 | 高 | 产品经理 | 变更控制委员会、迭代冻结 |
| R005 | 第三方 CDN 服务中断 | 外部 | 2 | 3 | 6 | 中 | 运维 | 多 CDN 供应商、故障切换 |
| R006 | 数据迁移丢失 | 技术 | 2 | 4 | 8 | 中 | DBA | 全量备份、校验脚本、灰度迁移 |
| R007 | 团队微服务经验不足 | 人员 | 3 | 3 | 9 | 中 | 技术负责人 | 培训计划、引入外部顾问 |
| R008 | 测试覆盖不足 | 技术 | 3 | 3 | 9 | 中 | QA 负责人 | 自动化测试、核心路径优先 |

### 使用脚本生成热力图

```bash
python3 scripts/generate_risk_heatmap.py --file ecommerce_risks.json --output ecommerce_risk_report.html
```

---

## 六、风险应对策略

| 策略 | 适用场景 | 示例 |
|------|---------|------|
| 规避（Avoid） | 改变计划消除风险 | 放弃使用未成熟技术 |
| 转移（Transfer） | 将风险转移给第三方 | 购买保险、外包高风险模块 |
| 缓解（Mitigate） | 降低概率或影响 | 增加测试、准备备选方案 |
| 接受（Accept） | 风险低或无法避免 | 记录并监控 |

---

## 七、定期复查建议

- **高/严重风险**：每周复查
- **中风险**：每两周复查
- **低风险**：每月复查

每次复查更新：
1. 风险状态是否变化
2. 概率/影响是否需要调整
3. 应对措施是否执行到位
4. 是否有新增风险

---

## 参考资料

- PMI — *A Guide to the Project Management Body of Knowledge (PMBOK)*（项目管理知识体系）
- ISO 31000 — Risk Management Guidelines（风险管理指南）
- Hillson, D. — *Practical Project Risk Management*（实用项目风险管理）