有些项目，就是得一步一步来
做软件的人爱聊敏捷，但现实里有一类项目，你让它「边做边改」是要出大事的。比如给银行做的结算系统，给政务做的申报平台，还有软硬件一体的嵌入式设备，需求在立项那一刻基本就定死了，后面每改一处都要走审批。这种项目硬套敏捷，只会把自己套乱。
这类项目用的就是瀑布模型。名字听起来老派，但很多行业到现在还在用，原因就一个：可控。每一步都有明确的交付物，出了事能查到是哪个环节。
瀑布不是「慢」，是一步一个坑
瀑布的流程是一条直线，前面那步没走完，就不往下走。大概五段：
- 需求分析：把要做什么写成文档，白纸黑字确认下来，这是后面所有工作的地基
- 设计：架构、接口、数据结构，先想清楚再动手
- 开发：照着设计写代码、做产品
- 测试：整体联测，不是开发一点测一点
- 交付：上线、验收、归档收尾
很多人误以为瀑布慢，其实它慢在「前期想得多」，换来的是后期返工少。敏捷反过来，前期快，但改起来也快，代价是可能要返工。选哪个，看项目，不看潮流。
什么样的项目才该上瀑布
别一听到「传统」就排斥，判断标准就一条：需求会不会变。需求越稳，越适合瀑布。具体这几类：
- 金融、政务这类强合规的项目，每个阶段都要留档备查，审计来了一翻就有
- 嵌入式、硬件开发，软件和硬件进度绑在一起，返工成本极高
- 外包交付，合同写死了范围，甲方要的就是按图施工
反过来，你要是做个互联网 App，连自己下个月加什么功能都没谱，就别用瀑布。需求锁死了反而把自己憋死。
三个最容易翻车的地方
瀑布看着简单，翻车点很集中。
- 需求没锁死就开工。需求文档是瀑布的地基，地基没签字就写代码，后面全得推倒重来。所以第一道铁律是：需求基线必须评审、必须签字。
- 阶段之间不评审。设计完了没人把关就直接开发，等于把问题留到测试才爆发。每个阶段结束都要有个「门」，过了才能进下一步。
- 变更当成小事。瀑布最怕「顺手改一下」。哪怕一个小改动，也要走变更流程，评估影响、更新文档、重新排期。
变更怎么管，才不会乱
瀑布不代表拒绝变化，它管变化的方式是变更控制。不是「不能变」，而是「变了要花钱、要重排」。真要改需求，走这几步：
- 提出变更，写清楚改什么、为什么改
- 评估影响：要动多少天、会不会连带别的模块、工期要不要顺延
- 拍板：谁有权限批这个变更，批了才改，没批就维持原样
这套流程听起来繁琐，但正是它保证了交付可控。一个用瀑布项目管理系统的团队，变更、评审、交付物都能在一个地方留痕，出了事能查到是谁、在哪个环节、因为什么，而不是互相甩锅。
选工具，别被「敏捷标配」带偏
市面上的项目管理工具一大半是给敏捷设计的，看板、燃尽图、Sprint 那一套。做瀑布项目的团队用这些，会觉得哪里都不对劲，因为它们默认你要「持续迭代」，而你要的是阶段门禁、交付物、变更记录。
挑一款合适的瀑布项目管理软件，看这几点就够：
- 能不能把项目拆成阶段，每个阶段设入口和出口条件
- 能不能管交付物，需求、设计、测试文档有没有地方归档
- 变更有没有留痕，审批流清不清楚
- 甘特图好不好用，进度能不能一眼看清
价格上还有个坑：很多按人头收费的工具，团队一扩张成本就失控。选一套免费、不限人数的项目管理软件，先把阶段、交付物、变更这套流程跑顺，比一上来就为「敏捷标配」的贵工具买单要实在得多。
