瀑布开发不适合互联网，我们试过

一、我们为什么至今还会掉进瀑布的坑里

2021 年第四季度，我们团队接了一个内部协同工具的改版项目。需求方给的 Brief 是“把现有的 OA 系统做一次体验升级”，听起来并不复杂。但最后这个项目从立项到交付用了 11 个月，超预算 40%，上线后第三周就被迫启动了一次紧急回滚。

这不是一个技术能力的问题，团队里的前端、后端都是经历过多个项目的老人。真正把我们摁在地上摩擦的，是方法论选型上的致命错误：我们在一个需求高度不确定的互联网产品上，执拗地执行了一套标准的瀑布开发流程。

今天回过头复盘，我必须把这一点说清楚：瀑布开发不适合互联网，我们试过，而且亏得很实在。这不是理论推演，不是敏捷教练为了卖课编出来的恐吓故事，而是我们自己用真金白银和团队士气换来的教训。

很多团队并不是不知道瀑布的问题，而是在决策那一刻，瀑布看起来实在是太诱人了。老板希望看到完整的计划、明确的上线日期、可控的预算。需求方希望“一次性把需求说清楚，后面就别改了”。开发团队也希望在写代码之前，所有逻辑都板上钉钉。大家都有一种幻觉，叫做“这次我们想清楚了”。

而互联网产品的本质特征是：当你以为你想清楚了的时候，市场已经变了，用户已经变了，甚至提需求的那个人自己也在变。瀑布模型要求你在一开始就做出最全面、最准确的设计，这本身就与互联网产品的不确定性形成了结构性冲突。

下面我会把这次项目的完整经历拆开来讲，包括我们当时为什么选了瀑布、过程中发生了什么、数据上到底亏了多少、以及后来我们是怎么把自己从泥潭里拉出来的。

二、我们当时为什么会选瀑布，没有人会故意选择一个“错”的方法论

在复盘的时候，最容易被问到一个问题：“你们为什么不一开始就用敏捷？”这个问题暗含了一个假设，好像我们是在两种方法之间自由选择，然后脑子一热选了错的那个。事实完全不是这样。

1. 甲方合同已经把路径锁死了

我们当时面对的是一个传统行业客户的数字化转型项目，合同签订的时候，SOW 里就已经写清楚了四个里程碑节点：需求冻结、设计冻结、开发完成、UAT 上线。每一个节点对应一笔付款。这种合同结构天然就把你推向瀑布，客户按阶段验收付款，团队按阶段交付成果，所有的项目管理指标都围绕“是否按计划完成”来设定。

在合同层面，我们不是没有争取过。我们提出过按迭代交付、按功能点验收的方案，但当时的现实情况是，甲方的采购部门、法务部门和项目管理办公室全部要求“可量化的、按阶段考核的交付标准”。你没办法跟一个法务解释“Sprint 目标可能会在 Sprint 过程中调整”。

2. 团队过去的成功经验恰恰是绊脚石

我们团队的核心骨干大多有大型系统集成的背景，做过政府项目、做过 ERP 实施，这些领域的共同特点是需求可以穷举、流程可以梳理、系统边界相对清晰。在这些项目里，瀑布加上适当的变更控制，确实是行之有效的方法。

问题在于，我们把“过去的经验”当成了“通用的真理”。当面对一个面向 C 端用户的互联网产品时，我们下意识地复用了同一套打法，先做业务调研、再写需求规格说明书、然后出高保真原型、接着是概要设计和详细设计，全部评审通过之后才开始编码。

这个流程本身没有错，错在被用在了错误的环境里。

3. “想清楚了再做”的思维惯性深植于组织文化

比制度更难改变的是文化。我们的项目决策链上，从 PMO 到技术负责人，几乎所有人都默认“高质量交付 = 充分的前期设计”。评审会上最常听到的一句话是：“这个逻辑你还没想清楚，怎么就开始写了？”

在瀑布的语境里，这句话是对的。但在互联网产品的语境里，很多逻辑只有等你把东西做出来、放到真用户面前，才能真正“想清楚”。我们花了大量时间在会议室里推演用户行为，画了无数张流程图，但最后上线发现用户的真实行为和我们推演的路径完全不一样。这个问题不是设计能力的问题，而是信息获取方式的问题，办公室推演永远无法替代真实用户数据。

这三个因素叠加在一起，让“选瀑布”在那个时间点上看起来根本不是选择，而是唯一可行的路。而这条路上最大的陷阱，我们接下来一一踩了个遍。

三、瀑布开发在互联网项目上的七层地狱

瀑布模型的标准流程是：需求分析 → 系统设计 → 编码实现 → 测试验证 → 上线部署 → 运维维护。每一阶段都有明确的输入和输出，上一个阶段完成了才能进入下一个。这个模式在建筑工程、硬件制造等物理约束极强的领域里运转得很好，但在互联网领域，它引发了以下七个连锁问题。

1. 需求冻结是一句美丽的谎话

我们的项目在第三个月完成了需求评审，所有相关方签了字，需求说明书盖上了“冻结”的章。当时大家都松了一口气，以为最难的沟通阶段终于结束了。

冻结后的第二周，甲方的业务负责人发来一封邮件，说“最近竞品上线了一个新功能，我们的方案可能需要调整一下”。这封邮件就像一个裂口，之后每周都有新的“微调建议”涌进来。到第六个月的时候，我们统计了一组数据：需求冻结后提出的变更请求共 47 个，其中被定性为“会影响现有设计”的有 23 个，真正被拒绝的只有 3 个。

为什么拒绝不了？因为对于甲方来说，这是“业务需要”，你不做就是“不配合业务”。而对于我们自己来说，我们每拒绝一个变更，就意味着已经在开发中的系统离用户的真实需求又远了一步。所以我们一边走变更流程，一边强行开发，一边调整设计文档，整个项目变成了一个表面上还在按瀑布流程走、实际上已经失控的巨型混沌体。

2. 文档成为项目最大的沉没成本

在瀑布流程中，文档是阶段交付物，也是评审依据。我们在这个项目上产出了 200 多页的需求规格说明书、80 多页的概要设计、以及一套完整到可以当教科书用的详细设计文档。

到项目后期，这些文档大多变成了废纸。有三个典型的表现：

第一，文档与代码严重不一致。当需求变更发生后，开发团队的首要任务是改代码、保上线，文档的更新永远排在最后。到第八个月的时候，我们的需求规格说明书大概只反映 60% 的当前系统逻辑。

第二，文档维护成本挤占了实际开发时间。我们专门安排了一个技术写作人员来维护文档体系，但即便如此，每周仍有大量时间花在“文档对齐”上，同一个变更，要同步更新需求文档、设计文档、接口文档、测试用例文档。粗略估算，文档维护相关的工作量占到了整个开发周期的 15% 到 20%。

第三，文档给了所有人虚假的安全感。每个人都以为“文档上写得很清楚”，但真正到了联调和测试阶段，才发现每个人对“写得很清楚”的理解都不一样。文档越厚，这种偏差越隐蔽，爆发时的破坏力也就越大。

3. 测试被压缩成灾难

由于前面的需求阶段和设计阶段花了太多时间，等到编码真正开始的时候，上线日期已经定死了，没有任何商量余地。换句话说，延期多少都要吃掉测试时间。

我们的开发阶段原计划三个月，实际用了四个半月。而测试阶段原计划一个半月，被压缩成了三周。这个数据本身就已经说明了一切。

测试压缩带来的后果是连锁性的：集成测试不充分，大量 Bug 在 UAT 阶段才被发现；UAT 阶段的修复又引入新的回归问题；上线后第一周，生产环境报出了 17 个 P1 级别的缺陷。其中有三个缺陷直接导致了业务流程中断，这就是开头提到的紧急回滚的根因。

4. 用户反馈来得太晚，也太贵

在第七个月之前，用户看到的只有原型图和需求文档。他们对着静态页面给了很多反馈，我们也根据这些反馈调整了一些设计。但原型和真实产品之间的鸿沟，比我们想象的大得多。

真实产品上线后，我们拿到了第一波用户行为数据。结果是，我们精心设计的三个核心功能中，有两个的使用频率远低于预期。用户日常扫码进入系统的目的和我们在需求阶段设想的“高频刚需场景”完全对不上。

这个时候修改的成本有多大？如果是原型阶段发现，改一下 Axure 文件，半天搞定。如果是开发初期发现，调整一下后端逻辑，一个 Sprint 内可以解决。但到了上线之后，改动涉及数据库结构、前后端接口、缓存策略、权限模型，随便一个功能调整，代价都是数十人天。

瀑布把用户验证放在了流程的最末端，这意味着所有的验证成本都被放到了最大。

5. 团队士气被无效等待消耗殆尽

瀑布开发有一个隐含的心理伤害，它让团队成员长期处于“等待”状态。设计师在等需求冻结，开发在等设计完成，测试在等开发交付。每个阶段，总有一部分人处于工作不饱和的尴尬状态。

我们团队的一个前端开发在项目中期跟我说了句话，我到现在还记得：“这两个月我一直在写 Demo，我不知道自己写的东西会不会被改掉，也不知道什么时候能真正上线看到效果。”

这不是某个人的问题，这是流程结构导致的系统性士气低落。人在没有即时反馈的环境中工作，会迅速丧失对成果的感知，进而丧失对项目的认同感。到项目后期，我明显感觉到团队的主动性在下降，大家不再主动提优化建议，不再关心最终用户怎么想，只关心“需求文档上怎么写的我就怎么做”。

6. 技术债务在瀑布的掩护下快速累积

瀑布模型对技术债几乎没有任何感知能力。因为技术债是动态的、持续的、隐形的，而瀑布只关心“当前阶段的任务是否完成”。

在我们这个项目中，为了赶进度，开发团队做了大量“先跑通再说”的临时方案：接口不做版本管理直接硬编码、缓存策略用最简单的全量刷新、错误处理全部走通用异常拦截器。这些方案在功能测试阶段都是“通过”的，看起来没有问题。

但进入生产环境之后，日活从 0 一下子跳到几千，这些临时方案就开始一个接一个地崩。接口响应时间从毫秒级变成秒级，数据库连接池频繁耗尽，监控告警几乎没有，因为我们根本没时间搭。

瀑布的“阶段完成”机制制造了一个错觉：这个模块已经“做完”了。但“功能跑通”和“可运维”之间还有巨大的鸿沟。而这个鸿沟，在瀑布的流程设计里根本没有被看见。

7. 项目成功标准被悄悄替换

这是最隐蔽的一个问题。瀑布项目的评估体系天然倾向于“按时交付”而非“用户满意”。因为时间、预算、范围是瀑布的三大铁三角，而“用户价值”不在这个铁三角之内。

到项目中后期，团队内部形成了一个默认共识：“只要能按时上线就是胜利。”没有人再讨论这个功能用户到底需不需要、体验好不好的问题。评审会上大家关注的是“进度是否正常”、“风险是否可控”、“变更是否走完流程”。项目管理的工具和指标，慢慢把“做正确的事”替换成了“正确地做事”。

最终上线的版本，从项目管理角度看是一个“合格交付”，需求文档上列的功能基本都实现了。但从用户角度看，它是一个需要大量修补的半成品。这种项目成功与产品失败之间的反差，是瀑布模型在互联网项目上最深层的结构性缺陷。

四、数据复盘：一个项目亏掉了什么

这个项目结束之后，我们做了一个完整的数据复盘。以下数据来自项目管理系统、财务记录和团队问卷，我把几个关键数字列出来，不是为了诉苦，而是希望这些数字能帮其他人做决策的时候多一个参考依据。

1. 时间成本翻倍

项目原始计划 7 个月，实际耗时 11 个月，超出 57%。超时的核心原因不是开发效率低，而是需求变更导致的大量返工。我们对返工时间做了分类统计：因为需求理解偏差导致的返工占 35%，因为需求变更导致的返工占 40%，因为技术方案设计不到位的返工占 15%，因为 Bug 修复的返工占 10%。前两项加起来占了 75%，这两项都和瀑布的“前期锁定需求”机制直接相关。

2. 预算超支的结构性原因

总预算超出原计划 42%。其中，人员成本超出 50%，因为项目延期导致了额外的人力投入；Bug 修复和紧急上线带来的运维成本完全不在原始预算之内，这部分追加了大约 18 万。

另一个容易被忽视的成本是机会成本。这个项目占用了团队最核心的 12 个人长达 11 个月。在这期间，我们被迫推掉了两个新项目机会。如果当时用更短周期的方式交付了 MVP 版本，团队至少可以提前 4 到 5 个月释放出来承接新业务。

3. 上线后三个月内的返修投入

我们跟踪了上线后三个月的数据。这三个月内，团队有 60% 的时间投入在需求调整和缺陷修复上，只有 40% 的时间在做新功能开发。一个正常迭代的产品团队，Bug 修复和需求调整的占比通常应该控制在 20% 到 30% 之间。我们的数据说明，上线时交付的是一个“看起来完成但实际上存在大量质量问题”的版本。

4. 用户满意度的量化对比

项目上线后我们做了 NPS 调研，得分是 -12。作为对比，我们同期另一个采用迭代交付的小项目，上线时 NPS 得分是 +28。这中间 40 分的差距，就是瀑布强行把用户验证推到流程末端所付出的代价。

五、从瀑布到迭代：我们是怎么爬出来的

这个项目结束后，我们内部做了一次长达两天的全面复盘。结论非常清晰：不是团队能力问题，不是需求方配合问题，就是方法论和项目特征不匹配的问题。基于这个判断，我们开始在后续的互联网产品项目中进行系统性的调整。

1. 第一步：在合同阶段就为迭代留空间

我们学到的第一个教训是：如果合同本身是按瀑布设计的，后端的任何敏捷实践都只是表面功夫。现在我们会在合同洽谈阶段就明确提出迭代交付方案：按产品功能模块划分里程碑，而不是按“需求-设计-开发-测试”的阶段性文档来划分。

具体的做法是，在 SOW 里写清楚：“本项目采用分期迭代交付模式，每个迭代周期为 2 到 4 周，每个迭代交付一组可上线运行的功能。迭代范围内的具体需求，允许在迭代开始前一周根据业务最新情况进行优先级调整。”这不是一个放之四海而皆准的方案，但它至少在法律层面为后续的灵活调整留出了一条通道。

2. 第二步：用“最小可用版本”替代“完整需求冻结”

我们不再追求“把所有需求想清楚再动手”，而是先和需求方一起确定：第一个版本最核心要验证的是什么？哪些功能是实现这个验证必须的？其他所有看起来重要但可以推迟的功能，全部放到后续迭代。

在我们的一个新项目里，原始的需求池有 80 多个功能点。经过“最小可用版本”的筛选，第一个迭代只保留了 12 个功能点。这 12 个功能点支撑了一个完整的核心业务流程，上线之后我们立刻得到了用户数据，然后基于数据来排定后续的优先级。结果是，这个项目从第一个版本上线到实现原始需求池中 70% 的功能，只用了 4 个迭代，而用户满意度在第二个迭代就已经转正。

3. 第三步：把测试和反馈前置

瀑布最致命的问题是反馈延迟，所以我们要做的就是把反馈尽可能提前。我们的具体做法包括：

需求评审阶段就引入测试人员。测试不在开发完成之后才开始介入，而是在需求讨论阶段就参与进来，从可测试性的角度挑战需求描述，帮助把需求的验收标准在早期就明确下来。

用低保真原型做用户验证。不等到高保真设计完成，在低保真阶段就把核心流程拿给用户走一遍。用户在白板原型上就能指出流程逻辑的问题，这个时候修改的成本几乎为零。

每个迭代必须交付可体验的版本。我们的硬性规定是，每个迭代结束时产出的必须是可部署、可体验的版本，而不是一堆“开发完成但还没联调”的代码。这个规定倒逼团队在迭代周期内完成集成和基本测试，避免了瀑布时期“全部开发完了再联调”的噩梦。

4. 第四步：工具链的配套改造

方法论变化必须有工具支撑，否则就是空谈。

在瀑布阶段，我们用项目管理工具主要是为了跟踪任务完成情况，本质上是一个“计划-执行-检查”的线性管理。转到迭代模式之后，工具需要支持的是需求池的动态优先级管理、迭代看板的可视化、以及与代码和测试系统的数据打通。

我们当前使用的主流工具能够做到：需求从用户故事拆解到开发任务再到代码提交和测试用例，全链路可追溯。迭代进度、燃尽图、Bug 密度趋势这些指标，可以在看板上一目了然地看到。对于团队来说，这种透明性解决了一个核心问题：每个人都知道当前迭代的真实进度，不需要等到里程碑节点才发现进度偏差。很多中大型企业在选择项目管理工具时，也会关注这类功能对迭代交付的支撑能力。

六、瀑布有没有用？，一个需要诚实回答的问题

写了这么多瀑布的问题，我必须做一个重要的澄清：这篇文章不是在主张“瀑布一无是处”，而是在说“瀑布不适合互联网产品开发这个特定场景”。

在我的实践中，瀑布仍有它明确的适用区间。

1. 瀑布适用的场景

需求高度确定且变更成本极高的项目。比如政府监管系统对接、金融核心交易系统的基础架构层、或者硬件的嵌入式软件开发。这些场景中，需求和约束在项目启动时就已经足够明确，变更的代价也确实足够高，花时间做充分的前期设计是理性的。

合规和审计要求严苛的项目。某些行业要求项目过程必须有完整的文档追溯，每一个决策都要有评审记录。瀑布天然产出大量过程文档，在这些场景下反而是优势。

跨组织协同的大型系统集成项目。当多个供应商、多个系统并行建设时，接口标准的早期锁定是项目成功的前提。没有瀑布式的整体设计，接口一旦错位，修复成本高到不可承受。

2. “瀑布骨架 + 迭代血肉”的混合模式

在 100 人以上的中大型组织中，完全从瀑布跳到纯 Scrum 往往不现实。组织内部的采购流程、合规要求、汇报体系都不是一夜之间能改的。我们找到的一个折中方案是：在项目级保持瀑布的大阶段框架，但在每个阶段内部采用迭代式开发。

具体来说，项目的整体规划仍然有里程碑节点，但在实现阶段，每个功能模块走 2 到 4 周的短迭代。迭代内部严格遵循“开发-测试-演示-反馈”的闭环，但对外汇报时仍然用里程碑节点来和干系人沟通。

这种做法当然不够“纯粹”，但它解决了一个现实问题：在组织环境还没准备好全面敏捷之前，团队可以先从内部交付模式开始改变，而不需要等待整个组织的转型。

七、不同情况下的行动建议与取舍

每个团队面临的情况不一样，没有普适的药方。但以下几点是基于我们自己踩坑经验的判断，供参考。

1. 如果你正在一个瀑布合同里挣扎

不要试图推翻合同重新谈判。这在绝大多数情况下不现实，而且会消耗大量政治资本。应该做的，是在合同框架内找弹性空间。

具体操作：在需求冻结之前，主动增加一轮用户验证环节，哪怕只是低保真原型的测试，也比纯看文档强。在开发阶段内部，团队自组织地引入短周期站会和迭代看板，哪怕对外仍然按里程碑汇报。这些“灰色地带”的调整，可以在不触犯合同的前提下显著改善交付质量。

2. 如果你正准备签一个新项目

在商务阶段就做三件事：

第一，用数据说话。把过去瀑布项目的延期率、返工率、用户满意度数据摆出来，向甲方说明迭代交付的商业合理性。甲方并不天然偏好瀑布，他们只是需要一个可控感和确定感。当你用数据证明迭代反而更可控的时候，很多阻力会自然消解。

第二，提供一个折中的里程碑方案。不要一上来就说“我们没有固定里程碑”，这会让甲方的 PMO 直接把你否掉。应该提供的是“以功能交付为节点的里程碑”，而不是“以文档交付为节点的里程碑”。

第三，在合同里约定变更处理机制。不是禁止变更，而是明确变更的流程和代价。当变更的成本透明化了，需求方自己就会做出更慎重的选择。

3. 如果你的团队只会瀑布

这个问题比很多人想象的要普遍。很多技术骨干在瀑布环境里成长起来，转到迭代模式时最大的障碍不是技能，而是心理安全感。他们习惯了“先把设计做透再动手”，对于“不知道下个迭代要做什么”这件事有本能的不适。

针对这种情况，不要强推，要渐进。可以从一个低风险的小项目开始试水，让团队在真实项目中感受迭代的好处，而不是在培训教室里听敏捷教练讲理论。实践中我们观察到，当团队经历过一次“用户看到了真实产品并给了积极反馈”之后，大部分人会从抵触转向认同。

4. 组织转型到底要不要等

我们当时踩过的一个大坑就是：以为“等组织准备好了再变”。事实证明，组织永远不会有“准备好”的那一天。转型不是一个开关，而是一个逐步渗透的过程。从一支小团队、一个小项目开始，跑出成果，拿到数据，然后把这些成果拿给决策层看。用成果说话比用理论说服有效得多。

八、总结：互联网不需要完美计划，它需要持续正确的试错能力

回到文章标题那句话：瀑布开发不适合互联网，我们试过。

“试过”这两个字背后，是一个完整的失败项目的代价。但我不认为这次失败没有价值，它让我们彻底想清楚了一件事：互联网产品的本质特征是不确定性，而应对不确定性的方法不是更详细的计划，而是更短的反馈循环、更小的批量交付、更快的验证节奏。

如果你现在所在的项目正走在瀑布的路上，而你隐约感到哪里不对，我的建议是：

立刻去做一次数据复盘。统计一下需求冻结之后的变更数量、每个变更的修复成本、团队在文档和会议上的时间占比、以及上线后的返修率。这些数据会告诉你，你的直觉是不是对的。

不要等下一个项目再改。哪怕在这个项目内部，也有很多可以立刻开始的调整：在下一个里程碑之前引入一次用户验证，在开发团队内部引入站会和看板，把测试人员提前拉进需求讨论。这些动作很小，但累积起来，能显著改变项目的走向。

把这篇文章分享给你的利益相关方。包括你的老板、你的甲方、你的团队成员。因为方法论的转变从来不是一个人的决定，它是一个团队甚至一个组织的共识。而共识的起点，往往就来自一个真实的故事和一组真实的数据。

我们付过学费了，希望你们不用再付一次。