瀑布开发从0到1，真实复盘

复盘引言：上线前48小时，我删掉了3000行代码

2023年11月，某大型制造企业的MES系统二期项目进入上线倒计时。在最后一次全链路压测中，我们发现了一个致命的逻辑死锁：当生产排程模块与质量追溯模块同时写入同一批次数据时，事务锁等待时间超过8秒，直接导致产线终端卡死。

团队所有人的眼睛都盯着屏幕上的报错日志。有人提议加索引优化查询，有人建议修改事务隔离级别。我打开代码仓库，定位到三个月前在设计阶段画的那张状态机图，问题不在数据库，而在状态机的转换路径设计本身存在不可达路径。修复方案只有一个：重写状态机的核心流转逻辑，涉及4个微服务、11张数据表、约3000行Java代码。

距离上线还有48小时。没有灰度发布，没有A/B测试，没有任何回旋余地。我们最终选择回退到上一个稳定基线，延期两周。这次事故的直接成本是142万元的违约赔偿金，间接成本是对客户信任的一次重创。

事后复盘，我们所有人都在问同一个问题：在瀑布模型的要求下，我们是否有可能在设计阶段就避免这个灾难？答案是有，但我们当时缺少一套系统性的风险预判机制。而这，正是我这篇复盘文章想要讲清楚的核心命题。

一、核心结论：瀑布开发从0到1，真正考验的是“一次性做对”的能力

在敏捷开发大行其道的今天，很多人把“瀑布模型”等同于“落后”、“笨重”、“不接地气”。但在过去五年中，我以项目经理或技术顾问的身份，完整参与了3个从0到1的瀑布模型项目：一个政府公共资源交易平台、一个医疗设备公司的合规管理系统、以及上文提到的MES生产执行系统。三个项目总合同金额超过6000万元，平均项目周期14个月，团队规模从22人到65人不等。

这些项目有一个共同点：一旦进入编码阶段，需求变更的代价呈指数级增长。与互联网产品不同，B端复杂业务系统的代码模块高度耦合，一个字段的添加可能涉及前端表单、后端校验、数据库存储过程、报表导出逻辑、以及下游接口文档的联动修改。在敏捷环境下可以“先上线再迭代”的轻度变更，在瀑布模型下意味着至少2人天的工作量。

基于这些项目的一手数据，我提炼出瀑布开发从0到1的四个核心结论：

1. 瀑布模型的成功不取决于过程执行力，而取决于前期决策质量。代码写得好不好是第二位的，需求定义得准不准、架构设计得稳不稳，才是决定成败的首要因素。
2. 文档不是负担，而是唯一可追溯的协作语言。在长达一年以上的项目周期中，人员流动不可避免。没有结构化文档在传递上下文，新加入的开发者几乎不可能还原当初的设计意图。
3. 评审机制的有效性直接决定了缺陷修复成本。在设计评审阶段发现一个错误的成本可能是1小时会议时间，在联调测试阶段发现同样的错误，成本可能是一个迭代周期。
4. 团队对“不可逆决策”的警觉程度，决定了项目的风险水位。数据库选型、核心技术框架、系统集成架构，这些决策一旦做出就很难回头，必须具备最高级别的审慎度。

下面我将按照项目推进的真实时间线，逐一复盘每个阶段的踩坑经历、决策逻辑和可复用的方法论。

二、决策背景：当“敏捷”不是选项时，我们如何选型与定调

1. 为什么必须用瀑布模型？三个约束条件不可妥协

很多技术自媒体喜欢把敏捷和瀑布对立起来，营造一种“敏捷先进、瀑布落后”的叙事。但在真实的商业项目中，开发模型的选择从来不是技术偏好问题，而是约束条件下的最优解。

以我参与的医疗合规管理系统为例，项目的约束条件极其刚性：

• 合规约束：国家药监局对这个系统的功能点有明确的事前备案要求。所有功能必须在需求阶段完整列出，提交监管部门审核。审核通过后，功能列表不可增减。这种合规框架天然排斥迭代式需求演进。
• 合同约束：项目采用固定总价合同，金额520万元，交付物、交付时间、验收标准全部在合同中逐条约定。任何超出合同范围的需求都是“二期项目”，需要重新走招采流程。
• 集成约束：系统需要对接医院内部8个上游系统（HIS、LIS、PACS、EMR等），这些系统由不同供应商提供，接口文档稳定但缺乏弹性。我们不能随时要求对方配合修改接口，只能在设计阶段一次性完成接口规格确认。

在这样的约束下，谈“小步快跑”是不负责任的。正确的做法是认清现实，把瀑布模型执行到位，而不是心存侥幸地用“伪敏捷”去应付瀑布项目。

2. 技术选型的权衡：我们放弃了微服务，选择了模块化单体

在MES项目中，技术选型是第一个重大决策。当时团队内部有两派声音：

• 微服务派：主张Spring Cloud + Docker，理由很充分，独立部署、技术栈灵活、未来可扩展性强。这也是当时技术社区的主流声音。
• 模块化单体派：主张Spring Boot单体应用，按业务模块划分包结构，共用数据库。理由也很务实，团队只有7个后端开发，微服务的运维复杂度远远超出团队能力边界。

我最终拍板选择了模块化单体架构。这个决策的逻辑如下：

事后证明这个决策是正确的。在项目中期，团队有2名核心开发人员离职，新加入的同事在两周内就通过阅读模块化代码结构理解了业务逻辑。如果当时选择了微服务，光是环境搭建和链路追踪的学习成本就可能让项目延期一个月以上。

这个决策的核心逻辑是：在瀑布模型中，技术选型的首要考量不是先进性，而是确定性和团队承载能力。你做的是从0到1的交付项目，不是从1到100的平台建设。

三、常见误区：90%的瀑布项目失败，不是模型的问题，而是执行变形

1. 误区一：把“需求冻结”理解成“不许沟通”

这是最普遍的误解。很多团队机械执行瀑布流程，在需求评审签字之后就把《需求规格说明书》锁进抽屉，拒绝与业务方做任何沟通。真正的需求冻结，指的是功能性需求的基线锁定，而不是沟通渠道的关闭。

在公共资源交易平台项目中，我们的需求量达到327个功能性需求点，涉及招投标、专家抽取、电子保函、在线开标等12个业务模块。需求冻结后，我们仍然保持与业务方每周一次的需求讨论会，但讨论的议题有严格边界：

• 允许讨论：业务流程的优先级调整、UI交互体验的优化、非功能性需求（如响应时间、并发量）的细化。
• 不允许讨论：新增功能点、修改已有功能点的核心业务逻辑。
• 需要走变更流程：任何涉及合同范围、交付时间、成本变化的需求调整。

这套“有限沟通”机制让项目在保持稳定性的同时，避免了瀑布模型最大的弊端，信息孤岛和反馈滞后。当测试阶段暴露出某个招标流程与用户实际操作习惯不一致时，设计阶段的沟通记录帮助我们快速定位了问题根源：不是需求写错了，而是UI交互路径没有充分贴合用户的工作流。

2. 误区二：在框架设计的完美主义上投入过多时间

这是技术负责人最容易犯的错误。在医疗系统的设计阶段，我们的架构师花了两周时间设计一套“万能的”权限控制模型，试图用一张RBAC表覆盖所有未来的可能性，从院级权限到科室权限，从功能权限到数据权限，甚至预埋了字段级权限控制的扩展点。

这个设计本身没有技术问题，但存在严重的项目成本问题：

• 为了“万能的”扩展性，权限模型引入了5张关联表，查询任何一条数据权限需要JOIN至少3次。
• 当实际业务中95%的场景只用到“科室-角色-功能”三层权限时，这套“万能”设计反而让最简单的查询变慢。
• 最终我们在性能测试时发现，权限校验成为高频操作的瓶颈点，不得不回退到更简单但够用的设计。

这件事给我的教训是：瀑布模型中，架构设计的黄金法则是“设计到刚好够用的深度”。你现在能确定的扩展需求才叫需求，不能确定的叫过度设计。把过度设计节省下来的时间投入到接口联调和集成测试上，ROI要高得多。

3. 误区三：用评审记录代替真实反馈

瀑布模型极度依赖评审机制。需求评审、设计评审、代码评审、测试用例评审，每一个阶段节点都意味着一次集体审查。但我在两个项目中都观察到同一个问题：评审会变成了“走过场”的形式主义。

典型症状包括：评审材料提前一天才发出，评审参与者在会议上才第一次看到内容；评审问题流于表面（“这个命名不规范”、“这段注释不够详细”）；真正致命的设计缺陷几乎没有在评审阶段被发现。

在MES项目中，我做了一个机制调整：

• 评审材料必须提前至少3个工作日发出，评审参与者必须提交至少3条书面意见才能进入会议室。
• 评审主持人不是设计者本人，而是由另一位同级别的技术同事担任，目的是“让设计者必须在评审会上为自己的每个决策辩护”。
• 每个评审问题的闭环必须记录在评审问题追踪表中，谁提出、谁负责验证修复、在哪个时间点关闭，所有动作留痕。

这套机制实施后的第一个设计评审，我们在一个下午发现了11个问题，其中2个是阻塞级的架构缺陷。如果这些缺陷流入编码阶段，修复成本至少是评审阶段的20倍。

四、阶段复盘：需求、设计、编码、测试、上线的全链路拆解

1. 需求阶段：冻结前的90天，决定项目成败的70%

瀑布模型下，需求阶段是我投入时间最长、精力最多、也是最不敢偷懒的阶段。以公共资源交易平台为例，从项目启动到需求冻结，我们花了整整89个工作日。期间的行动可以拆分成五步：

（1）业务调研：用“沉浸式跟岗”替代“会议室访谈”

传统的需求调研是让业务方在会议室里讲流程。我发现这种方式效率极低：业务人员会无意识地省略“自己认为理所当然”但恰恰是系统核心的操作细节。在交易平台项目中，我让3名需求分析师分别到招标代理机构、公共资源交易中心、评标专家抽取现场，跟随业务人员工作一周。这一周里我们发现了大量“会议室中永远不会被提及”的需求：

• 评标专家抽取系统必须在抽取前30分钟才能登录，这是内部风控流程，没有任何书面管理制度。
• 电子保函的审核时效性要求是T+0，因为很多投标企业是在投标截止当天才申请保函。
• 开标直播的延时必须控制在3秒以内，否则会被投标人质疑公平性。

这些细节如果在需求文档中缺失，后期补充就是需求变更。

（2）需求分级：史诗-特性-用户故事的三级拆解

这里我们参考了Scrum中的需求管理方法，在PingCode项目管理工具中建立了一个需求分层结构，但做了适配瀑布模型的调整：

使用PingCode这类专业的项目管理工具来管理需求层级，比用Excel有明显的优势：每个用户故事可以关联到源代码、测试用例、缺陷记录。当后期出现需求争议时，我们可以在5分钟内追溯到最初的需求定义、评审记录和所有相关变更。

对于100人以上的大型组织，PingCode提供的需求泳道视角和跨项目依赖关系图，能帮助产品负责人一眼看清哪些需求之间有前置依赖，避免在排期时犯下“先开发了B功能，但A功能还没做完所以B无法联调”的低级错误。这种视觉化的需求管理能力，在复杂瀑布项目中是实实在在的效率倍增器。

（3）原型验证：低保真原型比高保真原型更适合瀑布项目

这个观点可能和很多人的直觉相反。我的实践是，在瀑布模型的需求阶段，高保真原型容易造成“虚假的共识”。当业务方看到一个视觉精美的原型时，会产生“这就是最终系统”的错觉，从而忽略了对业务流程和异常场景的讨论。

我们在这个项目中全部使用Axure线框图，禁止UI设计在需求阶段介入。原型只表达三样东西：字段布局、操作流程、异常提示。丑陋但有效。

（4）需求评审：用“反向讲解法”消除理解偏差

传统评审是需求分析师讲、业务方听。我们反其道而行之：让业务方来讲解他们对需求的理解，需求分析师在一旁核实。当业务方的理解与需求文档不一致时，当场标记为“理解偏差点”。这个做法在交易平台项目中发现了17处偏差，其中2处涉及核心招投标流程的逻辑差异。

2. 设计阶段：架构决策的分级策略与评审机制

设计阶段是瀑布模型的“承重墙”。编码阶段的效率和质量，70%取决于设计阶段的质量。我的管理方法是将设计决策分为三个等级，不同等级适用不同的评审力度：

（1）一级决策（不可逆决策）：数据库选型、核心框架、集成架构

这类决策一旦做出，后期回头的成本极高。我在MES项目中要求，所有一级决策必须具备两个方案的对比分析，且必须有一个“为什么不用其他方案”的论证段落。单方案通过的评审不予批准。

（2）二级决策（高成本可逆决策）：模块划分、接口协议、数据模型

这类决策后期可以调整，但改动的波及面较广。要求评审时有至少一位与该模块无直接关系的技术同事参与，避免团队内部的“群体思维”盲区。

（3）三级决策（低成本可逆决策）：代码规范、工具配置、内部实现细节

这类决策完全放权给开发团队自行确定，只需要在团队Wiki中记录决策结论和理由。

在医疗合规管理系统的设计阶段，数据库选型是一级决策中的典型。我们需要在PostgreSQL和MySQL之间做选择。最终的对比论证如下：

• PostgreSQL在复杂查询、事务完整性、审计日志方面有显著优势，这几项恰好都是合规管理系统的核心需求。
• 但团队里只有2名开发者有PostgreSQL的深度使用经验，其余5人需要学习curve。
• 我们选择了一个折衷方案：核心业务数据库使用PostgreSQL，日志和报表类数据使用MySQL，通过数据同步工具保持一致性。这实际上是一个务实的“混合型”一级决策。

3. 编码阶段：瀑布模式下的质量控制体系

瀑布模型的编码阶段周期最长、开发人员的工作最分散，最容易出现“质量黑箱”。等到集成测试阶段才能发现编码问题，那时修复成本已经很高了。我们的应对策略是一套三阶段代码审查机制：

（1）自检阶段：提交前的自动化门槛

所有代码提交必须通过：

• SonarQube静态代码扫描，阻塞级问题数必须为0。
• 单元测试覆盖率不低于70%，核心业务逻辑覆盖率不低于90%。
• 代码规范检查（CheckStyle/StyleCop）零告警。

（2）同行评审阶段：模块负责人制

每个模块指定一位“代码负责人”。所有进入该模块仓库的PR，必须经过负责人Review并批准。审核重点不是代码风格，而是：

• 业务逻辑实现是否符合设计文档？
• 异常处理是否覆盖了所有已知的边界条件？
• 是否存在潜在的性能瓶颈（N+1查询、大事务、未索引的外键）？

（3）定期走查阶段：随机抽检+全局视角

每周五下午，架构师从当周合并的代码中随机抽取3-5个PR，在全员会议上做深度走查。这个机制的震慑效应远大于实际的发现问题数，当每个人知道自己的代码可能会被当众“示众”时，自检和同行评审的质量会大幅提升。

4. 测试与上线：瀑布模型最脆弱的环节，如何加固

瀑布模型的测试阶段是所有风险集中爆发的地方。由于集成测试被推迟到编码结束后才进行，任何模块间的不兼容问题都是在“大联调”中暴露。我在三个项目中积累了以下应对经验：

（1）提前介入集成测试的“契约测试”

我们在编码阶段就要求各模块对外发布接口契约文档，明确定义每个API的输入、输出、异常码、响应时间SLA。基于这份契约文档，测试团队可以在编码阶段就编写集成测试用例，并使用Mock服务模拟未完成的模块。这样一来，等到真正的联调阶段，大部分接口级兼容性问题已经被提前发现。

（2）测试用例数量的经验公式

基于三个项目的数据，我总结出一个经验公式：

测试用例总数 ≈ 功能点数 × 3.5 + 接口数 × 2 + 关键流程数 × 8

例如，一个327个功能点、43个对外接口、12条关键业务流程的系统，合理的测试用例规模约为：(327×3.5) + (43×2) + (12×8) = 1144 + 86 + 96 = 1326个用例。如果一个测试团队给出的用例数量远低于这个预估，很可能覆盖度不足。

（3）上线风险的“情景预设”

瀑布模型下，上线是单次大型操作，没有敏捷模式下的灰度缓冲。我们为每次上线准备三份文档：

• 上线检查清单：逐一确认所有前置条件是否满足。
• 上线剧本：精确到分钟的操作步骤和执行人。
• 回滚剧本：如果出现任何预定义的条件触发回滚，谁在什么时间点做出决策、谁负责执行回滚、回滚后如何与客户沟通。

在医疗合规系统上线时，我们真的启用了回滚剧本。上线后发现一个低频场景下的数据迁移脚本遗漏，导致部分历史数据的字段映射错误。因为回滚剧本已经预演过3次，我们在28分钟内完成全面回滚，客户甚至没有来得及发现异常。

五、不同项目规模下的瀑布实践取舍

并不是所有瀑布项目都值得投入同样力度的流程控制。基于项目规模和复杂度，我把瀑布实践分为三个级别：

对于100人以上的组织使用PingCode时，有一个功能点特别值得瀑布模型团队关注：迭代概览与燃尽图。虽然Scrum团队用燃尽图追踪Sprint进度，但在瀑布模型中，我们同样可以使用类似的进度可视化。把一个瀑布阶段（如编码阶段）看作一个“大迭代”，设置阶段起止时间，每日更新任务完成情况，燃尽图能直观地反映出阶段进度是否偏离计划。在MES项目中，正是通过燃尽图在第5周发现编码进度出现偏离趋势，我们才及时做了资源调配，避免了更大的延期。

六、瀑布与Scrum的交叉借鉴：实战中的实用主义

我不认同敏捷和瀑布是彼此对立的两极。在实际项目中，我们完全可以借用Scrum中的有效实践来弥补瀑布的短板。以下是我在瀑布项目中成功引入的三个Scrum实践：

1. 站立会议：打破瀑布阶段内的信息孤岛

瀑布模型容易陷入“各做各的”困境。在MES项目的编码阶段，我们每天上午执行15分钟的站立会议，形式完全参考Scrum，但议题做了调整：

• 昨天完成了什么设计/编码任务？遇到了什么阻塞？
• 今天计划完成什么？需要谁配合？（这一条在瀑布模型中特别重要）
• 有没有发现任何与设计文档不一致的地方需要讨论？

站立会议每天只需要15分钟，但它创造了一个日常的信息同步节点。在长达8个月的编码阶段中，站会帮助我们发现了至少30个需要跨模块协作解决的问题，这些问题如果留到集成测试阶段才暴露，修复成本会高出很多。

2. 故事点估算：给瀑布阶段加一个相对估算的锚

瀑布模型通常使用人天进行绝对估算。但人天估算有一个致命问题：不同开发者的“1人天”产出差异可能达到3倍。在公共资源交易平台项目中，我们尝试在需求阶段引入故事点估算作为辅助手段：

• 以最简单的CRUD功能为1个故事点基准。
• 所有用户故事由团队共同估算故事点，采用Planning Poker的方式投票。
• 将故事点转换为工时预估时，使用团队的历史速率数据校准，而不是拍脑袋。

这个方法让我们的工时预估偏差率从第一期的±45%降低到二期的±18%。对于后续项目，故事点数据也成为了宝贵的组织过程资产。

3. 回顾会议：在瀑布的结尾补上反思环节

敏捷的Sprint回顾是持续改进的核心机制。瀑布模型没有天然的回顾节点，所以我们在每个阶段结束时强制插入一次回顾会议，形式完全照搬Scrum回顾：

• 做得好的（Keep）：哪些实践应该保留？
• 做得不好的（Stop）：哪些做法应该停止？
• 可以改进的（Start）：下个阶段应该开始做什么？

需求阶段结束后的回顾会议帮助我们发现了“跟岗调研时间不足”的问题，在设计阶段开始前就调整了资源分配。如果没有这个节点，我们可能在后续阶段继续重复同样的错误。

七、工具链：PingCode在瀑布项目中的落地实践

瀑布模型对项目管理工具的需求与敏捷团队有所不同。敏捷团队看重的是看板可视化、迭代规划和燃尽图。而瀑布团队更需要：

• 需求追溯链：从顶层的史诗到底层的任务，再到代码提交和测试用例，一条完整的追溯链路。
• 文档与任务的关联：设计文档、接口契约、会议纪要等非结构化信息能够与任务关联。
• 跨阶段的工作流：一个用户故事从“需求分析”到“设计”到“开发”到“测试”到“验收”的完整生命周期管理。

在MES项目启动时，我们对比了三款主流的项目管理工具，最终选择了PingCode。选择理由和实际使用体验如下：

1. 需求追溯：从史诗到提交记录的一条线

PingCode支持史诗（Epic）→ 特性（Feature）→ 用户故事（User Story）→ 任务（Task）的四级拆解，这一点和Jira的层级结构类似。但它在瀑布项目中的独特价值在于与代码仓库和CI/CD流水线的深度集成。当开发者提交代码时在commit message中引用用户故事编号，PingCode会自动将提交记录关联到对应的用户故事上。

在一次需求变更影响分析中，业务方质疑一个数据校验规则的改动是否需要同步修改报表模块。我在PingCode中从需求追溯到原始用户故事、关联的设计文档、关联的代码提交记录，并定位到报表模块中使用了同一份校验逻辑，整个过程在4分钟内完成。如果使用传统的文档+Excel方式，同样的追溯可能需要半小时以上。

2. 迭代规划：将瀑布阶段映射为“大迭代”

PingCode基于标准的Scrum模型设计，但我们可以灵活地将其适配到瀑布场景。具体做法是：

1. 将整个瀑布项目的各个阶段（需求、设计、编码、测试）分别创建为独立的迭代。
2. 每个迭代有明确的起止日期和交付物清单。
3. 使用迭代概览页面实时跟踪阶段进度，包括完成的任务数、剩余的工作量、燃尽趋势。

在MES项目编码阶段中期（第5周），迭代燃尽图显示实际剩余工作量的下降速度明显慢于理想燃尽线。这个信号让我们比任何传统的周报更早地意识到进度风险，及时做了资源调配。

3. 评审与回顾：记录在迭代回顾板上的改进闭环

PingCode的迭代回顾功能支持记录会议中讨论的“做得好/做不好/改进计划”三个维度的内容。在瀑布项目中，我们在每个阶段结束时使用回顾板记录经验教训。形成的好处是：

• 改进计划可以转换为具体的任务，指定负责人和截止日期，不会出现“会上说得很好、会后没人跟进”的情况。
• 历史项目的回顾记录可以作为新项目的知识库，避免新团队重复犯同样的错误。

4. 多产品数据互通：Project + Testhub + Wiki的联动

PingCode旗下还包括Testhub（测试管理）和Wiki（知识库）等产品，这些产品之间的数据互通在实际使用中带来了效率提升：

• 在Project中创建的用户故事，可以直接在Testhub中关联测试用例，形成需求-测试的双向追溯矩阵。
• Wiki中沉淀的接口契约文档和设计决策记录，可以内嵌引用到Project的需求或任务中，避免信息孤岛。

在一次客户审计中，审计方要求我们证明“所有需求都有对应的测试用例，所有测试用例都有执行记录”。我们从Testhub中导出了一张需求-用例映射表，在PingCode Project中追溯了每个需求的完成状态，半小时内完成了审计证据的整理。

八、我的决策框架：什么情况下坚持瀑布，什么情况下考虑混合模式

经过三个从0到1的瀑布项目的洗礼，我沉淀出一个瀑布模型适配度评估的决策框架。在做任何新项目的方法论选择时，我都会先回答以下五个问题：

1. 需求是否可以在启动前完整定义? 如果可以确认80%以上的功能需求，瀑布可行；如果可以确认的比例低于50%，必须考虑混合或敏捷模式。
2. 需求变更的代价是否可以承受? 在B端复杂系统、合规性强的领域，变更代价极高，瀑布反而是保护团队的方式。在用户端产品上，需求变更是常态，瀑布会导致大量浪费。
3. 团队是否具备一次性做对的领域知识? 如果团队之前做过类似系统，有充足的领域经验，瀑布的效率更高。如果是探索性项目，用敏捷试错更合理。
4. 客户/合规方是否要求固定范围和交付时间? 这是硬约束，没有讨论空间。如果是固定总价合同，瀑布几乎是唯一选择。
5. 系统集成的复杂程度有多高? 如果需要对接大量外部系统，且这些系统的接口文档固定但缺乏弹性，瀑布的优势会更明显。

基于这五个维度的加权评分，可以得到一个项目的方法论倾向性评分。我的经验阈值是：

• 得分 >80分：纯粹瀑布模式，严格执行本文所述的所有机制。
• 得分 60-80分：瀑布为主体的混合模式，在编码阶段引入Scrum的站立会议和迭代回顾，但需求和设计阶段保持瀑布的严谨性。
• 得分
  <60分：不建议使用纯粹瀑布模式。可以考虑使用阶段性的瀑布+局部的敏捷迭代，或完全切换到敏捷开发框架。

结语：瀑布没有死，它只是变得更专业了

写这篇复盘文章的初衷，不是为了证明瀑布模型比敏捷更好，也不是为了说服谁一定要用瀑布。我只是想用亲身经历说明一件事：在大量行业和场景中，瀑布模型仍然是最务实、最有效的交付模式。它的最大问题不是“过时”，而是执行变形。

做得好的瀑布项目，需求阶段比敏捷团队更深入业务、设计阶段比敏捷团队更审慎周全、编码阶段因为设计质量高反而行云流水。做得差的瀑布项目，需求阶段走过场、设计阶段拍脑袋、编码阶段浑水摸鱼，最后在测试阶段把一切问题像圣诞节拆礼物一样集中爆发。

如果你正在或即将负责一个从0到1的瀑布项目，我想把三个最重要但最容易被忽视的建议留给你：

1. 不要害怕在需求阶段花时间。这个阶段多用一周，可能在测试阶段节省一个月。
2. 不要为了文档而写文档。文档的唯一价值是传递决策上下文。如果一份文档没有人会看第二次，它就不值得写。
3. 在团队中培养“对不可逆决策的警觉”。数据库选型、接口设计、核心算法，这些一旦做出就很难改的决策，值得花最多的讨论时间。

最后，如果你是100人以上组织的技术负责人，正在寻找一套能够兼容瀑布管理和Scrum敏捷实践的项目管理工具，我建议你实际试用一下 PingCode。它的需求追溯能力、跨阶段工作流、以及与Testhub和Wiki的数据互通，在瀑布项目的实践中给我带来了实实在在的效率提升。不管最终是否选它，至少它定义了一个好的项目管理工具在瀑布场景下应该具备的能力标准，你可以用它作为评估其他工具的参照系。

瀑布模型没有死。死掉的只是那些不愿意为“一次性做对”付出前期努力的团队。而真正的一次做对，从来不是靠运气，而是靠一套系统化的、可复盘的、持续迭代优化的工程方法论。希望这篇复盘能为你的下一个瀑布项目提供一些真实的参考。