UAT问题归并与关闭门槛：同类问题别反复开

这个案例来自 ToB企业服务 场景。

ToB 项目到了 UAT 阶段，团队最怕的并不只是问题多，而是同一个问题被不同形式反复记录，最后让所有人都误以为工作量翻了好几倍。
最常见的现场通常是：

客户在 UAT 表格里记一条
群里又发一遍截图
现场测试时再口头提一次

如果没有把它们归到同一问题主线上，项目很容易出现两种错觉：

客户觉得提了很多次还没人解决
项目组觉得问题池无限膨胀

这个问题为什么在多人联合测试里特别严重

这家企业做流程系统和智能体项目，UAT 期间通常会有：

客户业务测试人
客户 IT
供应商交付
项目经理

问题记录入口也很多：

Excel 或飞书表格
项目群
现场会议纪要
工单系统

一旦没有统一主线，同一个问题会以不同表述不断出现：

“按钮点不了”
“提交流程报错”
“审批页打不开”

本质上可能都是同一个根因。

旧流程为什么总让双方都感觉更乱

1. 问题记录入口多，归口却不统一

表格更新一条，
群里再发一次，
项目经理又在纪要里记一次。
最后没人知道哪一条算主记录。

2. 关闭条件也容易被说得太模糊

客户会说：

“这个差不多可以了。”

但项目团队真正要判断的是：

是不是已经验证通过
还是只是客户没继续点
是不是还有相关子问题没收口

3. 同一问题没归并，关闭判断就会更乱

一条看似已关闭，
另一条同源问题还开着，
最终项目状态会非常混。

改造前的旧流程

flowchart TB
    A[客户在UAT中通过多入口记录问题] --> B[项目组分别收集表格 群消息和纪要]
    B --> C[同一问题被多次创建或跟踪]
    C --> D[项目看起来工作量暴增]
    D --> E[关闭时又难判断哪些真收口了]

派宝怎么把“同一个问题”并起来、收下去

派宝在这里不负责替团队判断业务正确性，而是先把同源问题归并，再把关闭门槛挂清楚。

1. 先做事件归并

系统会根据：

测试步骤
页面对象
时间接近度
现象描述

判断：

是同一个问题
还是相关但独立的问题

2. 再形成主问题链

派宝会把不同入口上的记录挂到一条主问题下，减少重复跟踪。

3. 再做补做完成度跟踪

每个主问题会继续判断：

是否已修复
是否已回归验证
是否仍缺客户确认

4. 最后用关闭条件校验判断是否真能关

不是开发说修好了就算完。
系统会明确：

技术修复是否完成
客户验证是否完成
是否还有同源子问题未关

改造后的流程图

flowchart TB
    A[UAT表格 群消息 纪要和工单进入系统] --> B[事件归并<br/>识别同源测试问题]
    B --> C[工单创建<br/>以主问题为单位建立处理链]
    C --> D[补做完成度跟踪<br/>持续跟踪修复 回归和客户确认]
    D --> E[关闭条件校验<br/>判断是否满足真实关闭门槛]
    E --> F[减少UAT问题越记越多的错觉]

上线后的变化

项目上线后，最明显的变化不是 UAT 问题突然变少了，而是双方终于更少在“明明是同一个问题却像出现了三次”这种混乱里耗精力。

几个变化特别明显：

项目经理更快看清主问题数量而不是碎记录数量
客户感知到的问题响应链更完整
开发和测试更少重复修同一个根因
已关闭问题的可信度更高

项目复盘结果

以 23 个项目的 UAT 阶段为样本，项目复盘结果如下：

对比项	改造前	改造后
同一问题被多入口重复记录的比例	较高	下降约 60%
项目经理人工归并测试问题耗时	很长	缩短约 57%
“已修复但客户仍说没解决”的情况	较多	明显下降
UAT 阶段问题数量看起来失真的情况	常见	明显改善
验收前因关闭判断不清反复开关问题的情况	较多	明显减少

为什么这个案例值得写

因为 UAT 问题管理不是单纯缺陷跟踪，而是一个“问题归并、完成度跟踪和关闭门槛判断”共同参与的项目收口场景。
这类问题在 ToB 企业服务里非常典型。