结论先说:当甲方看业务结果、乙方看技术完成度时,可对照的交付表不是把两套指标合成一张大表,而是为每个交付物同时写清“乙方可证明的完成状态”和“甲方可验收的使用状态”,并约定两者不一致时以哪一方为准。缺少后台数据或账号权限时,仍能先完成字段定义和样例核对,但只能得出“双方对同一交付物的理解是否一致”,不能据此判断对方实际做得快不快、好不好。
项目进入验收阶段,乙方交付表上写着“栏目模板完成、表单功能完成、移动端适配完成”,甲方手里的表却写着“编辑能独立改文案、客户提交能进销售邮箱、手机打开不串版”。两边都没说谎,但会议往往卡住:乙方认为做完了,甲方认为不能用。这个现象有两种解释。
第一种解释是指标层级不同。乙方的指标描述的是生产动作是否执行,甲方的指标描述的是使用结果是否发生,两者本来就不在同一层。第二种解释是验收口径没有落到同一对象上。乙方说的是“表单功能”,甲方说的是“销售邮箱收到线索”,中间还隔着通知配置、邮箱权限、垃圾邮件规则等环节,双方其实在验收不同的东西。
要判断到底是层级不同还是口径不同,可以做一个最小动作:任选一个已交付的模块,让甲方和乙方各自用一句话写出“它做完了意味着什么”,再互相交换。如果两句话指向同一个对象,只是深度不同,属于层级问题,补一层验收说明即可;如果两句话指向的对象都不一样,属于口径问题,必须回到需求阶段重新对齐,否则后续每个模块都会重复卡住。
能区分两者的证据有三类。一是对象是否一致:都指向同一个页面、同一个表单、同一段内容,还是各说各的。二是可观察动作是否一致:乙方说“完成”,甲方能否指出一个具体动作来验证,比如“用编辑账号登录后改一段文字并看到前台更新”。三是例外情况是否被提前写出:双方是否都承认某些情况不算失败,比如第三方邮件延迟、测试数据为空。
不追求大而全,先给每个交付物写两行。第一行是乙方状态,写“做了什么、在哪能看到、用什么证明”;第二行是甲方状态,写“谁在什么条件下能使用、使用后应看到什么”。两行之间用同一个交付物编号关联,编号不重复使用。
假设一个场景:甲方要求“客户提交后销售能收到”,乙方理解为“表单提交成功提示出现”。双方在表里分别写下这两句后会发现,前者需要邮箱通知链路,后者只需要前端提示。此时应把交付物拆成“表单提交提示”和“线索通知到达”两项,而不是争论谁对谁错。这个拆分动作会直接影响下一步:报价和排期需要按两项分别确认,而不是按原来的一项打包。
如果甲方拿不到后台账号、看不到埋点数据,或乙方不提供测试环境,仍然可以做三件事。第一,用静态样例核对字段定义:让乙方提供一张页面截图或一段录屏,甲方逐项对照交付表里的使用状态,看描述是否与画面一致。第二,用书面问答固定边界:把“谁能用、在什么条件下用、看到什么”写成问题清单,要求逐条书面回答,回答本身也是后续对照依据。第三,约定差异记录方式:每次发现描述与画面不符,只记录交付物编号、双方原话和日期,不急着下结论。
这些动作能得到的结论有限。它们可以说明双方对同一交付物的理解是否一致,不能说明对方实际执行效率、代码质量或后续稳定性。截图和录屏可以被挑选,书面回答也可能遗漏例外情况,所以不能因为一次核对顺利就推断整个项目风险很低。反过来,一次核对发现多处描述不符,也不能单独证明对方故意隐瞒,更常见的合理解释是需求阶段就没有把使用状态写进文档。
可对照的交付表只有在影响下一步动作时才有价值。建议把每个交付物的两行状态与付款节点绑定:乙方状态全部可证明、甲方状态至少有一条被实际验证,才进入下一笔付款或下一阶段排期。如果甲方状态暂时无法验证,例如缺少账号权限,就把它标记为“待验证”,并写明验证所需的条件和由谁提供,而不是直接算作通过。
这样做会带来一个直接结果:项目节奏可能变慢,因为过去靠口头确认的环节现在需要留下可对照的记录。但它也把争议从“你觉得做完了没有”转移到“这个交付物的使用状态由谁在什么条件下验证”,后续每次出现分歧时,都可以回到同一张表查编号,而不必重新争论一遍。对甲乙双方指标不同的项目来说,这张表的作用不是统一指标,而是让两套指标在同一交付物上互相看得见。