一个进出口公司的系统验收时全绿：技术员按测试用例点了两天，功能全通过。上线第十天财务炸了：对账模块的汇率口径和公司规定差着一层，两个月账全要重核。技术员没错，他验的是功能跑得通；错的是验收流程里没有业务的人。后端系统开发的最后一道关，必须让真正用系统的人来把。
技术验收测不出来的东西
技术员验证的是需求文档上写了的东西：按钮点了有反应、数据存得进去、报表出得来。但文档上没写清楚、开发方自己脑补的部分，只有业务人员知道对不对：佣金提成的分母含不含退款、库存盘点单审核后能不能反审、运费满减和会员折扣叠加时谁先谁后。这些口径问题系统运行得越久，纠错成本越高，必须在上线前抓出来。
业务验收怎么组织
- 提前一周定时间，把财务、仓管、销售各岗位的人排开，每人给半天，别挤在同一天；
- 准备真实测试数据：几张正常单、一张退货单、一张部分退款的单、一张跨月改地址的单，边缘场景最出问题；
- 让业务按日常工作流程走完整链路，从录入到结账，别只测单个功能点；
- 问题当场记录、分级：致命的算错钱、丢数据必须修完才上线，体验类问题记入待办不阻塞上线。
那次汇率口径的问题，就是财务在UAT里拿一张真实报关单走流程时抓出来的。如果当时没安排财务参与，系统要跑两个月、错上几百笔账才会被发现。
组织UAT还有个额外收获：业务人员提前摸了系统，上线时的培训成本和抵触情绪都小得多。很多系统上线后用不起来，一半原因是用户第一天才知道系统长什么样，抵触情绪自然大，验收环节其实是最好的全员预热。
试运行期写进合同
验收通过不等于万事大吉。合同里加一条试运行期，一个月到两个月比较常见，期间发现的功能性问题免费修复，修复不影响尾款之外的额外收费。这条对双方都公平：开发方有动力把收尾做干净，客户也不用为小修小补反复谈价。
两条建议：把UAT写进项目计划，明确各岗位的参与时间和问题分级标准，别当成临时起意；验收报告让业务负责人和技术负责人双签，谁的口径谁确认，出了争议按签字追。比格网络带项目时习惯提前一周把测试场景清单发给客户各岗位，业务上场的验收，才是真正意义上的交付。这也是后端系统开发和普通软件采购最大的区别——它交付的是你们公司自己的业务规则。
