2.1 瀑布模型：单程直达列车

2.1 瀑布模型：单程直达列车

本章从最老的一张运行图讲起。瀑布常被当成"落后"的代名词，但如果你看完本节还持这个印象，说明没看清它的适用边界——在需求冻结、审计严格的线路上，瀑布至今是正确答案。本节讲清它的行车逻辑、失效条件，以及它给后来所有模型留下的遗产。

单程直达的行车逻辑

瀑布模型的运行方式：需求分析、设计、实现、测试、运行维护五个阶段严格串行，每个阶段产出成套文档，经评审签字后冻结，下一阶段才能开工。像单程直达列车——始发站装货、中途不停靠、终点一次性交付，全程各站凭票上车，没有回程票。

它的底层假设有两条：需求在项目早期可以被完整想清楚，以及改动一张已冻结的文档，代价远高于在纸面阶段多想半天。在建筑行业这两条近乎公理——楼盖到八层不会推了改户型。瀑布把这套公理搬进软件，赌的是需求同样可以提前冻结。

每个阶段有明确的进出站条件。以需求阶段为例：进站凭立项书与调研材料，出站凭一份通过评审的需求规格说明书——评审不通过就留在站台继续打磨，不允许"先往上走再补"。这套纪律是瀑布真正的遗产，后面所有模型都继承了它。

什么时候该用瀑布

判断标准不是新旧，而是三个条件的满足程度：

• 需求高度稳定：业务逻辑由法规或物理约束决定，五年不会大改；
• 交付一次成型：客户只接受完整成品，不接受半成品试用；
• 验证成本极高：试错一次的代价大到无法承受，必须在纸面反复确认。

满足三条的典型场景：军工与航天软件（适航认证要求每份文档可追溯）、医疗设备嵌入式系统（审批流程以文档为审计对象）、大型合同制外包（甲乙方按里程碑付款，冻结点即结算点）。在这些线路上，敏捷式"边跑边改"反而会带来合规灾难。

失效机理：反馈回路太长

瀑布的问题不在流程本身，而在错误暴露得太晚。需求阶段埋下的误解，要到测试阶段才被撞见，返工要跨越设计、编码两个已冻结的阶段，代价成倍放大。业内常用的缺陷修复成本曲线给过量化印象：同一处需求误解，在需求阶段修正花一份力气，拖到上线后修正可能要花几十份——还不算信任损失。

几个失效信号值得你背下来：

• 客户第一次真正"使用"产品是在验收那天；
• 需求规格书写了数百页，没有人能读完并保持理解一致；
• 变更委员会月度例会积压几十条变更申请，冻结名存实亡。

⚠️ 冻结是瀑布的命门，也是它最常被违反的地方。需求冻结后客户照样提变更，团队口头答应"下个版本再说"，实际悄悄塞进当前迭代——流程纪律一旦开了这种口子，瀑布就只剩瀑布的缺点（反馈慢），没有它的优点（可审计、可追责）。

与后来的模型比一比

这张表不需要背，需要的是遇到具体项目时过一遍前文的三个判断条件。值得一提的是，瀑布并非没有反馈——它的反馈藏在各阶段评审里，只是反馈对象是文档而非可运行的产品。评审员的想象力替代不了用户的实际使用，这才是它反馈失真的病根。

案例复盘：一张没跑完的直达票

云梯货运集团曾在结算平台之外立项"车辆维保管理系统"，走的就是瀑布：需求规格书评审用了一个半月，设计与开发按部就班，五个月后进入测试。测试周第一周，仓库主管看到系统后提出："维保记录要能按车牌拍照上传，不然司机不会用。"这条需求在规格书里不存在——不是调研漏了，而是主管们在看到界面之前，自己也说不清操作习惯。项目为此停摆三周做变更评估，交付比计划晚一个月。

复盘的结论很克制：不是瀑布选错了，而是**"用户自己也说不清需求"这个前提不成立时，选了瀑布**。维保系统属于操作型工具，用户习惯只能在使用中被发现；后来集团内部类似的管理小工具一律改走短迭代，只有对接国标数据上报的模块仍保留瀑布——那一块的规则由行业标准冻结，正是瀑布舒服的线路。

变更晚到的账，当场算一笔

瀑布对变更的敏感可以量化感受。设需求阶段修一处误解的成本是一个单位，行业反复观察到的量级大致是：设计阶段修要三到六个单位，编码阶段八到十五个，测试阶段二十起步，上线之后五十到两百——还会随系统之间的耦合加深。代入一个直观场景：一份有四十个条目的需求基线，如果理解偏差率只有一成，就有四处偏差；全部拖到上线后才发现，按五十单位计就是两百个单位的返工成本，相当于把需求阶段的工作量重做好几遍。评审看起来花掉了几个单位，实际是在给这两百个单位买保险——瀑布的每道冻结闸口，本质上都是一张廉价的期权。

变体：分段验收的瀑布

纯粹的"一口气直达"在实践里还有个温和变体：分段瀑布——把大项目切成几个里程碑段，每段完成即向客户做一次正式演示与确认，确认通过才启动下一段。它保留了瀑布的文档与冻结纪律，只是把"客户第一次看到东西"的时间从终点提前到每个大站。这算不算不纯正的瀑布？不重要——选型本来就不是选标本，而是选主心骨。对合规要求重、又无法接受终点才能见面的客户，分段瀑布常是比"硬敏捷"或"硬瀑布"都更舒服的折中。

两个高频疑问

问：公司领导只认瀑布式的排期表，我该怎么办？ 先交出领导真正要的东西：可承诺的日期与可核查的进度。瀑布排期表的形态是熟悉的，按它汇报并不妨碍内部用小节奏推进——把每个阶段内部再切成小班次自管理，对外仍按阶段汇报。先在交付信用上站稳，再逐步把"阶段内也演示"介绍给干系人，比正面推翻对方的认知框架有效得多。

问：需求规格书写多细才算够？ 有一个自检问句：拿掉这条，开发或测试会不会做出与验收期望不同的东西？会，就写；不会，就是冗余。规格书的敌人是两个极端——薄到各人各理解，厚到没人读完。让"能否防止两种不同的正确实现"来决定每一条的去留。

本节要点回顾

• 瀑布五阶段严格串行，文档评审冻结后才能进下一站，核心假设是需求可提前想清。
• 适用三条件：需求稳定、一次成型交付、试错代价高；强合规线路是它的主场。
• 失效机理是反馈回路太长，缺陷暴露越晚修复越贵，变更积压会击穿冻结纪律。
• 它的真正遗产是阶段进出站条件与评审纪律，被后来所有模型继承。
• 用户自己也说不清需求时，不要选瀑布——选错运行图比跑得慢更致命。

下一节看第一张改良运行图：把大旅程切成小段，让反馈提前回来。