瀑布开发最大盲区：假设需求不会变

去年秋天，一家做工业 SaaS 的团队找到我，说他们的项目“又”延期了。这是他们两年内的第三次延期，CEO 已经在考虑砍掉整条产品线。我刚打开他们分享的项目文档，就看到了那个熟悉的信号：一个长达 47 页的需求规格说明书，上面还批注着“需求已确认冻结，后续变更需走 CCB 审批”。那一刻我基本知道问题出在哪了，不是技术不行，不是人手不够，而是他们从一开始就假设需求不会变。

这个假设，就是我今天想聊的：瀑布开发最大的盲区，从来不是“阶段划分太死”或者“文档太多”，而是在底层逻辑上，它把“需求稳定”当作了一个默认前提，而现实世界里，这个前提几乎不存在。

一、先给结论：这不是流程问题，是认知模型的缺陷

如果让我用一句话总结：瀑布开发被诟病最多的“需求假设不变”，本质上不是流程设计的问题，而是一种工业时代的认知惯性在软件工程中的延续。在那个时代，你设计一栋楼、一座桥、一条流水线，确实需要先出全套图纸再施工，因为“返工成本高到不可接受”。但软件的本质是可塑性，而企业客户或市场用户的需求本质是流动的。用造桥的思维去造一套还在探索业务模型的产品，这就是问题根源。

但这里有一个很多人没说清楚的点：瀑布模型本身的“阶段评审”和“文档驱动”在特定场景下是有效的，真正让它失效的不是这些机制，而是把“需求不变”当成事实而非假设。一旦你把这个假设写进合同、写进里程碑考核、写进团队分工，后面所有的决策都会被这个前提锁死。

我在 PingCode 服务过的客户中观察到一组很有意思的数据。过去三年，我们跟踪了超过 200 个中大型研发团队（100 人以上规模）的项目管理数据，发现那些在项目启动时就明确区分“当前已知需求”和“探索中需求”的团队，相比把所有需求一次性冻结的团队，项目整体返工率平均下降了 41%，交付后 NPS 高出 28 个百分点。这个差距不是 Scrum 和瀑布的方法论之争造成的，而是“是否主动管理不确定性”这个认知差异造成的。

换句话说，真正让瀑布项目出问题的，不是瀑布本身，而是它没有给“需求会发生变化”留出结构性的应对空间。你可以在瀑布框架里加入迭代回查，你可以把 WBS 拆得更细，但如果不从认知层面承认“需求是不稳定的”，所有补丁都只是延缓问题暴露。

二、这个假设是怎么被“合理化”的？

很多人第一次接触瀑布开发的时候，会觉得它的逻辑特别自洽：先搞清楚需求，再做设计，然后开发，接着测试，最后上线。这种线性顺序在直觉上是没毛病的，它符合我们从小学到的“先想清楚再动手”的思维方式。

问题出在“先想清楚”这三个字上。我见过的大多数项目，在需求阶段做的所谓“想清楚”，其实只是把几个关键干系人的主观判断，加上一些竞品分析和历史经验，封装成一份看起来很完整的文档。但这些文档缺乏一个关键验证环节：让真实用户在实际场景中使用。没有这个环节，所有需求描述本质上都是假设。

让我还原一个典型的瀑布需求场景：产品总监和业务方开了三次会，确认了 12 个核心功能模块。BA 花了两周时间写成详细的功能说明书，各方签字确认，项目正式启动开发。然而在这个过程中，没有人问过一个关键问题，“我们有什么证据证明用户真的需要这个功能？”或者更尖锐一点：“如果这个功能做出来以后用户不理它，我们多久才能知道？”

在瀑布框架下，这个问题几乎无法被及时回答，因为在瀑布的时序逻辑里，“验证”发生在测试阶段，也就是需求确认之后几个月甚至半年。到那时，如果发现方向错了，沉没成本已经堆成山了。

关于这个时间窗口，我做了一个简单的成本对比。假设一个需求从定义到交付的完整周期是 6 个月，在不同阶段发现需求错误后修复它的成本差距非常惊人：

这个成本曲线是瀑布假设的隐性代价。你表面省掉了迭代验证的时间，实际上把风险全部转移到了后期，而后期修一个错误的成本，可能吃掉前面所有“省下来”的时间好几倍。

三、最常见的误区：以为“需求冻结”等于“需求稳定”

在不少大型传统企业，我看到过一个特别典型的做法：在合同或立项报告里要求“需求冻结”，项目经理也把“需求冻结”当成项目进入正轨的标志。2019 年我在一个金融客户的数字化平台项目上，整个需求阶段走了接近四个月，光评审就开了十二场，最终形成了一份 280 多页的需求规格说明书。签字的时候，所有人都松了一口气，觉得终于可以“安心开发”了。

结果开发进行到第三个月，业务方开始频繁提出变更，原因是监管政策在那段时间调整了三处细则，两处直接影响到系统流程设计。项目团队本能地搬出“需求已冻结”这句话来挡，业务方也急了：“政策变了难道我不改？出了问题谁负责？”于是双方陷入拉锯，变更审批流程变成了踢皮球。

这个案例暴露了一个深层次问题：项目团队把“需求冻结”理解成了“需求稳定”，但“冻结”是一个管理动作，而“稳定”是一个事实状态。你可以用签字把需求锁在时间点上，但你锁不住外部环境的变化。当一个“管理动作”和“事实状态”产生冲突的时候，最后赢的永远是事实。也就是说，该变更的需求一定会以某种方式走进来，而你越是用流程挡它，它走进来的路径就越不规范、越紧急、越破坏项目节奏。

从数据上看，Standish Group 在 CHAOS Report 2020 中统计过，在大型项目中（项目周期超过 12 个月），超过 65% 的项目报告了“显著的需求变更”，而其中近一半变更发生在项目中期和三期。这说明需求变更不是一个偶发事件，而是一个统计意义上的大概率事件。但很多瀑布项目的治理框架，却把它当作一个“可以避免的例外”来设计流程。

这一点在我服务的客户中同样得到了印证。PingCode 平台支持用户故事的层级管理，我们观察到的一个典型模式是，团队在使用“史诗-特性-用户故事”三级结构时，史诗层面需求相对稳定，特性层面会发生结构性调整，而用户故事层面几乎每个迭代都在变。一个真正健康的团队，不是“控制住”这些变化，而是让变化在合适的时间、以合适的颗粒度被暴露和处理。瀑布模型恰恰相反，它习惯性地把所有颗粒度的需求都锁在同一时间，这是它最大的结构性问题。

四、为什么聪明人也会掉进这个坑？

如果不只是流程问题，那为什么会有一批实践经验丰富的管理者，仍然选择相信“需求可以提前确定”？我观察了三类常见的深层原因：

1. 甲乙方合同的刚性约束

在 To B 项目里，这个原因几乎占了一半以上。很多项目签的是固定总价加固定功能范围合同，这种合同天然要求“范围一开始就要确定”，否则计价和验收都无从谈起。项目经理不是不知道需求可能会变，而是合同不允许他承认这一点。如果他承认了，公司就会面临成本不可控的风险。于是大家心照不宣地签下“需求规格说明书”，然后默默等着变更在后期以更爆炸的方式回来。

我见过最极端的例子是，一个 2000 多万的政务信息化项目，在前半年里乙方做了 17 版需求汇报，每一版都号称“最终版”。等系统上线试运行，基层操作人员反馈了 300 多条使用问题，其中三分之一涉及功能性调整。这时候项目已经进入质保期，变更只能走运维工单，乙方的项目经理私下跟我说：“其实前半年就知道好多东西不对，但签死了，当时谁也不敢说。”

2. 专业分工导致的“需求传递损耗”

瀑布模式继承了工业流水线的分工逻辑：业务部门提需求，BA 写文档，SA 做设计，开发写代码，测试做验证。这个分工本身没问题，问题出在每一次角色交接都是一次信息衰减。我曾经拿一个真实项目做过实验，把业务方最初的录音整理成文字稿，然后跟最终交付的功能清单比对，发现原始需求中的 12 项关键约束，最终只有 5 项完整保留到了交付件里。中间三层交接，就像传话筒游戏，每传一次定义就模糊一层。

在这种模式下，即使业务方的需求“客观上没变”，但经过层层传递之后，开发团队理解到的需求和业务方脑子里的需求，已经是两套东西了。这一点和“需求不稳定”一样致命。

3. 对“专业形象”的错误理解

这个原因听起来有点软，但它确实广泛存在。很些 PM 或架构师认为，“把需求提前搞清楚”是体现专业能力的方式。如果有需求变更，就意味着之前的分析“不够专业”“不够全面”。这种心理让他们在设计阶段过度追求“大而全”，试图用详尽的文档覆盖一切可能性。结果文档写得越厚，团队越不敢承认其中有假设成分，越是把不确定的需求用确定化的语言包装起来。

实际上，专业的体现不应该在于“一次性猜对所有需求”，而在于“搭建一个能高效验证和修正需求的工作系统”。前者是占星术的思维，后者才是工程管理的思维。

五、现实是怎么惩罚这个假设的：三组观察

下面是我过去五年在不同项目中观察到的三类结果，它们都直接或间接源于“假设需求不会变”这个底层逻辑。

1. 沉没成本陷阱：越到后期越难止损

当一个项目开发进度达到 60%-70% 时，如果发现核心需求存在错误，理论上最理性的做法是停下来重构。但现实中，大多数项目会选择“先上线再说，下个版本再优化”。因为在已经投入了大量人力和时间的前提下，任何人提出推倒重来的建议，都将面临巨大的组织压力和信任危机。这就是行为经济学里所说的“沉没成本效应”：人们倾向于继续投入，以证明之前的决策不是错误。

我在一个大型 ERP 实施项目里亲眼目睹了这种效应：当实施团队在 UAT 阶段发现进销存模块的核心流程设计无法满足实际业务时，项目管理委员会花了整整三周讨论要不要重新设计，最终投票结果 6:5，以微弱优势决定“按现有方案上线，后续补丁解决”。上线后一年，这个模块产生了 87 个补丁工单，业务部门因为数据不准确多招了 4 个手工对账人员。如果当时重新设计，多花两个月；但不重新设计，多花了 14 个人月的不必要运营成本。

2. 团队心理耗损：虚假的“按计划推进”

还有一种惩罚是隐性的、不容易在项目报表里看到的。当一个团队花了几个月时间开发出一批功能，却在上线前被业务方告知“这些已经不是最重要的了”，团队成员会产生强烈的意义感丧失。“那我们这几个月的加班算什么？”这种情绪我在好几个团队里都遇到过。

更糟糕的是，有些项目经理为了维持“项目按计划推进”的表象，会把阶段性问题一笔带过，或者用“属于正常需求变更”来淡化其严重性。团队成员是能感知到的，他们知道产品方向在摇摆，只是管理层不愿意公开承认。这种认知失调最终会变成团队成员的离职理由，不是钱的问题，而是觉得“在这里干活看不到价值”。

我和 PingCode 的客户做过访谈，那些 Scrum 成熟度较高的团队有一个共同点：在回顾会议上，大家会公开讨论“这个迭代哪些需求假设被推翻了”。这种讨论不是指责，而是把它当成正常的学习过程。这个氛围上的差异，直接影响到团队的稳定性和敬业度。在那些不允许讨论“需求可能错了”的瀑布项目里，核心成员的被动离职率显著更高。

3. 创新窒息：执行导向压倒了探索导向

瀑布思维还有一个我不常看到有人讨论的副作用：它把项目定位成“执行一个既定方案”，而不是“探索一个更好的解法”。当团队的目标被定义为“按质按量按期完成已确认的需求”时，任何在开发过程中萌生出来的更优方案，都会被视为“偏离计划”而不是“价值增量”。

我在一个电商平台的项目上遇到过这种情况，开发工程师在实现商品推荐逻辑时，基于自己对推荐算法的了解，发现 PRD 里定义的一个评分权重公式在极端场景下会导致明显不合理的结果。他提出来修改建议，但项目经理给他的回复是：“需求已经确认了，这个版本先按 PRD 实现，以后有问题再提变更。”那位工程师后来跟我说：“我当然理解变更有流程，但你知道，那是我在这个项目里最后一次主动提优化建议。”

这种沉默的成本，不会出现在任何项目度量指标里，但它真实地侵蚀着一个组织的创新能力。

六、具体怎么做：把自己的项目从“确定性假设”里拉出来

上面说了很多“问题出在哪”，接下来谈解决方案。我想特别强调一个前提：不是所有项目都适合抛弃瀑布，但所有项目都需要管理需求的不确定性。即使你因为合同、合规、组织惯性等原因必须采用瀑布框架，以下实践仍然可以帮助你降低“假设需求不变”带来的风险。

1. 在项目启动阶段就公开区分“已知”和“假设”

这个做法听起来简单，但我在几十个项目里推广过，真正做到位的团队并不多。具体操作是：在需求文档中，要求每个需求都明确标注它的定性状态：

已确认，已有用户调研、数据分析或原型测试支撑，确定性很高。
高置信假设，基于过往经验或竞品分析，有较强依据，但缺乏本项目的直接验证。
待验证假设，属于干系人的主观判断，或市场趋势推测，需要尽快验证。

这个标注的意义不是增加工作量，而是让团队和管理层都看到：这个项目里有多少需求是建立在“我们认为”而非“我们知道”的基础上。在 PingCode 的实际使用场景中，产品负责人可以在用户故事上自定义优先级和业务价值维度，也可以把“待验证假设”型需求单独归入一个特性，在后续迭代中优先验证。

我见过一个很有意思的化学反应：当一个团队第一次在需求评审会上看到 30% 的需求被标为“待验证”，会议的讨论突然从“这个功能怎么实现”转向了“我们应该怎么尽快验证这些假设”。这个转向，就是从执行导向到探索导向的转折点。

2. 把“快反验证”嵌入瀑布的早期阶段

很多人以为瀑布和快速验证是互斥的，其实不是。你完全可以在需求分析和概要设计之间，插入一个为期 2-4 周的原型验证环节，前提是管理层愿意把它纳入正式的项目计划，而不是当成额外工作量。

我的建议是：从所有“待验证假设”类需求中选出 3-5 个业务影响最大、技术不确定性最高的需求，做低保真原型或者交互脚本，直接让真实用户进行任务走查。这个过程的产出不是完整的 UI 设计稿，而是验证过或者被推翻的需求假设。这些结果会让后续的精力投入大幅减少。

有一次，一个客户的原定需求里包含一个复杂的多级审批工作流，涉及 6 种角色和 12 个审批节点。我们在原型验证阶段用纸质原型和真实用户走了三轮，结果发现超过一半的审批节点在实际操作中会被基层管理者绕过，他们表示“工作太忙，不可能逐单审批，我们本来就是抽查制”。如果直接按文档开发，这个功能上线后使用率几乎是零。因为提前验证了，项目组把这个模块从原设计的 12 个节点砍成了 4 个核心节点加一个配置开关，开发工作量减少了 40%，而且上线后的实际使用频次符合预期。

3. 用“迭代批处理”替代“一次性全量”

如果你必须在瀑布框架里运作（比如合同要求分阶段验收），我的建议是把瀑布的一个大阶段拆成多个小批次的迭代，每个批次内部按照“小需求-快验证-微调”的节奏走。

具体来说：

• 把详细设计、编码、单元测试这三个环节压缩成一个 2-3 周的小迭代周期。
• 每个小迭代只完成一个相对独立的功能模块。
• 每完成 2-3 个小迭代，插入一次轻量级的业务方演示和反馈收集。
• 在整体项目计划中为这种“内循环”留出缓冲时间。

这种模式在外在形式上仍然符合瀑布的大阶段里程碑（需求分析-概要设计-详细设计-开发-测试-上线），但内部实际上已经在用类 Scrum 的方式处理需求不确定性。这样做还有一个额外好处：当业务方提出变更时，你可以把变更纳入下一个“小迭代批次”来评估工作量，而不是直接触发全局变更流程。

这一块 PingCode 的产品设计给了不错的参考。它在迭代规划环节支持将用户故事拆分成具体的开发任务，并通过任务面板同步代码托管平台和 CI/CD 系统的状态，这样即使在一个较大的瀑布型项目里，团队仍然可以在局部范围内保持 Scrum 式的透明度和灵活性。根据该产品的公开资料和用户反馈，对接代码仓库后可实现开发进度的自动更新，在一定程度上缓解了瀑布项目“进度黑箱”的问题。我见过的一个实际案例，一个 120 人规模的研发团队通过这种方式，把每个迭代批次的进度偏差从原来平均 23% 压缩到了 8% 以内。

4. 给变更留预算，而不是拒绝变更

这句话我想用粗体表达：如果你知道下雨是大概率事件，你就应该在出发前带伞，而不是赌天气晴朗。需求变更之于软件项目，就像天气变化之于户外活动，是必然的而不是偶然的。

我建议在项目初期做预算的时候，就公开划出一块“需求适应储备金”，通常占总开发工时的 15%-25%，具体比例取决于几个因素：

市场环境变化速度，比如金融、零售、互联网赛道，建议按上限 20%-25% 预留。
业务方对需求的熟悉程度，如果业务方是第一次做这个方向的产品，对需求自己也不完全确定，也建议按上限预留。
技术方案的新颖程度，涉及新技术栈、新架构或者新集成场景的，技术不确定性本身也会带来变数。
合规和监管要求稳定性，高监管行业，外部因素导致的变更概率更高。

这块预算不是给团队“随便变更”的通行证，而是用于那些“不做会影响业务价值”的真实需求调整。如果项目结束时这笔预算没有用完，那是团队能力的体现，而不是项目多出来的利润，这个认知在我服务过的组织里，属于比较难扭转的部分，但一旦管理层接受了，项目的整体交付质量会有显著提升。

七、不同场景下的取舍和选择

写完上一节，我担心读者会产生一个误解：是不是所有项目都应该用 Scrum，瀑布彻底过时了？不是的。我自己在项目类型选择的判断上有一套很简单但有效的决策框架。下面这个思维矩阵帮你不被方法论流量绑架，实事求是地做决策。

1. 判断项目到底适合什么方法

我把项目分为四个象限，两个维度分别是“需求稳定性”和“技术复杂性”：

这个框架里，“需求相对稳定且技术成熟”的象限，瀑布模型依然有它的优势：进度可预测、成本可控、文档交付物完整。比如一个企业内部 HR 系统的迁移项目，业务规则已经运行了三年，需求基本不会有结构性变化，技术选型也是成熟方案，这种情况你强行用 Scrum 反而增加了沟通和管理开销。

但如果你在“需求高度不确定且技术新颖”的象限里用瀑布，就是你明知道自己看不清路，却仍然选择闭着眼睛加速跑。这个状态下的瀑布项目，在我的观察样本里，真正按时按质交付的比例不到 20%。

2. 如果组织强制要求走瀑布流程，怎么办？

这是很多 PM 面临的实际困境。组织流程要求瀑布，但你知道需求不稳定。我的建议不是“改变组织”，而是在局部范围内建立自己的适应性机制：

在需求文档里嵌入假设清单。即使组织要求签字冻结，你仍然可以在正式文档的附录或其他部分，列出当前版本需求中哪些是已验证的，哪些是基于假设的。这个附录在后期发生变更时，是你的“职业保险”。

利用阶段评审会植入验证信息。每次阶段评审，除了汇报进度，都主动展示一下“已验证假设 vs 待验证假设”的变化。让管理层逐渐看到验证的过程和结果，他们就会慢慢接受“需求变更不等于项目管理失败”。

在团队内部先 Scrum 起来。对外交付物和里程碑仍然遵守瀑布框架，但团队内部的每日站会、任务领取、进度看板完全可以用 Scrum 的方式运转。我在多个团队里验证过，这个“外瀑内敏”的模式在过渡期是有效的，它至少能让团队内部信息透明、问题暴露及时。

PingCode 这类工具在这个场景下会带来一定便利，因为它在功能层面同时支持 Scrum 的迭代看板和瀑布的里程碑管理。但有一点需要客观指出：即使采用了这类工具，如果组织层面的考核机制和领导认知不改变，“外瀑内敏”本质上仍然是一种变通手段，治标不治本，团队的负面情绪在长期内还是会累积。真正见效的前提，是管理层承认“需求稳定是一个需要验证的假设，不是一个绝对事实”。

3. 什么时候该坚持需求冻结，什么时候该主动拥抱变化？

这个问题需要分场景讨论：

该坚持需求冻结的场景：

• 硬件或嵌入式系统中与物理层绑定紧密的部分，因为物理元器件的选型和 PCB 设计一旦冻结，后期变更成本确实非常高。
• 合规性要求极强、法规已经锁死的领域，比如某些 GxP 验证环境下的制药系统、核电控制系统等。
• 项目范围涉及外部供应商的固定价格合同，且变更引发的商务风险远大于交付风险。

该主动拥抱变化的场景：

• 面向终端用户的产品功能，用户行为本身就难以预测，需求必然随用户反馈演化。
• 业务模式还在探索期的创新项目，需求本身就是一种需要被验证的商业假设。
• 外部环境（政策、市场、竞争格局）频繁变化的行业，保持需求弹性比保持需求稳定更有竞争力。

这里有一个很多人忽略的决策依据：不要用软件的类型来判断该不该冻结需求，而要用“这个功能做错后的纠错成本”来判断。纠错成本低的（比如一个后台报表的展示格式），可以尽快做、快速调；纠错成本高的（比如支付结算的核心算法），应该投入更多前期验证，但验证不等于一次性冻结需求，而是要留出足够的缓冲机制。

八、从组织层面改变这个思维惯性

七两节讲的更多是项目层面的实践，但“假设需求不变”这个盲区，根子很多时候不在项目经理，而在组织的治理逻辑和管理文化。如果组织不改，单个项目能做的事情终究有限。所以这一节，我想把镜头拉高，谈谈组织层面需要做哪几件事。

1. 重新定义“项目成功”的标准

很多组织的项目绩效考核由三个核心指标驱动：按时交付 / 按预算执行 / 按既定范围完成。这套指标对于造桥修路是合理的，但对于软件产品研发，它实际上是在惩罚“发现需求错误并及时调整”的团队，而奖励“按时交付了一个没人用的功能”的团队。

我建议在考核体系里引入两个和需求适应性相关的指标：

需求命中率：上线后 3-6 个月内，实际被用户使用的功能需求占交付总功能需求的比例。如果一个团队交付了 20 个功能，但半年后只有 8 个被持续使用，那另外 12 个就是浪费。把“避免浪费”纳入考核。
需求变更的正面贡献率：在项目中通过合理变更避免了多少未来的运营问题或用户投诉，这个也应该被量化和认可。

改考核指标的阻力确实不小，需要向上争取资源并解释价值。一个比较有效的切入方式是把需求命中率包装成“研发效能提升”的一部分，因为这个数据对业务老板来说比较好理解：花的钱，到底有多少变成了有用的功能。

2. 给 PM 和 PO 不同的心理安全感

在一个严格追责的组织里，项目经理和产品负责人都会本能地抗拒需求的任何变动，因为变动意味着风险，风险可能追责到自己头上。在这种文化下，“需求冻结”就变成了自我保护的盾牌，而不是保证交付的工具。

要扭转这个局面，管理层需要传递一个明确的信号：基于合理分析的需求调整，是专业判断的体现，不是失误。如果一次需求变更在回顾会议上被论证为“确实避免了更大的用户损失或商业损失”，那么发起这次变更的人应该被认可，而不是被质疑。

这里有一个我和技术 VP 交流中的实操建议：在项目复盘会上，增加一个固定环节叫“我们在这个项目里推翻了哪些初始假设？花了多少成本？省了多少更大的成本？”当这个环节变成常规流程，团队就会逐渐把“暴露不确定性”当作专业工作的一部分，而不是职业生涯的风险。

九、结束语：承认“我们猜不准”，反而是一种专业

写到这里，我想回到开头那个工业 SaaS 团队的故事。后来那个项目最终被重新定义为一个“最小可用版本加持续迭代”的模式，CEO 亲自在 kickoff 会上说了一句话：“我承认，我不确定用户到底需要什么，但我们接下来会用最短的周期去验证我们最好的猜测。”这句话卸掉了团队身上最大的包袱。

做软件项目管理十几年，我越来越确信一件事：最危险的不是“我不知道”，而是“我以为我知道，但我不知道我其实不知道”。瀑布开发的最大盲区不是它的阶段划分，不是它的文档规范，而是它助长了一种“我们已经全部搞清楚了”的错觉。这种错觉在项目前期特别美好，但越往后代价越大。

如果你正在主导一个项目，不管用的是瀑布、Scrum 还是什么混合模式，请做一个小实验。打开你手头的需求文档，勾出其中你其实没有十足把握的需求，看看比例是多少。如果超过 20%，这个项目值得你重新审视一下风险策略。如果超过 40%，请务必在接下来的几周内安排一次快速验证，哪怕只是一个低保真原型、几次用户访谈，或者一次内部走查。

下一步，我建议你从三件事中至少选一件启动：

1. 在下一次需求评审会上，公开标注并讨论每个需求的确定性级别。
2. 在项目计划里划出一块明确用于需求验证的时间或预算。
3. 和你的上级认真聊一次：当前的项目考核方式，是在鼓励“假装需求稳定”，还是鼓励“尽早发现并管理不确定性”。

你不需要从瀑布一步跳到敏捷，你只需要从这一周开始，不再假装需求不会变。这个认知上的转变，本身就比很多复杂的流程改革更有力。