项目启动时列一份风险清单，写满二十条，然后再也没打开过——这大概是最常见的项目管理形式主义。
问题不在于"列了没用"，而在于列的方式不对：列的是所有可能的风险，而不是真正需要应对的风险；写的是风险描述，而不是应对动作；没有人负责跟进，也没有触发条件。
有效的风险管理只做三件事：识别出真正会发生的、按影响和概率排序、给高优先级的配预案。二十条压成五条，但这五条有人盯、有预案、有触发线。
一、四个识别角度
风险识别最容易漏的是"想不到的那类"。用四个固定角度扫一遍，覆盖度会好很多：
角度一：依赖别人的地方。 凡是需要外部（其他部门、供应商、客户）配合的环节，都是风险点。问一句"如果他们没按时给，我们怎么办"。
角度二：第一次做的事。 新技术、新流程、没合作过的团队。第一次做的事，工时估算普遍偏乐观 50% 以上。
角度三：单点。 只有一个人会的技能、只有一台机器、只有一个渠道。这个点出问题，整个项目停摆。
角度四：历史上出过问题的地方。 翻上几个项目的复盘记录，重复出现的问题极可能再次出现。这是最高性价比的识别来源，做法可以看项目复盘怎么做。
团队一起做识别比一个人做好得多，因为每个角色看到的风险不同。半小时的集体扫描，通常比项目经理独自想两小时覆盖得全。
二、评估：影响 × 概率
识别出来之后必须排序，否则二十条平铺着等于没排。
用两个维度打分，各分三档：
| 概率低 | 概率中 | 概率高 | |
|---|---|---|---|
| 影响大 | 关注 | 重点 | 重点 |
| 影响中 | 记录 | 关注 | 重点 |
| 影响小 | 忽略 | 记录 | 关注 |
- 重点（3–5 条）——必须配预案、指定负责人、设触发条件
- 关注——定期检查，暂不投入资源
- 记录——写下来即可，不跟进
- 忽略——不必进清单
关键是控制"重点"的数量。超过 5 条，说明要么项目本身风险过高（该考虑缩小范围），要么评估标准太松。
影响的评估要具体到后果："影响交付"太笼统，"导致交付延期两周并触发合同违约条款"才能支撑判断。
三、四种应对策略
对每条重点风险，选一种应对方式：
规避（Avoid）——改变计划让这个风险不再存在。
风险：新框架团队没用过，可能踩坑 规避：这个版本先用熟悉的框架，新框架放到下个版本做技术预研
转移（Transfer）——把风险交给更有能力承担的一方。
风险：某个模块我们做不熟，工期不可控 转移：外包给专业团队，合同里约定交付时间和违约条款
减轻（Mitigate）——降低发生概率或影响程度。
风险：关键人员离职导致项目停滞 减轻：安排第二个人参与核心模块，文档必须同步更新
接受（Accept）——承认它可能发生，准备应急方案。
风险：客户可能在中途调整需求 接受：预留 20% 的缓冲，且提前约定变更的处理流程
"接受"不等于什么都不做。 接受意味着你判断应对成本高于风险成本，但仍要准备应急方案和触发条件。
四、触发条件必须写清楚
这是风险清单里最容易缺失、也最决定成败的一栏。
没有触发条件的风险项，等于永远不会被激活——因为没人知道什么时候该行动。
写法示例：
风险：第三方接口联调延误
触发条件：对方未在 3 月 10 日前提供测试环境
应对动作：启动 Mock 数据方案，同时向双方上级升级
负责人：张三
触发条件要满足两点：可观察（有明确的时间或数值）、有提前量（触发时还来得及应对，而不是已经出事了）。
"如果延期了"不是好的触发条件，因为延期已经发生；"如果 X 日期前 Y 还没到位"才是。
五、跟踪节奏与升级机制
跟踪频率：重点风险每周检查一次，关注类每两周一次。
检查时只问两个问题：
- 概率或影响有变化吗？ 有变化就重新评级，可能升为重点或降为关注
- 触发条件到了吗？ 到了就执行预案，不再讨论
升级机制要提前约定什么情况下升级、升给谁：
- 单个风险的影响超出项目组能承担的范围
- 两个以上重点风险同时触发
- 预案执行后风险没有缓解
升级不是坏消息，是正常机制。 团队如果觉得升级等于承认失败，就会拖到无法挽回才说，这是风险管理最常见的失效方式。
六、把风险清单放进项目现场
风险清单单独存成一份 Excel，被打开的频率极低。更有效的做法是让它和项目的其他材料在一起。
在同一块画布上：
- 风险清单挂在进度图旁边——某条风险对应哪个任务、影响哪个里程碑，用连线标出来
- 用颜色标状态——红（已触发）/ 黄（接近触发）/ 绿（受控）。周会时缩小看一眼，问题分布一目了然
- 预案文档直接挂在风险项旁边——触发时不用现找
- 历史风险保留——项目结束后这份清单就是复盘素材，也是下个项目识别风险的输入
英飞·思想家支持表格、图形、文件等多种组件在同一块画布上组合，多人实时协作，各风险负责人可以自己更新状态。项目进度图的画法可以看项目进度图怎么画。
七、三个常见误区
误区一：把已知问题写成风险。 已经发生的是问题，需要立刻解决；还没发生的才是风险，需要预案。两者混在一张表里，会导致真正的风险被淹没在待办事项里。
误区二：只在启动时做一次。 风险是动态的——项目推进中会消失一些、新增一些。至少在每个里程碑重新评估一次。
误区三：风险清单只有项目经理知道。 风险应对需要执行，执行需要相关人知情。重点风险必须让对应的负责人明确知道自己在盯什么。
常见问题
风险和问题有什么区别？
风险是可能发生的，需要预案；问题是已经发生的，需要立刻解决。两者不该放在同一张表里跟踪。
风险清单列多少条合适？
清单可以长，但"重点"级别控制在 3–5 条。超过说明项目风险过高或评估标准太松。
怎么识别想不到的风险？
用四个固定角度扫描：依赖外部的环节、第一次做的事、单点依赖、历史上出过问题的地方。团队一起做比一个人做覆盖得全。
触发条件怎么写？
要可观察且有提前量。"如果延期了"不行（已经发生），"如果 X 日期前 Y 未到位"才行。
多久检查一次？
重点风险每周一次，关注类每两周一次，每个里程碑重新评估一遍全部风险。
结语
风险管理有没有效，看三件事：重点风险是不是控制在 5 条以内、每条有没有可观察的触发条件、有没有明确的负责人。
二十条没人跟的清单，价值不如五条有预案的。识别要用固定角度扫，评估要按影响乘概率排，应对要选定策略并写清触发线。做到这几点，风险清单才是管理工具而不是立项材料的附件。