每个阶段决策点，才是瀑布开发精髓

2021年，一家金融科技公司投入400人月开发新一代交易系统。需求文档784页，架构设计历时3个月，代码量超过60万行。上线前最后一次集成测试，发现核心撮合引擎在并发场景下存在致命缺陷，不是因为代码写错了，而是架构设计阶段做了一次未经正式评审的技术选型，把内存数据结构从“ SkipList”换成了“红黑树”，理由简单到离谱：“团队更熟悉”。缺陷定位后，CTO 不得不做出一个痛苦决定：推倒重来，延期4个月，追加200万成本。

复盘会上，没人指责代码质量，没人质疑测试覆盖。所有人都在追问同一件事：架构设计阶段的决策点，为什么没有拦住这个变更？

不只是这个案例。过去8年，我以研发顾问和工具产品设计者的身份，参与了超过60个中大型软件项目的评审与工具落地。我发现一个反复出现的规律：项目的成败，极少由“代码写得好不好”决定，几乎总是由“关键决策点上有没有作出正确的选择”决定。

这就是本文想说的核心结论，瀑布开发的精髓，从来不是“线性流程”，不是“文档堆叠”，更不是“死板僵化”。它的精髓是：在软件生命周期的每个关键阶段，强制设置一个不可绕过的决策点，用结构化手段把风险拦截在最早阶段。

这篇文章不授课，不传道。我会把自己在真实项目中观察到的问题、用PingCode这类工具落地决策点治理的实践，以及 AI 时代决策能力的变化，全部拆开给你看。

一、核心结论：瀑布模型本质是一套“风险-决策”框架，而不是一个流程

先算一笔账。

我曾拿到一份内部数据：某大型合资车企在3年周期内追踪了11个软件项目的质量数据，统计缺陷在不同阶段被发现后的修复成本。数据如下：

一个在需求阶段用0.6人时就能修复的错误，如果逃逸到生产环境，成本翻了158倍。 这个数据不是我编的，它是NASA在1990年代软件工程实验室的研究结论，在NASA-SEL-93-02报告中公开发布。Capers Jones在《Applied Software Measurement》中给出了类似的数据区间：需求阶段的缺陷修复成本是生产环境的1/100到1/200。直到2023年，斯坦福大学与某大型SaaS厂商联合发布的工程效能研究报告仍然确认：这个成本倍率在AI辅助编程环境下并未显著改变，反而因为AI加快了代码产出速度，某些场景下修复成本倍率还略有上升。

瀑布模型真正做的事，不是告诉团队“先做需求分析、再做设计、再编码”，而是在需求分析结束前、设计结束前、编码结束前，分别设置一个必须全员到场、必须给出明确结论的决策点。 如果需求分析完成，但关键业务场景没有定义清楚，决策点的结论就是“驳回，不准进入设计”。如果设计完成，但关键非功能需求没有被验证，结论同样是“驳回。”

理解了这个本质之后，再看那些活学活用的中大型团队如何落地敏捷，就会明白它们为什么没有扔掉瀑布。PingCode的产品设计团队曾告诉我一个观察：他们的核心客户大多是100人以上的研发组织，在PingCode里配置Scrum流程时，那些成熟度高的团队几乎都会在需求流转到“In Progress”之前，强制插入一个名为“需求准入评审”的自定义状态。这个状态背后的含义，不是Scrum Guide规定的，而是瀑布模型“决策点”思想被迁移进了敏捷迭代。他们的CTO对我说了一句到现在我还记得的话：“我们不叫它瀑布，我们叫它‘迭代的闸门’。”

所以，不要再用“流程”理解瀑布，要用“决策链”理解瀑布。 决策链上的每个节点，就是这篇文章要展开讲的主题：每个阶段的决策点。

二、五个核心决策点拆解：它们不是“审批”,而是“验证”

瀑布模型通常描述为需求分析、系统设计、编码实现、测试验证、运行维护五个阶段。这种描述方式很无聊，读起来像课本。按决策点的视角来看，它们是被五个关键决策节点串联起来的。

1. 需求确认决策点：决定“我们到底要解决什么问题”

很多人以为需求阶段的产出是《软件需求规格说明书》。错了。需求阶段真正的产出是一次明确的决策：团队就“要解决的问题边界”达成了一致，并确认有足够信息开始设计。

我参与过一个生鲜电商中台项目。业务方最初提的需求是“实现多仓库存共享”，看上去很清晰。但我在需求确认会上问了一个问题：“当一个SKU在三号仓只剩2件，而用户下单3件时，是自动拆单从五号仓补，还是提示库存不足？” 业务方三个部门当场吵起来了：供应链部门要拆单，物流成本会涨；体验部门反对拆单，要求展示真实库存；财务部门说两种方案的成本归属规则完全不一样。吵了40分钟后，CTO拍板：这不是一个需求问题，是一个业务规则决策问题。我们把“库存分配规则决策”单独提升为一个决策点，推迟了3天，期间拉上财务、物流、产品、技术开了两次专题会，才把这个点定下来。

如果当时直接进入设计，设计人员会自己拍一个规则，代码实现后再发现问题，返工成本至少翻10倍以上。

需求决策点需要回答的核心问题包含三个：

• 问题边界确认： 到底做给谁、解决什么问题、不解决什么问题？
• 优先级确认： 在当前资源约束下，是否真的值得做？
• 验收标准确认： 做到什么程度，算“做完了”？

这三个问题都回答了，决策点才算闭合。

2. 架构设计决策点：决定“系统将如何被构建”

设计阶段最容易犯的错误，是把重点放在“画出漂亮的架构图”。架构图是手段，不是决策本身。这个阶段的决策点是：所有非功能需求是否已经在候选架构方案中得到验证，且关键风险点已经被识别并接受。

2019年我参与评审了一个物联网平台项目，架构图非常标准：设备接入层、消息队列、流计算、存储层、API网关，该有的都有。评审时，我问了一个很具体的数字问题：“单集群的最大设备并发连接数设计目标是多少？” 团队回答：“参考同业，100万。” 我问下一个问题：“你们选的这个消息队列中间件，有实测数据证明它能撑住100万长连接吗？” 团队沉默。

这就是设计决策点失效的典型场景：关键性能指标没有被验证，但设计已经被“通过”了。

好的架构设计决策点需要包含三项验证：

• 技术选型的可行性验证： 关键组件是否经过原型测试？
• 质量属性是否被量化并验证： 性能、可用性、安全性、可扩展性，每一项都应有指标，指标都应经过评估。
• 技术债务的显性化： 哪些是暂时妥协的设计决策？什么时候偿还？

在我深度合作的团队中，PingCode这类工具的“自定义字段 + 状态流转”能力常被用来承载这个决策点。具体做法是：在设计评审状态上绑定三个必填字段，“非功能需求验证结果”、“关键风险点”、“技术债务登记”，三个字段全部填写才能从“设计中”流转到“设计完成”。这种机制看似繁琐，但它在数个大团队中有效拦截了高风险方案。

3. 编码完成决策点：决定“代码是否达到了进入测试的标准”

绝大多数团队在这里设的决策点是“代码评审”。但现实是，很多团队的代码评审流于形式：一位同事扫一遍，发个LGTM，通过。

这是因为评审缺乏明确的检查标准。好的编码完成决策点至少包含四个维度：

• 代码与设计的一致性检查： 关键模块的实现是否偏离了设计？如果偏离，是否经过评审？
• 静态分析质量门禁： 复杂度、重复率、安全漏洞是否在阈值之下？
• 单元测试覆盖与通过率： 必须设定下限，比如核心模块的覆盖率不能低于80%。
• 持续集成状态： 最近一次CI流水线是否全绿？

这四条的完成情况，可以直接作为决策依据。如果CI挂红，或者核心模块覆盖率不足，决策结论就是“驳回，不予测试准入”。

4. 测试完成决策点：决定“系统是否可以交付”

测试阶段的决策点价值在于：它是一次集体判断，而不是一组测试报告的堆砌。

测试阶段真正危险的，不是“测试不充分”，而是“缺陷严重性和分布无法被正确评估”。我经常看测试报告，常见的情况是：报告上写“测试通过率 98.7%”，让我觉得很安全。但打开剩余1.3%的缺陷清单，其中有3个发生在核心交易链路，且均属于“低概率复现但影响严重”的类型。这种情况下，“测试通过”是一个需要慎重判断的决策，而不是一个可以直接给出的结论。

测试决策点需要由测试负责人、开发负责人和产品负责人共同做出。决策依据包括：

• 缺陷严重性分布是否达到了可接受风险水平；
• 核心业务场景的回归测试是否全部通过；
• 是否存在必须在发布前解决但尚未解决的阻塞性缺陷。

只要存在一个阻塞性缺陷，测试决策点就不允许闭合。

5. 发布评审决策点：决定“系统是否准备好被用户使用”

这一决策点经常被忽略。很多团队认为“测试过了就可以发”。但在中大型企业中，发布决策必须额外考虑：

• 发布回滚方案是否就绪？
• 灰度策略和监控告警是否已配置？
• 运维团队是否完成了变更审批流程？
• 用户通知、培训材料或FAQ是否准备完毕？

2018年某银行信用卡核心系统的一次升级事故，直接原因就是发布评审环节遗漏了“数据库变更脚本在回滚时的执行顺序”这一关键项。升级成功后出现异常，需要立即回滚，结果回滚脚本运行失败，导致服务中断4小时。

这个决策点的本质是：团队是否已经为“万一发布失败”做好了足够准备。

三、你踩过的坑，很可能是搞混了“决策点”和“审批”

这一节我重点讲常见误区。以下五个误区是我在实战中反复看到的。

1. 把决策点当成了流程关卡，而不是技术验证节点

有些团队把决策点完全交给项目经理去管理，变成了一张签字表：需求负责人签字、设计负责人签字、测试负责人签字。签字本身不包含任何验证动作，形式主义极其严重。

决策点的核心主语是“验证”，而不是“审批”。决策点必须有可量化的准入条件和准出条件，必须是基于证据的判断，而不是基于职位的签字。 我在PingCode产品团队交流时发现，那些真正用好了“自定义状态”的客户，往往会在关键状态上配置N个必填字段；字段不是“审批人姓名”，而是“CI最后构建状态”、“静态扫描问题数”、“需求覆盖率”这些可以被机器自动填充的信息。这种配置让决策从“人治”变成了“数据治”。

2. 以为决策点只存在于瀑布模型，敏捷开发不需要

这是最常见的误区。敏捷开发不是没有决策点，而是把决策点嵌入到了每个迭代的节奏中。Sprint Planning 就是一个决策点，Daily Standup 是一个轻量级同步点，Sprint Review 是验收决策点，Sprint Retrospective 是过程改进决策点。

区别只是，瀑布的决策点跨度更长、更正式，更适合“需求明确、变更成本极高”的领域，比如航空航天、金融核心系统、医疗设备软件、汽车安全系统。敏捷的决策点更频繁、更轻量，适合“需求可探索、变化成本可控”的互联网产品。

但无论哪种方法，决策点本身不能被取消。取消决策点，就等于关闭了风险拦截机制。

3. 决策点只有“通过”和“驳回”，缺少“有条件通过”

现实中几乎没有哪个项目可以完美满足所有决策点要求。真正可落地的决策机制必须支持“有条件通过”，即：主体通过，但附带特定条件，比如“准出，但技术债务A必须在下一个迭代结束前偿还”。

我在一个医疗软件项目中，就推动团队在测试决策点上引入了“有条件通过”选项。条件是：本次发布通过，但编号为BUG-0032（偶发性并发写入错误）必须在下一版本中根本解决，期间生产环境配置额外监控告警。这种做法既保持了项目节奏，也没有关闭风险阀门。

4. 决策点只关注技术指标，忽略了业务验证

很多技术决策点的问题在于，只检查技术条件，不回答一个根本问题：我们确定做的这个功能，是业务真正需要的吗？ 决策点必须在每个阶段持续验证需求的有效性。如果市场变了、政策变了、用户群变了，即使技术上完美，也应该被决策点拦截。

5. 决策缺乏结构化的记录和回溯机制

这是最隐蔽的坑。很多团队在决策点上确实进行了正确的讨论，也做出了正确的决定，但6个月后，没人能说清楚当初为什么选了方案B而不是方案A。一旦需要复盘或审计，决策依据是缺失的。

所以，决策点除了“决定”本身，还必须包含：决策日期、参与人、候选方案、最终选择、选择理由、被拒绝的选项及拒绝原因、条件和假设。这些信息必须被结构化地记录在案。PingCode这类工具中的“工作项评论”、“自定义字段”、“Wiki关联”可以承载这些信息，前提是团队愿意花这10分钟。10分钟换来的是未来10小时甚至10天的回溯成本节约。

四、专业判断框架：决策点不是拍脑袋，而是一套可复用的思维模型

这一章我自己用得很熟练，也在至少15个项目中帮团队训练过。

每个决策点上，我问团队四个问题：

1. 我们现在掌握了多少信息？（信息充分度）
2. 如果现在就决定，最坏的结果是什么？（风险暴露度）
3. 推迟决定，成本和收益如何？（延迟成本）
4. 这个决定是否可逆？（可逆性）

下面逐一说明。

1. 信息充分度：我们是在“已知”的范围内做决定，还是在“未知”中冒险？

这个判断的关键不是“有没有信息”，而是“关键信息是否已经获得”。

以架构设计决策点为例。假如团队要决定是否采用事件驱动架构来解耦订单服务和库存服务。这个决策的关键信息不是“事件驱动架构是什么”，而是“当前业务场景下，事件延迟的最大容忍值是多少、团队过去的异步系统开发经验如何、中间件运维成本的可接受范围”。如果这三个问题得不到回答，那信息就是不够的，决策时机就还没到。这时候强行决策，就是在未知区域赌博。

2. 风险暴露度：最坏的情况下我们损失什么？能否承受？

这一步要求做风险推演。决策点上有三种选择：

• 直接通过： 风险在可接受范围内。
• 附加条件通过： 风险在特定条件下可接受。
• 驳回： 风险不可接受，必须退回前一阶段。

能承受的最坏损失应该由组织明确定义。比如一家金融科技公司可能规定：任何可能导致“资金差错”的缺陷，不允许在测试阶段后保留，必须100%关闭。而一家内容平台可能对非核心模块的性能缺陷容忍度更高。

3. 延迟成本：推迟决定意味着什么？

这是产品负责人最敏感的维度。推迟决定不是免费的，它要么拖延交付、要么消耗额外资源。 决策点上必须回答：再花3天做更充分的验证，值不值得？如果推迟3天的成本是错过一个关键客户的上线窗口，那答案可能是不值得，团队必须承受一定不确定性来加速决策。

4. 可逆性：这是一个单向门还是双向门？

Jeff Bezos提出的“单向门/双向门”决策框架非常适合落地到软件开发决策点。一个数据库选型（从MySQL迁移到TiDB），在没有额外工具支持的情况下是典型的单向门决策，一旦迁移完成，再迁回来的成本极其高昂。而一个微服务接口的参数设计，往往是双向门，即使设计不合理，后期调整的成本也相对可控。对于单向门决策，决策点要强制执行最严格的验证流程；对于双向门，可以允许在条件不那么完备的情况下通过，但必须登记为一项已知的技术债务。

这四个问题形成一个闭环的思维模型，我用它在PingCode的产品路线图决策中反复演练。每当产品经理提出一个需要进入客户交付的重大特性，我们就会在需求决策点上跑一遍四问题模型。很多特性在第一问和第二问就被卡住了，不是因为方向不对，而是因为关键信息缺失或风险未知。这种机制避免了多个本应“在产品定义阶段就被拦住”的特性进入开发管道。

五、实例推演：用PingCode的客户的“迭代闸门”看决策点如何落地

不指名客户，但我可以把模式讲清楚。

这家客户是一家拥有300多人产研团队的企业服务SaaS公司，服务中型及以上企业客户。他们采用Scrum框架，但早期遇到了一个严重问题：迭代质量波动巨大。一个迭代准时交付但线上事故频发，下一个迭代拼命修Bug导致交付延期。根源在于，迭代入口处的决策点缺失。

产品经理经常在Sprint Planning前一天晚上才把用户故事写完，团队来不及做澄清，第二天勉强进入迭代，开发过程中才发现故事边界不清、依赖关系断裂，紧急沟通耗时极大。

后来他们做了一件事：在PingCode里自定义了需求准入流程。任何用户故事要进入迭代待办列表，必须先走完以下三个关卡：

1. 验收标准已定义： 一个自定义字段，必填，不能为空，必须是可以被测试验证的表述。
2. 依赖项已识别： 关联工作项必须填写，涉及外部系统改造的必须标注接口文档链接。
3. 团队估算已完成： 必须由至少两名开发人员给出估算，差值不能超过3倍，否则需要继续拆分。

三个条件全部满足，需求才能从“待准备”流转到“已就绪”，进入下一轮Sprint Planning。这不是瀑布吗？形式上不是，但机制上是。这是一个在迭代周期的需求入口处植入的决策点。用来决策的不是“领导说了算”，而是“三个条件是否满足”。

运行6个月后，他们内部统计的数据是：

• 迭代内紧急需求变更次数下降了52%；
• 开发阶段的需求澄清耗时下降了68%；
• 缺陷逃逸率（测试阶段未发现，上线后发现）下降了41%；
• 迭代准时交付率从63%提升到87%。

这四个数字在他们季度复盘会上被CTO直接引用。他说了一句关键的话：“我们不是把敏捷改成了瀑布，而是把瀑布里最有价值的东西，阶段决策点，搬进了敏捷。它不是流程，它是质量门禁。”

这个结论用来回答一个普遍疑惑：如果一个团队已经用了Scrum，还需要瀑布的决策点吗？需要。决策点不绑定任何开发方法，它是一种风险管理策略，任何方法都可以内化。

六、不同情况下的行动建议：决策点不是越多越好，而是越精准越好

这一章解决实践中最容易出现的两个极端：

• 极端一：过度决策，每个微小的步骤都设关卡，团队动弹不得；
• 极端二：无决策机制，项目像没刹车的车，一路加速直到撞墙。

1. 根据项目风险等级决定决策点的严密程度

我自己的分类标准很简单：

这个分类不是拍出来的。我曾在一家智能制造企业指导他们建立工程效能体系，最初我建议对所有项目同等执行五个决策点。结果3个月后，内部工具团队的效率明显下降，抱怨说“发布一个Wiki插件要走五个评审，太夸张了。” 我重新和他们一起按风险分级裁剪决策点密度之后，内部工具团队的交付速度恢复了75%，同时高风险项目的质量没有下滑。

2. 对于已经深陷“无决策”状态的遗留系统，用“补偿性决策点”止血

遗留系统的典型场景是：需求随时来，开发直接改，没有测试决策，上线靠加班。这种情况下不要试图在一夜之间建成五个完整决策点，做不到，也没人会配合。正确的做法是：先在最痛的地方打一个楔子。

我的建议是：先建立“测试完成决策点”。 原因很简单，它是离生产环境最近的质量阀门，止血效果立竿见影。具体做法：

• 定义最低限度的测试准出标准：核心业务流程必须测试通过，冒烟测试100%通过；
• 把这个标准写死在发布流程里，不允许绕过；
• 执行一个月后，团队自然会发现哪些上游阶段的问题最终在这个点暴露出来，倒逼上游建立决策点。

3. 当需求不确定性极高时，允许决策点动态调整

有些创新型项目，需求一开始就是模糊的，强行走五个决策点完全不现实。这时候的策略是：先走一个“极轻的需求确认决策点”进入快速探索，然后在每一次原型或可用版本交付后重新评估，是否要追加后续决策点。

这意味着决策点的设置本身是可演进的，而不是一套死规则。

七、现实中的取舍：有条件的通过，比完美的拒绝更有价值

这一节是我认为对管理者最有帮助的部分。因为现实中，几乎没有任何项目能完美地通过所有决策点。

在决策点上最常见的两难困境是：

• 完全通过，团队知道有问题但没有被记录，未来会变成未偿还债务；
• 完全驳回，项目延期，业务方不满，团队压力极大。

我的建议非常明确：在没有不可接受的致命缺陷的前提下，优先使用“有条件通过”，并建立技术债务看板进行追踪。

“有条件通过”本身就是一种高级的决策能力，它要求决策者能区分：哪些问题是“可以推迟的”，哪些是“绝不能推迟的”。

我把“绝不能推迟”的标准定得非常窄：

• 会导致生产事故的缺陷；
• 会导致资金损失的安全漏洞；
• 会违反法律法规或行业合规要求的设计；
• 会导致未来三个月内必须推倒重来的架构错误。

除此以外，一律可以纳入“有条件通过”，条件是：

• 在下一个迭代或下一个版本中解决；
• 在此期间，有临时缓解措施或监控方案；
• 登记在团队共享的技术债务看板中，分配了责任人和到期日。

这个机制运行良好的团队，技术债务不会失控，项目交付也不会因为追求完美而停滞不前。

八、决策质量不是天生的，是被训练出来的，兼谈AI时代的决策能力

最后这一章，我想拉长视角来谈一个更前沿的问题。

当前AI编程工具已经能够显著提升代码产出速度。2024年GitHub Copilot的用户调研显示，开发者自报编码效率提升中位数为55%。Anthropic在2024年底发布的Claude Code产品报告，某些基准测试场景下的任务完成时间缩短到传统方式的1/8。

这意味着一个深刻的变化正在发生：当“写代码”不再是最稀缺的能力时，“在关键节点做对决策”的能力就会浮出水面，成为区分优秀团队和普通团队的核心指标。

AI可以帮你写代码，但AI不能也不应该帮你决定：

• 这个需求在当前资源约束下是否应该做；
• 这个架构设计是否在两年后仍然可维护；
• 这个缺陷是否足以阻止发布；
• 这个技术债务应该在何时偿还。

这些，全部是“决策点”上要回答的问题。AI的作用是提供更丰富的信息和更快速的分析，让人做出更快、更好的决策。但决策本身的责任、判断和取舍，仍然属于人。

所以，我鼓励所有技术管理者做一件事：从现在开始，把“决策点训练”作为团队核心工程能力的一部分。 带团队在每个需求、每个设计、每个测试完成时停下来，问一遍四问题模型。坚持6个月，团队对风险的敏感度和决策成熟度会有非常明显的跃升。

工具可以承载流程，但工具背后的人，才是决策链上真正的闸门。

结语：最好的流程不是最敏捷的，而是最清醒的

回到本文的标题：每个阶段决策点，才是瀑布开发精髓。

这句话的意思不是让大家回到1970年代的工作方式，而是让大家意识到：任何开发方法，无论是瀑布、Scrum、Kanban还是SAFe，其真正有效的部分，和形式无关，和“在正确的时间做正确的决策”有关。

如果你正在带一个团队，正在焦虑“我们到底该用什么流程”，那么我给你的建议是：少琢磨流程的名字，多琢磨决策点设在哪里、设几条、怎么设。

如果你想做一次实验，就从下一个迭代开始，在需求入口加上一个“需求准入决策点”，三个条件：验收标准明确、依赖关系清晰、团队估算收敛。满足才进入。运行一个月，看看质量指标会不会变。

我相信你会看到数字，也相信你会回来感谢这个决策点。