项目风险评估怎么做？概率影响矩阵、三种方法与实例

项目风险评估要把“担心会出问题”变成具体记录：什么条件下可能发生什么事件，会影响哪个项目目标，有多大可能和影响，应由谁准备应对。先用一致口径排序，再为重点风险确定响应、触发条件和复核时间。风险矩阵帮助讨论优先级，但不能预测未来，也不能替团队作出接受风险的决定。

可以先在Boardmix 模板社区查找风险评估矩阵，把团队想到的风险放到同一画布，再按下面的方法补齐条件、影响与责任。

1. 什么是项目风险，和已经发生的问题有什么区别？

项目风险是可能影响项目目标的不确定事件或情况，既可能带来损失，也可能形成机会。例如，外部测试账号“可能延迟获批”是风险；到了约定日期仍未获批，已经造成联调阻塞，则需要作为当前问题处理，并继续评估由此产生的新风险。

风险可能出现在项目生命周期的不同阶段，计划再详细也无法消除全部不确定性。评估的目的，是让团队在重要决定前理解暴露程度和应对代价。不是把所有可能性写进表格后，就宣称项目安全。

也不要只看负面事件：如果合作方可能提前交付可复用组件，团队可以评估是否有机会缩短测试准备时间。威胁与机会应分别说明影响方向，不宜把它们混在一张“损失高低”表中相互抵销。需要了解更完整的过程，可结合项目风险管理的识别、响应与跟踪步骤阅读。

2. 如何进行项目风险评估？先统一概率和影响口径

先写清风险，再评估概率与影响，最后确定响应。PMI 的协作式风险规划方法强调根据项目目标与容忍度定义矩阵，并用风险登记记录评估、责任和后续复核。图的颜色和打分范围不是放到任何项目都有效的统一标准。

2.1 识别风险：把原因、事件和影响分开

邀请实施、业务、测试及相关供应方分别提出潜在威胁和机会。对照项目范围、交付物、约束及以往问题检查，避免只关注某个部门最熟悉的风险。可以沿着WBS 工作包逐项提问：“这份成果可能因什么条件无法按要求交付？”

将“外部系统不稳定”改成更具体的记录：“由于联调环境仍待审批，测试账号可能晚于联调开始日获批，导致核心接口验收延后。”这句话分清了已知条件、尚未发生的事件和对目标的影响。已发生的阻塞、纯粹的猜测和缺少信息的假设，也要分别标注。

2.2 确定概率：说明判断依据与时间范围

概率回答“在所评估的时间范围内，这件事有多大可能发生”。可以先用低、中、高做定性判断，同时记录根据：历史相似项目、当前审批状态、供应方承诺或专业人员意见。没有可靠样本时，不要把“中等可能”伪装成精确的 57%。

本例只评估“本轮上线前”的风险。如果评估范围变成未来一年，发生条件与概率就可能不同。不同成员给出不同判断时，应记录分歧和待补资料，不必为了让矩阵整齐而强行平均。

制作风险矩阵时，先在横轴与纵轴旁填写每一档的具体含义，再放置风险，图中的位置才具有可比较性。

2.3 确定影响：先选项目目标，再判断严重程度

影响回答“如果发生，会对交付日期、预算、质量或范围造成什么后果”。同一事件可能对进度影响小，却对数据安全或关键验收影响很大。应分别写清，不能只给一个没有解释的总分。

例如，一个试用系统上线项目，可以先约定：延迟不超过 1 个工作日为低影响，延迟 2 至 3 个工作日为中影响，延迟 4 个工作日及以上或错过已承诺的验收窗口为高影响。这只是演示尺度，不是行业标准；涉及安全、合规或关键质量底线的情况，需单独列为不可轻易接受的约束。

风险矩阵的四种组合可以这样理解，具体方向、颜色和处置阈值以团队图例为准：

• 高影响、高概率：通常优先讨论响应，明确资源和决定人。
• 高影响、低概率：不能因概率低就忽略；评估预防、应急和承受能力，必要时升级决定。
• 低影响、高概率：关注重复发生后的累积影响，考虑通过流程改进减少频繁中断。
• 低影响、低概率：可进入观察清单，但仍记录复核条件，不等于永远不用处理。

颜色仅辅助识别。无论使用三档还是五档矩阵，都要同时显示文字等级，并给相似风险使用相同口径。概率与影响等级相乘可以作为内部排序方法，但等级数字不是实际损失，也不宜在不同项目之间直接比较。

2.4 确定响应：不能只写“加强沟通”

针对重点威胁，可以考虑避免风险暴露、降低发生可能或影响、转移适当责任，或者在知情基础上接受并准备应急动作。选择哪种响应，取决于成本、可行性和项目的风险容忍度。转移责任也不代表项目团队完全没有后续责任。

把“加强沟通”改成可检查动作，例如“接口负责人在联调前 5 个工作日确认测试账号申请状态；若到前 3 个工作日仍无批准时间，向项目负责人升级，并评估备用测试方案”。期限、触发条件与批准人明确之后，措施才可执行。

2.5 定期复核：重新评估响应后的剩余风险

风险登记不应只在立项时填写一次。每逢关键交付、外部条件变化或响应动作完成，重新检查概率、影响和应对效果。措施可能降低某种风险，也可能引入另一种限制；例如备用测试环境可提前验证部分功能，却不能证明正式环境联调已经通过。

3. 项目风险评估表示例：从矩阵走到责任与行动

下面以“试用系统上线前评审”为演示场景，列出三条风险。低、中、高为假设的团队判断，用于展示字段填写，不是统计预测或实际客户数据。

R1 和 R3 都可能影响验收窗口，即使 R3 概率较低，也不该仅凭矩阵颜色略过。排序之后，还需要为重点项补全执行细节。以 R1 为例：

• 责任人：接口负责人跟进账号；项目负责人决定是否调整联调与验收安排。
• 当前响应：确认审批材料是否完整，取得明确的预计批准时间，检查备用方案能覆盖哪些测试。
• 触发条件：联调前 3 个工作日仍没有可确认的批准时间，立即提交影响说明，而不是等到联调当天。
• 应急边界：备用方案只验证已注明的功能；正式接口与真实权限仍需单独验收。
• 复核记录：写明检查日期、账号状态、尚未覆盖的测试和下一次检查人。没有正式联调结果时，不把风险标为已消除。

在 Boardmix 上，可以把矩阵、风险详情和待确认资料放在同一画布。团队成员在风险节点旁补充事实与意见，会议结束后将已确认动作同步到团队实际使用的任务跟踪方式。白板让讨论更连贯，执行仍需要责任人持续跟进。

4. 三种分析方法：蝴蝶结、德尔菲和决策树怎么选？

矩阵用于初步排序；当某条风险需要进一步理解原因、综合专业判断或比较应对方案时，可以分别选用下面三种方法。

4.1 蝴蝶结分析法：检查原因与后果之间的控制

蝴蝶结分析法（Bow-tie Analysis，BTA）围绕一个关键事件展开：左侧放可能导致它的威胁和预防控制，右侧放可能后果及减轻后果的控制。英国民航局的 Bowtie 说明还强调控制可能失效的条件。不要只画原因和后果，却漏掉每条路径上的控制及其有效性。

以 R1 为例，中间事件为“联调开始时测试账号不可用”；左侧可以放申请资料缺失、审批排期未确认等原因，分别对应资料检查和提前确认；右侧放测试延后、验收受阻等后果，再标出调整测试顺序、申请协调等响应。每个控制都应有责任与检查方式。

在 Boardmix 画布上用图形和连接线区分原因、事件与控制，在控制旁补充说明。颜色可以辅助扫描，不能替代文字标签，也不能证明控制实际有效。

4.2 德尔菲技术分析法：在不充分信息下组织专业判断

德尔菲法也称专家调查法。它不是把专家召集到一起自由讨论就结束；经典做法通过匿名、分轮征询和反馈汇总，让参与者独立判断，再根据其他意见重新考虑。RAND 的德尔菲方法指南说明了这种结构化征询的基本特点。

1. 确定同一个待判断问题，向参与者提供一致的背景、范围和资料。
2. 独立收集判断与理由，避免第一轮意见被职位高或表达强势的人带动。
3. 由组织者汇总并去除个人身份，反馈意见分布和主要理由，而不只给一个平均数。
4. 再轮询问是否需要调整判断，记录仍存在的分歧与适用条件。

专家选择、题目设计和信息质量都会影响结果，形成共识也不等于预测必然正确。涉及匿名征询时，不应让成员在带实名光标的共用画布上直接公开首轮答卷；可以先通过符合匿名要求的方式收集，再把脱敏汇总放入白板讨论。

用流程图列出各轮征询和反馈安排，并标注匿名收集方式、参与标准和结束条件；图中只展示去标识化的汇总，不展示能够反推出个人身份的回答。

4.3 决策树分析法：比较备选响应的条件与结果

决策树适合在多个方案之间作选择：先画决定节点，再列方案可能遇到的事件、概率和后果。可以比较不同路径的期望成本或收益，但前提是概率、成本口径及分支关系合理，不能把估计当确定结果。

例如，对 R1 可以比较“等待原环境”与“先用备用环境验证部分功能”，把新增准备成本、延期可能和仍需完成的正式验收分别放在对应分支。期望成本较低的方案也可能违反验收或安全要求，这类硬约束要先检查，再比较数值。

需要符号和倒推计算方法时，可继续阅读决策树的节点、概率和计算示例，再把当前风险的备选应对画成分支。Boardmix 用于绘制与协作讨论，专业定量模型的计算和验证应使用适当方法，不能仅靠图形判断方案最优。

5. 评估完成后，怎样把风险带入项目执行？

项目风险评估的交付物不只是一个彩色矩阵，还应包含风险登记、优先级理由、责任人、响应动作和下一次检查安排。将重要响应纳入项目计划，确认所需时间与资源；措施未完成、条件未消失时，不因开过一次会议就关闭风险。

结束评审前，请另一位成员随机选一条风险，确认能回答：可能发生什么？影响哪个目标？判断依据是什么？谁在何时做什么？条件变化后如何重新评估？答不清的字段应当继续补齐。

接下来可以进入 Boardmix 创建团队风险评估画布，将风险矩阵、关键风险详情和响应安排放在一起。先完成几条具体、可跟进的记录，再逐步扩展；比堆满没有责任和条件的风险词条更有帮助。