# 项目风险怎么找、怎么排：从依赖和假设里翻，用概率乘影响决定先处理谁

把工期背后没说出口的前提翻成风险清单，打分排序，再给前几条配上能动手的动作

> 风险管理 · 进度与排期 · 项目管理基础 · 约 8 分钟 · 10 月 28 日

## 本篇要点

1. 风险还没发生，问题已经发生：前者去做准备，后者去处理，不要记在同一张清单里。
2. 一条能用的风险要写成原因、事件、影响三个部分；写不出影响，就没法打分也没法派人。
3. 找风险不必靠灵感，按依赖、假设、外部条件三条线索依次扫一遍即可。
4. 依赖里软逻辑最容易被忽略，外部依赖只能盯，关键路径上的活动天然风险更高。
5. 排期里每句没说出口的前提都是假设，配上验证人和验证日期后，往往一个电话就能消掉一条大风险。
6. 排序用概率乘影响，但打分前必须先约定分档标准；多人各打一遍，分差大说明理解不同。
7. 乘法只用来排序；不可逆的损失即使分数低，也要单独处理。
8. 排在前面的风险要落成回避、减轻、转移、接受、上报中的一项具体动作，其中转移只转财务后果，不转责任。
9. 每条风险要有触发条件、责任人和检查日期，应对动作带来的二次风险要重新进清单。
10. 清单管不到真正的意外，小项目一页纸够用，每个里程碑前重扫一次。

---

上一个篇文章把日期算出来了：3 月 18 日上线切换。表上每格都有工期，看起来能交出去。但每个工期后面都压着几句没说出口的话——“小李这两周没有别的活”“供应商接口和去年一样”“客服能抽四个人”。写计划时这些话被当成真的，没有人验证过。

风险管理的起点就在这儿：把这些默认成立的前提翻出来，看哪条不成立时会伤到项目。下面用同一个客服系统迁移项目，把找风险、排优先级、配动作走一遍。

如果你手上有项目，先别往下读：给排期表每格的工期补一句没说出口的前提，凑五条，再对照下文。

## 一、风险要写成一件具体的事

已经发生、正在耽误你的叫问题（issue），处理就行；还没发生、一旦发生会伤到目标的叫风险（risk），为它做准备。两者混在一张清单里，开会就一半时间救火、一半时间空想。

一条能用的风险要写三部分：什么条件（原因）、会发生什么（事件）、伤到什么（影响）。PMBOK 识别风险的实践里叫 cause–risk–impact [1]。

“数据迁移有风险”不能算一条：没法打分，也没法派人。改成：“供应商 3 月要上接口新版本（原因），可能改订单字段名（事件），映射表得重写，迁移推后两到三周，挤掉上线前试跑（影响）。”原因指出哪一步还有余地，影响决定它值几分。

## 二、线索一：依赖，谁卡谁就会断

上一个篇文章讲过三种依赖：工作性质决定的硬逻辑、团队习惯形成的软逻辑、等外部交付的外部依赖[上一篇](https://pangzhengboyin.com/articles/dependencies-and-milestones-before-dates-58d44179)。

硬逻辑断不了顺序，但会放大延迟——“试跑通过才能正式迁移”，试跑晚三天，迁移就晚三天。软逻辑平时表现为“我们一直这么干”，人手一紧就塌，比如“变更要走两次评审”，评审人一出差就成阻塞。外部依赖不在你手里，只能盯、不能安排。

还有一条：处在最长那条链上的活天然风险更高，因为关键路径上的活动一延迟，项目终点就跟着延 [2]。所以先扫那条链。

客服项目扫出三条：脚本只有小李会写，他 3 月可能被别的项目借走；试跑要用的测试环境，运维 2 月底要收回去，何时还回来没定；正式迁移那晚要供应商工程师在线值守，他们周末值班须提前申请。

## 三、线索二：假设，工期背后没说出口的前提

工期估三天，背后是“这个人这三天没别的事”；培训估两小时，背后是“主管同意抽四个人”。做法不是让假设消失，而是写下来，每条配一个人、一个验证日期。这在 PMBOK 里对应假设日志（assumption log）：假设内容、谁验证、什么时候验证完、结果如何 [3]。

它的价值在于验证成本常常极低：打个电话问供应商“3 月的版本会改字段吗”，可能就消掉一条十几分的风险；不问，它就一直躺在计划里，等 3 月才炸。

客服项目的假设是：小李 2 月底到 3 月中没别的项目占用；新版本与去年文档一致；客服能抽四个人，每人每天两小时；客户告知函不需额外法务审批。

逐条问一句“如果这条不成立，会怎样”，答案具体并且真能伤到目标的留下，答案是“那就麻烦一点”的划掉。

## 四、线索三：外部条件

供应商、客户、监管要求、公司层面的其他安排、季节档期都属于这一类。这类风险你改不了，只能改自己的准备程度，所以归宿通常是上报或转移，而不是“我再努力一点”。比如任何接入客户数据的系统上线前都要过信息安全评审，排期由安全部门定——不是你的能力问题，但你得提前知道最早什么时候排得上，赶不上 3 月 18 日时能做什么。

## 五、排序：先定尺子，再做乘法

十几条风险，全处理等于没处理。常见做法是给每条打两个分——发生的可能性（概率）和一旦发生对目标的伤害（影响），相乘。乘法的意义不是算得准，而是把“很少见但致命”和“天天见但无所谓”分开 [4]。

打分前必须先把尺子说清楚：一个人心里的“影响 4 分”是延期三天，另一个人理解成延期一个月，分数放一起就没意义。尺子自己定，只要全项目用同一把。下面是示例，不是行业标准：

| 分 | 概率（示例） | 影响（按延期计） |
| --- | --- | --- |
| 1 | 不到 10% | 一周以内 |
| 2 | 10%–30% | 一到两周 |
| 3 | 30%–50% | 两到四周 |
| 4 | 50%–70% | 一到两个月 |
| 5 | 70% 以上 | 两个月以上 |

影响不一定按延期算。这个项目最怕客服把工单分错，影响就该换成“多少比例的工单会分错、多久修好”。选哪把尺子，取决于项目最不能失去什么。

两个细节：同批风险找两三个人各打一遍，分差大的那几条往往说明大家对这件事的理解根本不同，正好当场对齐；分数会变，每月或每个里程碑前重打一次 [4]。

客服项目的结果（分数 = 概率 × 影响）：

| 编号 | 风险 | 概率 | 影响 | 分数 |
| --- | --- | --- | --- | --- |
| R1 | 小李被别的项目借走一个月，脚本无人接手，迁移推两个月 | 3 | 5 | 15 |
| R2 | 供应商 3 月改接口字段名，映射表重写，迁移推两到三周 | 4 | 3 | 12 |
| R3 | 信息安全评审排期靠后，赶不上上线日 | 3 | 4 | 12 |
| R4 | 测试环境晚还两周，试跑只剩两天，上线顺延一个月 | 2 | 4 | 8 |
| R5 | 客服抽不出人，培训缩水，上线后一周工单错分率高 | 4 | 2 | 8 |
| R6 | 正式迁移中途失败且无回滚，客户数据损坏 | 1 | 5 | 5 |
| R7 | 培训材料要改两页 | 5 | 1 | 5 |

注意 R6：分数只有 5，但属于“一旦发生就没法补救”的那一类，要放在分数之外单独处理——迁移前做全量备份、演练一次回滚，并把这一步排进正式迁移的紧前工序。乘法只用来排序，不是判决。

## 六、给前三条配动作

小项目处理前三条就够了，多了没人执行。常见五种应对：回避、减轻、转移、接受、上报 [5]。

- **回避**：改方案，让这件事没有发生的机会，代价是功能或成本。不做自定义字段映射、改用供应商的标准导入工具就是回避——风险没了，客户要的那几个字段也没了。
- **减轻**：不动方案，降概率或降后果。让小李把脚本写成第二个人也能跑、并结对走一遍，是降概率；提前两周用真实数据在测试环境试跑一次，是降后果。
- **转移**：把后果转给别人，一般靠合同或保险，通常要花钱。转移的是财务后果，不是责任——供应商赔你工时，上线延误还是你向老板解释 [6]。可以写进合同的是：“接口变更需提前十个工作日书面通知，返工工时由供应商承担。”
- **接受**：写下来并配触发条件，低分项进观察清单定期看。主动一点的接受会留缓冲或备好应急计划，比如给正式迁移留三天余量 [6]。
- **上报**：超过你权限或预算的，交给有权限的人，并指定接收人。安全评审排期属于这一类。

常见的呈现方式，是按概率和影响的高低组合画成四象限，每格对应一种策略 [7]：

![四象限图：按概率和影响的高低组合，分别对应回避、减轻、转移、接受四种威胁应对策略](https://4squareviews.com/wp-content/uploads/2012/08/081512_2347_2.png?w=468)

有三样东西容易漏。**触发条件**要写成“供应商邮件里第一次提到 3.1 版本”，比“关注供应商动态”有用得多，因为别人一看到就能提醒你 [6]。**二次风险**指应对动作自己带来的新风险——改用标准导入工具消掉了字段映射，同时冒出“客户自定义字段丢失导致投诉”，这条要重新进清单打分 [6]。**责任人**是每条风险一个人名加下次检查的日期，没有名字的清单会烂在硬盘里。

## 七、怎么算做完

三条检查：每条能不能读出原因、事件、影响？前三条有没有本周就能动手的动作（“持续关注”不算动作）？有没有低分但不可逆的条目？

边界也说清：真正没人想到的意外列不进清单，只能靠缩短交付周期、留缓冲去吸收；十几个人的小项目不必搞正式登记表，一页纸、每周看一眼就够。清单从写出来那天就开始过期，里程碑前重扫一遍，比一次写得很厚更有用。

这份清单做不到让项目不出事。它让你在 2 月底就知道该给谁打电话、该问哪一句，而不是在上线前一晚才发现测试环境还没还回来。

## 思维导图

```mermaid
flowchart LR
  A["三条线索"] --> A1["依赖：硬逻辑、软逻辑、外部依赖"]
  A --> A2["假设：工期背后的前提"]
  A --> A3["外部条件：供应商、评审、档期"]
  A1 --> B["写成原因—事件—影响"]
  A2 --> B
  A3 --> B
  B --> C["先定分档标准，再打概率乘影响"]
  C --> D["前三条：回避、减轻、转移、接受、上报"]
  C --> E["不可逆项：不看分数直接处理"]
  D --> F["触发条件、责任人、检查日期"]
  F --> G["里程碑前重扫，二次风险回流"]
```

## 术语表

- 风险与问题：还没发生的叫风险，去做准备；已经发生、正在耽误事的叫问题，去处理。
- 三段式风险描述：把一条风险写成“原因—事件—影响”，原因指出哪一步还能动，影响决定它值几分。
- 假设日志：把排期和估算里默认成立的前提写下来，每条配验证人和验证日期，让隐性前提变成可检查的条目。
- 概率—影响打分：给可能性和伤害各打一分再相乘，用来把“少见但致命”和“常见但无关痛痒”分开排序。
- 威胁应对策略：回避（改方案避开）、减轻（降概率或降后果）、转移（把财务后果转给别人）、接受（写下来配触发条件）、上报（交给有权限的人）。
- 触发条件：一个具体的、别人看到就能提醒你的信号，说明某条风险即将发生。
- 二次风险：应对措施本身引入的新风险，要重新进清单打分。

## 来源

1. [Identify Risks 实践要点 — 原因—事件—影响的风险陈述，风险与已发生问题的区分，以及贯穿项目周期反复识别](https://hksmnow.com/definitions/pmbok/identify-risks.php)
2. [PMBOK 第 6 版 11.2 Identify Risks 输入说明 — 关键路径活动为何天然风险更高，假设日志为何是风险来源](https://4squareviews.com/2018/07/13/6th-edition-pmbok-guide-process-11-2-identify-risks-inputs/)
3. [Assumption Log 模板 — 每条假设要有责任人和验证日期，很多假设本身就是风险](https://www.projectmanagementdocs.com/template/project-documents/assumption-log/)
4. [Probability and Impact Assessment 模板 — 1–5 分档、分数等于概率乘影响、多人打分、定期重评](https://projects101.org/resources/pmbok_templates/2_Planning_Templates/2.34_Probability_and_Impact_Assessment_Template.pdf)
5. [PMBOK 第 6 版风险管理章节 — 回避、转移、减轻、接受、上报等威胁应对策略](https://www.pmi-centralitaly.org/wp-content/uploads/2019/06/PMBoK_Risk_03072018.pdf)
6. [Risk Planning 章节 — 主动与被动接受、应急储备、触发条件、二次风险，以及转移不等于转移责任](https://doi.org/10.1002/9781394222094.ch10)
7. [概率与影响高低组合到四种威胁策略的对应关系 — 正文四象限配图出处](https://4squareviews.com/2013/08/09/5th-edition-pmbok-guide-chapter-11-risk-strategies/)

---

原文：https://pangzhengboyin.com/articles/finding-and-ranking-project-risks-dc2c461d

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具：每篇 5–10 分钟，边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com