验收条件要在合同阶段成型
验收阶段出现僵局，往往是因为开工时没有定义清楚什么叫做完成。功能能用、性能可以、界面差不多，这些表述在双方理解中差别很大，到了节点上就变成了各说各话。
可以落地的做法是把验收标准拆成三类：功能验收、数据验收、非功能验收。功能验收对应需求清单中的条目，数据验收对应历史数据的迁移结果，非功能验收对应响应速度、并发能力、浏览器兼容范围等。
每一类都要写明验证方式。由谁操作、按什么步骤、观察哪些现象，写清楚之后，验收就从主观判断变成了可重复执行的动作。
缺陷分级比总数更有意义
把所有问题笼统地称为缺陷，会导致一个后果：上线卡在几个不影响使用的小问题上，而真正严重的隐患反而被淹没。比较合理的方式是按影响程度分级，并约定各级别的处理时限。
分级通常可以这样划分：导致主流程中断或者数据错误的属于最严重一级，必须修复后才能上线；影响部分功能但存在替代操作路径的属于中间一级，可以约定在短期内修复；界面措辞、间距、样式细节属于末级，可以列入后续优化。
分级标准需要在开工前达成一致，而不是在验收会上临时争论。同时要约定各级别问题的数量上限，避免用数量而非性质来决定是否上线。
数据迁移与性能的验收口径
数据迁移常常被排除在验收范围之外，导致系统上线后才发现数据对不上，而责任归属又很难界定。稳妥的做法是提前约定抽样规则与允许的差异范围。
性能验收同样需要具体口径。在什么网络条件下、由多少并发用户、执行哪几个操作、响应时间不超过多少，这些参数必须写下来。缺少条件的性能承诺没有可验证性。
还需要考虑验收环境的差异。测试环境的配置与生产环境不一致时，性能表现会有明显偏差，因此验收应当在尽可能接近真实的条件下进行。
验收不通过时的处理约定
验收不通过并不等于合作破裂，真正容易产生分歧的是后续如何处理。合同中应当写明整改周期、复验方式以及因整改导致的工期变化如何计算。
同时要约定甲方配合义务。验收需要业务人员参与操作与确认，如果因为配合安排不到位导致验收推迟，这部分时间不应计入交付方的责任范围。
最后建议把尾款的支付节点与验收结果绑定，但保留一个合理的观察期。系统上线后短期内往往还会暴露问题，留出一段稳定观察期对双方都更公平。
验收过程中的沟通方式也值得注意。发现的问题应当以书面形式汇总，标明现象、复现步骤与期望结果，避免只在会议中口头提出。口头反馈容易在传递中变形，也不利于核对哪些问题已经处理、哪些还在排队，最终会影响对上线时间的判断。
