全文约 1900 字，阅读约 5 分钟。
重点内容：瀑布不是慢，是把返工成本往前挪。判断用不用瀑布只看一件事，需求会不会变。它最容易翻车的地方不是流程，是需求基线没签字就开工。
有些项目，就是得一步一步来
做软件的人爱聊敏捷，但现实里有一类项目，你让它边做边改是要出大事的。给银行做的结算系统，给政务做的申报平台，还有软硬件一体的嵌入式设备，需求在立项那一刻基本就定了，后面每改一处都要走审批。这种项目硬套敏捷，只会把自己套乱。
这类项目用的就是瀑布模型。名字听着老派，但很多行业到现在还在用，原因就一个，可控。每一步都有明确交付物，出了事能查到是哪个环节。它跟敏捷的区别可以对照着敏捷和瀑布到底差在哪那篇看，这里只说瀑布自己。
瀑布不是慢，是把返工成本往前挪
瀑布的流程是一条直线，前面那步没走完，就不往下走。标准分五段，每段出口都有件具体的东西要交出来。
需求分析阶段，把要做什么写成需求规格说明书，功能点、边界条件、异常处理都写清楚，甲方和乙方一起评审，签了字才算基线定下来。这是后面所有工作的地基。
设计阶段分两层，先做概要设计，系统拆成几个模块、模块之间怎么调、数据库怎么建；再做详细设计，具体到每个接口的参数和表结构。先想清楚再动手。
开发阶段照着设计写代码，这阶段产出的是可运行的代码加单元测试。测试阶段是整体联测，不是开发一点测一点，要把系统当整体跑一遍，出测试报告。交付阶段上线、验收、归档，验收报告一签，项目才算收尾。
很多人误以为瀑布慢。它慢在前期想得多，换来的是后期返工少。敏捷反过来，前期快，改起来也快，代价是可能要返工。选哪个看项目，不看潮流。
什么样的项目才该上瀑布
别一听到传统就排斥。判断标准就一条，需求会不会变。需求越稳，越适合瀑布。具体这几类。
金融、政务这类强合规的项目。每个阶段都要留档备查，审计来了一翻就有，这跟瀑布的交付物体系天然对得上。
嵌入式、硬件开发。软件和硬件进度绑在一起，板子都开模了你说要加功能，那不叫改需求，那叫重做。返工成本极高，所以宁可前期多花时间。
外包交付。合同写死了范围和金额，甲方要的就是按图施工，你要的是改一处能多结算一处，双方都需要一条清晰的线。
反过来，你要是做个互联网 App，连自己下个月加什么功能都没谱，就别用瀑布。需求锁死了反而把自己憋死。
三个最容易翻车的地方
瀑布看着简单，翻车点很集中，而且基本都出在同一件事上，该较真的时候没较真。
一是需求没锁死就开工。需求文档是瀑布的地基，地基没签字就写代码，后面全得推倒重来。第一道铁律是，需求基线必须评审、必须签字。签字这个动作看着形式主义，它真正的用处是逼着所有人在动工前把话说清楚。
二是阶段之间不评审。设计完了没人把关就直接开发，等于把问题攒到测试才爆发，那时候改一处要动一大片。每个阶段结束都得有一道门，过了才能进下一步，而且这道门得有具体标准，不是开个会走过场。
三是变更当成小事。瀑布最怕顺手改一下。哪怕一个小改动，也要走变更流程，评估影响、更新文档、重新排期。很多项目滑下去不是因为改得多，是因为改的时候没人记，最后谁也说不清现在做的到底是哪一版。
变更怎么管才不会乱
瀑布不代表拒绝变化，它管变化的方式叫变更控制。不是不能变，是变了要花钱、要重排。真要改需求，走这三步。
第一步提变更，写清楚改什么、为什么改，别口头说一句就动手。第二步评估影响，要动多少天、会不会连带别的模块、工期要不要顺延、成本怎么算。第三步拍板，谁有权限批这个变更，批了才改，没批就维持原样。
大一点的项目会设个变更控制委员会，几个关键角色坐一起定期过一遍堆着的变更单，决定哪些做、哪些砍、哪些往后放。听着繁琐，但正是它保证了交付可控。
这里还有个容易漏的点。变更批了之后，需求文档、设计文档、测试用例都得跟着改。只改代码不改文档的团队，三个月后就没人知道系统真正长什么样了。
现在其实很少有人纯瀑布了
说实话，纯瀑布在实际项目里越来越少见，更多是混着来。外面套瀑布的壳，阶段和门禁照设，交付物照交；里面的开发阶段切成几个短迭代，每周或每两周出一版可运行的东西。
这么干的好处是，既保住了瀑布要求的交付物和审批留痕，又能让问题早点暴露，不至于憋到测试阶段一起炸。甲方看得到东西，心里有底；团队也不至于几个月不知道自己做的对不对。
所以别把它当成二选一。门禁和交付物是骨架，迭代是肌肉，两个可以长在一起。
选工具，别被敏捷标配带偏
市面上的项目管理工具一大半是给敏捷设计的，看板、燃尽图、Sprint 那一套。做瀑布项目的团队用这些会觉得哪里都不对劲，因为它们默认你要持续迭代，而你要的是阶段门禁、交付物、变更记录。
挑工具看这几点就够。能不能把项目拆成阶段，每个阶段设入口和出口条件；能不能管交付物，需求、设计、测试文档有没有地方归档；变更有没有留痕，审批流清不清楚；甘特图好不好用，进度能不能一眼看清。
价格上还有个坑，很多工具按人头收费，团队一扩张成本就失控。像智序 ORDR 项目管理软件这种核心功能免费、不限人数的，可以先拿来把阶段、交付物、变更这套流程跑顺，比一上来就为敏捷标配的贵工具买单实在得多。具体功能边界可以看版本对比，想先零成本试的，免费项目管理软件怎么选这篇里有更细的拆解。
流程定不下来，换什么工具都一样。工具能做的是让较真这件事留下痕迹。
常见问题
瀑布模型分哪几段？
标准五段：需求分析（写规格说明书签字定基线）、设计（概要加详细）、开发、测试（整体联测）、交付（上线验收归档）。
什么项目该用瀑布？
需求越稳越适合：金融政务强合规（每阶段留档备查）、嵌入式硬件（改设计要重开模）、外包交付（按图施工）。
瀑布最容易翻车在哪？
三处都出在「该较真没较真」：需求没锁死就开工、阶段之间不评审、把变更当小事不改文档。
瀑布怎么管变更才不乱？
变更控制三步：提变更写清改什么为什么、评估影响工期成本、有权限的拍板才改；批了需求设计测试用例都得跟着改。
现在还有纯瀑布吗？
很少。多混着来：外面包瀑布壳设阶段门禁交交付物，里面开发切成短迭代每周出可运行版，既保留痕又早暴露问题。
资料来源
文中数据与产品信息引自：智序 ORDR 版本对比、智序 ORDR 私有化部署方案。
如有侵权请与我们联系