风险识别：把「应该没事」换成「如果发生怎么办」
项目开始前用固定维度扫一遍风险，再按影响和可能性分级，为高项准备触发条件与应对动作。
结论先行：风险清单的价值不在长度，而在每条都有触发信号、影响范围和负责人。没有应对动作的风险只是担忧。
项目推进顺利时，最容易被跳过的一步是风险识别。大家倾向于假设一切按计划走，直到某个依赖方延迟、某个接口不稳定，才临时救火。提前花一小时列风险，通常能省下后面几天的被动。
六个扫描维度
| 维度 | 要问的问题 | 典型风险 |
|---|---|---|
| 需求 | 验收标准是否清楚 | 反复改需求导致返工 |
| 资源 | 人力和预算是否到位 | 关键角色请假或离职 |
| 依赖 | 外部团队或系统是否可靠 | 接口延迟、审批卡住 |
| 时间 | 关键节点是否重叠 | 节假日、封版期冲突 |
| 质量 | 有没有验证手段 | 测试覆盖不足，问题到线上才暴露 |
| 外部 | 政策、供应商、客户 | 合规变化、供应商涨价 |
分级：影响乘可能性
用两列打分：影响指对目标、成本或声誉的损害，可能性指发生概率，各 1 到 5 分。两项相乘超过 12 的，进入重点跟踪；6 到 12 的，定期回看；6 以下的记录即可，不必投入太多精力。分级的作用是把注意力放在少数真正会伤到项目的事上。
每条风险写四件事
- 触发信号：出现什么现象说明它正在发生。
- 影响范围：会影响哪个节点、哪些人。
- 应对动作：发生时先做什么，谁来做。
- 负责人：一个人，而不是项目组。
只写可能有延期风险没有意义，因为无法判断何时该行动。写成若供应商在 11 月 10 日仍未交付样品，则启用备选供应商 B，由采购负责，才具备可执行性。
一条完整的风险记录
支付联调延迟
- 风险：支付接口联调延迟，导致上线推迟。
- 触发信号：11 月 8 日仍未拿到测试环境账号。
- 影响：灰度时间压缩到一天，回滚验证不足。
- 应对：启用备用支付渠道，先上线主流程；同时由研发负责人每天跟进对方进度。
- 负责人：研发负责人老陈。
风险会议怎么开
不要开成大家想想有什么风险的开放式讨论，容易冷场。按六个维度逐项过，每项限时三分钟，主持人记录并按分数分级。会后再补一次书面清单，请各模块负责人确认自己那几条，避免只有主持人一个人记得。
自检清单
- 每个关键依赖是否都有风险条目？
- 每条风险是否有触发信号和应对动作？
- 高分段风险是否指定了唯一负责人？
- 是否约定了下一次回看的时间？
关于乐观： 风险识别不是唱衰。把风险写出来，是为了在顺利时不必反复担心，在出事时不必临时找方案。乐观可以留在心里，清单要写实。
风险清单需要定期更新。项目进入新阶段，旧的风险可能消失，新的会出现。每周花十分钟过一遍，比一次性写很长的清单更有效。