瀑布开发需求，永远定不下来

一、我在 2018 年差点毁掉一个项目，不是因为技术错，而是因为一个幻觉

2018 年第三季度，我接手了一个中型 SaaS 项目的交付管理工作。客户是一家 200 人规模的金融科技公司，合同签了 6 个月，需求文档 173 页，双方盖章签字，阵仗非常正式。我们团队内部开启动会的时候，所有人都觉得这次稳了，需求写得这么细，客户这么认真，照着做就行。

结果第三个月，项目进入开发深水区，客户那边的业务负责人换人了。新负责人上任第一周，发来一封邮件，附件 47 页，标注了 96 处需求调整。我至今记得当时技术 lead 的表情，他不是愤怒，是茫然。因为其中 30 多处改动涉及到底层数据模型，而我们刚刚完成了那部分的编码和单元测试。

那之后的两个月，我们经历了：开发返工、测试用例大面积作废、前后端联调推倒重来、上线时间延期两次、团队加班时长翻倍。最终项目交了，但利润率几乎归零。复盘的时候，团队里一位干了十五年的架构师说了一句话，我记到现在：

“我们不是输给了需求变更，我们是输给了‘需求可以定下来’这个幻觉。”

这句话，是我后来彻底反思瀑布模型下需求管理逻辑的起点。也是今天这篇文章的真正起点。

二、核心结论先放这里：需求定不下来不是问题，问题在于你按“能定下来”去管理

在做了 7 年项目管理、服务过 40 个以上企业客户之后，我有一个判断，这个判断在今天讲出来可能仍然会让一些人不舒服：

瀑布开发模式下的需求管理困境，根源不在于需求本身变化多，而在于管理框架预设了一个静态的世界。

这个结论有三层含义：

第一，需求变化是商业环境的正常信号，不是客户的恶意。 我见过太多项目经理把需求变更当成“客户不专业”的证据，但真相往往是：客户的业务在变、竞品在动、监管在调、老板在改主意。让一个外部客户在签合同那一刻就准确预言 6 个月后的业务形态，概率有多高？我自己的统计是，中大型项目超过 70% 的需求变更来自不可预估的外部因素，剩下 30% 才是前期调研不到位。

第二，瀑布模型本身的“阶段门控”机制会放大变更的破坏力。 当需求在编码阶段才被发现有问题时，修复成本是需求阶段发现问题的 10 到 100 倍。这不是新知识，Barry Boehm 早在 1981 年就通过实证研究得出了这个结论。但我观察到的更残酷的事实是：很多团队即使知道这个数据，也还是会选择“先把需求冻结再说”，因为冻结需求比承认不确定性在组织内部更容易获得政治正确。

第三，真正需要被管理的不是需求文档，而是需求变更的“信息流”和“决策权”。 把需求定不下来的责任推给“客户说不清”或“销售乱承诺”，是一种廉价的心理防御。我做过的项目中，凡是建立了正式变更评估机制和可视化需求追溯链的团队，即使变更率依然很高，项目交付质量和团队士气也明显好于那些试图“堵住”变更的团队。

三、我见过的四种“需求定不下来”的真实场景，每一种对应的解法完全不同

这些年我接触了几十个项目，发现“需求定不下来”是一句高度概括的抱怨，但底下藏着完全不同的病理。如果不加区分地套用同一种药方（比如“转敏捷就好了”），大概率会把问题搞得更糟。我按自己的经验把情况归纳成四种类型，每一种我都亲眼见过并且亲手处理过。

1. 第一类：业务本身高度不确定型

典型场景：创业公司的新产品线、大公司的创新孵化项目、进入全新市场或品类的尝试。这类项目的共同特征是，客户自己也说不清最终产品应该长什么样，因为市场还没验证、用户还没反馈、商业模式还在试。

我服务过的一家跨境电商客户就是典型。他们想做一套选品决策系统，但选品逻辑本身每个月都在根据 TikTok 爆款趋势调整。这种情况下，让客户在项目启动时签一份“需求确认书”几乎是自欺欺人。

这类场景的正确姿势： 承认不确定性是第一位的。与其写 200 页需求文档，不如把资源集中在构建“可演示的最小闭环”上。用高频的演示和反馈来替代低频的签字确认。我后来给这家客户采用的是两周一个迭代节奏，每个迭代结束时必须拿出一个可交互的版本给业务方试用，需求文档只写下一个迭代的，再远的不写死。

2. 第二类：决策链条长、多层审批型

典型场景：大型国企、金融机构、政府项目、集团型企业的内部管理系统。需求本身在业务层面是相对清晰的，但项目涉及多个部门、多个层级审批，A 部门确认的需求到了副总那里被推翻，副总批了之后再被集团合规部打回来修改。

2021 年我参与的一个集团 ERP 改造项目就踩了这个坑。业务需求在分子公司层面全部确认完毕，结果集团 IT 治理委员会一句话把底层架构选型推翻了，整个项目返回到需求阶段重新来过。

这类场景的正确姿势： 问题不在需求分析能力，而在干系人管理。需要提前识别“隐形决策者”，并在需求阶段就拉他们入场。我后来养成一个习惯，项目启动前先画一张“决策链地图”，标注出每一个可能说“不”的人，在需求评审阶段逐一触达。同时，需求文档里明确记录“谁、在什么时间、以什么依据”确认的需求，让变更发生时责任可追溯。这不是推卸责任，这是保护团队。

3. 第三类：需求依赖外部系统或政策、不可控型

典型场景：项目依赖第三方 API、支付通道、物流接口、政府数据平台、政策合规条款等。这些外部依赖一变，你的需求就得跟着变。

我在 2019 年做过一个对接税务系统的项目，开发到一半，国家税务总局发布了新版接口规范，旧版接口给了 3 个月过渡期。客户说：我们必须按新版来。这意味着已经写完的接口层代码全部报废。

这类场景的正确姿势： 外部依赖必须在项目初期被标记为“高风险假设”，并设置触发式预案。我把所有外部依赖在需求文档里标红，并要求每一个标红项都有一条“如果 X 发生变化，我们执行预案 Y”的说明。同时，与客户明确约定：属于外部依赖导致的需求变更，重新评估工期和成本，不纳入乙方违约责任。

4. 第四类：伪需求多、前期调研走过场型

这一类其实最冤枉，也是最应该被避免的。需求变来变去不是因为业务真的在变，而是因为前期调研根本没做到位。客户方对接人口头说了一套，项目经理记下来就当成需求，等开发出来给真正用的人一看，对方说：这完全不是我要的。

我见过最极端的例子，一个 CRM 项目，前期调研只访谈了销售总监一个人，系统的实际使用者，一线销售，完全没被问过。系统上线后，一线销售集体抵制，最终项目被废弃，几百万打了水漂。

这类场景的正确姿势： 不用谈什么敏捷还是瀑布，这是基本功问题。需求调研阶段必须覆盖至少三层角色：决策者、管理者、一线使用者。三方的关注点完全不同，决策者要数据看板，管理者要流程管控，一线用户要操作效率和体验舒适度。只聊一层，必翻车。

四、一个被广泛误解的概念：需求冻结不是解决方案，它是止痛药，会上瘾

在瀑布模型的项目管理实践中，有一个广为流传的“最佳实践”叫做需求冻结。通常的做法是：在某个阶段节点，各方签字确认需求文档，之后任何变更都必须走正式的变更控制流程，且可能附带额外费用。

我在职业生涯早期是需求冻结的坚定拥护者，觉得这是保护团队的盾牌。直到连踩三个大坑之后，我才重新审视这个做法。

第一个坑：客户签字了但根本没看懂。 一份 200 页的需求文档，你让客户方业务负责人在一周内逐条确认，现实吗？对方大概率挑重点翻一翻就签了。签字变成了一种仪式，而不是真正的确认。等开发出实际界面，对方说“这和我签字时想的不一样”，你拿出签字记录，对方说“我当时理解错了”，然后呢？你跟他打官司吗？

第二个坑：冻结之后的变更走流程太慢，团队等不起。 一个正式变更从提出、评估、报价、审批到下达给开发团队，在大型组织里经常要走 2-4 周。2-4 周什么概念？一个 3 个月的项目，等流程走完工期已经过去了四分之一。团队不能干等着，只能按原需求继续开发，然后变更批下来之后再返工。

第三个坑：冻结制造了对抗关系。 客户方的使用部门提出合理需求调整，项目经理拿出签过字的需求文档说“不行，追加费用”，使用部门转头找客户方高层施压，高层压客户方项目负责人，负责人压乙方项目经理。几轮下来，双方关系从合作变成博弈，信任归零。

我现在的观点很明确：

需求冻结可以用，但不能把它当成解决需求变更问题的根本手段。它是在特定阶段对核心范围进行锁定的一种临时管理动作，而不是让整个项目免受变化影响的保护罩。

更务实的做法是区分“冻结层”和“弹性层”。核心业务流程、数据架构、安全合规要求，这些应该被冻结，因为它们的变动成本确实太高。但交互细节、报表样式、非核心功能模块，这些应该保持弹性，用更轻量级的变更确认方式来替代正式审批流程。

这套分层的思路，是我在踩了几年坑之后逐渐摸索出来的。它不是什么理论创新，但确实帮我后来的项目在“保持稳定”和“响应变化”之间找到了一个相对可操作的平衡点。

五、我从 PingCode 的实践中观察到的解法：用数据流对抗信息断裂

这里我必须要提到一家具体厂商的实践，因为我确实亲眼看过他们的团队怎么处理这个问题。

PingCode 的产品研发部门，大概是在 2019 年前后开始全面采用 Scrum 框架进行产品迭代。他们的客户主要是 100 人以上的中大型企业，这类客户的需求管理复杂度天然就高，多个业务部门、多种角色诉求、第三方系统集成要求、合规和安全约束，等等。

我在 2022 年有机会深入了解了他们的工作方式，有几个点让我印象深刻：

第一，他们不试图在项目启动时就把所有需求“定下来”。 PingCode 的团队用史诗、特性、用户故事三级结构来管理需求，但他们的高明之处不在结构本身，而在于明确规定了“只有当前迭代内的用户故事才需要足够清晰到可以开发”。下一迭代的需求只保留方向和优先级，细节允许模糊。再远的需求只保留在史诗层面，不进行拆分。

这种做法背后的底层逻辑是：需求描述的精度应该和开发的时间距离成正比，距离越近越细，越远越粗。 这听起来像是常识，但真正能做到的团队少之又少。因为人有一种心理倾向：既然花了时间讨论，就忍不住想要把所有细节都定清楚，否则觉得不安心。但正是这种“提前细化”的行为，制造了大量的浪费，三个月后那些细节大概率会变。

第二，他们把迭代评审和回顾做成了真正的“信息回流通道”。 瀑布模式下，需求一旦进入开发就好像沉入海底，直到系统测试甚至验收阶段才重新浮出水面。这中间发生了什么，客户和业务方几乎看不到。PingCode 的做法是每个迭代结束必须做评审演示，不是对着 PPT 讲，而是拿可交互的软件给客户看。这个动作相当于在每个迭代终点设置了一个“信息回流点”，让需求理解偏差在一个迭代周期内（通常是两周）就被发现和纠正，而不是等到三个月后才暴露。

我观察到一个细节：PingCode 的迭代回顾会上，团队不只是讨论“这个迭代哪里做得好哪里不好”，他们会在回顾板上有意识地记录“本迭代发生了几次需求变更、每次变更的触发原因是什么、是外部因素还是前期分析遗漏、是否可以在下个迭代避免”。这些记录积累几个迭代之后，团队就能从数据中发现自己在哪个环节最容易出问题，然后定向改进。这就把一个“被动的、应激式的需求管理”变成了“主动的、学习型的需求治理”。

第三，工具层面做到了需求-任务-代码-测试的全链路关联。 这一点看似是工具功能，实际上影响的是信息透明度。在 PingCode 的 Scrum 解决方案中，一个用户故事从创建那一刻起，它所拆解出的开发任务、关联的代码分支、对应的测试用例、发现的缺陷，全部可以在一个页面上溯源。当客户提出一个需求变更时，团队可以在几分钟内评估出：这个变更涉及多少代码、会影响哪些已有的测试用例、有多少未关闭的缺陷可能被波及。

这种信息透明度，直接解决了我在传统瀑布项目里最头疼的问题：评估变更影响靠拍脑袋。 以前项目经理接到变更需求，只能找技术负责人估算，技术负责人翻一翻代码再根据经验估一个数，这个估算的误差经常达到 50% 以上。有了全链路关联之后，评估依据变成立刻可查的数据，而不是模糊的经验，谈判时底气也足得多。

六、实操篇：当需求注定定不下来时，你的团队应该做的七件事

说了这么多分析和观察，如果你正在一个瀑布项目里焦头烂额，下面这些是我认为真正能帮上忙的操作。不是理论，不是大词，是我自己和带过的团队一条一条践行过的动作。

1. 停止用“需求确认书”麻痹自己

签字可以继续签，但请在心里把签字的定义从“客户确认了就定了”改成“客户确认了当前阶段的理解”。两字之差，天壤之别。前者让你在变更发生时觉得“客户违约了”，后者让你在变更发生时觉得“理解升级了”。心态不一样，接下来的所有动作都会不一样。

2. 建立“最近2周需求+远期方向”的双层规划

不管你名义上用的是瀑布还是敏捷，实质上都应该做到：最近一个交付周期（建议不超过两周）的需求细化到可开发可测试的程度，未来两到三个交付周期的需求只保留优先级排序和概要描述，再远的需求只记录方向不做拆分。这个习惯会迫使团队专注于“马上要做的事”，减少对远期模糊需求的无效争论。

3. 每个需求后标注两个元数据：可变性等级和变更成本预估

我给团队订了一个规矩：每一条需求入池时，除了写清楚内容和验收标准，还必须标注：

• 可变性等级：基于业务分析判断，这条需求未来变更的可能性高/中/低。
• 变更成本预估：一旦这条需求改变，预计返工量是几人天。

这两个标签组合起来，能帮我们在规划迭代时做出更聪明的选择：高可变性+高变更成本的需求尽可能推迟开发；高可变性+低变更成本的需求可以纳入当前迭代但架构设计要预留弹性。

4. 把“需求变更记录”当成项目资产，而不是罪证

很多团队也记录需求变更，但记录的目的是“将来跟客户算账用的”，这种心态下，变更记录写得越详细，对抗意味越重。我建议换一个角度：变更是团队理解客户真实需求的过程证据。把每一次变更的原因、影响范围、决策人记录下来，项目结束时回头复盘，你会发现一套关于这个行业、这个客户的隐性知识。这套隐性知识才是乙方公司在项目中积累的核心资产，远不止是项目款。

5. 要求产品负责人/需求分析师参与迭代全过程，而不仅仅是需求阶段

瀑布模式下，需求分析师写完文档就转岗做别的项目去了，这是造成需求信息断裂的重要原因之一。我之后在项目管理中做了一个调整：负责需求的人必须在整个交付周期内保持一定投入比例（比如 30% 的时间），参与迭代评审、回答开发团队的问题、对变更进行第一轮评估。这不是增加成本，这是防止因为信息断裂导致的更大成本。

6. 用“假设验证”替代“需求确认”

这个思路转变价值最大。传统做法是：你认为用户需要这个功能，写进需求文档，让用户确认。我把这个流程改成：你认为用户需要这个功能，这只是一个假设，我们做一个最粗糙版本来验证这个假设。如果假设正确，继续投入；如果假设错误，立刻调整方向。这种“假设驱动”的思维模式，把需求管理从一种行政确认行为变成了一种科学实验行为，前者怕变化，后者欢迎反馈。

7. 在合同中为变更管理建立共同认知

这是最容易被忽略但可能是最重要的一条。很多外包项目的合同里，变更条款写得含糊或者过于严苛，这给后续的执行埋下了巨大的风险。我后来在签合同前一定会和客户专门开一次“变更管理对齐会”，把以下问题讲清楚、写进合同附件：什么算是变更而不是需求澄清？变更的影响评估由谁做、以什么为依据？不同量级的变更走什么样的审批流程？额外费用和时间怎么计算？

这些东西提前说清楚，不是不信任，恰恰是专业信任的体现。客户在签合同的时候就明白“变更有成本有流程”，比项目中期突然被告知“你得加钱”要好得多。

七、什么时候你应该坚持确定性，而不是拥抱变化

写到这里，可能有人会误以为我主张所有项目都应该放弃确定性、拥抱变化。恰恰相反。

有一类项目，对需求的稳定性要求是刚性的，不能也不应该被“迭代式澄清”取代。根据我的经验，判断标准如下：

1. 安全攸关系统

医疗设备控制软件、航天飞行系统、核电控制平台、车载安全模块，这些领域的软件，任何一个需求变动都可能引发链式的安全后果，需要严格的变更影响分析和全面回归测试。在这类项目中，需求冻结不是可选策略，是必须策略。即使因此导致开发效率降低，也必须接受。

2. 合规审计驱动的项目

某些金融系统、税务平台、招投标管理系统，需求的核心部分来自监管条文。监管条文一旦明确，需求就确定了，直到监管条文更新。这类项目不需要过度准备“弹性”，因为它们的变化是可预期的、有前置信号的。

3. 外包合同中明确约定了固定范围、固定报价、固定交付时间的项目

如果你签的是一份三方比价之后确定的固定总价合同，那么需求范围必须尽可能锁定。在这种情况下，需求冻结有其商业合理性。但不锁定的代价是乙方承受无限返工风险，这在商业上是不可持续的。

坦率地说，判断“该不该拥抱变化”的标准可以浓缩成一句问句：

项目的主要风险是“做错需求”，还是“错过时机”？ 如果答案是前者，偏向确定性；如果答案是后者，偏向适应性。大多数企业软件项目其实处于两者之间，需要的不是二选一，而是分层管理。

八、一个我不愿意承认但必须写出来的真相

坦白地说，在我做过的所有项目里，没有任何一个项目的需求是真正“定下来”的。一个都没有。

那些最终交付成功、客户满意的项目，不是因为需求没变，而是因为项目管理者和团队在心理上、流程上、合同上都为变化预留了空间。他们不把需求变更视为意外，而是视为信息。

而那些做得痛苦、甚至失败的项目，往往有一个共同特征：项目启动时所有人都信心满满地说“这次需求搞清楚了”，然后当第一轮变更来临时，整个团队的认知防线瞬间崩塌，从自信跌入抱怨。

这个行业的很多痛苦，其实不来自于需求本身，而来自于我们对确定性的执念。

如果你正在负责一个需求永远定不下来的项目，我的建议不是让你去学一套新的项目管理方法论，而是先做一个小小的心理实验：从今天开始，把每一次需求变更当成客户在给你发送信号，“关于真实需求，我现在比以前知道得更多了”。把这个信号接住、记录下来、反馈到开发中，而不是愤怒地拒之门外。

这个转变不会立刻让你的项目变好，但它会让你自己先从一个被动的受害者，变成一个主动的信息处理者。而这是一切实质性改善的起点。

下一步做什么？如果你手里的项目正处在需求反复变更的煎熬中，我建议你明天就做一件事：打开你最近十次需求变更的记录，逐条在变更原因那一栏标注，是外部环境变化、内部决策调整、前期调研遗漏、还是沟通理解偏差。标注完之后你大概率会发现一个规律：大部分变更是集中在某一两类原因里的。找到那个原因，针对它做一件事，哪怕很小，也比继续在原地抱怨“需求永远定不下来”有用一百倍。