字数 12371，阅读大约需 62 分钟

第56讲：项目的“防火墙”——规划与识别风险

【老孙开篇寄语】

各位“拆弹专家”和“预言家”们，大家好！

欢迎回到《2026版“软考找老孙”高项通关84讲》。

上一讲，我们搭建了沟通的“神经网络”，确保信息畅通无阻。大家都觉得：“好了，现在人和信息都到位了，项目肯定能顺风顺水了吧？”

呵呵，年轻人，图样图森破。
墨菲定律 告诉我们：“凡是可能出错的事，就一定会出错。”

昨天，我路过开发组工位，听到张三在吹牛：“放心吧老大，这套代码稳如老狗，绝对没有 Bug！”
我心里“咯噔”一下。作为一个二十年的老兵，我闻到了 “风险” 的味道。
果然，今天早上，我们采购的智能门禁硬件厂商突然发公告说：“因芯片短缺，发货推迟三个月。”
张三傻眼了：“完了，硬件不到位，我的代码没法联调啊！”

这就是 风险 (Risk)。它像潜伏在暗处的狙击手，随时准备给你的项目致命一击。
很多项目经理（PM）是“救火队长”，哪里着火救哪里，每天累得像条狗。
而高明的 PM 是 “防火专家”，在火还没烧起来之前，就把隐患掐灭了。

今天，我们要开启 第15章 项目风险管理 的大门。我们要学会用“天眼”去扫描未来，把那些还没发生的“雷”，一个个挖出来，造册登记。
记住老孙的一句话：“没有风险的项目是不存在的，只有对风险视而不见的项目经理。”

一、 上节回顾与热身

1. 上节核心回顾：沟通管理的“任督二脉”

在上一讲（第55讲），我们打通了项目的“任督二脉”。

2. 上节课后作业精讲（深度复盘）

上节课的作业看似简单，实则暗藏玄机。很多同学在计算渠道数时掉进了陷阱，在选择沟通方法时过于教条。来，老孙带大家进行深度复盘。

【作业1：沟通渠道爆炸案】

• • 题目回顾： 原有 6 人，新招聘 4 人。求现在的渠道总数？增加了多少条？
• • 深度解析与数学陷阱：
  这道题考的是 “非线性增长” 的概念。
• • 老孙点拨：
• • 惊人的结论： 人数只增加了 66%（从6到10），但沟通渠道却增加了 200%（从15到45）！这就是为什么“人多力量大”在软件开发中往往不成立，反而是“人多嘴杂效率低”。
• • 管理启示： 贝佐斯的“两个披萨原则”（团队人数不要超过两个披萨能喂饱的数量）就是为了控制 N 的大小。作为 PM，当团队超过 10 人时，必须进行 “分层管理”，把大网拆成几个小网，否则你会被沟通成本拖死。
1. 1. 计算现状： 现在的总人数 人。
• • 条。
2. 2. 计算过去： 原来 人。
• • 条。
3. 3. 计算增量： 条。

【作业2：沟通方法实战】

• • 场景1：通知全公司 5000 人新考勤制度。
• • 正解： 推式沟通 (Push)。
• • 理由： 受众极广，信息标准化，且具有强制性。不需要每个人都回复“收到”，只需要确保发送到位。
• • 避坑： 千万别用“拉式”（发在内网等大家自己看），因为肯定有人不看，到时候迟到了赖你没通知。必须群发邮件或钉钉全员通知。
• • 正解： 交互式沟通 (Interactive)。
• • 理由： 这是一个复杂、模糊且容易产生分歧的话题。需要大量的实时讨论、澄清、甚至争论。
• • 避坑： 别发邮件吵架。邮件一来一回要几天，而且冷冰冰的文字容易产生误解。直接拉进会议室，甚至站在白板前画图，效率最高。
• • 正解： 拉式沟通 (Pull)。
• • 理由： 信息量巨大（100个文档），受众广泛但需求不一（有人想看数据库，有人想看前端）。
• • 避坑： 别用“推式”（把100个文件打个包群发）。这会把大家的邮箱撑爆，而且以后更新版本很麻烦。上传到 Wiki 或知识库，发个链接即可。