一个做医疗器械的客户要求按阶段交付文档，每个阶段评审签字才能进下一阶段。这就是典型的瀑布模型。它被吐槽了很多年，但在特定项目里依然是最稳的选择，关键看项目性质。

优点：可控、可审计

  • 阶段清晰：需求、设计、编码、测试、维护五段，每段有明确交付物和退出标准。
  • 文档完整：需求规格说明书、概要设计、详细设计齐全，交接和验收有依据。
  • 便于合同管理：固定总价、固定工期，里程碑付款，甲乙双方都好算账。
  • 质量前置：设计评审能在写代码前发现架构问题，返工成本比上线后低。

缺点：反馈来得太晚

用户第一次看到能跑的系统，往往已经过去半年。需求理解偏了，改一行要回溯需求、设计、代码、测试四份文档。测试被压到最后，进度一紧就先砍测试，缺陷全留给运维。变更成本随阶段线性上升，到了维护期改一个字段可能牵动整个模块。

什么项目适合

需求稳定、技术成熟、合规要求高的场景：军工、医疗设备、银行核心系统、招投标项目。这类项目验收看文档，改动要走变更单，瀑布的刚性反而是优点。反过来，互联网产品需求天天变、要快速试错，用它就是自找麻烦。

现实中的折中做法

多数团队用的是带迭代的瀑布：整体阶段不变，每个阶段内部小步交付；或者在需求阶段插入原型确认，把反馈提前。也有人改成V模型，让每个开发阶段对应一个测试阶段，尽早验证。

判断方法很直接：合同里写死了范围和验收标准，用瀑布；上线时间比范围更重要，用敏捷。最怕流程按瀑布走、需求按互联网节奏变，两头不讨好。