终验会上最容易混在一起的是三件事:一期是否达到约定、剩余问题怎样处理、下一阶段是否值得做。如果把二期采购当作一期验收的隐含条件,技术和商业判断都会失真。先把当前交付讲清楚,才能讨论后续合作。
终验材料要能交给接手的人
交付清单除了功能,还要覆盖运行环境、配置位置、权限与密钥管理、资料更新、日志与告警、停用回退、维护责任和遗留问题。不要交出一个只有原研发能解释的容器包,就称为完整移交。
在AWS10月21日的观测架构文章里,直接上报与共享Collector方案的取舍之一是管道由谁维护、共享组件怎样影响故障域。这类运营责任也应进入我们的交接材料,不能只交架构图而不指定负责的人。原文
把四种结果分别写清楚
| 状态 | 需要留下的材料 |
|---|---|
| 已满足 | 对应需求、样本与实际版本 |
| 已知缺陷 | 影响、临时措施、修复计划与责任人 |
| 待确认 | 缺少什么证据,谁在何时补齐 |
| 范围外建议 | 业务价值、依赖与下一阶段评估方式 |
不是所有遗留问题都适合用一个“后续优化”打包。涉及越权、数据损坏或核心功能失效的事项,需要按风险处理;不影响当前范围的小改进,可以共同决定排期。具体合同如何约定验收与付款,应按项目材料处理,不能套用文章中的通用结论。
扩展机会来自真实使用记录
二期讨论可以从用户反复绕行的步骤、人工复核负担、资料更新瓶颈和已观察到的高价值任务开始。每个建议先写假设:面向谁,解决哪一步,怎样判断收益,以及可能增加哪些维护成本。
如果一期使用频率不足,先调查原因。问题可能来自资料准备、流程责任或用户培训,也可能说明任务不值得自动化。追加模型和功能并不必然改变这些条件。
本文没有“千万二期订单”或真实客户签字仪式。终验记录的价值是让双方对已经完成的工作与接下来的责任形成同一份理解;后续合作仍然需要单独证明值得投入。