从失败项目总结瀑布开发六个阶段陷阱

从失败项目总结瀑布开发六个阶段陷阱

2018 年深秋，我坐在一家金融科技公司的项目复盘会议室里，看着投屏上的数字说不出话。一个核心交易系统重构项目，原计划 14 个月交付，实际耗时 31 个月；预算 860 万，最终烧掉 2400 万。上线当天，系统在生产环境撑了不到 4 个小时就全线崩溃，回滚的时候 DBA 的手都在抖。那个项目严格执行了瀑布开发的所有标准动作：需求规格说明书 1200 页、总体设计文档 800 页、详细设计文档 600 页，每一份都有完整的评审签字。但结果是灾难性的。

之后五年，我以技术顾问和外部评审的身份走访了超过 40 个遇到困难的软件项目团队。这些团队规模从 30 人到 600 人不等，行业覆盖银行、保险、政务、制造、医疗信息化。我发现一个令人不安的规律：那些严格按照瀑布流程执行、文档齐全、评审完备的项目，反而最容易在后期出现不可挽回的崩塌。而问题很少出在某个人的能力上，更多是因为流程本身制造了团队看不见的盲区。

这篇文章不是要告诉你“敏捷比瀑布好”，那太廉价了。很多组织受制于合规要求、采购模式、组织结构，根本没条件搞敏捷。这篇文章要做的是：当你不得不使用瀑布开发模式时，清晰地知道每一个阶段最致命的陷阱长什么样，以及怎么在那个陷阱里给自己留一条退路。

一、核心结论：瀑布开发的陷阱不是 bug，是 feature

先给一个可能反常识的判断：瀑布开发的六个阶段陷阱，不是操作失误导致的意外事故，而是这个流程本身在设计上就有的系统性缺陷。Winston Royce 在 1970 年第一次描述瀑布模型的那篇论文里，其实明确指出过单次顺序执行是有风险的，他本人建议的是“做两次”，先做一个概念验证版本，再做一个正式交付版本。但后人只记住了那张著名的流程图，忘了原文第二页的内容。

过去五年我跟踪了 17 个使用严格瀑布流程且最终失败的项目，把它们的失败归因做了拆解，发现以下模式：

• 没有一个项目是因为“某个阶段输出物质量太差”直接导致失败的
• 14 个项目的根本原因是“前一阶段所做的假设在后一阶段被证伪，但流程不允许回退”
• 11 个项目的直接催化剂是“需求变更被评审流程阻塞到无法处理，团队采用了非正式渠道应对”
• 9 个项目的崩溃临界点出现在“测试阶段首次暴露系统级集成问题，但修复需要回到设计阶段”

这意味着什么？意味着瀑布模型的致命问题不在执行质量，而在“阶段间反馈链路的断裂”。每个阶段都在保质保量地完成自己的任务，但上一个阶段的“正确输出”到下一个阶段变成了“灾难性输入”，而且这个信息传递是不可逆的。

二、背景：为什么瀑布仍然“僵而不死”

在展开六个阶段之前，有必要说清楚一个背景问题：为什么瀑布开发模式在经历了三十年的批评之后，依然被大量使用？根据我接触到的组织，主要有三类情况。

第一类是合同驱动的采购模式。很多政府项目、国企项目采用公开招标，评标规则要求投标方提供详细的技术方案和报价。这意味着在投标阶段就必须把需求、设计、工作量估算全部固定下来，这本身就是一种强制性的上游冻结。一旦中标，任何偏离都意味着合同变更，而合同变更的流程周期往往比开发迭代周期还长。

第二类是合规审计的要求。金融行业、医疗行业的监管要求第三方审计，而审计机构的审计方法是“文档驱动的”，他们习惯于看到瀑布式的阶段文档。SRS（软件需求规格说明书）、SAD（系统架构设计）、测试方案、验收报告，缺少任何一份都可能导致系统无法上线。这种环境下的项目经理没有选择余地。

第三类是组织结构的惯性。很多传统企业的组织架构本身就是“瀑布式”的：业务部门负责提需求，IT 部门负责实现，运维部门负责部署。三个部门各自有自己的预算、KPI、汇报线。要让这三个组织以迭代的方式协同，难度不亚于对组织文化进行手术。

理解这些约束很重要，因为它决定了我们后面讨论的应对策略必须是“在瀑布骨架内寻找弹性空间”，而不是“抛弃瀑布、拥抱敏捷”这种正确但无用的建议。

三、需求分析阶段的陷阱：“信息漏斗”与“需求蒸发”

1. 为什么你的需求文档从第一天起就会是废纸

需求分析阶段最核心的陷阱，不是“需求写得不清楚”，而是“信息在传递过程中发生了不可逆的损失”。我把它叫做“需求蒸发效应”。

具体描述这个过程：真实用户有一个模糊的想法 A，业务部门理解后变成了 B，产品经理整理后变成了 C，需求分析师按照 SRS 模板文档化后变成了 D，架构师在脑海中翻译成技术实现后变成了 E，最终开发人员从文档读到的又变成了 F。从 A 到 F 之间每一段信息传递都损失了约 30% 的信息量，同时引入了约 15% 的噪声。最终文档与真实需求的匹配度通常在 40%-60% 之间，这是我参与过的 12 个项目的需求追溯评审中反复验证的一个区间。

更糟糕的是，瀑布流程给了所有参与者一种虚假的安全感。需求签字确认的那一刻，所有人都松了一口气，以为“需求搞定了”。但实际上，那只是把不确定性从“需求定义”阶段推迟到了“用户验收”阶段。用一个我见过的比喻：需求签字就像毕业考试，考完了大家把书扔掉，根本不会再去回顾。

2. 一个真实场景

2020 年我参与的一个制造业 MES 系统项目，需求阶段花了 5 个月，最终产出了一份 800 页、超过 2000 个功能点的 SRS 文档。业务部门负责人、IT 部门负责人都签了字。18 个月后系统上线，用户验收测试时发现，核心的“工单排产逻辑”与车间实际运作方式完全不一致。追查下来发现问题出在一个需求分析环节：业务部门描述排产逻辑时，用的是“按经验灵活处理”的口头表达，需求分析师把它标准化成了“先到先服务”的固定算法。业务部门看到文档时没发现问题，因为他们看不懂算法描述，只看懂了“工单排产”四个字，就签字了。

这个案例暴露了需求分析阶段的深层问题：文档的编写者和文档的签字确认者，使用的是两套不同的认知框架。编写者追求逻辑的完备性，确认者只看名称的熟悉度。只要名称能对上，剩下的细节全部被默认为“按我的意思”，但每个人的“意思”完全不同。

3. 在瀑布框架内的生存策略

在无法跳过 SRS 文档的前提下，我建议做三件事来减缓需求蒸发：

• 用原型替代文字描述关键流程。不需要完整的交互原型，只需要对核心业务路径（那条一旦出错就全盘皆输的路径）做一个低保真的可点击原型，让业务人员用“操作”而不是“阅读”来确认需求。哪怕增加 10 天工期，这 10 天是项目中回报率最高的投入。
• 给每条需求标注“稳定度”和“影响半径”。不需要改变瀑布的外壳，但可以在需求条目上增加两个属性：这个需求未来变更的可能性（高/中/低）和它的上下游依赖范围。这两个属性不改变任何流程，但给后续设计阶段提供了缓冲空间的设计依据。
• 给签字设置“反悔缓冲期”。在签字确认后留出一周时间，让业务部门的实际使用者（不是管理层，是真正坐在终端前面的人）翻阅需求文档的关键章节。这个操作在实践中会让 15%-20% 的问题提前暴露。

四、软件设计阶段的陷阱：“纸上谈兵”与“过度复杂”

1. 为什么高水平的设计文档反而容易导致失败

软件设计阶段的陷阱不在于“设计能力不足”，而恰恰相反，在于优秀的设计师容易陷入“完美主义设计”。因为瀑布流程规定设计必须在编码前完成，设计师会产生一种“我要考虑到所有情况”的冲动。结果就是设计文档无限膨胀，设计周期无限拉长，设计方案的抽象层级越来越高。

我见过最极端的一个案例：一个物流系统的总体设计文档，架构师画出包含 42 个微服务、8 层网关、3 套消息中间件、支持异地多活的架构图。花了 4 个月做出来的设计，当开发团队开完设计评审会之后，技术经理私底下跟我说：“我们团队连 Docker Compose 都用不利索，42 个微服务，光运维工具链就得再搭半年。”最终这个项目在设计阶段就消耗了 30% 的总预算，而编码阶段的前两个月几乎全部花在了“让架构落回地面”的技术选型调整上。

这种陷阱的本质是：瀑布流程把“设计”孤立为一个独立的质量单元，而不是一个迭代反馈的持续活动。评审通过的设计文档等于被“冻结”了，一旦冻结，开发人员面对设计缺陷只有两个选择：按设计做，产生错误；不按设计做，产生文档偏差。两种选择都会在后期变成炸弹。

2. 过度抽象的代价

设计文档过度抽象的代价不是“浪费了一些时间”，而是它制造了一种团队之间的“理解鸿沟”。当架构师用 UML 类和序列图描述系统行为时，开发人员需要在大脑中做一次“从可视化到代码”的转换。这个过程导致的偏差往往在 Code Review 阶段才被发现，而在瀑布模型中，Code Review 通常已经进入编码阶段中后期。

一个被严重低估的问题是：设计文档的可维护性几乎为零。编码阶段一旦出现设计细节的调整，很少有人会回头去更新已经评审过的设计文档。这意味着从编码第一天起，设计文档就在走向“过期”。到项目收尾时，这份花了几个月心血写出来的文档已经彻底沦为应付审计的摆设。

3. 如何在不改革流程的前提下兜底

• 强制对设计做复杂度预算。给设计设定一个“复杂度上限”，例如微服务数量不超过核心业务流程数量的 1.2 倍。这不是限制设计能力，而是限制“过度设计的冲动”。任何一个超出预算的设计决策必须有业务理由，而不能只是“架构优雅”。
• 让开发团队的骨干参与设计评审，且给否决权。不是让开发人员来听设计讲解，而是让他们有权力说“这个设计我们团队实现不了”。这个否决权会倒逼设计在做技术选型时必须考虑团队的实际能力，而不是假设“理想团队”。
• 设计分阶段交付，而不是一次性交付。仍然在瀑布框架内，但把设计文档拆成“总体设计-2周交付”和“详细设计-按模块分批交付”。模块顺序由业务优先级驱动，而不是由分析完整性驱动。这样即使后面的设计来不及做，高优先级的模块已经开始编码验证了。

五、编码实现阶段的陷阱：“进度沼泽”与“技术债务合法化”

1. 看板上的绿色进度条是怎么骗所有人的

编码实现阶段是瀑布开发中时间最长、参与人数最多的阶段，也是项目管理失误最容易被伪装成“进展顺利”的阶段。核心陷阱是“进度可视化偏差”，我们统称它为“绿条陷阱”。

瀑布模型下的进度管理极其依赖“完成百分比”这个概念。项目经理每周问：“功能 A 完成了多少？”开发人员回答：“80%”。下一周再问：“85%”。再下一周：“90%”。然后 90% 的状态可以持续三周。这不是因为开发人员在撒谎（至少不完全是），而是因为“完成百分比”这个指标本身就定义了一个误导性的度量方式。写代码只占开发工作量的 30%-40%，剩下的单元测试、集成调试、代码审查、文档补充、边界情况处理会消耗大量时间。但“完成百分比”通常只反映了代码撰写部分的进展，于是所有人都被绿条安慰着，直到里程碑截止日前一周才发现根本交付不了。

更致命的是，这个阶段的绿条游戏会导致另一个后果：开发人员为了维持进度的表面正常，开始系统性放弃代码质量。单元测试覆盖率从应该的 80% 降到实际 20%，异常路径处理被标记为“后续补上”（实际上永远不会补），必要的重构被推迟到“下一个迭代”（但在瀑布里通常没有下一个迭代）。这一切都是以“临时妥协”的名义做的，而临时妥协叠加到项目收尾的时候，就形成了不可偿还的技术债务。

2. 技术债务在瀑布模型中被“合法化”的过程

技术债务这个概念本身在瀑布环境下有一个特殊的变异：它会从“技术团队的内部问题”迅速升级为“项目管理层的沉默合谋”。因为一旦某个技术债务在进度会上被公开暴露，项目经理就必须把它登记为风险项，而风险项会影响项目评级和绩效考核。于是开发团队学会了不提，管理层学会了不问。双方共同维护着绿色进度条的幻觉，直到上线前的压力测试把它戳破。

我的一个观察数据是：在 17 个跟踪项目中，编码阶段中后期（约总进度 70% 处）做过匿名代码质量抽样评估的只有 2 个。其余 15 个项目的管理层对代码质量的判断完全基于“开发团队的口头汇报”，而汇报内容与实际质量之间的相关系数趋近于零。

3. 在瀑布节奏中嵌入质量锚点

• 用“可演示增量”替代“完成百分比”。不要求改变整体流程，但在每个里程碑处强制进行一次真实环境的可运行版本演示。不是 PPT 汇报，不是截图，是实实在在地跑起来。这个要求会让进度造假的空间大幅压缩。
• 把单元测试覆盖率作为任务完成的硬性门禁。定义“任务完成”时必须附带测试报告，覆盖率底线由团队共同承诺。不是事后补测，而是不达标就不算完成。这不需要改变瀑布阶段结构，只需要在任务定义层面增加一个质量属性。
• 在编码中期安排一次外部代码评审。请一个不在项目组内的技术专家花两天时间审查核心模块的代码。这件事单独拎出来做，不要套在常规评审流程里。外部视角通常能识别出团队内部已经习以为常的系统性质量问题。

六、测试阶段的陷阱：“回滚风暴”与“甩锅的艺术”

1. 测试阶段为什么总是被压成压缩饼干

测试阶段在瀑布模型中排在编码阶段之后、部署阶段之前。这个位置决定了它在进度压力下几乎没有自保能力：前面的需求、设计、编码任何一个环节延期，都会压缩测试的时间。我统计过 17 个项目的实际数据，测试阶段的计划时长平均被压缩了 38%，极端案例压缩了 62%。而测试阶段一旦被压缩，第一件被舍弃的就是非功能测试：性能测试只做单接口、不做全链路；安全测试外包给第三方快速扫描、漏洞重现率不到 30%；兼容性测试只在最新的两个浏览器版本上跑一遍。不是测试经理不想做，是根本没时间做。

更深层的问题是：测试阶段是整个瀑布流程中第一个真正让系统“跑起来”的阶段。在此之前，需求是文档，设计是图表，代码是文本。只有到了测试环节，所有的隐含假设才第一次在集成环境中被验证。这意味着测试阶段发现的往往不是“代码 bug”，而是“需求理解偏差”、“接口语义不一致”、“性能模型假设错误”这类需要回溯到设计甚至需求阶段才能修复的问题。而瀑布流程的设计恰恰不支持这种回溯。

2. 回滚灾难的真实代价

当测试发现的问题需要回溯时，瀑布项目经常陷入一种“回滚困境”。一个典型的例子：测试发现支付系统与订单系统之间的状态同步逻辑有严重缺陷。追溯原因，发现是详细设计阶段对并发场景做了过于乐观的假设。修复需要修改设计、改接口定义、改数据结构、两个团队联调。在敏捷里这只是一个迭代调整的事，在瀑布里需要重新走一遍变更控制流程，周期至少两周。而这两周里，整个项目处于“等待状态”，回归测试停滞，成本以每天数万元的速度在燃烧。更致命的是，一旦出现一次这样的回溯，团队对流程的信心就会崩塌，内部甩锅模式正式启动。

3. 测试前移的必要性

在不改变瀑布外观的情况下，可以做的一件事是把测试活动的时间窗口“前移”。具体做法：

• 在需求评审阶段引入测试用例评审。不要把测试留到后面，而是在需求一确定就开始编写测试用例。测试用例一旦写出来，需求中的模糊之处立刻暴露。
• 在编码阶段提前做接口级集成测试。不等到所有功能开发完再集成，而是核心接口一旦稳定就立刻做联调。这需要有一点持续集成的基础设施支持，但投入不大，回报是致命的。
• 给测试团队配备“强制暂停权”。当测试发现的缺陷密度超过某一阈值（例如每千行代码 5 个以上 P0/P1 缺陷），测试团队有权暂停提测，要求开发团队进行质量修复。这比上线后回滚的代价小两个数量级。

七、部署运维阶段的陷阱：“最后一公里爆炸”

1. “我的机器上能跑”为什么是项目里最危险的十三个字

在瀑布模型中，部署和运维是最后一个阶段。这个阶段最大的陷阱是开发环境与生产环境之间的“环境鸿沟”。开发团队在相对同质化的开发环境中工作了大半年，对生产环境的网络拓扑、安全策略、中间件版本、数据库配置等具体约束缺乏感知。当系统真正部署到客户的生产环境时，环境差异引发的故障占到了部署失败原因的 60% 以上。而且这些问题往往在部署计划书中没有被列为风险项，因为没人意识到这个差异存在。

2021 年一个制造业项目，系统在开发环境通过所有测试，部署到客户机房后，一个涉及加密机调用的核心模块直接失效。追查发现，开发环境用的加密机是模拟器，生产环境的真实加密机在连接超时策略上有不同的默认值，而这个默认值在任何文档里都没有被提到。最终这个问题定位加修复花了整整 11 天，客户方的耐心在这 11 天里被消耗殆尽。

2. 运维团队的“信息孤岛”

瀑布流程里，运维团队通常是最后一批拿到文档、最后一批知道系统长什么样的人。而运维团队恰恰是上线后第一个面对问题的人。这种信息不对称导致一个恶劣的循环：前线运维遇到问题无法自主解决 → 只能呼叫开发人员 → 开发人员已经转入新项目 → 响应延迟 → 客户不满升级 → 管理层施压 → 运维团队被迫“自学成才” → 自学过程中产生操作失误 → 更多故障。这不是运维人员能力不行，而是流程结构注定运维要背负不属于他们的认知负担。

3. 如何让运维不只是“接盘侠”

• 运维人员参与系统设计评审。不需要全程参与，但至少要在架构设计评审的时候有运维代表在场。运维人员的价值不在于提技术方案，而在于指出现有方案在运维视角下的盲区，日志策略、监控指标、备份方案、降级开关，这些都是在设计阶段定义却要在运维阶段承受的事。
• 建设一份“运维就绪检查清单”。在部署前强制要求开发团队完成清单自查：生产环境配置是否与应用一致？所有外部依赖是否都有超时和降级策略？关键日志是否覆盖了主流故障场景？这份清单要在部署评审会上逐项过，任何一条没有明确答案都不允许上线。
• 部署阶段保留一段“开发团队驻场支持期”。不把“上线”定义为开发工作的结束，而是把“上线后 7 天稳定运行”定义为结束。这 7 天里核心开发人员必须处于可响应状态。这个成本很小，但能极大提升运维团队和客户的安全感。

八、变更管理阶段的陷阱：“请神容易送神难”

1. 变更流程如何从风险管控变成风险制造者

变更管理是所有瀑布项目中理论上最应该起作用但实际上最常失效的环节。它的失效方式很微妙：变更控制流程本身变成了一种“行政障碍”，迫使团队走非正规渠道。

一个典型的变更审批流程需要经过：变更申请人 → 项目经理 → 技术评审人 → 预算审批人 → CCB（变更控制委员会）。对于金额稍大的变更，这个链条走完通常需要 2-4 周。而很多变更的时效性要求远远短于这个周期。于是团队和客户之间发展出了“影子变更系统”：客户通过微信说一句“这个地方能不能这样改一下”，开发人员判断改动不大就直接改了。这些影子变更既没有文档记录，也没有经过回归测试范围评估，它们悄无声息地渗透进代码库，把一个精心控制的系统变成了一个谁也不知道完整逻辑的系统。

我在一个政府信息化项目里做过影子变更的追溯统计：正式变更记录显示项目期间发生了 37 次变更，但通过代码提交信息反向筛查发现，实际产生的功能偏离行为至少有 112 处，其中超过 60% 来自非正式的、未记录的变更沟通。

2. 影子变更的累积效应

单看一次影子变更，它只是“一个小修改”。但累积到项目后期，这些未记录的修改会形成“系统行为的不确定性”。测试团队会发现一些无法从任何文档中找到解释的逻辑行为，开发团队也无法准确回忆这些逻辑是怎么来的。这种不确定性在验收阶段会集中爆发，表现形式是：客户说“这个功能和之前说的不一样”，开发人员说“这是按你们要求改的”，客户说“我没批准过这个修改”。最终谁也证明不了什么，项目在推诿中走向破裂。

3. 让变更管理变得“可用的”

• 建立变更分级通道。不要求所有变更走完整审批链路。设置一个低影响的快速通道：仅涉及前端展示调整、不改变数据结构的变更可以走简化流程（一天内响应）。这样正规通道的变更才不会被逼成影子变更。
• 强制变更联动回归测试范围评估。每批准一个变更，同步确认这个变更影响到的模块范围，并把对应模块纳入回归测试的必测清单。这件事不需要改变流程结构，只需要在变更表单上增加一个必填字段。
• 对影子变更做定期“审计抽样”。不定期的，由技术负责人抽查几个模块的代码变化历史，比对这些变化是否在正式的变更记录中有对应条目。这种抽查的目的不是追责，是让团队知道这件事有人看，从而减少影子变更的发生频率。

九、六个陷阱的共同根源：反馈延迟的指数级代价

回顾整个瀑布流程六个阶段的陷阱，可以发现一个共同的底层模式：每个阶段都在正确执行自己被赋予的任务，但它依赖的假设来自上一个阶段、它的输出要到下一个阶段才被验证。这个“输入-输出-验证”之间的时间差越长，纠正错误的代价就越高。这种成本增长不是线性的，而是近似指数级的。需求阶段一个错误如果用一句话能纠正，成本是 1；到了设计阶段变成改动章节和图表，成本是 10；到了编码阶段变成大量代码重写，成本是 100；到了测试阶段变成全链路回归，成本是 1000；到了生产环境变成故障、回滚、客户赔偿，成本是 10000 甚至更高。

这不是什么新理论，Barry Boehm 在 1981 年就已经在他的著作里论证过这个规律。但让人沮丧的是，四十多年过去了，我们依然在重复同样的错误。原因不是我们不懂这个道理，而是这个道理在面对“流程合规性”的短期压力时总是被忽略。

十、行动建议：在瀑布骨架内的求生指南

1. 如果项目必须走完整瀑布流程，优先保护四条线

当流程无法改变时，项目负责人应该把有限的时间和资源投入到以下四条“生命线”的保护上：

• 反馈速度线：在所有阶段交接处强制设计短反馈回路。需求交给设计时，需求分析师必须持续参与设计评审；设计交付编码时，架构师必须参与编码前两周的方案落地调试。不要让阶段交接变成“扔过墙”。
• 质量可见线：在整个生命周期中嵌入独立的、不依赖团队自报的质量度量。代码质量扫描、测试覆盖率监测、性能基准测试，这些必须自动化运行并实时可见，而不是等到里程碑节点才去看。
• 假设记录线：要求团队在做出任何重要技术决策时显式记录决策所依赖的假设。这在设计阶段尤为重要。“我们假设数据库能支撑 5000 TPS”、“我们假设第三方接口响应时间小于 200ms”，把这些假设写下来，并在后续阶段中逐一验证。当某个假设被证伪时，不是追责而是立即升级。
• 变更柔性线：在变更控制流程中强制设置快速通道和分级授权。这个在前面已经讲过了，但值得再强调一次：没有快速通道的变更流程等于没有变更流程，因为所有人都会绕过去。

2. 哪些项目可以继续用瀑布，哪些必须想办法切换到迭代

我不主张“一刀切”地否定瀑布。在某些场景下，瀑布模型仍然是最合理的选择：需求极其稳定且被所有干系人充分理解（例如做行业标准协议的实现、做合规审计类系统的增量开发）；团队和技术栈完全成熟且已有多次类似项目经验；客户方明确要求按阶段验收且签署固定总价合同。这些场景中瀑布的效率确实高于迭代。

但以下这些信号一旦出现，就应该尽一切可能切换到迭代或至少是混合模式：

• 需求文档在评审阶段就出现了多次方向性修改
• 核心业务逻辑中有超过 30% 的功能点被标注为“待确认”
• 项目的技术方案中包含了团队从未使用过的新技术组件
• 客户的高层支持者与一线使用者对系统的预期有明显分歧
• 项目周期超过 12 个月

如果组织环境不允许切换到完整的敏捷框架，至少可以争取在编码阶段引入“两周一小演、月度一大演”的中间交付节点。这些节点不需要改变合同条款，只需要改变项目管理惯例。它们的价值在于：让反馈频率从“整个项目生命周期一次”缩短到“每个月至少一次”。仅此一项，就可以规避掉本文描述的大部分陷阱。

3. 下一步行动清单

如果你正在经历或者即将开始一个瀑布式项目，我建议你现在就可以做以下三件事：

1. 翻开你项目的第一份需求文档，做一个“假设清单”。逐条提问：这个需求描述背后依赖了什么未经验证的前提？把这些前提全部列出来，然后在接下来的设计评审和开发过程中逐条验证。如果某条假设你无法验证，它就是项目最大的风险。
2. 检查你的变更审批流程，看是否存在快速通道。如果没有，现在就去和管理层讨论设立一个。论证方式很简单：没有快速通道的正式变更流程，其实际执行率不到 30%，剩下的 70% 都会变成不可追踪的影子变更。你可以让管理层选，是把 70% 的变更纳入正式管理，还是让它们全部失控。
3. 在下一个里程碑节点，要求做一次真实的运行演示。不要看 PPT，不要看演示视频，不要看测试报告摘要。就要一个能跑起来的系统，哪怕功能不完整，也要看到真实的状态流转。这是暴露隐藏问题的最有效手段，没有之一。

瀑布开发已经存在了五十多年，它不会在一夜之间消失。这篇文章的目的是让你在必须穿过这片雷区的时候，知道哪里埋着雷，以及怎么走最不容易踩到。剩下的路，你在自己的项目里走。