名称: 项目风险登记描述: 用于通过结构化风险跟踪管理项目不确定性，识别和评估风险，使用概率×影响评分（风险矩阵），分配风险所有者和缓解计划，跟踪应急措施和触发器，监控风险在整个项目生命周期中的演变，或当用户提及风险登记、风险评估、风险管理、风险缓解、概率-影响矩阵，或询问“这个项目可能出什么问题？”。

项目风险登记

目的

主动识别、评估、优先排序和监控项目风险，以减少意外、支持知情决策，并确保利益相关者理解不确定性。将模糊担忧（“这可能行不通”）转化为可操作的风险管理（概率×影响评分、指定所有者、具体缓解措施、可测量触发器）。

何时使用

在以下情况下使用此技能：

项目启动：在重要工作开始前建立风险基线
高不确定性：新技术、不熟悉领域、复杂依赖、监管约束
利益相关者压力：高管/董事会希望了解“可能出什么问题”
关键路径关注点：延迟、依赖或单点故障威胁时间表
门评审：季度检查、里程碑评审、继续/停止决策需要风险评估
事件响应：发生重大问题，需要识别相关风险以防止再次发生
组合管理：比较多个项目的风险概况以进行资源分配
变更请求：范围/时间表/预算变更需要风险重新评估

常见触发词：

“这个项目的最大风险是什么？”
“什么可能导致我们错过截止日期？”
“我们对这个估计/计划有多自信？”
“如果X失败，我们的备用计划是什么？”
“哪些依赖可能阻碍我们？”

是什么？

项目风险登记是一个动态文档，跟踪所有已识别的风险，包括：

风险识别：可能出错（威胁）或比预期好（机会）的情况
风险评估：概率（可能性？）×影响（如果发生有多坏/好？）= 风险评分
风险优先排序：首先关注高评分风险（红色/高），监控中等（黄色），接受低（绿色）
风险所有权：负责监控和缓解的指定个人
风险响应：缓解（减少概率）、应急（如果发生减少影响）、接受（不采取行动）
风险触发器：风险正在实现的早期预警指标（激活应急措施的时间）
风险监控：定期更新（状态变化、新风险、已关闭风险）

风险矩阵（5×5 概率×影响）：

影响 →     1         2         3         4         5
概率 ↓   最小化   较小   中等   主要   严重

5 高   │ 中等 │ 中等 │ 高 │ 高 │ 关键│
         │   5    │   10   │   15   │   20   │   25    │
4        │ 低   │ 中等 │ 中等 │ 高 │ 高   │
         │   4    │    8   │   12   │   16   │   20    │
3 中等 │ 低   │ 低   │ 中等 │ 中等 │ 高   │
         │   3    │    6   │    9   │   12   │   15    │
2        │ 低   │ 低   │ 低   │ 中等 │ 中等  │
         │   2    │    4   │    6   │    8   │   10    │
1 低    │ 低   │ 低   │ 低   │ 低   │ 中等  │
         │   1    │    2   │    3   │    4   │    5    │

风险阈值：

关键（≥20）：升级到高管，立即需要缓解
高（12-19）：主动管理，每周评审，记录缓解措施
中等（6-11）：密切监控，每月评审，应急计划
低（1-5）：接受或最小化缓解，季度评审

示例：软件迁移项目

风险ID	风险	概率	影响	评分	所有者	缓解	应急
R-001	第三方API在项目中期弃用	3	4	12（中等）	工程主管	联系供应商获取弃用时间表	构建抽象层以快速替换
R-002	关键工程师在关键阶段离职	2	5	10（中等）	工程经理	知识分享、配对编程	合同备份工程师
R-003	数据迁移耗时比估计长3倍	4	4	16（高）	数据主管	先对10%数据进行试点迁移	延长时间表，减少范围

工作流程

复制此检查清单并跟踪进度：

风险登记进度：
- [ ] 步骤1：跨类别识别风险
- [ ] 步骤2：评估概率和影响
- [ ] 步骤3：计算风险评分并优先排序
- [ ] 步骤4：分配所有者和定义响应
- [ ] 步骤5：定期监控和更新

步骤1：跨类别识别风险

使用结构化类别（技术、时间表、资源、外部、范围）进行头脑风暴。参见常见模式获取类别检查清单。使用resources/template.md获取登记结构。

步骤2：评估概率和影响

对每个风险进行概率评分（1-5：罕见到几乎确定）和影响评分（1-5：最小化到严重）。邀请主题专家确保准确性。参见风险评分框架获取定义。

步骤3：计算风险评分并优先排序

对每个风险，概率×影响。在风险矩阵（5×5网格）上绘图以可视化风险概况。首先关注关键/高风险。参见resources/methodology.md获取高级技术如蒙特卡洛模拟。

步骤4：分配所有者和定义响应

对于每个高/关键风险，分配指定所有者（非“团队”），定义缓解（减少概率）、应急（减少影响）和触发器（何时激活应急）。参见resources/template.md获取响应规划结构。

步骤5：定期监控和更新

每周评审风险登记（活跃项目）或每月（长期项目）。随着上下文变化更新概率/影响，添加新风险，关闭已解决风险，跟踪缓解进度。参见护栏获取监控节奏。

常见模式

风险类别（用于头脑风暴）：

技术风险：技术故障、集成问题、性能问题、安全漏洞、技术债务、复杂性低估
时间表风险：依赖延迟、估计错误、范围蔓延、资源不可用、关键路径受阻
资源风险：关键人员离职、技能缺口、预算超支、供应商/承包商问题、设备不可用
外部风险：监管变化、市场波动、竞争对手行动、经济下滑、自然灾害、供应商破产
范围风险：需求不明确、优先级变化、利益相关者分歧、镀金、任务蔓延
组织风险：缺乏高管支持、竞争优先级、资金不足、组织变革、政治冲突

按项目类型：

软件项目：第三方API变更、依赖漏洞、云提供商中断、数据迁移问题、浏览器兼容性、扩展问题、安全漏洞
建设项目：天气延迟、材料短缺、许可问题、劳工罢工、土壤条件、成本超支、安全事件
产品发布：制造延迟、供应链中断、竞争对手发布、定价误算、市场需求低于预期、质量问题
组织变革：员工阻力、沟通中断、培训不足、预算削减、领导层变动、文化错位

按风险响应类型：

缓解（减少概率）：培训、原型制作、流程改进、冗余、质量检查、早期测试
应急（如果发生减少影响）：备用计划、保险、储备（时间/预算）、替代供应商、回滚程序
接受（不采取行动）：低评分风险不值得缓解成本，缓解后的残余风险
转移（转给他人）：保险、外包、合同（罚款条款）、保修

典型风险概况演变：

项目开始：许多中等风险（不确定性高），少数关键（缓解前）
项目中段：关键风险缓解到中等/低，新风险出现（依赖、集成）
接近完成：低风险占主导（大多数问题解决），少数高（最后一刻惊喜）
红旗：风险评分随时间增加（缓解无效，新问题出现速度超过解决）

风险评分框架

概率量表（1-5）：

5 - 几乎确定（>80%）：预计会发生，历史数据证实，无缓解措施
4 - 可能（60-80%）：很可能发生，类似项目曾出现此问题，弱缓解
3 - 可能（40-60%）：可能发生或不会发生，取决于情况，有缓解措施
2 - 不太可能（20-40%）：很可能不发生，有缓解措施，低历史先例
1 - 罕见（<20%）：非常不可能，强缓解，无历史先例

影响量表（1-5） - 根据项目上下文调整维度：

对于时间表影响：

5 - 严重：>20%延迟（例如，3个月项目延迟3周以上），错过关键截止日期，连锁延迟
4 - 主要：10-20%延迟，错过里程碑，影响依赖项目
3 - 中等：5-10%延迟，时间缓冲消耗，无外部影响
2 - 较小：<5%延迟，在冲刺/阶段内吸收，轻微时间压力
1 - 最小化：<1%延迟或无延迟，可忽略的时间影响

对于预算影响：

5 - 严重：>20%预算超支，需要新资金批准，项目可行性受威胁
4 - 主要：10-20%超支，应急储备耗尽，需要范围削减
3 - 中等：5-10%超支，应急储备部分使用，无需范围削减
2 - 较小：<5%超支，在预算灵活性内吸收
1 - 最小化：<1%超支或无预算影响

对于范围/质量影响：

5 - 严重：核心功能丢失、客户质量问题、监管违规
4 - 主要：重要功能削减、显著质量下降、客户投诉
3 - 中等：可有可无功能削减、轻微质量问题、需要内部变通方案
2 - 较小：边缘案例功能削减、外观质量问题
1 - 最小化：无范围或质量影响

复合影响（当多个维度受影响时）：

使用任何单个维度的最大值（悲观、保守）
或使用加权平均：时间表40%，预算30%，范围/质量30%

示例评分：

风险：“关键工程师在项目中期离职”

概率：2（不太可能 - 20%基于任期、满意度、保留率）
影响时间表：4（主要 - 3周延迟以入职替代、知识转移）
影响预算：2（较小 - 招聘费用、一些加班）
影响范围：3（中等 - 可能削减高级功能）
复合影响：4（取最大值：时间表影响最坏）
风险评分：2 × 4 = 8（中等）

护栏

确保质量：

主动识别风险，非被动：在问题发生前运行风险研讨会
- ✓ 在项目启动时头脑风暴风险，使用检查清单（技术、时间表、资源等）
- ❌ 只在事件发生后添加风险（被动）
具体而非模糊：“集成失败”是模糊的，“供应商API速率限制阻止迁移”是具体的
- ✓ “第三方支付网关因欺诈规则拒绝10%交易”
- ❌ “支付问题”
分离概率和影响：不要混淆“如果发生很坏”与“很可能发生”
- ✓ 小行星击中办公室：概率=1（罕见），影响=5（严重），评分=5（低优先级）
- ❌ 混淆：“这真的很坏所以必须是高优先级”（忽略低概率）
分配指定所有者，非团队：“工程团队”不负责任，“Sarah（技术主管）”是
- ✓ 所有者：Sarah（技术主管），负责监控和激活应急
- ❌ 所有者：工程团队（责任分散）
定义缓解和应急：缓解减少概率，应急处理如果发生
- ✓ 缓解：早期集成原型（减少概率）。应急：构建抽象层以快速替换（减少影响）
- ❌ 仅缓解，无备用计划
定期更新：过时的风险登记比没有更糟（虚假信心）
- ✓ 活跃项目每周评审（高/关键风险），长期项目每月
- ❌ 在启动时创建登记，从不更新（概率/影响随项目进展变化）
关闭已解决风险：不要让登记无限增长，归档缓解/无关风险
- ✓ 标记风险“已关闭”并带解决日期，移到归档部分
- ❌ 永远保留所有风险（信号噪声比下降）
立即升级关键风险：如果出现关键风险，不要等待每周会议
- ✓ 概率=5 影响=5 评分=25 → 同一天升级到高管，紧急缓解
- ❌ 等待计划评审（风险可能实现）

快速参考

资源：

快速开始：resources/template.md - 风险登记模板，包含评分表、响应规划、监控日志
高级技术：resources/methodology.md - 蒙特卡洛模拟、决策树、敏感性分析、风险聚合、挣值管理
质量检查：resources/evaluators/rubric_project_risk_register.json - 评估标准

成功标准：

✓ 识别15-30个跨类别风险（技术、时间表、资源、外部、范围、组织）
✓ 所有高/关键风险（评分≥12）有指定所有者、缓解计划和应急措施
✓ 风险评分区分（非全部评分6-9；使用完整1-25范围）
✓ 缓解和应急计划具体且可操作（非“密切监控”）
✓ 定义何时激活应急的触发器（可量化阈值）
✓ 登记定期更新（活跃项目每周，长期项目每月）
✓ 风险概况匹配项目阶段（开始时高不确定性，随时间减少）

常见错误：

❌ 识别风险太少（<10）→ 不完整风险图景，虚假信心
❌ 所有风险评分中等（6-9）→ 未区分，优先排序不清晰
❌ 模糊风险（“事情可能行不通”）→ 不可操作
❌ 未分配风险所有者 → 责任分散，缓解未发生
❌ 缓解无应急 → 无备用计划如果缓解失败
❌ 创建一次后从未更新 → 数据过时，风险演变
❌ 仅负面风险（威胁）→ 缺少机会（正面风险）
❌ 风险登记与项目计划分离 → 未集成到工作流程

何时使用替代方案：

事前分析：项目未开始时，想象失败场景（补充风险登记）
FMEA（失效模式影响分析）：制造/工程项目需要详细失效分析
蒙特卡洛模拟：当需要概率时间表/预算预测时（使用methodology.md）
决策树：当风险涉及顺序决策分支点时
情景规划：当风险是战略/长期时（市场波动、竞争对手行动）

项目风险登记与管理Skill project-risk-register