name: risk-heatmap description: "项目风险管理工具：录入风险条目（概率、影响、类别、责任人、应对措施），自动计算风险评分并生成可交互的HTML风险热力图（5×5概率-影响矩阵）。当用户提到风险登记册、风险矩阵、风险热力图、概率影响矩阵，或请求进行风险评估、项目风险管理、梳理项目风险、做个风险分析时触发。" license: MIT
风险登记册 — 概率-影响矩阵
系统化的项目风险管理工具。录入风险条目，自动计算风险评分，生成可交互的 HTML 风险热力图（5×5 概率-影响矩阵）。
快速入门
引导用户完成 3 步：
- 识别风险：列出项目中可能出现的风险事件
- 评估风险：对每个风险评定概率（1-5）和影响（1-5）
- 生成热力图：运行脚本生成 HTML 可视化报告
用户只需说：
"帮我梳理一下这个项目的风险，生成一个风险热力图"
助手会引导用户逐步完成风险识别与评估，然后生成可视化报告。
一、风险评估框架
概率等级
| 等级 | 名称 | 含义 | 参考频率 |
|---|---|---|---|
| 1 | 极低（Rare） | 几乎不可能发生 | <5% |
| 2 | 低（Unlikely） | 不太可能发生 | 5-20% |
| 3 | 中（Possible） | 有可能发生 | 20-50% |
| 4 | 高（Likely） | 很可能发生 | 50-80% |
| 5 | 极高（Almost Certain） | 几乎必然发生 | >80% |
影响等级
| 等级 | 名称 | 进度影响 | 成本影响 | 质量影响 |
|---|---|---|---|---|
| 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 报告包含：
- 项目概览：项目名称、评估日期、风险统计摘要
- 风险热力图：5×5 概率-影响矩阵，颜色编码，风险编号标注在对应格子中
- 风险登记表：完整的风险条目表格，按风险评分从高到低排序
- 风险分布统计：按类别和等级的饼图/统计
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） | 风险低或无法避免 | 记录并监控 |
七、定期复查建议
- 高/严重风险：每周复查
- 中风险：每两周复查
- 低风险：每月复查
每次复查更新：
- 风险状态是否变化
- 概率/影响是否需要调整
- 应对措施是否执行到位
- 是否有新增风险
参考资料
- PMI — A Guide to the Project Management Body of Knowledge (PMBOK)（项目管理知识体系）
- ISO 31000 — Risk Management Guidelines（风险管理指南）
- Hillson, D. — Practical Project Risk Management（实用项目风险管理）