字数 8873，阅读大约需 45 分钟

第43讲：钱都花哪了？——规划成本与估算成本

【老孙开篇寄语】

各位手握“钱袋子”的大管家们，大家好！

欢迎来到《2026版“软考找老孙”高项通关84讲》的 “规划篇·第一乐章·金钱帝国”。

还记得第一讲里我提到的那个 “智慧邻里” 项目吗？那个承载着“美好家园”集团从传统物业向数字化转型的“一号工程”。那时候我们还在讨论为什么要做这个项目，讨论它的战略意义。现在，项目已经立项，需求收集完了，进度计划也排得七七八八了。

就在今天上午，集团的 王总 把我叫到了他的办公室。他手里拿着我之前提交的那个漂亮的甘特图，眉头紧锁，指着最后一栏的空白处，抛出了那个最现实、最敏感、也最让他肉疼的问题：
“老孙啊，进度我看懂了，国庆节上线我也没意见。但是，这项目到底要花多少钱？1000万的预算，到底够不够？别到时候干了一半没钱了，让我去董事会挨骂。”

看着王总那双锐利的眼睛，我心里咯噔一下。我知道，很多新手PM这时候可能会慌，可能会随口说个“大概...也许...一百万吧？”
这种“拍脑袋”的回答，在职场上是自杀行为。

• • 估少了，后面没钱了，你得自掏腰包吗？项目烂尾了算谁的？
• • 估多了，董事会觉得不划算，项目直接被砍，你也就失业了。

成本管理，是一门平衡的艺术。
你不仅要算得准（估算成本），还要花得稳（制定预算），更要能在花完之前就把事办成（控制成本）。

今天，老孙将带你走进 成本管理 的世界。我们将用 “买菜做饭” 的逻辑，结合“智慧邻里”的真实场景，彻底讲透那些高大上的财务术语。
准备好你的计算器，我们要开始算账了！

一、 上节回顾与热身

1. 上节核心回顾：时间的掌控

在上一讲（第42讲），我们依然沉浸在“智慧邻里”的进度管理中。小王遇到的那些烂摊子——张三请假、服务器没到位、需求变更，我们都一一化解了。
我们学会了：

1. 1. 监控： 看着 燃尽图 那条上翘的尾巴，我们知道那是 范围蔓延，必须得治。用 SPI < 1 这个指标，我们量化了进度的落后。
2. 2. 纠偏： 面对资源冲突，我们明白了 资源平衡（牺牲时间） 和 资源平滑（保住时间） 的区别，就像在停车场里挪车位一样。
3. 3. 敏捷： 我们玩了一把 规划扑克，大家拿着斐波那契数列的牌，吵吵闹闹地把工作量估算出来了。

2. 上节课后作业精讲（深度解析与避坑指南）

上次留的三道题，那是相当有水准的。很多同学在后台留言说“做哭了”。别急，老孙这就带你一个个拆解，看看坑都在哪。

【作业1：燃尽图诊断】

• • 题目回顾： 在一个为期 10 天的迭代中，燃尽图显示前 7 天实际剩余线一直是一条水平直线（没下降），直到第 8 天才突然呈断崖式下降。请问这是什么病？怎么治？
• • 老孙大白话解析：
• • 考点定位： 这道题考的是 “燃尽图形态分析” 和 “Scrum Master 的职责”。
• • 病理分析：
• • 现象： 前 7 天水平。这就像你减肥，前 7 天体重一点没掉。这正常吗？绝对不正常。
• • 原因一（最可能）： 障碍（Impediment）未消除。比如开发环境一直没搭好，或者服务器挂了，或者是需求文档里有大坑，大家都在等产品经理确认。大家虽然都在工位上坐着，但产出是 0。
• • 原因二（次可能）： 颗粒度太粗。所有的任务都估成了“8天”。大家都在闷头干，直到第 8 天才干完提交。但这不符合敏捷“小步快跑”的原则。
• • 原因三（人性）： 学生综合征。前几天摸鱼，最后两天通宵赶工。
• • 很多同学选了“估算保守”。如果是估算保守，线会一开始就猛降（做得快），而不是水平。
• • 还有同学选了“范围蔓延”。如果是范围蔓延，线会 往上翘（工作量变多），而不是水平。

【作业2：资源优化决策】

• • 题目回顾： 关键路径上的活动 A 延期了，导致项目要晚 5 天上线。此时非关键路径上的活动 B 有 5 天的总时差。项目经理决定把做 B 的人调去支援 A。请问这是什么操作？有啥风险？
• • 老孙大白话解析：
• • 考点定位： “资源优化技术” 和 “布鲁克斯法则”。
• • 操作定性：
• • 首先，这利用了 B 的 浮动时间，把 B 的资源释放出来了，有点像 资源平滑 的思路（利用时差）。
• • 其次，把人加到 A 上，这是典型的 赶工（Crashing） 手段（用增加资源来换取时间）。
• • 所以，这是一个 混合打法。
• • 风险一： “新人上手成本”。做 B 的人懂 A 的业务吗？不懂的话，A 的人还得花时间教他。这叫 “磨合期”。
• • 风险二： 布鲁克斯法则。软件工程名言：“向一个已经延期的项目增加人手，只会让它更延期。” 为什么？因为沟通成本呈指数级上升。原本 2 个人干，沟通渠道是 1 条；现在 3 个人干，渠道变 3 条。大家光开会同步信息就花了一半时间。

【作业3：敏捷估算】

• • 题目回顾： 某团队最近三次迭代的速度分别是：20点、25点、15点。待办事项列表里还有 120 个故事点。问还需要几个迭代？下个迭代能不能加 10 个点？
• • 老孙大白话解析：
• • 考点定位： “速度（Velocity）计算” 和 “敏捷原则”。
• • 计算过程：
• • 平均速度： (20 + 25 + 15) / 3 = 20 点/迭代。这是团队目前的“真实战斗力”。
• • 剩余迭代： 120 / 20 = 6 个迭代。这很简单。
• • 答案： 绝对不能！
• • 理由： 敏捷讲究 “拥抱变化”，但也讲究 “节奏稳定”。迭代一旦开始，范围就 冻结 了。如果在迭代中间随意加塞，会打乱团队的节奏，导致燃尽图上翘，士气低落。
• • 正确做法： 把这 10 个点放到 Product Backlog（待办列表） 的最上面。等下个迭代计划会议（Planning Meeting）时，作为最高优先级处理。或者，如果真的十万火急（比如服务器炸了），那必须 置换 掉当前迭代里等量的 10 个点（未开始的任务），保持总工作量不变。这叫 “进一出一” 原则。

二、 咱们今天聊点啥？（本讲目标）

2.1 为什么你必须学好这一讲？