# 项目风险登记册 ## 目录 1. 目的 2. 何时使用 3. 它是什么？ 4. 工作流程 5. 常见模式 6. 风险评分框架 7. 护栏 8. 快速参考 ## 目的主动识别、评估、优先排序和监控项目风险，以减少意外发生的可能性，做出明智的决策，并确保利益相关者了解不确定性。将模糊的担忧（“这可能行不通”）转化为可操作的风险管理（概率×影响分数、指定所有者、具体缓解措施、可衡量的触发因素）。 ## 何时使用 **在以下情况下使用此技能：** * **项目启动**：在重要工作开始之前建立风险基线 * **高度不确定性**：新技术、不熟悉的领域、复杂的依赖关系、监管限制 * **利益相关者压力**：高管/董事会希望了解“可能出现问题的地方” * **关键路径问题**：延迟、依赖性或单点故障威胁着时间表 * **门审查**：季度签到、里程碑审查、通过/不通过决策需要风险评估 * **事件响应**：发生重大问题，需要识别相关风险以防止再次发生 * **投资组合管理**：比较多个项目的风险状况以进行资源分配 * **变更请求**：范围/时间表/预算变更需要重新评估风险 **常见触发因素：** *“这个项目最大的风险是什么？” *“什么可能导致我们错过最后期限？” *“我们对这个估计/计划有多大信心？” *“如果 X 失败，我们的后备计划是什么？” *“什么依赖关系会阻碍我们？” ## 这是什么？ **项目风险登记册**是一份动态文件，跟踪所有已识别的风险： 1. **风险识别**：可能会出现什么问题（威胁）或比预期更好（机会） 2. **风险评估**：概率（可能性有多大？）×影响（如果发生有多坏/好？）= 风险评分 3. **风险优先级**：首先关注高分风险（红色/高），监控中（黄色），接受低（绿色） 4. **风险所有权**：指定负责监控和缓解的个人 5. **风险应对**：缓解（降低概率）、应急（减少发生时的影响）、接受（不采取任何措施） 6. **风险触发因素**：风险正在发生的预警指标（启动应急措施的时间） 7. **风险监控**：定期更新（状态变化、新风险、退休风险） **风险矩阵（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)** ：接受或最低限度缓解，季度审查 **示例：软件迁移项目** 风险识别 |风险|问题 |影响 |分数 |业主|缓解措施 |意外事件 ---|---|---|---|---|---|---|--- 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：定期监控和更新** 每周（活跃项目）或每月（较长项目）审查风险登记册。随着环境变化更新概率/影响、添加新风险、消除已关闭的风险、跟踪缓解进度。请参阅 Guardrails 以监控节奏。 ## 常见模式 **风险类别（用于头脑风暴）：** * **技术风险**：技术故障、集成问题、性能问题、安全漏洞、技术债务、复杂性被低估 * **进度风险**：依赖性延迟、估计错误、范围蔓延、资源不可用、关键路径受阻 * **资源风险**：关键人员离职、技能差距、预算超支、供应商/承包商问题、设备不可用 * **外部风险**：监管变化、市场变化、竞争对手行为、经济衰退、自然灾害、供应商破产 * **范围风险**：需求不明确、优先事项不断变化、利益相关者意见不一致、镀金、任务蔓延 * **组织风险**：缺乏行政支持、优先事项相互竞争、资金不足、组织变革、政治冲突 **按项目类型：** * **软件项目**：第三方 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（技术主管），负责监控和启动应急措施 * ❌ 业主：工程团队（责任分散） 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） * **决策树** ：当风险涉及具有分支点的顺序决策时 * **情景规划**：当风险具有战略性/长期性时（市场变化、竞争对手行动）

项目风险登记册

包含技能