上线那天验什么：定制项目的八项验收清单

这个分类里前面的文章，讲的都是签合同之前怎么挑人：比报价、看需求文档、抠维护条款。可合同签得再细，最后要靠一次验收把东西交到你手上。验收做松了，前面省下来的钱会在这里花回去。

这篇只讲一件事：上线那天，验什么、拿什么验、不通过怎么办。

一、“演示一遍没报错”不算验收

演示有三处天然的失真，跟供应商诚不诚实没关系：

• 数据是准备的。客户名不会重名、订单不会缺字段、库存永远够。真实数据里最不缺的就是这两个——重的和缺的。
• 路径是主路径。从下单到出库走得很顺，因为这是所有人天天走的那条。而真正出问题的是旁支：退货冲减、跨月对账、临时调价、把已审核的单子撤回。
• 有人带路。演示的人知道下一步该点哪，你的员工第一次上手，会点到没做防护的地方。

所以验收不是“看一遍”，是按清单勾一遍。清单不来自供应商，来自你自己的三张表。

二、先有三张表，才有“验”这个动作

表	里面写什么	没有它会怎样
需求清单	每条一行、编上号，一句话说清“谁在什么情况下做什么、系统给出什么结果”	验收时只能用“感觉还差不多”来判断，争议无解
角色权限表	有哪些角色、每个角色能看什么、能改什么、不能碰什么	上线后人人能看全部成本，只能靠“别乱点”约束
对接清单	要和哪些外部系统打交道：ERP、财务、微信、支付、短信、物流，各自用谁的账号	联调拖到最后一刻，一处不通整条流程断

这三张表最好是开发前就定下来的。如果已经到了验收这一步才补，也能补——把系统里现在实际有的东西，逐条抄成清单，跟你的业务对一遍，把对不上的标出来。这一步花两小时，能省后面三个月的扯皮。

三、八项验收，一项一项勾

项目	怎么验	不合格长什么样
1 · 主流程	按需求清单从头走一遍，每走完一条就在编号上打勾	“这个我们先跳过”——跳过的都会变成上线后的问题
2 · 异常与边界	空着提交、超长文本、重复提交、断网、把数量填成 0 或负数	页面白屏、报错弹窗、或者更糟：安静地存下一条错数据
3 · 权限	用每个角色的账号各登录一次，试着看别人的数据、改不该改的字段	业务员能看到成本价；离职账号还能登录
4 · 数据迁移	老系统导过来的数据，抽十笔与手头台账对一遍；总数、金额、日期三处	条数对得上，金额差几分——多半是单位或精度
5 · 性能	挑上班最忙的时段试：二十个人同时开单、导一个月的报表	单机测试很快，多人用时转圈，报表要等几分钟
6 · 对接	把每个外部系统的“断线”也试一遍：短信发失败、支付回调丢了、ERP 停了	对接一通就以为完事，断了以后数据卡在中间没人知道
7 · 交付物	源码工程、数据库脚本、部署文档、第三方账号、一份操作培训	“在我们服务器上能跑”，换台机器部署不起来
8 · 出错可查	故意制造一次失败，看能不能查到是谁、什么时候、做了什么	出错只有一句“系统繁忙”，排查全靠猜

这八项里，第 2、4、8 项最常被跳过，也最常在三个月后变成麻烦。原因很简单：它们都不在演示的路线上。

四、别在演示环境里验收

三个具体要求，写进验收当天的安排里：

• 用真实数据，哪怕只有一个月的。拿你自己的客户名、真实订单、真实库存去跑，把脏数据（重名、缺字段、格式乱）一并带进去。
• 让真正用的人来点。不是老板点，是仓库管理员、业务员、财务各自点自己的那段。他们点出来的问题，比验收组想出来的准。
• 影子运行一周。新旧两套并行，同一批单据两边各录一次，周末对一次数。差异逐笔查清，这是最笨也最有效的验收方式。

五、验收单怎么写，不通过怎么办

验收单上除了“通过／不通过”，还要有三样东西，否则通过与否都是空话：

• 问题清单：一条一条列，写清在第几号需求、什么操作、出现什么、期望什么。截图或录屏附上。
• 严重程度：分三档就够——阻断（不能干活）、错误（数据会错）、体验（能用但别扭）。前两档不清零，不签字。
• 修复期限：每档对应一个约定时间，写进同一张单子，双方签日期。

另外建议在合同或附件里加一句：由甲方指定一台干净的机器，在乙方协助下独立部署一次，能跑通再付尾款。这一条能筛掉不少“只在自己电脑上能跑”的项目，也是判断源码交付是否完整的唯一办法。

六、上线后第一个月，比开发期更费人

第一个月的三件事，最好在验收会上就说明白：

• 谁值守。出问题时找谁、通过什么方式找、工作时间之外怎么办。
• 改动的边界。看清楚一件事是“缺陷”还是“新需求”。缺陷是当初说好的没做到，不该收费；新需求是当初没提的，该另算。这个界线模糊，后面每次沟通都会吵一遍。
• 培训的留存。培训别只做一次，留一份录屏或图文操作说明。人员流动比系统更新快得多，新人上手全靠它。

这几条和这个分类里讲选型时该抠的维护条款是一件事的两头：签合同时留的余地，验收时才用得上。

七、四句最常见的争议，事前都能防

当场听到的话	真实含义	事前怎么防
“需求里没写”	清单没写清，双方理解不同	需求编号 + 一句话结果，别用“优化”“完善”这种词
“这是优化，不是 bug”	想把它算成新需求、另收费	验收单上按“阻断／错误／体验”分级，用级别判断而不是用词判断
“在我们这没问题”	环境不一样：数据、网络、浏览器、手机型号	在甲方的设备和网络上验，别在对方办公室验
“这个上线以后再说”	现在做不完，或者做不了	写进问题清单，给期限；不许口头搁置

八、一句话

验收不是给项目结账，是给自己留凭据。八项勾完、问题清零、独立部署跑通、源码和文档到手，这套系统才真正属于你；少一样，你付的是使用费，不是买断费。

附：验收当天的清单

什么时候	做什么
验收前一周	把三张表补齐；约好真实数据与使用人员的时间；准备一台干净的机器
验收当天	按八项逐条勾，现场记录问题；让仓库、业务、财务各自点自己的那一段
当场确认	问题清单分好级、定好期限、双方签字；明确尾款与独立部署的关系
之后一周	新旧并行、对账一次；差异逐笔查清后再决定是否全面切换
第一个月结束	复盘一次：哪些问题反复出现、谁在值守、培训材料是否够用

手上正有一个项目要验收、想找人替你把这八项过一遍，可以把情况发给我们；如果清单还没成型，我们从你那三张表开始帮你理。

本文由建沅网络定制开发方向的技术团队撰写，观点来自一线项目实践。如需转载请联系我们并注明出处。