问题落地方案：项目负责人开展Bug / 缺陷的效率提升案例解析

去年三季度，我接手一个 120 人研发组织的效能复盘。老板给的题目很直接：为什么测试团队天天加班提 Bug，开发也天天加班改 Bug，版本还是延？我拉出 6 个季度的缺陷数据后，看到的第一个数字和所有人的直觉都相反，这个团队人均每周只关闭 2.3 个缺陷，工程师并不懒；真正的问题是缺陷单平均在途 9.8 天，其中只有 1.6 天真的在写代码。剩下 8 天多，全花在等人响应、等复现、等确认、等排期上。

这篇文章就是那次改造的完整拆解：我怎么定位瓶颈、怎么设计规则、哪些做法有效、哪些做法后来被我推翻了。

一、核心结论：缺陷效率的瓶颈不在"改"，而在"等"

我把 12 个团队、6 个季度的缺陷数据做了归一化处理，结论比我预想的更集中：一个缺陷从提交到关闭，真正用于定位与编码的时间中位数只占 18%，其余 82% 分散在首次响应等待、复现确认往返、排期队列和验证回归里。这意味着项目负责人把力气花在"催开发改快一点"上，天花板极低，你拼命压那 18%，就算压到零，整体也只快不到两成。

更直白的说法是：缺陷管理的本质不是产能问题，而是在途时间问题。产能是"单位时间能改多少个"，在途时间是"一个缺陷从生到死要多久"。前者受团队规模和技能约束，短期几乎动不了；后者受流程规则和信息质量约束，一两周就能改出肉眼可见的变化。我后来所有的动作，都是在压缩在途时间，而不是在提高产能。

1. 三个被低估的时间黑洞

（1）首次响应等待

缺陷提交后的第一段时间最容易被忽视。测试同学提完单，往往不知道谁接了、什么时候接，只能靠群里 @ 人。我们统计过一个版本周期内的 832 个缺陷，提交后 24 小时内没有任何状态变更的占 43%，平均首次响应时长 1.9 天。这 1.9 天里没有任何技术工作发生，但缺陷已经在"在途"了。

（2）复现确认往返

第二个黑洞是信息不全导致的来回追问。典型对话是"这个我本地复现不了""你用的哪个环境""测试环境，构建号 20240612-3""那你清一下缓存试试"。每一次往返平均消耗 0.6 天，而一个缺陷平均要往返 4.3 次。我们抽样了 200 个被判定为"无法复现"的缺陷，其中 71% 在补充了环境、构建号、账号角色后可以稳定复现，它们不是幽灵缺陷，是描述缺陷的缺陷。

（3）排期队列

第三段是最隐蔽的：缺陷被确认了，但排在"下个迭代"里，然后在下个迭代又排到"下下个迭代"。我们统计的中位排队时长是 3.1 天，长尾（P10）达到 21 天。排队本身不产生任何价值，但它让缺陷在系统里持续老化，等到真正修的时候，代码已经变了三轮，定位成本反而更高。

2. 从"缺陷数量管理"转向"在途时间管理"

大部分团队的缺陷看板是这样的：本月新增多少、关闭多少、存量多少、 reopen 率多少。这套指标能回答"做了多少"，但回答不了"卡在哪"。我把它换成了另一套：在途时长分位数、各阶段停留时长、超 SLA 缺陷占比、缺陷老化分布。核心指标从"数量"变成"时长"。

这个替换带来的第一个变化是责任归属变清晰了。当你看"本月关闭 180 个缺陷"，没人知道该表扬谁、该追问谁；当你看"P1 缺陷中有 14 个在'待排期'停留超过 3 天"，负责人是谁、该做什么，一目了然。指标一旦能指认到具体的人和具体的动作，改进才可能发生。

3. 负责人真正要管的是信息完整度，不是人

这句话我是在踩了坑之后才敢说的。改造初期我做过一件事：给每个模块指定缺陷响应责任人，要求 4 小时内必须响应。执行两周后，响应率上去了，但在途时长几乎没降，因为响应只是点了一下"已确认"，接下来还是卡在复现上。

真正起作用的动作是另一件事：把缺陷单从"一段自由文本"变成"一份结构化证据"。当一个缺陷单必须包含环境、构建号、复现概率、复现步骤、期望与实际对比，能被直接复现的比例从 29% 提升到 78%。负责人的核心工作不是催人，而是设计让人不需要被催的结构。

二、背景和真实场景：一个 120 人研发组织的缺陷现场

为了不让结论悬空，我把当时的基本盘交代清楚。这是一家中型 SaaS 公司，研发 120 人，拆成 4 条产品线、9 个特性团队，测试 18 人，两个发布窗口（双周迭代 + 月度大版本）。用的是某项目管理平台做需求与缺陷管理，缺陷单和需求单混在同一个项目空间里，字段高度自由，谁想填什么填什么。

1. 我们接手时的数据基线

下面这张表是我做基线盘点时用的框架。我把每个指标都和"同类规模团队参考区间"做了对比，判断哪些是真问题、哪些只是正常水平。这个对比很重要，很多团队花了大力气优化的指标，其实本来就在健康区间里。

请注意表格最后两行。如果只看"缺陷密度高"这个直觉，很容易把资源投到"让测试少提 Bug"或者"加强代码评审"上。但基线对比告诉我们，代码质量和测试覆盖并不是这块的短板，真正的短板在缺陷单本身的质量和流转规则。这是我后面所有决策的出发点。

2. 三个真实场景还原

（1）场景一：一条 12 个字的缺陷单

我随机抽了一张当时被标为"无法复现"的单子，全文是："订单页点提交没反应，急。"没有环境、没有账号、没有订单号、没有截图。开发在下面追问了 6 条评论，跨了 4 天，最后以"无法复现"关闭。三周后同一个问题在线上爆发，用户投诉。事后复盘发现，这是特定优惠券组合下的金额校验异常。

（2）场景二：版本冻结前夜的缺陷洪水

这个团队有个习惯：功能开发到最后一刻，测试在冻结前集中回归，缺陷在冻结前 48 小时集中爆发。我们统计了连续 6 个版本，冻结当日提交的缺陷是平时的 5 倍。这直接导致两个后果：一是当天提交的缺陷基本来不及修，全部流入下个版本；二是开发在高压下赶工，返工率在这几天翻倍。

（3）场景三：等级通胀

31% 的缺陷被标为 P0 或 P1，这意味着"紧急"这个词已经失去区分度。开发看到一屏 P1 的时候，实际选择是"按提交顺序处理"，于是真正的高危缺陷反而被埋在中间。等级通胀的根源不是测试想虚报，而是等级定义里没有客观锚点，"影响用户体验"这种描述，任何人都能往自己那张单子上套。

3. 为什么"加人"没有解决问题

在我介入之前，这个团队试过一个非常自然的方案：加两个开发。三个月后数据出来了，缺陷关闭数量上升了 22%，但在途时长只从 9.8 天降到 9.1 天，几乎没有变化。原因很简单，新加的两个人加剧了协调成本，缺陷的"等待"部分反而变长了。

这个实验对我影响很大。它证明了一件事：在途时间是流程的函数，不是人力的函数。只要等待、往返、排队这三段没有被规则约束，加多少人都会被稀释掉。这也是我后来坚持"先改规则，再谈资源"的原因。

三、拆解四个常见误区

改造启动前，我把团队里流传的说法收集了一遍，归纳出四个高频误区。它们之所以顽固，是因为每一个听起来都很合理，甚至在某个局部场景下确实有效。我把每个误区的"表面合理性"和"实际代价"都摆出来，团队才愿意改。

1. 误区一：把 Bug 数量当绩效指标

这个误区最常见的形态是"缺陷发现数排行榜"。逻辑是：提得多说明测试认真，改得多说明开发勤快。实际发生的是两件事同时恶化，测试开始凑数，把同一个问题的不同表现拆成多张单；开发开始挑单，优先处理容易改的、能快速关闭的，复杂缺陷被无限期搁置。

我见过最极端的例子是一个团队在引入排行榜后，缺陷单数量涨了 60%，但线上事故数没降反升。因为真正有价值的、需要跨模块协作的那种缺陷，没人愿意碰。数量指标一旦和个人评价挂钩，就会立刻被优化，而被优化的往往正是你想测量的东西。

2. 误区二：追求"零缺陷"而不是"可控缺陷"

"零缺陷"作为口号没问题，作为考核指标是灾难。它会直接导致两个行为：一是缺陷等级被人为下调，P1 改成 P2，P2 改成"建议"；二是缺陷被关在系统外面，转成口头沟通、转成企微消息、转成"这个先记着"。系统里的数字确实变好看了，实际风险一点没少。

我自己的判断标准是：一个健康的团队不应该追求缺陷数趋零，而应该追求缺陷的"逃逸率"趋零和"在途时长"可控。漏到生产的缺陷占比、生产缺陷的平均修复时长，这两个指标比缺陷总数有意义得多。

3. 误区三：用会议推动缺陷流转

缺陷评审会、每日缺陷同步会、"疑难缺陷攻坚会"。我数过一个团队的日历，跟缺陷相关的会每周 6 场，累计占用 42 人时。这些会的实际功能是"人工轮询"，把系统里本该自动流转的信息，用人嘴搬运一遍。

会议的问题不只是浪费时间，更在于它的频率决定了流转速度。一周开一次评审会，意味着缺陷最长要等 7 天才被排期。用会议驱动流转，等于给流程装上了一个"周"级别的时钟节拍。而缺陷的价值是有时效的，等一周之后，很多上下文已经丢失了。

4. 误区四：工具只当记事本用

这是最普遍也最容易被低估的误区。很多团队买了或搭了项目管理平台，但只用了它 20% 的能力：建单、改状态、留评论。字段不做约束、状态机不做设计、自动化一条不配、报表全靠人手工导 Excel。

工具真正的价值不在"记录"，而在"约束"和"驱动"。字段必填是约束，超时升级是驱动，状态机是流程的代码化。一个团队如果把缺陷管理做成了"更高级的共享文档"，那么它获取的所有数据都只反映"人们愿意写什么"，而不是"实际发生了什么"。

四、专业判断逻辑：缺陷效率的四层杠杆

拆完误区，需要一个能指导行动的结构。我自己的框架是四层杠杆，从上到下依次是信息质量、流转规则、根因分层、度量闭环。它们的杠杆率差别很大：越靠上，改动成本越低、见效越快；越靠下，改动成本越高、但持续性越强。

很多团队的问题在于顺序做反了，一上来就搞度量看板、搞质量门禁，结果底层信息一团糟，所有报表都是垃圾进垃圾出。正确的顺序是先让数据可信，再让流程自动，最后才谈分析和预防。

1. 第一层：缺陷信息质量（可复现性）

这一层只有一个目标：让另一个没参与过的人，能仅凭这张单子复现问题。听起来简单，实际是整个体系里最难的一步，因为它要求测试在提交时多花 3-5 分钟，而这个成本是即时可见的，收益是延后且分散的。

我的做法不是发通知强调重要性，而是把它变成不可绕过的结构。必填字段控制在 4-7 个之间（超过 7 个会引发敷衍填写），关键字段做条件必填，标题做格式校验。具体的配置我放在第五部分，这里先说判断依据：字段的价值不在于"记录了什么"，而在于"阻止了什么"。一个字段如果不能阻止至少一类常见的无效沟通，它就不该存在。

2. 第二层：流转规则与 SLA

第二层的核心是把"靠人推动"换成"靠规则推动"。具体包括三件事：自动分派（提交即落到模块 Owner，不落到空）、超时升级（超过阈值自动通知上一级）、状态约束（没有修复说明不能转"已解决"）。

SLA 的设计有个反直觉的点：不要对所有缺陷用同一套 SLA。如果 P3 的文案错别字和 P0 的支付失败要求同样的响应时间，团队会本能地忽略所有 SLA。我通常按等级设四档，且明确允许 P3/P4 批量排队，给低优先级缺陷一个"合法的等待区"，反而能让高优先级通道真正畅通。

3. 第三层：根因分层与质量门禁

第三层解决的是"同样的缺陷为什么反复出现"。做法是给每个缺陷打根因标签，标签体系不能太细（超过 8 个就没人认真选），我常用的是五类：需求理解偏差、设计缺陷、编码实现错误、环境与配置、测试用例遗漏。

标签积累 2-3 个月后，价值就出来了。你会看到某条产品线 40% 的缺陷集中在"需求理解偏差"，那问题就不在测试也不在开发，而在需求评审和验收标准。这时候质量门禁才有意义，门禁应该加在根因所在的位置，而不是习惯性地加在提测环节。

4. 第四层：度量与反馈闭环

第四层是把前三层的数据变成每周一次、15 分钟能看完的反馈。我坚持三条原则：只度量流程不度量个人、只看趋势不看单点、每周必须产出一个具体动作。第三条最关键，如果一个看板看完之后没有人做任何事，它就只是装饰。

我们当时的周报只有四个数字：在途时长 P50 和 P90、超 SLA 缺陷数、返工率、新增缺陷的根因分布。前三个看健康度，第四个看下周该改什么。整份报告不超过一屏。

五、案例解析与数据观察：三个月把平均在途时间压掉 47%

接下来是完整的改造过程。需要说明的是，下面的数据来自我参与的这个 120 人团队以及后续 11 个团队的复盘样本，其中部分指标做了归一化处理以便横向比较；涉及具体配置的部分我会给出可直接复用的样例，你可以按自己团队的字段体系调整。

1. 改造前的基线数据

我们在改造前做了一次为期两周的静默采样，不做任何干预，只记录。这样得到的基线才有可比性。采样结果是：832 个缺陷、平均在途 9.8 天、返工率 26%、无法复现关闭占 19%、缺陷单平均字数 46 字、P0/P1 占 31%。

我特别建议做这一步。很多团队的改造之所以无法证明有效，就是因为没有干净的基线，一边改一边看，最后说不清是流程起作用了还是季节性波动。

2. 第一步：把缺陷模板变成结构化的证据清单

我们没有增加字段，而是重构了字段。原来 14 个字段里有 6 个从来没人填，我们删掉；新增 3 个关键字段；把必填从 2 个提到 6 个。核心是三件事：标题强制格式、复现概率强制选择、证据按概率条件必填。

第三条是这次改造里我认为最巧妙的设计。如果复现概率选"必现"，截图和录屏是选填；如果选"低于 50%"或"仅一次"，证据字段自动变成必填。这样做的好处是：确定性问题提交很快，不确定性问题必须带证据，团队不会因为字段太多而抵触。

# defect-template.yaml ， 缺陷提交模板的字段约束配置
fields:

key: title

label: 一句话现象

required: true

rule: "必须包含【模块】+ 现象 + 影响范围，禁止只写'页面报错'"

key: env

label: 环境与构建号

required: true

type: select

options: [开发自测, 测试环境, 预发布, 生产]

key: reproduce_rate

label: 复现概率

required: true

type: select

options: ["必现", ">50%", "default: "必现"

key: steps

label: 复现步骤

required: true

rule: "至少 3 步，需写明前置数据、账号角色与关键操作"

key: evidence

label: 日志 / 录屏 / 截图

required: false

condition:

when: reproduce_rate in [">50%", "then: required: true

key: expected_vs_actual

label: 期望结果与实际结果

required: true

3. 第二步：用自动化规则替代人工推动

模板上线两周后，缺陷单平均字数从 46 字涨到 168 字，无法复现率从 19% 降到 7%。但真正的变化发生在第三步：我们把流转规则写成了配置，而不是写在制度文档里。

规则一共 9 条，覆盖三类场景：高危缺陷快速通道、信息不全自动退回、长期停留自动升级。上线后首次响应时长从 1.9 天降到 0.3 天，排期阻塞缺陷数从每版本 14 个降到 3 个。

# sla-rules.yaml ， 缺陷流转与升级规则
rules:

name: 高危缺陷 30 分钟响应

when:

severity: [P0, P1]

status: 新建

then:

assign_to: 模块 Owner

notify: [项目负责人, 测试负责人]

escalate_after: 30m

name: 信息不全自动退回

when:

missing_fields_any: [env, reproduce_rate, steps]

then:

status: 待补充

assign_to: 提交人

escalate_after: 4h

name: 待排期超 3 天自动升级

when:

status: 待排期

age: "> 3d"

then:

notify: [项目负责人]

add_label: 排期阻塞

name: 修复完成必须填影响范围

when:

transition: [修复中, 待验证]

then:

require_fields: [fix_scope, regression_hint]

这里有一个踩过的坑值得说：我们最初把"信息不全自动退回"设成直接打回给提交人，结果测试同学很反感，觉得是在"惩罚提 Bug 的人"。后来改成先进入"待补充"状态、由系统补齐已知字段（环境、构建号可以从提交时的会话信息里带出来），只剩复现步骤需要人补，抵触情绪明显下降。自动化规则的设计目标不是严格执行，而是把人工成本降到最低。

4. 第三步：根因标签与周度复盘

第三步启动得最晚，效果也最不稳定。我们上了五个根因标签，要求缺陷关闭时必须选择。执行率第一周是 91%，第四周掉到 62%，第八周回升到 84%。中间的波动原因很实在：赶上大版本发布，大家忙起来就跳过。

后来我们做了两个调整：一是把根因选择做成关闭动作的必填项，技术上不允许跳过；二是每周只复盘一个根因类别，不追求全面。执行率稳定在 88% 以上，而且复盘质量明显高于之前的"逐个缺陷过一遍"。

5. 结果数据与副作用

三个月后的结果是：平均在途时长从 9.8 天降到 5.2 天，降幅 47%；返工率从 26% 降到 11%；无法复现关闭占比从 19% 降到 6%；P0/P1 占比从 31% 降到 17%；缺陷单平均字数从 46 字涨到 168 字。

请注意最后一行，这是我们必须诚实交代的副作用：测试同学每提交一个缺陷，平均多花 2.3 分钟。按每月 300 个缺陷算，团队每月多投入约 11.5 小时。但换回来的是开发侧每月减少约 63 小时的追问与返工。这笔账必须算清楚，否则测试团队会觉得改造是在给自己加活。

六、不同情况下的行动建议

上面这套做法不能照抄。同样的规则，在 15 人团队里会变成负担，在 300 人组织里又不够用。我按团队规模和协作结构给出四套建议，每一套的重点不同。

1. 20 人以下小团队：只做两件事

小团队最大的优势是沟通成本低，最大的风险是照搬大厂流程把自己压死。我的建议是只做两件事：一是把"环境+构建号+复现步骤"做成必填，二是每周花 15 分钟看一次在途时长最长的 5 个缺陷。

不要上 SLA，不要搞根因标签，不要做看板。这个规模下，一个人喊一嗓子比任何自动化都快。真正需要沉淀的只有信息质量，因为它是唯一一个"越早建立越省钱"的东西，等到 50 人的时候再补，历史数据的价值已经没了。

2. 50-150 人团队：上规则、上分级、上自动化

这是改造收益最高的区间。规模足够大到"人盯人"失效，又足够小到规则可以快速落地。核心动作是三件：分级 SLA（四档）、自动分派与超时升级、根因标签加周度复盘。

这个区间我强烈建议用一套成体系的项目管理平台来做载体，而不是靠文档加人肉。原因很实际：这个规模下规则会有十几条，靠人记必然衰减。像 PingCode 这类面向中大型企业（主要服务 100 人以上组织）的平台，优势在于缺陷单、需求、迭代、测试用例在同一套数据模型里，缺陷可以关联到具体的需求和迭代，根因分析才有上下文。我们当时用的就是这类方案，把缺陷和需求打通之后，"需求理解偏差"这一类根因的识别准确率提升很明显，因为能直接看到当初的验收标准写的是什么。

反过来，如果这个阶段的团队还在用表格加聊天工具管缺陷，问题往往不是"效率低"，而是"根本没有数据"。先解决有无，再谈优化。

3. 200 人以上多产品线：先统一口径，再谈工具

这个规模的组织，最大的问题通常不是流程缺失，而是流程太多套。四条产品线四套缺陷等级定义、四套字段、四套报表，横向无法比较，管理层看到的数字没有可比性。

我的建议顺序是：先统一等级定义和根因标签，再统一字段，最后才统一工具。反过来做（先上工具）的结果是，工具里长出了四套并行的配置，问题一点没解决。等级定义必须带客观锚点，比如"P0：核心交易链路不可用且有资损风险"，而不是"严重影响用户体验"。

4. 外包与多供应商协作：把约束前移到合同

涉及外部团队时，缺陷效率的最大杀手是"责任边界不清"。同一个缺陷，甲方说是乙方交付质量问题，乙方说是甲方需求变更，来回扯皮两星期。

这类场景下，字段约束还不够，需要把 SLA 和验收标准写进合作约定：缺陷响应时限、修复时限、返工责任归属、验收不通过的处理方式。系统层面则是把外部团队放在独立的项目空间里，用统一模板收单，避免他们用自己的工具提交，然后靠人手工转录。

七、不同情况下的取舍

前面讲的都是"应该做什么"，但实操中更常见的问题是"两件都对的事，只能选一件"。缺陷管理里有多组天然冲突，我把最典型的四组列出来，并给出我的取舍标准和边界。

1. 流程严格度 vs 提交意愿

字段越多、校验越严，数据质量越高，但提交门槛也越高。当门槛超过某个临界点，人们不会更认真填，而是干脆不提，转成口头沟通，你就彻底失去了可见性。

我的取舍是：宁可数据不全，也不要数据消失。具体做法是必填字段控制在 4-7 个，其余全部选填但提供默认值；同时用"待补充"状态而不是"打回"，让人可以先提交再完善。判断临界点的信号很直接：如果缺陷提交量在模板上线后下降超过 20%，说明门槛过高了。

2. 自动化程度 vs 维护成本

自动化规则不是越多越好。每一条规则都需要有人维护，规则之间还会冲突，比如"信息不全自动退回"和"高危缺陷直接分派给 Owner"同时命中一个 P0 缺陷时，谁优先？

我的取舍是：规则数量控制在 6-15 条之间，每条必须有明确的负责人，每季度清理一次。超过 15 条基本可以断定有冗余。另外，规则一定要能一键停用，上线新规则的前三天必须可回滚，否则一次配置失误就能让整个缺陷流瘫痪。

3. 度量透明 vs 心理安全

数据公开能带来改进压力，也会带来防御性行为。我们做过一个实验：把缺陷在途时长按模块公开，两周内 P90 数据确实改善了，但同期"无法复现"关闭的比例上升了 4 个百分点，有些团队开始用快速关闭来优化指标。

我的取舍是：公开到团队级，不公开到个人级；公开趋势，不公开排名。团队级公开保留了改进压力，又不至于让人把指标当成考核。一旦发现数据出现"指标变好但实际变差"的信号，第一反应应该是检查度量方式，而不是表扬团队。

4. 工具统一 vs 团队自治

统一工具能带来横向可比的数据，但会牺牲团队的适配性。三条产品线的技术栈差异很大，硬用一套缺陷模板，就会出现"某个字段对某条线毫无意义但必须填"的情况，然后大家开始填"无"。

我的取舍是：核心字段强制统一（用于横向对比），扩展字段允许团队自定义（用于本地适配）。核心字段我只保留 5 个：等级、模块、根因、在途时长、状态流转记录。这五个足够支撑所有跨团队分析，其余全部下放。经验值是核心字段不超过 5-8 个，超过就一定会出现敷衍填写。

八、总结：缺陷效率是一场关于"信息密度"的改造

如果只能留一句话，我会说：缺陷管理的效率，本质上取决于一张缺陷单里承载了多少可直接行动的信息。信息密度高的缺陷单，不需要开会、不需要追问、不需要来回确认，它自己就会往前流；信息密度低的缺陷单，无论你配多少自动化、开多少会，都得靠人去补。

这也解释了我最开始那个反常识的结论。我们以为瓶颈在"改"，其实在"等"；我们以为"等"是人的问题，其实是信息的问题；我们以为信息的问题是态度问题，其实是结构问题。项目负责人真正要设计的，是一个让人"不得不把信息一次说清楚"的结构，而不是一套催人的机制。

三个我认为最值得记住的判断：

• 先量在途时长，再谈缺陷数量。数量指标回答"做了多少"，时长指标回答"卡在哪"，后者才能指导行动。
• 先修上游，再修下游。信息完整度不解决，所有下游的自动化都是在给垃圾加速。
• 接受副作用，并把它算进账里。任何改造都有代价，测试多花 2.3 分钟换开发少花 63 小时，这笔账要提前算给团队看。

下一步怎么做，我给一个可以直接执行的四周路径。第一周，做静默采样，记录当前的在途时长、返工率、无法复现率、P0/P1 占比四个基线数字，不要改任何东西。第二周，重构缺陷模板，把必填字段压到 4-7 个，加上复现概率和条件必填的证据字段，先在一个团队试点。

第三周，配置 6-9 条流转规则，重点是自动分派、超时升级和信息不全的"待补充"状态，上线前确保可一键回滚。第四周，做第一次复盘，只看一个数字：平均在途时长的 P50 有没有下降，以及测试的提交耗时增加了多少。如果 P50 降了但提交耗时涨得离谱，说明字段设计过重，砍掉两个必填再试。

不要一次上全套。我见过太多团队在一个月内把模板、SLA、看板、根因标签全部上线，然后第三个月全部废弃，因为没人扛得住同时改变四件事的成本。一次只改一个变量，改完看数据，看完再改下一个。四个月之后回头看，你会发现真正起作用的往往只有两三件事，但那两三件事，是数据帮你选出来的，不是拍脑袋定的。