一句话：项目做到最后双方对「做完了」的理解不一样，尾款就卡住了。验收标准必须在开工时写下来，不是交付时才谈。
难点是「稳定」「够快」这类形容词不能当验收标准。德莉玛系统能定成可判定的条件：订单→BOM→玻璃图纸→报价链路端到端跑通；/api/bom、/api/glass_dwg、/api/quote 三个接口用真实 model+spec 反查结果一致；连续 14 天进程零重启（对照反面案例：LumenX 2 天重启 482 次）。
延伸：模块 12 · 稳定性与监控 讲「14 天零重启」这类指标怎么监控，以及三条监控层的区别。
因为它没在开工前定义。交付那一刻是项目里最尴尬的时间点——你刚做完，客户的期待值刚好在最高处，他脑子里的「做完」往往比他嘴里说的多得多。
| 翻车现场 | 双方各自理解的「做完了」 | 结果 |
|---|---|---|
| 核心功能说做完了，客户说「自动报价还没生效」 | 你交付的是报价引擎；客户要的是「店员录单时自动出价」这个结果 | 尾款卡住，工期已超，双方僵住 |
| 系统上线了，客户说「不稳定」 | 你交付的是「能跑」；客户理解的是「不崩」 | 双方开始拿感受说话，谁也举证不了 |
| 培训讲完了，客户说「我们的人还是不会用」 | 你交付的是「讲过了」；客户要的是「有人能独立录单」 | 培训被当成一次性任务，返工成本全在自己身上 |
验收标准的唯一检验方法：拿一条出来，两个人分别判断，答案必须是「是」或「否」，不能是「差不多」。做不到就重写。
| 领域 | ❌ 模糊的写法 | ✅ 可量化的写法 |
|---|---|---|
| 稳定性 | 系统要稳定 | 连续 14 天进程零重启，日均错误率 < 0.5% |
| 性能 | 查询要快 | 10 万条数据下单据查询 P95 < 1.5 秒 |
| 集成 | 要能对接 | 与黑湖小工单双向同步，单次成功率 ≥ 99%，失败有重试和告警 |
| 功能 | 报价要准 | 用 400 单历史订单回放，引擎输出价与人工确认价一致率 ≥ 95% |
| 数据 | 数据要干净 | 型号匹配覆盖率 ≥ 95%，尺寸字段覆盖率 ≥ 80%，缺失项在界面上可见不可静默 |
| 培训 | 要培训到位 | 现场让 3 个店员各独立完成 1 单开单 + 1 单改单，不需要我代操作 |
六类逐项打勾，缺项不签收。直接复制到项目文档里用。
文档不是给人看的，是给「三个月后半夜系统出问题时的人」看的。每份文档都要能回答一个具体问题。
| 必交文档 | 回答什么问题 | 不交会有什么后果 |
|---|---|---|
| 部署手册 | 这套系统装在哪台机器上、用什么命令起、怎么改配置、日志在哪看 | 服务器一重启没人敢动，只能找我——运维边界彻底失效 |
| 操作手册 | 一线怎么用：每个角色每天要做哪几个操作，异常怎么处理 | 一线不认这个系统，退回Excel，上线即闲置 |
| 管理员账号交接单 | 谁有账号、什么权限、密码怎么改、离职了怎么回收 | 人员变动后权限失控，安全责任不清 |
| 数据字典 | 每张表每个字段什么含义、取值范围、哪些是必填 | 客户想自己加个字段都不敢动；二次开发必须从零逆向 |
| 接口文档 | 和哪些系统对接、字段怎么映射、失败怎么重试、限流规则 | 对方系统一升级就挂，排查全靠猜 |
| 故障处理手册 | 常见故障的现象 → 原因 → 处置动作；什么情况该找我，什么情况自己处理 | 所有故障都变成「找开发」，客户觉得系统是个黑盒 |
培训不是讲一遍 PPT。讲完就散场，两个月后客户说「我们的人还是不会用」——那是必然结果，因为听懂了不等于会做。
| 场次 | 对象 | 时长 | 形式 | 验收方式（关键） |
|---|---|---|---|---|
| 1 安装部署 | 客户 IT / 管理员 | 约 2 小时 | 我讲原理+在他机器上一起做一遍 | 回到自己环境，独立完成一次重启 + 一次配置修改 + 查到指定日志，我只看不动手 |
| 2 日常操作 | 一线店员 / 销售 / 仓管 | 约 2 小时 | 按角色分组，在他们自己的数据上做，不用测试假单 | 现场让 3 个店员各独立录一单 + 改一单，我在旁边只答疑 |
| 3 故障处理 | 管理员 / 店长 | 约 1.5 小时 | 用真实故障案例演一遍（我先造一个错，再带着他们找） | 独立处置 2 个预设故障，按《故障处理手册》走完流程 |
这一节决定项目结束后你是不是变成免费客服。边界不写清楚，交付完成那天才是开始收费噩梦的起点。
| 阶段 | 谁负责什么 | 我这边怎么做 |
|---|---|---|
| 支持期内 | 系统缺陷修复、系统本身的故障排查、部署环境问题 | 按约定时效响应；先给临时绕行方案，再给根因修复 |
| 支持期内 | 数据导入导出、账号权限调整、新人上手带一带 | 远程协助，超出约定次数可另计 |
| 支持期外 | 新需求、新报表、新对接系统 | 按需求单报价，不在免费范围 |
| 支持期外 | 客户自己改配置导致的问题 | 可付费处理，但要先说明是配置问题不是产品缺陷 |
| 支持期外 | 第三方系统（云服务、短信、支付、ERP）变更导致的问题 | 配合排查可做，第三方产生的费用由客户承担 |
| 边界项 | 建议的写法（写进合同或交接单） |
|---|---|
| 支持期长度 | 交付后 30 天免费支持。理由要写清：这段时间正好覆盖客户全员跑一遍完整业务周期（一个月结、一次盘点），问题会集中暴露在这 30 天内 |
| 响应时效 | 分档写清：系统不可用（全店无法开单）2 小时内响应、4 小时内恢复；功能异常（某功能不好用、有绕行方案）1 个工作日内响应；咨询/建议 3 个工作日内回复 |
| 响应方式 | 统一入口：企业微信/钉钉群 + 一个工单邮箱或表单。不要用「随时找我」——口头需求无法追溯、无法统计，最后一定变成扯皮 |
| 服务时间 | 工作日 9:00–20:00，紧急故障（不可用）不限时间。节假日和夜间不属于免费支持，需提前约定 |
| 服务方式 | 远程支持为主。涉及门店现场、跨网络环境、需停机操作的，另计现场服务费 |
| 超出后怎么算 | 支持期后续费按年度运维包（含约定次数的响应与巡检）或人天计；单次非计划性处理按人天单价×系数计，报价单里先写清系数 |
| 坑 | 说明 / 对策 |
|---|---|
| 验收标准开工才谈 | 最贵的坑。这时候谈标准，谈的是责任不是标准。标准必须进启动文档，和需求诊断表一起签 |
| 培训讲完就散场 | 没有考核的培训等于没培训。每场培训都要有一个「当场必须做到」的验收动作（3 个店员各独立录一单） |
| 密码口头交接 | 「账号密码我微信发你」——人换了、聊天记录还在、离职了没人知道。必须签《管理员账号交接单》，写清权限范围和回收方式 |
| 文档写完从不更新 | 系统改一个字段文档不改，一个月后客户按文档操作报错。改代码和改文档放同一个提交里 |
| 没做数据抽样核对就签收 | 迁移了 3 万条单据，界面能打开就以为没问题。必须抽样 100 单逐字段核对，并抽一单验证备份真能还原 |
| 把「上线了」当「交付了」 | 代码在你服务器上能跑，但客户 IT 不会重启、不会看日志——这不是交付。交付的标准是客户能自己运维，依据就是第 4 节那份部署手册 |
我的核心观点是：交付事故绝大多数不是技术问题，是定义问题。所以我把「验收」这个动作从交付日往前挪到开工日——验收标准必须在开工时写下来，和需求诊断表、项目切片一起签，每条都要能被「是/否」判定。
举个对比：「系统要稳定」没法验收，「连续 14 天进程零重启、日均错误率 < 0.5%」就能。「查询要快」没法验收，「10 万条数据下单据查询 P95 < 1.5 秒」就能。形容词是后期扯皮的原材料，因为谁都可以说自己达到了。
第二个是培训必须现场考核。我不接受「讲过了」这种说法。日常操作那场，验收方式就是现场让 3 个店员各独立录一单 + 改一单，我在旁边只答疑不动手。做没做到位，当场就看得出来，不用等三个月后客户来抱怨。
第三个是运维边界必须写清楚，这是保护项目本身的。支持期我一般给 30 天，因为客户一个月结、一次盘点、一轮全流程跑完，真实问题会在这 30 天集中暴露。之后如果还提「怎么这么不稳定」，那多半不是系统问题，是使用方式或数据质量的问题，属于新工作。
所以我的做法是三句话：验收标准开工前定并可量化；培训要现场实操考核；运维边界写清楚，别让项目结束后变成免费客服。本质上是把「交付」从一次动作，变成一条有证据的链条。