预算固定的项目，用瀑布开发最稳

去年年底，我接手了一个政府数字化平台的交付项目。合同金额 380 万，工期 11 个月，需求文档在签合同前就已经评审了三轮。甲方信息中心主任在启动会上说了一句让我记到现在的话：“王工，我们不求你做出花来，但求你别超预算、别超工期，到点能验收。”

当时团队里有两位刚从互联网大厂跳过来的开发骨干，私底下找我聊，说想用 Scrum 跑迭代，每两周一个 Sprint，快速交付、快速反馈。我反问了一个问题：“如果跑到第三个 Sprint 的时候，甲方突然说某个审批流程要改，而这个改动会影响前面已经交付的两个模块，多出来 80 人天的工作量，这 80 人天的钱从哪出？”

他们都沉默了。

这不是一个技术问题，这是一个财务约束下的项目管理模型选择问题。而我的答案是，这种项目，老老实实用瀑布开发。不是我保守，而是我踩过坑，赔过钱，也见过太多团队在固定预算的项目里硬上敏捷，最后交付不了、回款不了、团队士气也崩了。

这篇文章，我就把这件事掰开揉碎讲清楚：为什么预算固定的项目，瀑布开发才是最稳的选择。这里面的逻辑，很多敏捷教练不会告诉你，很多项目管理课也不这么讲。

一、核心结论：固定预算项目选瀑布，不是倒退，是风险控制的最优解

在开始长篇分析之前，我先把核心结论亮出来，因为我知道你可能正拿着手机在会议间隙看这篇文章，没时间慢慢读。

对于预算固定、范围相对明确、交付标准清晰的项目，瀑布开发模式在成本可控性、进度可预测性和验收通过率三个维度上，全面优于纯粹的敏捷模式。

这不是我随口说的。过去八年我主导和参与交付了 40 多个项目，其中有 12 个是固定总价合同。这 12 个项目里，用瀑布模式交付的 9 个，平均预算偏差率控制在 7% 以内；用敏捷模式尝试交付的 3 个，有两个超出预算 20% 以上，一个中途被迫转回瀑布模式才勉强在预算内收尾。样本量不大，但趋势足够明显。

很多人可能不服气，觉得你是不是敏捷没跑好？Scrum 的迭代回顾、Sprint 计划你做到位了吗？我想说的是：敏捷是好东西，但它的好是有前提条件的。把敏捷用到不该用的场景里，就像拿跑车跑越野，不是车不好，是路不对。

二、先把场景说清楚：什么叫“预算固定的项目”

很多讨论敏捷好还是瀑布好的人，其实连最基本的场景都没对齐。你说的是内部产品迭代，他说的是外部客户交付，俩人聊的根本不是一回事，怎么可能达成共识？

所以这一节，我必须先把“预算固定项目”这个场景讲透。

1. 典型的固定预算项目长什么样

在我接触过的项目里，符合“预算固定”特征的大致分这几类：

• 政府信息化采购项目：公开招投标确定中标金额，合同金额锁定，超支部分乙方自己承担。验收标准写在招标文件里，不验收不给尾款。
• 企业 ERP/MES/WMS 等大型系统实施项目：合同金额在签约时就确定了，实施范围通过 SOW（工作说明书）详细约定。增项要走变更流程，变更未必能拿到钱。
• 软件外包项目：甲方把需求文档写得很细，找三家供应商比价，价低者中标。这种项目利润本来就薄，一旦超预算就意味着亏损。
• 企业内部立项的改造项目：年度预算已经批下来了，比如 200 万做某个系统的升级改造。年底花不完要收回，花超了要重新走审批。

这些项目有一个共同特点：钱是定死的，时间是定死的，范围在合同里是写死的（至少大面上是写死的）。这个“三定”特征，决定了项目管理模型的选择逻辑。

2. 固定预算项目的核心约束是什么

项目管理的铁三角，范围、时间、成本，在固定预算项目里，成本是刚性约束，时间和范围是半刚性约束。什么意思？

成本超了，项目就亏了，公司就不干了。时间可以少量浮动，但不能离谱，因为甲方也有自己的上线窗口期，比如某个系统必须在年底决算前上线，错过了就等明年。范围可以在细节上协商，但合同里承诺的功能模块必须交付，否则验收过不了。

在这个约束条件下，项目管理的首要目标不是“做出最好的产品”，而是“在既定成本和时间内，交付满足验收标准的产品”。这是个微妙的区别，前者追求的是质量最大化，后者追求的是风险最小化。

3. 为什么这个场景下敏捷的逻辑会失效

敏捷的核心思想是“拥抱变化”。Scrum 的 Sprint 回顾、产品待办列表的持续调整、每个 Sprint 结束后的检视与适应，这些机制设计的初衷，就是让团队能够快速响应需求变化。

但请注意：“拥抱变化”是有成本的。每次需求调整都意味着部分已完成工作要返工，返工就需要额外的人天。在时间计费或者成本可追加的模式里，这不是问题，客户买单就行了。在互联网公司内部，产品方向调整了，团队继续干就行，反正工资照发。

但在固定预算项目里，额外人天意味着利润被吃掉甚至亏本。你和甲方说“这个需求变了对最终用户更好”，甲方大概率回你一句“但合同预算就这么多”。你怎么办？自己垫？公司不会同意的。

所以不是敏捷不好，是敏捷的“变化容纳能力”在固定预算的财务约束下，变成了“成本失控放大器”。这个认知，是我赔过一个项目之后才真正刻进骨头里的。

三、拆解一个常见误区：敏捷能降本增效，为什么固定预算项目反而不适用

这个误区太普遍了。很多人看了敏捷的宣传，更快交付、更少浪费、持续改进，就天然觉得敏捷肯定比瀑布省钱。我见过不止一个甲方项目经理，在合同签完之后跟乙方说“你们用敏捷跑吧，效率高，我们也想早点看到东西”。

这个逻辑是有问题的，我拆开来讲。

1. 敏捷降的是“机会成本”，不是“开发成本”

敏捷之所以在互联网行业大获成功，是因为它解决了一个关键问题：在产品方向不确定的情况下，用最小的代价快速验证假设，避免做了一大堆功能结果没人用。

这个价值本质上降的是“机会成本”，你没把时间和钱花在错误的产品方向上。但注意，这有一个隐含前提：你本来就有可能走错方向。

而在固定预算的外包或实施项目里，方向早就定好了，需求文档就是方向。不需要验证，不需要 pivot，不需要用 A/B 测试来探路。这个场景下，敏捷降低机会成本的优势根本发挥不出来，但它的额外开销，频繁的会议、持续的沟通对齐、迭代返工的可能性，一样都不会少。

2. 敏捷的“效率”是建立在团队高度自治和持续投入前提下的

一个真正高效的 Scrum 团队需要具备什么条件？我来列一下：

• 团队成员全职投入，不被其他项目打断
• 团队有足够的自主权做技术决策
• Product Owner 能实时做优先级判断，且对业务有深刻理解
• 团队稳定，Sprint 之间人员不变化
• 组织文化允许试错

在固定预算的乙方交付项目里，这五个条件通常一个都满足不了。团队成员可能同时被分配到两三个项目上；技术选型在合同里已经定了，不能随意改；PO 是甲方的人，他可能一个月才参加一次 Sprint Review；项目组可能因为人力调配在中期换人；试错成本乙方自己承担，公司文化不允许。

在这种条件下硬跑 Scrum，结果是会议照开但决策做不了，迭代照跑但需求变不了，站会照站但问题解决不了。形式上都做了，效果一点没有，还多了一大堆流程开销。

3. 固定预算项目的甲方要的是“可控”，不是“可见”

敏捷强调“可见性”，通过可工作的软件来展示进度。这个理念很好，但对于固定预算项目的甲方来说，可见的东西未必可控。

甲方项目经理关心的不是你这两周做了多少个 Story Point，而是：

• 整体进度完成了百分之多少？
• 预算花了多少？还剩多少？
• 有没有延期风险？有的话缓冲期还剩几天？
• 什么时候能整体交付可以验收？

这些问题，瀑布模式通过里程碑计划、挣值分析、阶段评审这些传统手段可以回答得很清楚。而敏捷模式下，你只能告诉甲方“我们已经完成了三个 Sprint，交付了功能 A、B、C”，但要回答“距离整体验收还差多少”这个问题，你只能模糊地说“按照 Product Backlog 的优先级再跑七八个 Sprint 应该差不多了”。

如果你是出钱的甲方，听到这个回答，你会放心吗？

四、专业判断逻辑：为什么瀑布的“确定性”在固定预算场景下就是最大的价值

上一节我讲的是“为什么敏捷不合适”，这一节我要正面阐述“瀑布为什么合适”。这里面的价值，大多数讲敏捷的文章都不会告诉你。

1. 瀑布的“阶段门”机制天然保护预算不超支

瀑布模式最被人诟病的一点就是“阶段门”，必须上一个阶段评审通过，才能进入下一个阶段。需求评审完了才能做设计，设计评审完了才能编码，编码完了才能测试，测试完了才能上线。

很多人觉得这是僵化、低效、不灵活。但换个角度想，每一个“阶段门”都是一道预算闸门。

需求阶段结束，所有需求都锁定了，后续不会再有意料之外的新增；设计阶段结束，技术方案确定了，后续不会有架构级别的返工；编码阶段结束，功能都实现了，测试只是验证而非重建。每个阶段把不确定性关在门外，下一阶段的成本就是可控的。

我举一个真实的数字。我们四年前交付的一个电子政务项目，需求阶段花了整整两个月，光评审会就开了七次，所有页面原型全部画完甲方签字确认才进入设计。当时团队有人觉得太慢了，两个月代码一行没写。但项目跑起来之后，整个开发和测试阶段零需求变更，工期一天没超，预算偏差不到 3%。验收那天，甲方签完字跟我们的项目经理说：“你们前期磨的那两个月，真值。”

这个“值”，就是瀑布模式在固定预算场景下的核心价值。把不确定性消灭在最便宜的阶段，而不是留到最贵的阶段去解决。

2. 瀑布的文档资产让甲方能向上交代

很多技术人讨厌写文档，觉得代码就是最好的文档。但在固定预算项目里，文档是给甲方项目经理用来向上汇报和向下追责的。

甲方的信息中心主任需要跟局长汇报项目进展，他拿什么汇报？难道把 Sprint 燃尽图投在屏幕上说“领导你看我们已经完成了 42% 的故事点”？领导听得懂吗？

但如果你给他一份《详细设计说明书》《数据库设计文档》《测试用例清单》《UAT 测试报告》，他拿这些去汇报就有底气。文档不仅是交付物，更是组织间的信任传递工具。

在 PingCode 服务的很多中大型企业客户里，我看到过一个很有意思的现象：那些在人力资源、财务、采购等职能领域推行 Scrum 敏捷开发的团队，最开始都觉得 PingCode 的看板视图和 Sprint 规划功能很好用，但跑了两三个迭代之后，产品负责人普遍反映一个问题，“迭代回顾板上记录的团队改进点越来越丰富，可到了给部门领导汇报的时候，拿不出有分量的阶段成果说明”。

后来这些团队做了一个调整：继续用 PingCode 的 Scrum 面板管理迭代开发节奏，但整个项目的需求基线、关键设计决策和阶段验收标准，全部在 PingCode 的知识库和需求管理模块里，按照类似瀑布的里程碑节点进行归档。部门领导审阅的仍然是结构化的、带签字的交付文档。

这件事给我的启发是：文档不是开发的副产品，它是治理的证据。在需要多方审批、层层汇报的大型组织里，瀑布模式产生的文档资产本身就是交付价值的一部分。

3. 固定范围下的“关键路径”思维让排期更精准

瀑布模式的另一个隐藏优势是对关键路径的可见性。因为瀑布各阶段是顺序展开的，所有任务的依赖关系在项目计划阶段就梳理清楚了。哪些任务是关键路径上的不能延期，哪些有浮动时间可以在紧急情况下调配，一目了然。

敏捷模式里也有迭代计划，但 Sprint 之间的依赖关系和跨 Sprint 的关键路径通常不那么显性。尤其当多个 Scrum 团队并行工作时，整体的交付节奏很难用单一的关键路径来描述。

我在带固定预算项目时有一个习惯：即便是那些客户要求“看起来敏捷一点”的项目，我也会在内部维护一份基于 WBS 的传统进度计划。这份计划不需要给客户看，但它是我自己掌控项目节奏的底盘。一旦哪个环节出现延期苗头，我可以马上从关键路径上判断出对最终交付日的影响，从而决定要不要调配资源或者跟客户预警。

这个习惯救过我至少两次。一次是第三方接口供应商延期了两周，我从关键路径上算出来后续测试阶段还有两周缓冲，决定不等接口而先用 Mock 数据继续推进，最终整体进度没受影响。如果没有瀑布模式下的 WBS 和关键路径分析，这种判断很难快速做出来。

五、具体案例：从两个项目的对比看选择的代价

光讲道理不够，这一节我用两个亲身经历的项目来对比，让你更直观地感受两种选择带来的不同结果。

1. 项目 A：某市政务服务平台升级项目（瀑布交付）

项目背景：某地级市政务服务平台进行功能升级，涵盖 14 个子系统、110 多个功能点。公开招投标，中标金额 420 万，工期 13 个月，合同内明确了全部功能模块和验收标准。

我们的做法：严格按瀑布模型执行。

• 需求阶段（2.5 个月）：逐条确认 110+ 功能点的业务流程、页面原型、数据规则。每个子系统的需求说明书都与甲方业务负责人签字确认。使用 PingCode 的需求管理模块建立史诗-特性-用户故事三级需求矩阵，需求的优先级和业务价值在规划阶段就一次性评定完毕，后续迭代分解以此为基础不再变更。
• 设计阶段（1.5 个月）：完成数据库设计、接口设计、安全设计方案，全部通过甲方技术团队评审。评审中发现两个功能点的数据逻辑在需求阶段理解有偏差，但因为需求基线已经锁定，双方都清楚偏差修正必须在现有工作说明书范围内完成，因此技术方案调整只影响内部实现方式，不对外增加任何工作量。
• 开发阶段（6 个月）：按子系统分组开发，每月一次里程碑检查。期间有一个子系统因为第三方数据接口延期影响了两周进度，我们从非关键路径上调了两个人补齐。PingCode 的迭代概览页上燃尽图显示整个交付批次的任务完成率始终稳定，进度偏差没有超出项目缓冲。
• 测试阶段（2 个月）：功能测试、性能测试、安全测试、UAT 测试逐轮推进，所有缺陷在内部跟踪闭环。
• 上线与验收（1 个月）：顺利上线，一次通过验收。

结果：总工期 12.7 个月，比合同提前 9 天交付。总成本 389 万，预算偏差率 -7.4%（节省了 31 万）。验收一次通过，没有遗留问题。这个项目后来还拿了当年的省内信息化优秀案例。

2. 项目 B：某大型零售企业会员系统（尝试敏捷交付）

项目背景：一家大型零售连锁企业要重建会员管理系统，功能包括积分体系、会员等级、优惠券、精准推送等。合同总价 280 万，工期 10 个月，需求在合同附件里有概要描述但没有细化到功能点级别。

我们的做法：客户方 CIO 有互联网背景，强烈建议用 Scrum 跑。我们当时也想尝试，就按 Scrum 搭了团队。Product Owner 由客户方指派，每个 Sprint 两周。

前期看起来很顺利。前三个 Sprint 跑完了积分累积和积分兑换的基础功能，客户看到可用的软件还挺满意。但问题从第四个 Sprint 开始集中爆发：

• 客户方 PO 在 Sprint Review 上连续三次提出新的需求方向，说“市场上竞品已经在做社交裂变了，我们的优惠券模块能不能也加入分享红包功能”。这个功能在原始合同里完全没有。
• 我们评估了一下，加这个功能需要多出约 60 人天的工作量。跟客户沟通时，对方表示“这不属于新增需求，而是对优惠券模块的合理完善”。双方对合同范围内的“合理完善”理解完全不同。
• 与此同时，因为需求持续调整，前面 Sprint 交付的部分功能需要返工。积分过期规则从“自然年清零”改成了“滚动 12 个月”，数据库表结构要改，前面的单元测试要重跑，接口文档要重写。
• 到第六个 Sprint 的时候，项目经理做了一次估算：当前已完成的工作量对应合同金额大约 170 万，但实际已经花了将近 190 万人天的成本（含返工）。距离交付剩下的功能点还需要至少 140 万人天，这意味着如果继续按 Scrum 跑，项目最后要亏掉约 50 万。

最终处理：我们在第七个 Sprint 之后紧急叫停了 Scrum 模式，跟客户摊牌：要么签变更合同追加预算，要么锁定需求回到瀑布模式按计划交付。客户选择了后者。后面的三个多月我们用瀑布方式重新规划剩余任务，严格冻结需求，最终在第 11.5 个月完成交付，但总成本还是超了 18 万。

反思：这个项目没有亏大钱，但利润几乎被吃没了。复盘时团队总结了三点：第一，PO 是客户方的人，他的利益诉求和我们不一样，他希望做出更好的产品，这个动机没错，但他不用为预算负责。第二，合同里的需求描述太模糊，给了双方对“范围”博弈的空间。第三，也是最重要的一点，Scrum 在需求有弹性空间的场景里没问题，但合同已经把弹性空间锁死了，再跑 Scrum 就是在合同框架外透支自己的利润。

3. 两个项目的关键指标对比

我把这两个项目放在一起比较，差异一目了然：

这些数字不是要证明瀑布比敏捷好，而是要证明：在固定的预算和合同约束下，瀑布模式能更好地保护乙方的交付利润和甲方的验收确定性。这个结论是我用真实的损失换来的。

六、行动建议：固定预算项目下瀑布交付的七个关键控制点

既然结论已经很明确了，这一节我来讲具体怎么干。以下七个控制点，是我从多年交付经验中提炼出来的，每一个都是拿教训换的。

1. 需求阶段必须拿到“签字画押”的基线文档

听起来是废话，但真正做到位的项目不到三成。什么叫“到位”？

• 需求说明书不是你自己写完了发给甲方看的，是跟甲方一起一页一页过的。
• 每个功能点的描述要具体到：输入项是什么、处理逻辑是什么、输出结果是什么、异常情况怎么处理。不要有“根据实际情况灵活调整”这类模糊表述。
• 页面原型要做完，甲方业务负责人逐页确认。原型上标注的字段名称、校验规则、交互逻辑，就是后续开发和测试的依据。
• 需求评审会议不仅要开，还要留下签字记录。可以是纸质签字的评审纪要，也可以是邮件确认。

在 PingCode 的需求管理模块里，你可以为每个史诗、特性、用户故事编写详细描述，并在评审环节通过自定义字段标注“已确认 / 待澄清 / 有争议”等状态，需求基线的每一个版本变更都有操作日志可追溯。但工具不是核心，核心是人确认了才算数。

2. 建立正式的变更控制流程，收口要硬

需求冻结之后，任何变更，哪怕客户觉得是“小改动”，都必须走正式的变更流程。这个流程至少包括四个步骤：

1. 提出：客户方以书面形式提出变更请求，描述变更内容和原因。
2. 评估：乙方评估变更对工作量、工期、成本的影响，给出书面评估报告。
3. 决策：双方项目经理根据评估结果决定是否接受变更。如果接受，是否追加预算？是否顺延工期？这些必须白纸黑字写下来。
4. 执行：变更确认后更新需求基线文档和项目计划。

这个流程不是为了刁难客户，而是让变更的成本显性化。很多时候客户在 Sprint Review 上随口说“能不能加个小功能”，不是故意的，而是他根本不知道“这个改动到底要花多少钱”。当你把评估报告递给他，“这个改动需要多花 12 人天，折合 2.4 万开发成本，预计让上线时间延后 5 天”，他马上就理性了。大部分时候他会说“那算了，不急”。

3. 用 WBS 拆到 3 人天以内的任务粒度

很多项目经理做 WBS 只拆到模块级别，一个任务动辄十五二十人天。这种粒度没法做有效的进度跟踪。我的标准是：每个工作包的工作量控制在 1 到 3 人天。

为什么是这个粒度？因为如果某个任务预估要 10 人天，等到一周后发现进度滞后 40%，你基本已经没什么挽回余地了。但如果任务粒度是 2 人天，最多两天后就能发现偏差，三天内就能采取纠正措施。

用 PingCode 做项目分解时，我通常会从史诗拆到用户故事，再从用户故事拆出具体的设计任务、编码任务、单元测试任务，每个任务预估工时都精细到半天这个量级。这样做燃尽图的波动会比较真实，而不是到了迭代最后两天才突然发现一条断崖式下坠。

4. 预留缓冲期，但要放在明面上管理

固定预算项目的缓冲期不是一个“藏起来的时间段”，而应该是计划里明确标识、受控使用的管理工具。我的习惯是在项目计划的尾部单独设一个“项目缓冲期”，通常是总工期的 10% 到 15%。

关键路径上任何延期，都从这个缓冲期里扣。同时每周做一次缓冲消耗分析，如果消耗速度过快（比如项目进行到 30% 的时候缓冲已经消耗了 50%），立刻触发预警并向客户通报。

这种管理方式的好处是：你手里始终有一个可以量化的交付保障指标，用来跟客户和内部领导沟通。

5. 评审节点提前锁定，甲方的参与节奏要写入合同

这一点非常容易被忽视，但往往是最大的工期杀手。需求评审、设计评审、UAT 测试，这些环节都需要甲方关键人员参与。如果甲方的人叫不动，评审就搁浅了，后续所有工作都等着。

我的做法是：在项目启动会上就确定所有评审节点的时间安排，明确每个节点需要甲方的什么人参与。然后把这张时间表作为合同附件。

不是要为难甲方，而是要建立双方的共同节奏。如果在某个评审节点甲方无法按时参与，就从缓冲期里扣，同时在进度报告中记录“因甲方资源未到位导致评审延后 X 天”。这个记录不是为了将来打官司（虽然有时候确实需要），而是让双方对工期延误的责任有清醒认知，避免最后验收时扯皮。

6. 用挣值分析法跟踪成本与进度偏差

挣值管理是瀑布模式里最实用的量化管理工具，但很多项目经理只听过没用过。我在这简单解释一下三个核心指标怎么落地：

• PV（计划价值）：到某个时间点，按计划应该完成的工作量对应多少预算。这个在 WBS 和进度计划里提前分配好。
• EV（挣值）：到某个时间点，实际完成的工作量按计划单价计算值多少钱。注意不是实际花了多少钱，是“完成的活值多少钱”。
• AC（实际成本）：到某个时间点，实际已经花掉多少钱。

每个月底算一次：SV = EV – PV（进度偏差），CV = EV – AC（成本偏差）。如果 SV 是负数，说明进度滞后；如果 CV 是负数，说明成本超支。两个指标一目了然。

在 PingCode 里虽然没有原生的 EVM 模块，但你可以用自定义报表把任务的计划工时、实际耗时和完成状态数据导出来，在外部做挣值分析。或者更直接的做法，是利用 PingCode 的迭代概览和燃尽图来近似追踪进度偏差，虽然不是严格的 EVM，但日常管理中够用。

7. 验收标准在需求阶段就定好，不要到测试阶段再讨论

这一点我前面提过但不厌其烦再说一次，因为这可能是最大的坑。很多项目到 UAT 阶段才开始讨论“什么算验收通过”，结果发现甲方对“通过”的理解和乙方完全不一样。

正确的是：在需求评审阶段，每个功能点都要定义验收标准。标准要可测试、可量化。不是“系统响应速度比较快”，而是“在 200 并发用户下，列表查询页面加载时间不超过 2 秒”。不是“界面美观大方”，而是“符合甲方提供的 VI 设计规范和页面原型”。

PingCode 的用户故事里可以内嵌验收标准字段，Scrum Master 或项目经理在迭代规划时需要逐条核对这些标准是否可达、是否可测。这些验收标准在后续迭代开发中就是每个任务的完成定义（DoD），开发和测试同事从一开始就清楚要做到什么程度才算完，不需要等到 UAT 阶段再临时抱佛脚。

七、三种情况下的模式取舍：不是非此即彼

写到这里，我必须做一个重要的澄清，避免你读完这篇文章得出一个简单化的结论“瀑布好，敏捷不好”。不是这样的。

模式没有好坏，只有匹配度。下面我把最常碰到的三种情况分别讨论，告诉你在每种情况下怎么选。

1. 预算固定、需求明确的纯交付型项目，果断选瀑布

这种情况就是我前面花大量篇幅讲的典型场景。特征：合同金额锁定，需求文档完整，验收标准清晰，交付日期确定。典型的政府项目、大型系统实施、外包开发。

在这类项目里，选瀑布你没有选错，选敏捷反而可能选错。如果客户或者团队内部有人坚持要用敏捷，你可以这么沟通：“敏捷的价值在于快速验证和持续调整，但我们这个项目的需求已经验证过了，合同已经锁定了范围，敏捷的增量价值有限，但它带来的流程开销和范围漂移风险是真实存在的。我们可以在瀑布框架内吸收一些敏捷的做法（比如每日站会、看板可视化），但整体管理模式用瀑布。”

这个说法既尊重了对方的建议，又从专业角度给出了判断依据，通常能得到理解。

2. 预算有上限但需求有模糊空间的项目，用“铰接式瀑布”

这种情况很常见：合同金额定了，但需求文档只有概要描述，很多细节需要在执行过程中细化。完全用瀑布跑不动，因为需求基线锁不住；完全用敏捷风险又太高，因为预算没有弹性。

我的建议是采用“铰接式瀑布”。具体做法：

• 整体项目仍然按瀑布的阶段门机制管理，需求-设计-开发-测试-上线的顺序框架不动。
• 在需求阶段，对已确认的核心模块按瀑布方式锁定基线；对有争议或不确定的模块，标记为“待细化”，并在项目计划中为它们预留专门的细化时间窗口。
• 在设计阶段内部，对这些“待细化”模块允许小范围的需求迭代，但迭代终点有硬性截止日期。到了那个日期，不管细化到什么程度，需求也必须冻结，进入开发。
• 变更流程仍然严格执行。任何超出合同范围的变动，都要走评估和追加预算流程。

这种模式的实质是：在瀑布的壳子里，给前端阶段多留一点探索空间，但后端阶段的刚性不妥协。它既承认了某些需求确实需要边做边清晰，又没有让“拥抱变化”变成“拥抱失控”。

如果你在 PingCode 里落地这种混合模式，可以这样做：整体的项目里程碑和阶段门仍然按瀑布计划管理，但把需求阶段和设计阶段分别再拆成一个短期看板，允许产品经理和架构师在这个阶段内做几次快速迭代讨论。一旦设计评审通过，后续的编码和测试阶段就恢复到标准瀑布流程。PingCode 同时支持经典看板和 Scrum 迭代两种模式，项目管理员可以按阶段灵活切换，历史数据一脉贯通。

3. 内部产品研发、预算可调节的项目，敏捷是你的好朋友

如果是公司内部的产品研发，预算不是一次性锁死的，可以根据业务价值持续追加，那么敏捷的优势是瀑布无法比拟的。快速验证、快速迭代、数据驱动决策，这些东西在一个需要探索产品市场匹配度的场景里，是王道。

这种情况下，你应该毫不犹豫地选敏捷，而且要认真地跑，不只是走形式。站会好好开，回顾认真做，Sprint 目标要清晰，Definition of Done 要严格。跑步到位，敏捷才能真正产生价值。

但请注意：即便是在这类项目里，如果某个阶段需要外包给外部供应商，且合同是固定总价，那么那一部分仍然建议用瀑布模式管理。不是因为你信不过供应商，而是合同约束决定了管理模式。

八、一个更深层的观点：项目管理的本质是现金流管理

最后我想讲一个可能有点超出常规讨论范畴的视角。

做了这么多年项目，我发现很多项目经理有一个认知盲区：他们把项目管理等同于进度管理，觉得只要东西按时做出来就算成功。但从公司的角度看，项目管理本质上是现金流管理。

一个固定预算的项目，合同金额就是这笔生意的全部收入池。每多花一天开发成本，就是从利润里直接挖掉一块。每延迟一个月验收，就是回款晚一个月，资金成本又多一笔。

从这个视角再来看开发模式的选择：瀑布模式天然对应着阶段化的现金流支出节奏，需求阶段花多少钱、设计阶段花多少钱、开发测试阶段花多少钱，跟回款节点（首付款、里程碑款、验收款）是可以对齐的。财务部门喜欢这种可预测性。

而纯敏捷模式在现金流的可预测性上要差得多。因为范围在变、节奏在变，你很难在项目开始的时候准确告诉财务“三个月后我需要花掉多少人天”。对于靠项目利润活着的乙方公司来说，这个不确定性就是经营风险。

所以当你下一次面对“选瀑布还是选敏捷”的争论时，不妨把视野拔高一点。不要只从开发团队效率的角度讨论问题，也试着从公司经营和现金流安全的角度想一想。也许你会发现，很多技术层面争论不休的问题，换一个视角看，答案其实很清楚。

结语：确定性是一种被低估的价值

在这个全员讲敏捷、讲快速迭代的时代，“确定性”似乎成了一种贬义词。好像追求确定性就是保守、僵化、不思进取。但我不同意这种叙事。

确定性本身不是问题，关键看场景。在预算已经锁定、合同已经签字的项目里，确定性就是乙方活下去的底线，也是甲方拿到验收成果的保障。瀑布模式所提供的确定性，阶段化的交付节奏、清晰的里程碑节点、可审计的文档资产、可控的变更影响，在这些场景里不是落后的象征，而是专业的体现。

下一次你接到一个固定预算的项目，有人跟你说“咱们跑敏捷吧，效率高”，你可以先不急着答应或者拒绝。你可以心平气和地问一个问题：

“如果跑到一半，需求变了，多出来的工作量谁买单？”

这个问题本身，就包含了所有你需要的判断依据。

当然，我并不是要你死板地用瀑布。我自己的团队即便在瀑布模式下，也会做每日站会、用看板墙做任务可视化、定期做回顾总结。但这些做法的本质是在瀑布的框架内吸收敏捷的沟通效率，而不是把项目的财务约束和治理结构全部交给迭代逻辑去跑。

如果你正好也在管理一个固定预算的项目，你可以做一件事：回头翻翻合同，看看需求描述到哪个粒度。如果粒度不够，很多功能点只是列了个名字没有详细说明，赶紧安排需求细化，然后让甲方签字确认基线。这件事多花两周，但可能为你后面省下两个月和几十万的成本。

这个投入产出比，非常划算。

毕竟说到底，项目管理不是关于怎么写出好代码，而是关于怎么在给定的约束条件下，交付承诺的价值。理解了这一点，选瀑布还是选敏捷，就不再是个需要纠结的问题了。