PG官网

系统做完，验收当天，客户打开一看："这跟我想要的完全不一样。"

开发这边也委屈："当初需求就是按这个做的，怎么现在全不对了。"

这个场面，在软件行业太常见了。两边都觉得自己有理，最后闹到互相扯皮、拖尾款、甚至打官司。

说句实话，验收当天才发现问题，责任多半不在验收本身，在开发前就埋下了。这篇把验收这件事从头捋一遍：为什么总扯皮、怎么分阶段验收、验收清单该列什么、不合格怎么办。

验收扯皮，根子在哪

大多数验收纠纷，逃不开三个原因。

需求没写清。 合同里写着 "做一个会员管理系统"，但会员等级怎么分、积分怎么算、手机端要不要、报表长什么样，全都没写。没有依据的验收，最后只能凭感觉，凭感觉就有得吵。

标准不可量化。 "界面要美观"" 操作要流畅 ""功能要完善"，这些词在验收时一点用都没有。什么叫美观，什么叫流畅，甲方乙方各有一套标准。写进合同的验收项，必须能回答 "达到什么程度算合格"。

心态错位。 甲方把验收当成 "找茬大会"，乙方把验收当成 "走个过场"。一个使劲挑毛病，一个使劲糊弄，最后验收变成了拉锯战。

这三个问题，都不是验收当天能解决的，都得往前挪。

聪明做法，是分阶段验收

别把宝押在 "最后那一次" 上。项目周期里设几个验收节点，每个节点确认一次，问题早暴露、早修正，成本最低。

需求确认阶段。 需求文档和原型图出来后，先验收一次。确认功能清单、页面结构、业务流程，这一关过了，后面开发才有据可依。

开发中演示。 开发到一半，约一次演示。看看界面方向对不对、流程顺不顺，这时候改，改的是局部；等到全部做完再改，改的是全局。

上线试运行。 系统部署上线后，不要急着终验，留出试运行期。真实业务跑几周，数据对不对、有没有报错、业务人员用不用得惯，这些问题只有真实使用才会暴露。

终验。 试运行没问题，再走正式验收流程，签署验收确认。

分阶段验收还有一个作用，它逼着双方每过一关都把问题摊开说，而不是攒到最后一刻爆发。

验收清单，该列这些项

不管项目大小，验收清单至少覆盖这几个方面。

功能：逐条对照需求，每个功能点实际点一遍，而不是听对方说 "都做了"。

数据：测试数据跑几轮，看数据是否正确、统计是否准确、导入导出有没有丢。

性能：正常业务量下，页面响应、操作流畅度、并发承受能力。性能指标应该在需求阶段就定下数字，比如 "查询响应 3 秒内"。

兼容与适配：不同浏览器、不同手机型号、不同系统版本都要过一遍，业务越依赖线上，这块越不能省。

权限与安全：谁能看什么、谁能改什么，权限设置是否符合要求；涉及敏感数据的，加密和日志检查。

交付物：源码、数据库结构、接口文档、操作手册、部署说明，这些都在合同里约定清楚，验收时一并核对。

清单里的每一项，都要能回答 "达到什么标准算合格"。定不了的，宁可合同晚点签，也不要含糊着签。

验收不合格，怎么办

提前在合同里写清楚处理办法，比事后讲理有用。

整改时限。 验收中发现的问题，约定多少天内完成整改，整改完重新验收。

责任划分。 功能缺失、缺陷、需求变更，分别由谁承担，费用怎么算。需求中途要改，改的成本算谁的，写清楚。

尾款与保修。 尾款支付和验收结果挂钩，验收不过，按约定处理。同时约定保修期，保修期内的问题免费修复，响应时间也写进去。

条款写得细，不是不信任对方，是把双方的预期对齐。真到验收那天，按条款执行，大家都不用靠吵架解决问题。

上线不算完，试运行才是真验收

很多人把 "上线" 和 "验收" 当成同一件事，其实不是。

上线是系统开始跑，验收是确认系统达到合同要求。中间隔着一段试运行期，这段才是真正的检验。业务人员真实操作、真实数据流入、真实并发冲击，跑几周下来，问题基本都能暴露。

试运行期的长度，根据项目复杂度定，短的几周，长的几个月。这段期间发现问题，正常记录、正常修复，不算违约，但响应速度要约定好。

总结

验收这件事，主动权在签约前。

需求写细一点，验收标准量化一点，流程里多设几个节点，合同里把整改和保修写明白。这些功夫下在前期，验收当天就只是走流程，而不是开战。