从需求澄清到终验，瀑布开发全链路复盘

2008年，我在一家给运营商做Boss系统的公司，亲历过一个项目：合同金额470万，历时14个月，最后因为终验报告上的一行“系统在高并发场景下，开户接口响应时间未达合同约定的200毫秒以内”，被甲方卡掉了最后一笔15%的验收款。那笔钱，将近70万。而我们复盘的时候发现，这个问题不是出在代码写得烂，而是出在14个月前，需求澄清阶段，双方在《需求规格说明书》里对“高并发”的定义只写了四个字：“支持大并发”。没有具体数字，没有压测模型，没有峰值系数。直到终验，甲方掏出了合同附件里的《技术应答书》，里面赫然写着“单接口响应时间<200ms”，而我们签过字的那份《需求规格说明书》里，完全没出现过这个数字。两份文件打架，责任全在我们，因为合同约定，“技术应答书与需求规格说明书不一致时，以更高标准为准”。也就是从那以后，我养成了一个习惯：从终验倒推需求澄清。这篇文章，我会把这个习惯背后一整条的复盘逻辑、决策节点和实战案例，完整地拆给你。如果你是 PM、交付负责人、技术 TL，或者甲方里负责管外包 IT 项目的人，我非常确定，你能在这篇文章里找到至少三个明天就能用的动作。

一、核心结论：终验的果，早在需求澄清的因里就种下了

瀑布模型被骂“笨重”“僵化”不是一天两天了。但如果你真的带过合同金额在百万级以上、交付周期超过半年、涉及多个子系统的瀑布项目，你会发现一个被反复验证的事实：一个项目的成败，在需求澄清完成的那一刻，大约 60% 的结局就已经被锁定了。剩下的 40%，20% 看设计评审和变更控制，15% 看 UAT 阶段的博弈，最后 5% 才是运气。 终验不过，表面看是测试没测到位、代码质量不行、文档没交齐，但如果你顺着时间轴往回倒，几乎每一次终验卡壳，都能在需求澄清阶段找到它最早的种子。

这不是我的个人感觉。IEEE 在《软件工程知识体系指南》里引用过一组被广泛传播的数据（原始研究来自 Barry Boehm 的《软件工程经济学》）：在需求阶段修复一个缺陷的成本如果是 1，那么到了设计阶段是 5 倍，编码阶段是 10 倍，测试阶段是 20 倍，发布后再修复的成本可以飙到 50 倍甚至更高。这些数字或许在不同类型的项目里会有浮动，但它揭示的规律是铁板钉钉的：越晚发现问题，代价越大；越早澄清细节，风险越低。

所以我的核心结论很直接：终验不是终点，它是需求澄清质量的照妖镜。 复盘瀑布开发的全链路，正确姿势不是从需求讲到验收，而是从终验卡住的点，反推回需求阶段，看看当初哪句话没写清楚、哪个数字没量化、哪个场景没覆盖。这篇文章的结构，就会按照这个“逆推”逻辑来展开。我们先从终验最容易崩的三个点说起。

二、先看终验：你以为的问题，可能根本不是真正的问题

终验是甲乙双方最后一次正式交锋，也是钱能不能落袋的关键一战。这个阶段暴露的问题，通常能被归为三类。你得先搞清楚自己摔在哪一类坑里，才知道该回到哪个环节去补课。

1. 功能与需求不符，“我们做的，不是他们要的”

这是最常见的终验翻车原因。甲方走到终验这一步，往往已经忍了很久了。UAT 阶段他们提了很多意见，项目组也改了很多东西，但双方对“需求是否被满足”这个核心问题，始终没有达成过一致。到了终验，甲方会把 UAT 阶段所有没关闭的缺陷、口头的抱怨、甚至非功能性的主观感受，打包成“未按需求实现”这个理由，拒绝签字。

我后来复盘发现，这类问题的根源，百分之八九十不是开发没做对，而是需求澄清阶段，双方对“完成”的定义就没对齐。 甲方觉得“完成”等于“符合业务预期，用起来顺手”，项目组觉得“完成”等于“实现了需求规格说明书里列出的功能点”。这两个定义之间的鸿沟，就是终验时撕扯的空间。

2. 非功能性需求不达标，“系统太慢了/崩了/不好用”

这类问题比第一类更难缠，因为它常常有客观数据作背书。压测报告显示响应时间超标、安全扫描发现了中高危漏洞、系统在运行了三个月以后查询速度断崖式下跌……这些都不是“沟通误会”，而是实打实的技术债。但你再往前倒一步，这些技术债是怎么欠下的？需求阶段，客户说“系统要快”，你说“好的”；设计阶段，架构师说“这个查询要走全表扫描，数据量大了会慢”，项目经理说“先上了再说，后面再优化”；开发阶段，大家都忙着堆功能，没人提压测的事儿；到了测试阶段，功能性用例都跑不完，性能测试一拖再拖；最后终验，客户甩过来一份第三方压测报告，所有人傻眼。

非功能性需求从来不是“锦上添花”，它是终验时定性的硬指标。 你回头看合同，里面一定会有一条：“系统应满足以下非功能性指标……”如果需求阶段这一块没做量化澄清，你连反驳的依据都没有。

3. 文档与交付物不匹配，“交上来的东西对不上”

这个坑看起来低级，但在大型项目里发生的概率高得离谱。终验文档清单通常包括：需求规格说明书、系统设计说明书、数据库设计文档、接口文档、部署手册、运维手册、测试报告、用户手册……一个百万级项目，文档加起来上千页很正常。问题出在，开发过程中需求变更了十几轮，代码改了，但文档没跟上。到终验的时候，你交上去的设计说明书里写的表结构，跟实际数据库里的表都对不上，甲方随便抽查两个就能判你“交付物不合格”。

很多项目经理把文档当成终验前突击的“作业”，这想法从一开始就错了。文档不是交付物，是需求澄清的延续。 它在迭代中持续腐烂的根本原因，是需求澄清阶段没有建立“文档与代码同步更新”的机制。

三、回溯第一个关键节点：需求澄清的“量化博弈”

现在我们开始倒推。终验收的三大类问题，根源都指向了需求澄清。那我就来拆一下，需求澄清到底该怎么做，才能把终验收的雷提前排掉。

我先给一个判断：需求澄清的本质不是“搞清楚用户想要什么”，而是“把双方对结果的预期，锁定在一份可度量、可验证的协议里”。 这句话值千金。因为“搞清楚想要什么”是永远做不到的，甲方自己很多时候也不知道自己到底想要什么，或者甲方内部不同角色想要的东西互相矛盾。你能做的，是双方在一个明确的框架下达或共识：我们就用这些指标来衡量项目是否成功。如果将来任何一方想推翻，请先修改这些指标。

1. 功能需求：用场景树替代功能清单

我待过的团队里，很多 BA 写需求规格说明书，喜欢拉一张巨大的功能清单，几百条，每一条写着“系统应支持 XX 功能”。这东西开发喜欢看，因为它可分工、可估点、可度量。但客户不喜欢，客户脑子里的系统是一个个业务场景串起来的流程。你用功能清单去和客户做需求澄清，就像用零件图去跟人解释一辆车怎么开，对方会本能地觉得“你没理解我”。

后来我换了一种做法，效果好了很多：用场景树替代功能清单。 需求澄清阶段，先画出一棵场景树，树干是核心业务流程，树枝是分支场景和异常场景，树叶才是具体的功能点。每一个树叶级别的功能点，都必须能回溯到某个具体的业务场景。在需求评审会上，我不会念功能清单，而是带着客户沿着场景树走一圈：“张科长，月底你从财务系统拿到对账单以后，是不是在这里导入？如果对账单有 20 万条记录，系统应该在多长时间内给出差异报告？”客户一听这个场景，立刻就能给出反馈，因为在他们的脑子里，这些东西是连在一起的。

更重要的是，这种做法能帮你提前暴露一类终验收里极易翻车的细节，异常场景。 功能清单模式下，BA 列的 100 条功能，95 条都是“正常流程”下的功能。但真正导致终验收扯皮的，往往是那些非正常流程的东西：网络断了怎么办？审批人离职了怎么办？数据导入到一半浏览器关了怎么办？用场景树做需求澄清，每一根树枝都强迫你问自己：“这个场景还有哪些可能的分支？”你会发现，那些后来在 UAT 和终验收阶段被客户揪住不放的点，大部分都能在场景树的覆盖范围之内。

2. 非功能需求：把形容词全部翻译成数字

这是我在那个 70 万终验款打水漂的项目之后，给自己定的铁律：需求规格说明书里，不允许出现任何无法被客观度量、验证的形容词。 “快”要翻译成“95% 的请求在 200ms 以内”，“稳定”要翻译成“系统可用性 99.95%，全年允许的宕机时间不超过 4.38 小时”，“大量并发”要翻译成“以每秒 500 个开户请求的速率持续压测 30 分钟，平均响应时间不高于 300ms，错误率不高于 0.1%”。没有技术的翻译，这些词就是终验收时甲方手里的万能武器，你怎么证明“够快”？

我现在的做法是，在需求澄清阶段，专门辟出一个章节，叫“非功能需求量化矩阵”。这张矩阵不是让客户填的，客户只会写“快、稳、安全”，这张矩阵是项目组的技术负责人，在理解了客户的业务语境之后，翻译出来的技术指标，然后逐条与客户确认并签字。比如客户说“导出报表要快”，你得问清楚：最大的报表大概多少行？多少个维度？你预期在多长时间内导出？是在上班高峰期导，还是半夜导？这些问题客户第一次被问的时候，大概率答不上来，但你必须追问。因为今天不追问，终验收的时候客户就会用“我自己的电脑上导出的比这个快”来跟你掰扯。

3. 文档基准：搞清楚哪份文件说了算

我在运营商、银行、政府项目里反复被教育过一件事：合同、技术应答书、需求规格说明书，这三份文件如果出现矛盾，必须明确优先级。 很多公司签合同的时候，销售为了中标，在技术应答书里把技术指标写得无比大胆。这份文件到了项目组手里，没人认真看过，大家都只认《需求规格说明书》。到了终验收，甲方从技术应答书里拎出一条来，你就傻眼了。

需求澄清阶段的最后一个动作，不是写完需求规格说明书，而是把合同附件中所有技术相关的承诺项，逐条在需求规格说明书里做响应和细化。 如果发现技术应答书里写了“支持单机 10 万并发”，而实际评估下来只能做到 2 万，这个鸿沟必须在需求澄清阶段就暴露出来，走正式的变更流程。如果在这个阶段藏着掖着，指望后期用技术手段奇迹般地填平，我可以非常负责任地说，大概率会砸在自己手里。

四、架设从设计到 UAT 的“责任护栏”

需求澄清做扎实了，最多只能解决 60% 的问题。剩下的 40%，我要聚焦在两个节点上：设计评审和 UAT。这两个节点被同时放在这一章来谈，是因为它们构成了从需求到终验收的“责任通道”。设计决定技术债的上限，UAT 决定验收时的扯皮空间。中间的管理如果断掉了，前面需求澄清做得再好，终验收照样可能崩。

1. 设计评审：承认并记录每一笔“技术债”

我见过最危险的设计评审，是把评审会开成了“设计宣讲会”。架构师在上面讲方案，下面一片安静，最后项目经理问一句：“大家有没有问题？”没人举手，评审通过。这种评审背后掩盖的问题，终验收的时候会加倍吐出来。

我的经验是，设计评审的核心产出物，不应该只是一份通过评审的设计文档，还应该包含一份设计决策记录。在这份记录里，团队要明确写清楚：为了实现哪些需求、在哪些约束条件下，我们选择了一种什么样的设计方案；同时，我们因此接受了哪些已知的风险、性能折损、扩展性限制。比如：“为了满足客户要求在两周内上线发票管理模块，我们决定复用现有的通用审批引擎，不重新开发专用的发票审批流程。这将导致发票审批无法支持按金额分级审批，且当审批链超过 5 级时，页面响应可能超过 2 秒。该限制已与客户方产品负责人 XXX 确认，计划在第二阶段优化。”

这段话的价值太大了。它在终验收的时候，就是你的护身符。当客户说“为什么发票审批不能分级”的时候，你把设计决策记录拿出来，上面有他方负责人半年前的签字确认，这不是 bug，这是双方达成共识的“有计划的妥协”。你把每一笔技术债都在设计评审的时候摆到桌面上，量化它的影响，然后取得客户认可，这笔债就不叫债，叫“分阶段交付策略”。你如果不说、不写、不确认，那这笔债到了终验收，就是你单方面欠下的。

2. UAT：把“验收标准”提前嵌入测试用例

很多项目组把 UAT 当成“让客户随便点一点，提提意见”的阶段，这是灾难性的认知。你让客户“随便点点”，他就真的会随便提，而且提的意见会像雪球一样越滚越大，从界面好不好看，一直扯到业务流程合不合理。UAT 如果不加控制，它不是质量门，是需求变更的二次洪峰。

我在 PingCode 服务中大型客户的过程中观察到，那些能在 UAT 阶段高效收尾、平稳过渡到终验的团队，有一个共同特点：他们早在需求澄清和设计阶段，就把验收标准写进了测试用例。 PingCode 这样的研发管理平台，支持将需求、用例、缺陷互相绑定。这意味着，每一个用户故事下面，都能关联到具体可执行的验收用例。产品负责人在迭代规划的时候，就可以直接看到：“这个故事对应的验收条件是什么？有哪些测试场景？”而不是等到 UAT 的时候，再凭感觉去验收。

更进一步，我强烈建议在进入 UAT 之前，和甲方共同签署一份UAT 缺陷分类标准。这张表把 UAT 期间发现的问题分为四级：一级是致命缺陷，比如系统崩溃、数据丢失，必须修复才能继续；二级是严重缺陷，比如核心流程跑不通，影响上线但可通过变通手段处理，需限期修复；三级是一般缺陷，比如界面错位、提示语不友好，可协商是否在本期修复；四级是建议优化，纯属锦上添花，不开给本期。这张表要白纸黑字签下来。否则，甲方会拿着一个拼写错误，用和系统宕机同样的权重来催你修复，不是因为他分不清哪个重要，而是因为你不给他分类，他就默认所有问题都是同等级别的。

五、回到终验：把收尾变成一个可预测的流程

我们花了前面四章的篇幅从终验收倒推到了需求澄清，现在可以回到终验收本身，用前面的积累，把收尾变成一个稳当的过程，而不是天天祈祷的运气局。

1. 终验的策略：从“求你签字”到“共同完成约定”

终验收绝不是项目组鞍前马后伺候甲方、直到对方心情好了盖章签字的过程。终验收的本质，是双方坐在一起，逐条对照合同和需求规格说明书，确认交付物是否满足约定的过程。 如果你前面几个步骤，需求量化、设计决策记录、UAT 缺陷分类，都执行到位了，终验收会变成一种“对账”动作，你知道该交什么，他也知道该收什么，没有扯皮的空间。

但这个思路需要从一个很早就开始铺垫：从项目启动会开始，你就要不断向甲方强化“我们是在按照双方确认过的标准交付”这个心智。 每一次范围变更都要走正式流程，每一次技术妥协都要产出行决策记录，每一次 UAT 问题都要按分类标准处理。这些东西在终验收的时候，会形成非常强烈的心理暗示，不是你在求他签字，而是你们在一起完成项目合同约定的最后一环。这个心理位置，差之毫厘，失之千里。

2. 终验报告：它不是总结，是法律证据

太多项目经理把终验报告写成了一份散文式的项目回顾，感谢了客户，感谢了领导，总结了项目成绩，最后来一句“经双方确认，项目通过终验收”。这种写法，温柔有余，严谨不足。

终验报告是一份带有法律效力的商业文件。它的每一个字，在未来可能出现的尾款纠纷中，都可能被拿出来当作证据。我的写作原则是：只陈述事实，不抒发感情；只对照约定，不自吹自擂。 比如不要写“系统运行稳定，客户反馈良好”，而要写“依据合同附件三《性能指标列表》，共28项性能指标，经第三方压测机构验证，全部达标。验收结果记录详见附件五。”不要写“项目团队克服了重重困难”，而要写“合同约定的全部交付物清单见附件六，经双方逐项清点，交付完整。”这样的表述不浪漫，但它能保护你。在终验收会议上，浪漫一文不值，严谨价值千金。

六、针对不同角色和场景的行动建议

前面的讨论是普适性的，但读者可能带着不同的身份和处境。我把不同情况下的行动建议和取舍，拆成三个最常见的角色来谈。

1. 如果你是以乙方 PM 或交付负责人

你的核心风险在于，你夹在公司内部和客户之间，既对项目利润负责，又被交付质量和进度两线挤压。 对于你，我有三条具体建议：

第一，把技术应答书和合同附件里的技术承诺，变成需求规格说明书里的可度量指标，这件事必须你亲自盯。 不要派给下面的 BA，他们缺乏和销售、法务打交道的经验。你亲自把合同附件技术条款捋一遍，逐条映射到需求规格说明书里，发现无法实现的，立即启动内部升级。这个动作本身，就是在为终验收存弹药。

第二，设计决策记录这个工具，请马上引入你现在的项目。 它不需要任何新系统、新流程，只需要你在每次设计评审后，用一页纸记录：我们做了什么选择，接受了什么成本，谁确认了。这页纸在终验收时的价值，可能会超出你想象。

第三，UAT 开始之前，那套缺陷分类标准，由你来主笔起草，然后和甲方共同签字确认。 上到这个位置，不要省这几个小时的沟通成本。没有这个东西，你的研发团队会在 UAT 期间被折腾到怀疑人生，终验收的周期也会被无限拖长。

2. 如果你是甲方 IT 项目经理或业务方代表

你可能会觉得，这篇文章讲的是乙方怎么自保，甲方看这个有什么用？太有用了。因为甲方在瀑布项目里最大的风险，不是乙方坑你，而是你自己都不知道怎么验收，最后在老板面前交不了差。 我见过不少甲方的项目经理，需求阶段不好意思追问细节，觉得“显得不专业”，UAT 阶段又不敢拍板，觉得“万一上线以后业务部门不满意怎么办”，从头到尾都在被动应付。结果项目做完了，乙方催着验收，你心里其实没底。

对于你，我的建议是：积极参与乙方发起的量化澄清动作，把它变成你自己的管理抓手。 当乙方拿来一张非功能需求量化矩阵，问你需要把“快”定义成什么指标时，不要觉得对方在为难你。他是在帮你把你老板的预期翻译成技术语言，这是好事。你配合他。当乙方提出要签一份 UAT 缺陷分类标准时，你不要抵触，这是他在帮你控制内部用户的期望值，让你不至于在终验收的时候被业务部门拿着 UAT 阶段的所有意见，一条一条地质询。这些工具保护的是双方的利益。

3. 如果你在 PingCode 这样的平台上管理瀑布或混合项目

PingCode 这类研发管理平台，目前主要服务中大型企业以及 100 人以上的产研组织。在这个体量下，你很难再用 Excel + 微信群来管瀑布项目了。很多团队在用 PingCode 落地 Scrum，但其实它的需求层级结构（史诗-特性-用户故事）、测试用例与需求的关联、以及跨角色的信息透传能力，用来支持瀑布或混合模式的项目管理一样好用。

我的建议是：即使你采用的是瀑布模型，也请把需求拆细成用户故事级别，并在 PingCode 里维护需求与用例的关联关系。 瀑布不等于“憋三个月写一份大需求文档然后扔给开发”。你完全可以在 PingCode 里按照特性来组织需求，每个特性下面拆分若干用户故事，每个用户故事关联具体的验收用例。这样做的好处是，当开发完成某个用户故事时，测试可以立即基于关联的用例去做验证，而不是等到全部开发完了再集中测试。同时，这套关联关系到了终验收阶段，就是你和甲方逐条对照的机器清单，你打开 PingCode，拉出所有已被验证为通过的验收用例，导出成一份清单，这本身就是终验收报告里最有力的支撑材料。这种“可追溯性”，是瀑布模型最大的底气。

七、什么情况下你应该坚持瀑布，什么情况下你应该果断放弃

在文章的最后，我想谈一个今天已经无法回避的问题：既然敏捷这么流行，为什么还要用瀑布？你什么时候该坚持它，什么时候该果断切换到别的模式？

1. 坚持瀑布的三种典型场景

（1）合规与审计要求压倒一切。 政府、金融、医疗、军工类项目，系统上线前必须通过第三方测评、等保测评、甚至监管机构的现场检查。这类项目的交付物清单是法律文件里写死的，不是你说“我们采用敏捷，模块可以分批上”就能通融的。在这种场景下，瀑布模型的线性推进、阶段性文档交付、里程碑式评审，本身就构成了合规保护的证据链。你不能放弃它，你只能优化它。

（2）合同采购模式是固定总价。 如果甲方是用固定总价的方式采购，需求范围必须在合同签订时就锁定，后续任何变更都要走商务流程。这种情况下，你只能在瀑布框架下做事，因为你没有持续接收需求变更的预算弹性。这就是为什么很多外包公司和系统集成商会坚持用瀑布，不是因为思想落后，而是合同结构决定了管理模式。

（3）跨组织协同极其复杂。 当项目涉及多个外部供应商、硬件供应商、施工方、甚至不同业主单位时，各个组织之间的接口必须以书面文档形式进行锁定和冻结。敏捷倡导的“拥抱变化”，在这种多组织、强依赖的协作体里，可能导致整体性的混乱。

2. 应该放弃纯瀑布、转向混合或敏捷的三个信号

（1）甲方自己也讲不清楚需求。 这意味着需求澄清阶段，你无论怎么追问、怎么量化，都拿不到明确结论。这种情况下强行锁定需求范围，等于刻舟求剑，几个月后开发出来的东西必然偏离真实需求。如果判断甲方需求成熟度太低，应该在一开始就向甲方建议采用小步迭代的模式，先快速建立一个可用的版本，让用户在使用的过程中逐步聚焦需求。

（2）市场环境变化快，交付周期不允许过长。 互联网、电商、新零售类项目，市场窗口可能就只有几个月。如果你走完整的瀑布流程，需求评审花两个月，设计花一个半月，开发三个月，测试一个半月，做出来的时候竞品早就占领市场了。这种项目里，瀑布的“完备性”本身就是最大的风险，你交付了一个“完整”但“过时”的系统。

（3）团队已经具备了成熟的敏捷实践能力。 如果你的团队在分支管理、CI/CD、自动化测试、持续部署方面已经做得很成熟，那么你其实已经具备了在较短周期内交付高质量增量软件的能力。这种情况下，死抱着瀑布模型不放，反而是在限制团队的产能。

八、写在最后：复盘的价值不是问责，是建系统

我在这篇文章里反复提复盘、倒推、归因，目的不是为了去骂当年那个把需求写砸了的 BA，或者那个在 UAT 阶段没有顶住压力的项目经理。问责无用。一个项目做完了，真正有价值的复盘，是把那些导致终验收卡壳的环节，沉淀成可复制的工作模板、检查清单和流程机制。这样，下一个项目就不会在同一个地方再摔一次。

我从那个 14 个月的项目里学到的最重要的一课，不是“要重视性能测试”，而是“所有形容词都要在需求阶段被量化”。这个教训我已经内化到了自己的工作习惯里，现在把它写下来给你。如果你正在带的项目，即将进入需求澄清阶段，那么从明天开始，你可以做这么几件事：

1. 把合同附件里的技术承诺条款，全部拉出来，逐条在需求规格说明书里找到对应的细化描述。 找不到的，立即标记为高风险。
2. 在下一次设计评审会上，试着产出一份设计决策记录。 哪怕只有一页纸，它也将成为终验收时你手里最硬的挡箭牌。
3. 和甲方启动一次关于 UAT 缺陷定级标准的沟通。 把这个概念抛出来，看看对方的反应。只要他愿意跟你谈，你们就已经在为终验收铺平道路了。

这三件事不需要任何额外预算，不需要领导批准，你今天就可以动手。而它们带来的确定性，远比你在终验收前夜烧香拜佛要靠谱得多。项目的胜败，从来不取决于灵光一现的运气，而取决于在每一个该较真的节点上，你有没有把模糊的东西变清晰。这句话，与所有在瀑布项目里摸爬滚打的人共勉。