需求天天变，就别硬套瀑布开发

一、先说结论：不是瀑布模型错了，是你把项目当成了“已知的已知”

2021年，我接手过一个让我至今记忆犹新的项目。一家做企业财税SaaS的公司，产品VP带着30人的研发团队找到我，开口第一句话就是：“我们搞了8个月瀑布开发，结果交付那天客户说这不是他们要的东西。”

我问了他一个问题：“你们的PRD写了多少页？”

他说：“237页，改了11版，内部评审了6轮。”

我又问：“客户从需求调研到看到第一个可用的功能，中间隔了多久？”

他沉默了大概5秒：“8个月零12天。”

这个案例的核心问题不是瀑布模型不好用，而是这个团队在8个月里从未真正验证过自己理解的需求和客户想要的是不是同一回事。

237页PRD解决的是什么？是文档的完整性和内部的一致性。但它解决不了“客户自己都没想清楚他要什么”这个问题。而这也正是当下大部分B端软件项目和一部分C端产品面临的真实处境，需求天天变，不是客户不专业，而是业务本身就处于快速演化期。

所以这篇文章的结论先说在前面：需求天天变，就别硬套瀑布开发。但这不是让你必须全面转向Scrum，而是让你学会识别项目特征，在合适的阶段用合适的方法，甚至可以在一张项目路线图上同时编排瀑布和敏捷两种节奏。

二、背景：为什么越来越多的项目“需求天天变”

1. 不是客户变作了，是行业时钟被调快了

我在过去5年服务过43家大中型企业的研发效能改进项目，其中PingCode的客户名单里包括了不少100人以上的研发组织。这些团队有一个共同特征：他们的业务不是跑在真空中，而是被政策变化、竞品动作、客户组织变动三重力量不断拉扯。

举个例子，一家做人力资源数字化平台的PingCode客户（以下简称案例A，团队规模170+人），2022年经历了3次重大需求转向。第一次是因为金税四期上线，薪酬计税模块要从“年度汇算”切到“月度预扣实时比对”；第二次是某竞品推出了“灵活用工全链路结算”功能，逼着他们在一个季度内上线对标能力；第三次是客户内部HR部门重组，原先的审批流全要改。

案例A的研发VP当时说了句很实在的话：“如果按18个月前的瀑布规划走，我们现在交付的是一个三年前设计的产品，卖给三年前的市场。”

需求天天变不是管理失败的表征，恰恰是组织感知力的证明。真正可怕的是需求明明在变，你的开发流程却假装世界是静态的。

2. B端软件的“需求漂移”是结构性现象，不是个案

我从2019年开始追踪一个现象：企业级软件项目的需求稳定性，与该客户的行业监管密度成反比，与客户的业务创新速度也成反比。

下面这张表来自我对27个企业级软件项目的回顾统计（项目周期12-24个月，团队规模30-200人）：

这个数据有明确的指向：如果你所在的行业属于互联网、金融、零售快消等高频竞争领域，需求变更不是异常值，而是基线。在这些领域用纯瀑布模式做项目，相当于默认“未来12个月行业不会发生什么大事”，这个假设本身就脆弱。

3. “伪瀑布”比真瀑布更害人

我在企业里见过最可怕的开发模式，不是纯瀑布，也不是纯敏捷，而是名义上的瀑布，实际上的混乱。具体表现是：立项时按瀑布画了完整的甘特图，需求文档签字画押，但在开发进行到第3个月的时候，业务方开始频繁“口头提需求”。PM碍于关系不敢拒绝，研发组长被迫在已排期的任务中间塞入变更，测试团队根本没有时间更新用例。

这种模式的本质是：用瀑布的壳（里程碑、文档、审批流）掩盖了对需求变化的失控。最后交付的时候，实际做出来的东西和需求文档对不上，但谁也说不清是哪一环出了问题。

我在2023年辅导过一家做医药流通B2B平台的公司，就是典型的“伪瀑布”受害者。他们的项目计划书做得极其精美，WBS分解到第四级，但上线前一周才发现：仓库拣货流程里有3个关键节点需求文档根本没覆盖到，因为业务方觉得“这是常识，不需要写”，而研发方严格按照“只做PRD里有的”执行。双方都没错，但交付出了大问题。

这个案例让我确信一条原则：如果你的需求客观上不稳定，那透明频繁的验证比一套完美的需求文档更值得依赖。这也正是我后文主张的“动态编排”方法的出发点。

三、最常见的三大误区：为什么团队总是选错开发模式

1. 误区一：把“需求复杂”等同于“需求稳定”

很多技术管理者有一个根深蒂固的认知偏差：因为我的业务逻辑很复杂（比如ERP、财税引擎、医疗系统），所以需求一定是稳定的，只能用瀑布。

我在2020年和一个做三甲医院HIS系统的架构师有过长达两小时的争论。他的观点是：“医疗信息系统涉及患者安全、医保结算、药品管理，任何一个模块都有一两千条业务规则，这种系统没办法敏捷，必须先全部梳理清楚再动手。”

我问他：“你上一次完整梳理业务规则是什么时候？”

他说：“两年前，我们花了4个月做了全量需求调研。”

我又问：“过去两年，医保报销政策变了多少次？”

他愣了一下：“至少五六次吧。”

这里面的逻辑链很清楚：业务复杂度高 ≠ 需求不变。恰恰相反，越是高价值的复杂系统，外部规则和业务诉求变化的频率可能越高。国家医保药品目录一年一调，部分地区甚至半年一调；医院内部绩效考核方案跟着院长任期走。你的系统逻辑如果绑死在两年前的静态需求上，上线即落后。

正确的判断方式不是看“业务有多复杂”，而是看“核心规则的外部依赖有多强”。外部依赖越强，需求漂移风险越高，就越不适合全量瀑布。

2. 误区二：把“敏捷”理解成“没有文档、不做设计”

这是另一个极端。我见过不止一个团队在经历了一次瀑布失败之后，直接冲向了另一个深渊：完全放弃前期设计，声称要做“极限编程”，结果连最基本的数据模型都没对齐，两个迭代之后数据库表结构彻底失控。

Scrum Guide从来没说过不需要文档。它说的是“工作软件高于详尽的文档”，高于不是取代。一个典型的PingCode Scrum项目里，用户故事本身包含了验收标准和业务场景描述，迭代回顾会议纪要本身就是过程文档，自动化测试脚本本身就是设计意图的可执行表达。

我2022年跟过一个使用PingCode的200人规模SaaS团队（以下简称案例B），他们的做法值得参考：对每一个Epic，要求PO写一份不超过两页的Epic Brief，包含商业目标、核心场景、与现有系统的关系、关键非功能需求。这份文档在Epic启动的规划会上过一遍，但不再追求完整版PRD。具体用户故事的细节在每个Sprint Planning上补充。

案例B的产品总监总结得很到位：“我们不是不写文档，是把文档的颗粒度拆到刚好够决策，不浪费在三个月后大概率过时的细节上。”

3. 误区三：认为“选好模式就万事大吉”

无论是瀑布还是Scrum，方法论的边界在于：它们都只规定了流程，但没有规定决策依据。一个团队选择了Scrum，但如果PO不会做Backlog Refinement，Scrum Master不敢在Sprint中拒绝注入新需求，团队照样会陷入混乱。

同样，选择瀑布模式的团队如果能在关键里程碑上设置“需求冻结复核点”，主动识别漂移并触发变更控制流程，也不会出现8个月后交付即翻车的悲剧。

下面的表格总结了我观察到的三种典型失败模式：

这三个误区有一个共同根源：团队没有把“需求变化”当成一级输入变量纳入开发模式选择决策中，而是凭习惯、凭行业惯例、凭某一篇文章的推荐在决策。

四、专业判断逻辑：如何用一个框架决定你的开发模式

1. 我使用的三轴定位法

过去四年里，我帮助27个团队（团队规模从30到200人不等，其中7个是PingCode的付费客户）做过开发模式选型。我总结了一套实用性很高的判断框架，我叫它“需求变化图谱三轴定位法”：

第一轴：需求确定性，你的核心需求在多大程度上可以被提前完整描述？

• 高确定：政府合规类系统、财务报表核算模块、航空飞控系统
• 中确定：大部分B端管理软件的核心业务模块（CRM、HRM、进销存）
• 低确定：创新产品从0到1阶段、面向新市场的平台产品、强依赖外部政策的功能模块

第二轴：验证成本，你做错一次决策的代价有多大？这个代价以什么形式体现？

• 高代价·时间维度：交付窗口固定（如双11大促、年报审计期），错过即损失惨重
• 高代价·金钱维度：硬件成本高、第三方服务调用费昂贵、大规模用户召回成本高
• 高代价·安全维度：医疗设备、自动驾驶、工业控制系统容错率极低
• 低代价：大部分SaaS产品、内部管理系统、可灰度发布的C端功能

第三轴：组织敏捷成熟度，你的团队有没有能力跑好Scrum？

• 高成熟度：PO能独立决策优先级，团队可以自组织拆解任务，SM真正拥有流程守护权
• 中成熟度：Scrum流程能跑通，但PO经常被业务方牵着走，团队依赖技术Leader做拆分
• 低成熟度：站会变成了汇报会，回顾会变成了吐槽会，Sprint边界形同虚设

把这三个轴放在一起交叉判断，结论通常非常清晰：

这里面最需要解释的是第三行：需求确定低但验证成本高。一个典型场景是金融核心交易系统。你不能胡乱上线一版等用户反馈，但同时金融合规政策确实在变化。这时候最好的做法不是完整瀑布（因为需求会漂移），也不是纯Scrum（因为错误的代价太高），而是增量交付+原型验证+阶段性冻结。比如先交付资金清算的核心链路并冻结半年，再基于市场反馈和监管更新在下一个阶段释放新版本。

2. 不要用“整个项目”做单位，要拆到模块级

很多技术管理者喜欢问：“我们这个项目用瀑布还是敏捷？”

正确的问法是：“我们这个项目的哪些模块需求稳定、适合一次做对？哪些模块需求漂移风险高、需要短周期验证？”

我在PingCode的客户案例B（前面提到的200人SaaS团队）身上学到了一种实用的分模块判断法。他们的项目包含四个子系统：

1. 用户权限与组织架构管理（稳定性高）：底层RBAC模型几乎不变，接口标准，适合一次设计到位，采用了简版瀑布，需求文档+A阶段评审+集中开发+集中测试。
2. 薪酬计算引擎（外部依赖高、准确性要求极高）：税率规则和社保政策半年一调。采用了增量交付+每季度冻结一次逻辑，更新后全量回归测试。
3. 员工自助服务Portal（C端体验、需求变化快）：业务方每个季度要上线新的自助功能。标准Scrum，两周一个Sprint，固定发布节奏。
4. 报表与分析平台（数据模型稳定，展示需求多变）：底层数仓按瀑布建好ETL和主题域，上层报表看板按Scrum走迭代。典型的“底层瀑布+上层敏捷”混搭。

这个分模块策略让他们在2022年同时跑着三种完全不同的开发节奏，但整条产品线交付的可预测性反而提升了，因为每种节奏都有明确的适用前提和风险控制点，而不是所有人被迫执行同一种方法论。

下面这张图直观展示了上述四个模块的开发模式差异：

五、PingCode实操案例：200人团队如何在一个项目中跑三种节奏

1. 案例背景

案例B是一家人力资源科技SaaS公司，研发团队2021年底从120人扩编到200人，产品线从一个扩展到四个。扩张过程中出现了一个严重问题：原来一套Scrum流程打天下，但不同产品线的需求特征差异极大，强行对齐迭代周期导致频繁的Sprint失败和发布延迟。

2022年第一季度，他们的Sprint完成率只有62%，也就是10个Sprint里有将近4个没能完成承诺的Backlog。研发VP找到我时，团队已经有明显的挫败感。

我们做了一次完整的三轴评估，结果如下：

关键落地工具是PingCode的自定义工作项类型和跨项目路线图功能。案例B在PingCode中为不同模块配置了不同的工作项模板：

• 权限模块：使用标准需求→开发任务→测试用例的线性流程，工作项之间强依赖关系。
• 薪酬引擎：使用Epic→Feature→User Story三级结构，Feature设为“季度冻结”标记，一旦进入开发期，Feature下的Story不允许变更。
• 员工Portal：标准Scrum工作项体系，Product Backlog→Sprint Backlog→Task，每个Sprint由PO严格锁定。
• 报表平台：底层数据工作项走瀑布线程，前端看板工作项走Scrum线程，两者通过PingCode的关联关系链接，在路线图上可视化呈现。

2. 调整效果

调整方案从2022年5月开始执行，到8月份我回访时拿到了一组对比数据：

这里要做一个重要的澄清：效果提升不是因为“敏捷比瀑布好”，而是因为每个模块终于用上了适配其需求特征的开发模式。权限模块用瀑布后，因为需求真的稳定，效率反而提升了，团队不再需要每两周花费时间做规划会议讨论一个极少变化的部分。而Portal模块继续跑Scrum，因为它的业务场景天然适合高频交付。

案例B的研发VP在回顾会上说了一句我至今引用的话：“以前我们争论的是‘用敏捷还是瀑布’，现在问的是‘这个模块适合什么节奏’。问题的表述方式变了，答案也就有了。”

3. 踩过的坑：动态编排不是“随变而变”

这个案例在执行过程中摔过两次重要的跤，值得单独拎出来讲。

第一个坑：模块间依赖带来的节奏冲突。薪酬引擎的一个季度冻结版本需要调用权限模块的一个新接口，但权限模块按瀑布节奏要到下个月才排期。这个依赖没有在路线图上提前暴露出来，导致薪酬引擎的Sprint被迫延期一周。

解决方案是在PingCode的路线图视图中强制标注跨模块依赖，并且要求任何一方在规划冻结内容时必须向前广播接口变更计划。这本质上是用小量的额外沟通成本换取了节奏确定性的显著提升。

第二个坑：团队心理上的“不公平感”。Portal团队跑Scrum，每个Sprint都要经历规划会、评审会的节奏压力；权限模块团队跑瀑布，只有里程碑节点需要集中精力。有段时间Portal团队有人抱怨“为什么他们不用开站会”。

这个问题解决不在流程层面，在管理层面。研发VP召开了一次全员沟通会，把四个模块的需求特征和模式选择逻辑完整解释了一遍，并且明确了一点：不同的开发模式对应不同的岗位能力要求，也对应不同的绩效考核权重。权限团队考核重点是一次性交付质量，Portal团队考核重点是迭代速度和用户反馈响应。讲清楚逻辑之后，抱怨基本消失了。

这两个坑给我的教训很深：动态编排不只考验工具和流程设计能力，更考验组织的透明沟通和管理者的解释能力。

六、分情况行动建议：三种典型场景下你应该怎么做

1. 场景一：你接手了一个跑在瀑布上的老项目，需求已经开始漂移

不要立刻推倒重来。先做一件事：画一张“漂移热力图”。

具体做法：把过去三个月的需求变更记录全部拉出来，按模块、按变更类型（政策驱动/客户驱动/内部重构）、按影响范围（仅前端/涉及数据模型/影响上下游接口）做分类统计。做完这件事，你会清楚哪些模块是漂移高发区，哪些模块相对稳定。

基于热力图，分三类处理：

• 高频漂移模块：立即从瀑布主线抽离出来，转入Scrum节奏。不要等PRD写完，直接让PO整理最小可行Backlog，一个Sprint后就能拿到可演示增量。
• 中频漂移模块：维持当前瀑布计划，但在下一个里程碑节点增加一次“需求有效性复查”，邀请业务方正式确认当前文档描述仍然有效。确认后冻结至交付。
• 低频漂移模块：维持原计划不变，不折腾。

我在2023年用这个方法帮助一个做保险理赔系统的团队（团队规模60人）在4周内平稳过渡，没有出现任何业务中断。

2. 场景二：你从零开始一个新产品，但市场环境高度不确定

第一选择不是Scrum，而是先做两轮“预验证Sprint”。

很多团队从零开始就直接拉了标准Scrum流程，两个迭代后发现做的功能没人要。问题出在：Scrum解决的是“怎么做对”的问题，但没解决“做什么才对”的问题。

我的建议做法：

1. 第0周：用一周时间产出一份Lean Canvas（精益画布），明确假设清单。你假设哪些需求是真实的？哪些用户群会买单？按照风险等级排序。
2. 第1-3周：做两个验证Sprint，专门验证风险最高的两个假设。产出物不要求是完整功能，可以是原型、数据模拟、用户访谈录像。目标是用最低成本证伪。
3. 第4周：评审验证结果，决定是否进入正式产品开发。如果核心假设被证伪，及时止损。如果验证通过，基于已验证的需求启动正式Scrum。

这套做法我陪跑了3个从0到1的SaaS产品团队，平均帮助每个团队节省了至少6周的低价值开发时间。

3. 场景三：你的行业要求强合规，但业务本身变化快

典型如金融、医疗、税务领域。这类场景最容易出现“合规和敏捷打架”的困境。

我的建议是建立一个“双轨合规缓冲区”：

• 合规轨：涉及监管报送、资金安全、患者隐私等高合规要求模块，采用正式变更控制流程，每次变更必须通过合规评审。发布周期可以较长（如月度或季度），但每次发布必须保证合规完整性。
• 业务轨：不涉及合规边界的业务功能（如用户界面优化、增值服务、数据分析看板），采用标准Scrum发布节奏。
• 缓冲区：每条合规轨外面包一层自动化的合规校验脚本，业务轨的每次发布在合并到主干之前必须通过这些校验。这样可以保证业务轨的快节奏不会污染合规轨的完整性。

这套模式我2021年在一个第三方支付平台项目中设计并落地。合规轨按月度发布，业务轨按两周发布，两轨共享代码仓库但有独立的CI/CD流水线，合规门禁脚本把业务轨变更挡在安全线之外。运行18个月，没有出现一次合规事故，业务功能的交付速度反而比原来纯瀑布时代快了约40%。

七、不同情况下的取舍：你必须面对的四个真实矛盾

1. 交付速度 vs. 技术债务

选择敏捷、放弃瀑布的一个直接后果是技术债务的累积速度会快于预期。因为迭代周期短，团队在Sprint内做出的设计权衡，很可能在三个Sprint后变成瓶颈。

我的经验数据是：一个连续跑Scrum超过6个月的团队，如果没有在每个Sprint中专门留出债偿时间，技术债务的累积会导致第7-9个月开始交付效率下降约15-25%。这不是Scrum的错，而是任何追求短周期交付的方法论都必然面临的取舍。

解决方案不是回到瀑布，而是在每个Sprint Planning里强制分出一个“债偿百分比”，我通常建议初期5%-10%，成熟期10%-15%。案例B的做法是把债偿任务以User Story形式明写在Sprint Backlog中，并且和功能开发Story享受相同的验收标准。

2. 文档完整性 vs. 维护成本

瀑布派最担心的事：没有完整PRD，系统维护怎么办？这个担心有道理。敏捷团队如果完全不积累结构化知识，人员流动后系统认知断层确实是严重问题。

我的折中建议是“关键设计记录”（KDR，Key Design Record）制度：

• 非关键模块：用户故事+验收标准+测试用例 就是设计文档。
• 关键模块（涉及数据模型、对外接口、安全合规、核心算法）：每一个Sprint结束后，由开发负责人用半小时写一份半页到一页的KDR，描述本次迭代对关键设计做了什么改动以及为什么这么做。存入团队Wiki。

每月用半小时做一次KDR交叉审阅，确保记录和代码一致。这个制度在案例B运行了一年，后面新加入的两个人虽然没参与早期迭代，但通过阅读KDR链就快速建立了系统认知。

3. 计划可预测性 vs. 快速响应能力

瀑布的核心优势是可预测；敏捷的核心优势是可响应。在需求天天变的环境下，可预测本身就是一种幻觉。但企业管理者天然需要预测，预算、资源、市场承诺都需要时间坐标。

我的做法是引入“滚动预测窗口”：

• 未来一个Sprint：承诺级预测。Backlog明确，交付范围锁定。
• 未来2-3个Sprint：规划级预测。给出范围和优先级，允许20%变动。
• 3个Sprint以后：方向级预测。只说Epic方向和大致时间窗口。

这种三级预测结构在PingCode的路线图功能中可以配置出来。上游管理层看到的是“我们下个季度大概率拿到A、B、C三个能力”，而不是“我们精确到人天的甘特图已经排到6个月后”。事实证明，管理者要的不是“精确的错误”，而是“大致准确+透明可见”。

4. 团队自主性 vs. 组织控制力

真正的敏捷需要团队自组织能力，而很多组织的管理层习惯了对排期和资源的集中控制。这个矛盾不解决，任何方法论的改良都是表面文章。

我在案例B推动的一项关键变革是：把“里程碑审批制”改为“Sprint目标承诺制”。

• 旧模式：PMO审批每个模块的开发计划和里程碑，团队执行。
• 新模式：每个Sprint开始前，团队向管理层承诺Sprint Goal（用自然语言表述的一个业务目标，如“完成10月新税率规则的引擎适配并通过全量回归”）。Sprint Review时直接演示结果。管理层保留干预权，但不再对每个任务进行微观管理。

这个转变的本质是把控制点从事前审批后移到事后验证，用透明度换取信任。做了一年之后，案例B的管理层反而发现他们对项目进展的真实感知提升了，因为每两周他们看到的是可运行的软件，而不是一份进度百分比报告。

八、我的独特观点：停止在方法论层面二选一，学会在项目内部做“动态编排”

整篇文章读到这里，你应该能感受到我的核心立场：我不站敏捷，也不站瀑布。我站“项目成功”。

而这个立场之下最实用的能力，不是你多熟悉Scrum Guide的每一个段落，也不是你能画出多精美的WBS，而是你能不能在同一个项目内部，为不同模块、不同阶段、不同风险特征的工作配置不同的开发节奏，并且让这些节奏和谐共存。

我给这种能力起了一个名字：动态编排。

动态编排不是投机取巧。“这个模块需求稳定，用瀑布；那个模块需求多变，用敏捷”，这句话说起来轻巧，做起来需要三个前提：

1. 你有能力做模块级的“需求变化图谱”分析，即能准确判断哪些模块是高漂移区、哪些是稳定区。这需要历史数据和业务判断力的结合。
2. 你的项目管理工具能承载多种工作流，并且能在路线图层面将它们关联起来。PingCode的自定义工作项类型和多泳道路线图是目前国内工具里做得相对成熟的一类，但核心不依赖具体工具，依赖的是团队有没有意愿把这件事可视化。
3. 你的组织文化能接受“不一致”。管理者需要向团队解释为什么Portal跑Scrum而权限模块跑瀑布，并且把绩效评价体系对齐到各自模块的开发模式特征上。

我在过去四年里看到的一个趋势是：那些成功驾驭了需求变化的团队，最终都不是“选对了方法论”的团队，而是“放弃了对单一方法论的执念”的团队。他们不再争论敏捷好还是瀑布好，而是把注意力放在了两个更根本的问题上：“我们现在做的这个东西，需求到底稳不稳定？”和“在我们这个组织里，什么验证节奏成本最低、效果最好？”

能问出这两个问题的团队，无论是用瀑布、Scrum还是任何混合模式，结果通常都不会差。

九、下一步行动：从今天开始你可以做的三件事

1. 画一张你的项目“漂移热力图”

打开你过去三个月的需求变更记录（如果没有，去翻Jira/PingCode/飞书多维表格里的历史记录），按模块分类，标注每种变更的来源和影响范围。一个下午就能完成。做完这件事，你就有了一张决策地图：红色模块立刻调整开发节奏，黄色模块加复核点，绿色模块维持原样。

这张图的有效期通常不超过一个季度，动态编排之所以叫“动态”，就是因为每个季度要重新评估一次。

2. 选一个模块做“模式切换实验”

不要一次性全项目切换，风险太高。选一个漂移高频、验证成本中低的模块，用一个月时间跑3个Sprint的Scrum实验。和团队约定明确：这是实验，月底复盘，不成功就回退。我从没见过复盘之后团队选择回退的，但“可以回退”这个心理安全保障是让实验得以启动的前提。

3. 和管理层做一次“预测准确性对齐”

如果你的管理层习惯要精确到天的排期，而你的项目面临着显著的需求漂移，那你们需要一次对齐。别谈敏捷宣言，别谈方法论，就谈一个事实：“过去六个月，我们因为需求变更而调整计划的频率和幅度是多少？基于这个现实，什么样的预测精度是合理且诚实的？”

用数据说话。案例B的研发VP就是靠一组返工工时数据说服了CEO接受滚动预测模型。CEO要的不是假的精确，是真的可控。

最后留一句话给正在读这篇文章的你：需求天天变不可怕，可怕的是你的开发模式假装它不变。停止选边站队，开始动态编排。这是2025年一个成熟技术管理者应该具备的基本能力。