前言

项目经理日常最痛苦的事是什么？不是加班，不是被客户怼——是今天一切都好，明天突然告诉你”供应商说接口还要三周才能给”，而你一周后就要上线。

风险管理的目的是让”意外”变得不那么意外。你没法消除所有风险，但可以在风险变成问题之前，先想好应对方案。

一、风险识别：从六个维度扫描

每次接手新项目，按这六个维度过一遍，基本能覆盖 90% 的隐患。

1. 技术风险

信号 常见风险
项目用到了团队不熟悉的技术栈 学习曲线导致延期
需要对接的第三方 API 文档不完整 联调周期远超预期
有性能指标要求但没做过基准测试 交付前才发现性能不达标
数据迁移涉及老旧系统 老系统的数据格式是”惊喜”

2. 人力资源风险

信号 常见风险
关键模块只依赖一个人 这个人离职或生病，项目停摆
团队之前没合作过 磨合期影响效率
客户方对接人同时兼了三个项目 你想找他的时候永远找不到

3. 范围风险

信号 常见风险
合同中有”满足业务需求”等模糊表述 验收标准争议
客户在招标时就换了三版需求 签完合同后大概率还会变
项目金额小但功能清单长 成本超支风险高

4. 供应商/第三方风险

信号 常见风险
选了没合作过的新供应商 交付质量不确定
供应商的交付节点是你关键路径上的环节 他们延期你就延期
硬件采购需要客户方自行进行 采购流程可能远超预期

5. 合规与安全风险

信号 常见风险
系统涉及个人信息 等保测评、数据合规
客户是金融/医疗/政府行业 监管合规要求高
使用了开源组件 许可证合规、安全漏洞

6. 外部环境风险

信号 常见风险
客户方近期有组织架构调整 关键决策人可能变化
项目周期跨年度 预算跨年可能冻结
客户行业受政策影响大 项目可能被叫停或调整方向

二、风险评估：定性就够了，不一定非要定量

对于大多数交付项目，定性评估已经足够决策。用”概率 × 影响”的矩阵：

风险等级判定

影响低 影响中 影响高
概率高 中风险 高风险 高风险
概率中 低风险 中风险 高风险
概率低 低风险 低风险 中风险

影响程度的定义：

等级 进度影响 成本影响 质量影响
高 >10% 工期延期 >15% 预算超支 核心功能不可用
中 5%-10% 工期延期 5%-15% 预算超支 功能可用但有影响
低 <5% 工期延期 <5% 预算超支 不影响使用

三、应对策略：四种选择

策略 含义 举例
规避 消除风险发生的根源 用成熟技术栈替代团队不熟悉的新技术
转移 把风险转给第三方 购买第三方维保服务，把运维风险转出去
减轻 降低风险发生概率或影响 关键模块让两个人交叉备份，降低单点依赖
接受 风险在可承受范围内，不做特殊处理 偶尔的小 Bug 不影响系统运行

四种策略的选择逻辑：

  • 高风险的 → 先考虑规避，规避不了就减轻，实在不行再接受（但要加应急方案）
  • 中风险的 → 减轻为主，部分接受
  • 低风险的 → 接受，定期复核即可

四、风险储备：给自己留条退路

时间缓冲

不要在所有任务上都加 20% 的缓冲，那样计划没法看。只在关键路径和已知高风险任务上加：

1
2
3
4
5
正常工期: 12 天
加缓冲: 
  - 风险缓冲 20%: +2.4 天
  - 不确定性缓冲 10%: +1.2 天
总估算: 16 天 (实际报 14 天，预留 2 天)

注意：上报给客户的计划中体现预留的时间——否则客户会觉得你明明有缓冲还延期。

成本储备

在项目报价中预留 10%-15% 的风险储备金，用于覆盖合同内的合理调整和不可预见的问题。这笔钱不是利润，是保险。

五、风险跟踪：不是列个表就完事了

定期复核

每周项目例会固定一个”风险复核”环节，过一遍风险登记册：

  • 哪些风险已经发生？启动应对方案
  • 哪些风险概率在上升？
  • 有没有新的风险需要列入？

风险登记册模板

编号 风险描述 概率 影响 等级 策略 应对方案 触发条件 责任人 状态
R01 第三方接口文档 3 月才给 高 高 高 减轻 先搭 Mock 环境，UI 和逻辑先走通 2 月 28 日仍无文档 技术经理 监控中
R02 关键开发人员离职 低 高 中 减轻 代码走查制度、关键模块两人交叉掌握 — PM 监控中
R03 客户需求超范围 高 中 高 减轻 严格执行 CCB 流程，合同明确范围 — PM 已发生

从问题回溯到风险

每次项目结束后做复盘时，把所有”实际发生的问题”回溯一遍：哪些问题在发生前有预警信号？为什么没有提前识别为风险？把这个发现补充到项目的风险检查清单里。久而久之，你的风险识别能力会明显提升。

风险管理不是为了做一个漂亮的表格给领导看，而是让你在被问”如果 XX 发生怎么办”时，能拿出一个早就想好的答案。