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 输入格式

{
  "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 风险热力图。

使用方式

# 方式 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 负责人	自动化测试、核心路径优先

使用脚本生成热力图

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（实用项目风险管理）