project-risk-register

项目风险登记表

目录

1. 工作流
2. 常见模式
3. 风险评分框架
4. 防护措施
5. 快速参考

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

Impact →     1         2         3         4         5
Prob ↓    Minimal   Minor   Moderate  Major   Severe

5 High   │ Medium │ Medium │  High  │  High  │ Critical│
         │   5    │   10   │   15   │   20   │   25    │
4        │  Low   │ Medium │ Medium │  High  │  High   │
         │   4    │    8   │   12   │   16   │   20    │
3 Medium │  Low   │  Low   │ Medium │ Medium │  High   │
         │   3    │    6   │    9   │   12   │   15    │
2        │  Low   │  Low   │  Low   │ Medium │ Medium  │
         │   2    │    4   │    6   │    8   │   10    │
1 Low    │  Low   │  Low   │  Low   │  Low   │ Medium  │
         │   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% 的数据进行迁移试点	延长时间线，缩减范围

工作流

复制此清单并跟踪进度：

Risk Register Progress:
- [ ] Step 1: Identify risks across categories
- [ ] Step 2: Assess probability and impact
- [ ] Step 3: Calculate risk scores and prioritize
- [ ] Step 4: Assign owners and define responses
- [ ] Step 5: Monitor and update regularly

步骤 1：识别各类别的风险

使用结构化类别（技术、进度、资源、外部因素、范围）集思广益，找出可能出错的情况。类别清单请参阅常见模式。登记表结构请使用 resources/template.md。

步骤 2：评估概率和影响

为每项风险评定概率（1-5：从罕见到几乎确定）和影响（1-5：从轻微到严重）。请相关领域专家参与，确保评估准确。定义请参阅风险评分框架。

步骤 3：计算风险分数并确定优先级

为每项风险计算概率 × 影响。在风险矩阵（5×5 网格）中标示各项风险，以直观呈现风险概况。优先针对严重和高风险采取缓解措施。Monte Carlo 模拟等高级技术请参阅 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（中）

防护措施

确保质量：

1. 主动识别风险，而非事后应对：在问题发生前召开风险研讨会

   • ✓ 在项目启动时集思广益，使用检查清单（技术、进度、资源等）
   • ❌ 仅在事故发生后才添加风险（被动应对）

2. 具体明确，避免含糊：“集成失败”很含糊，“供应商 API 速率限制阻碍迁移”则很具体

   • ✓ “第三方支付网关因欺诈规则拒绝 10% 的交易”
   • ❌ “支付问题”

3. 分别评估概率和影响：不要将“发生后果很糟”与“很可能发生”混为一谈

   • ✓ 小行星撞上办公室：概率 = 1（罕见），影响 = 5（严重），评分 = 5（低优先级）
   • ❌ 混为一谈：“这件事后果很严重，所以优先级一定很高”（忽略了发生概率低）

4. 指定具体负责人，而非团队：“工程团队”不承担明确责任，“Sarah（技术负责人）”则承担明确责任

   • ✓ 负责人：Sarah（技术负责人），负责监控并启动应急方案
   • ❌ 负责人：工程团队（责任分散）

5. 同时制定缓解措施和应急方案：缓解措施降低发生概率，应急方案则在风险仍然发生时应对

   • ✓ 缓解措施：尽早制作集成原型（降低概率）。应急方案：构建抽象层，以便快速替换（降低影响）
   • ❌ 只有缓解措施，没有备用方案

6. 定期更新：过时的风险登记册比没有风险登记册更糟（会造成虚假的信心）

   • ✓ 活跃项目每周审查一次（高/严重风险），周期较长的项目每月审查一次
   • ❌ 在项目启动时创建登记册后便从不更新（项目推进过程中，概率和影响都会变化）

7. 归档已关闭的风险：不要让登记册无限增长，应归档已缓解或不再相关的风险

   • ✓ 将风险标记为“已关闭”，注明解决日期，并移至归档部分
   • ❌ 永久保留所有风险（信噪比会下降）

8. 立即上报严重风险：出现严重风险时，不要等每周会议再处理

   • ✓ 概率 = 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）
• 决策树：风险涉及带有分支节点的顺序决策时
• 情景规划：风险具有战略性或长期性时（市场变化、竞争对手行动）