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

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

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

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

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

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

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

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

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

上一个篇文章讲过三种依赖：工作性质决定的硬逻辑、团队习惯形成的软逻辑、等外部交付的外部依赖上一篇。

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

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

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

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

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

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

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

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

四、线索三：外部条件

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

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

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

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

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

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

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

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

六、给前三条配动作

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

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

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

四象限图：按概率和影响的高低组合，分别对应回避、减轻、转移、接受四种威胁应对策略

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

七、怎么算做完

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

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

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