简介：《华为软件测试回溯模板》是一份面向软件测试、质量管理和研发流程改进人员的培训型PPT，聚焦华为供应链质量管理部推行的质量回溯方法。内容把质量回溯拆解为根本原因分析与持续改进的闭环，讲解缺陷从Error到Defect再到Fault/Failure的传递机理，以及缺陷引入点、控制点与问题根因之间的关系，并给出控制引入点、切断传播途径、规避触发条件三类控制策略。资源还覆盖根因的定义、属性与分类，问题标识、证据搜集、改进方案、实施改进和效果评估等分析步骤，并结合IPD开发流程说明质量控制与质量回溯如何分工。压缩包共1个PPT文件，约1.65MB，结构完整，适合用于团队培训、测试复盘或质量案例学习。目前已有1233人学习，可作为搭建缺陷预防与闭环改进思路的参考材料。
1. 质量回溯不是开复盘会：软件测试回溯模板真正要解决的是「缺陷为什么会被放进来」
很多团队把质量回溯开成了一场道歉会：问题复现、责任人认领、加两条用例、散会。三个月后同类问题换个模块又来一次。软件测试回溯模板要解决的从来不是「这个 Bug 怎么改」，而是「这个缺陷当初为什么会被放进来、放进来之后为什么没人拦住」。它把一次事故拆成错误、缺陷、失效三个时刻，逼着你逆着传播链往回走，直到揪出一个既能被描述、又能被纠正的因素。这套动作的价值不在事后追责，而在于它是少数能把个人经验沉淀成组织能力的机制——根因分析做对了，失效模式库才有内容，流程改进才有靶子；做歪了，后面所有的度量、评审、复盘，都只是在给一份错误的报告做装饰。
2. 缺陷的传播链：Error、Defect、Fault 为什么不能当成同义词用
回溯做不下去的团队，十有八九是在这三个词上就开始含糊。把「错误」「缺陷」「故障」混着说，后果是分析会开到一半，大家已经分不清自己讨论的是人的动作、产品的状态，还是用户看到的现象。这套模板的第一层设计，就是先把三个时刻切开，让每条结论都必须落到某个具体时刻上。
2.1 错误、缺陷、失效：三个时刻对应三种修复成本
模板给出的定义非常克制：Error 是执行或计算等未符合规定要求；Defect 是错误隐藏在产品中，即形成缺陷；Fault/Failure 是产品终止规定功能，可修复的称故障，否则称失效。这三句话看似只是名词解释，实际划出了三个完全不同的战场。
Error 发生在人的动作层面——需求理解偏了一寸、接口约定漏了一个边界、配置项写错了一个字符。它的特点是转瞬即逝，不留下物理痕迹，只能靠当时的记录和当事人的还原。Defect 发生在产品层面——错误的动作把某个不一致固化进了代码、文档、工艺文件里，它静静躺着，可以存在很久而不被任何人察觉。Fault 发生在运行层面——某个特定输入、特定时序、特定环境把那个躺着的缺陷激活了，功能终止，用户或测试人员看见了。
为什么必须分开？因为三者的修复成本完全不是一个量级。业界常见的经验说法是，缺陷每往后流一个环节，修复代价就上一个数量级：在编码时改一行判断，在单元测试时改一个函数，在系统测试时可能要改接口契约，到了网上出了问题，代价里还要叠加客户信任、版本回退、现场支持。这条成本曲线是回溯存在的经济学理由——回溯不是为了把已经花掉的成本要回来，而是为了把下一个同类缺陷拦在成本曲线的低端。
更关键的是责任主体的差异。Error 的责任主体是具体的动作执行者和约束这个动作的规范；Defect 的责任主体是承载它的那件产物和产出这件产物的流程；Fault 的责任主体是触发条件和防护机制。回溯报告如果只写「某模块空指针导致崩溃」，那是 Fault 层的描述；写成「某函数未判空」，那是 Defect 层的描述；只有写到「接口契约里可空字段的约定缺失，且评审 checklist 里没有这一项」，才算摸到了 Error 层的门槛。大多数人停在第 1.5 层，所以改完还是复发。
我一般会这么理解：Fault 是症状，Defect 是病灶，Error 是病因。医生只按症状开止痛药，病人下次还得来。
2.2 引入点与控制点的错位：根因为什么总在「上游」
这是整套模板里最容易被忽略、也最值钱的一条判断：问题的根因一般情况在缺陷的引入点，一般不会在缺陷的控制点，因为控制点不是问题发生的源头。
先把两个概念摆清楚。引入点是错误被固化进产品的那一个环节——需求评审、方案设计、编码、工艺文件编制、临时技术更改。控制点是引入点之后用来发现和拦截缺陷的环节——代码评审、单元测试、系统测试、来料检验、出厂检验。同一条缺陷，在时间轴上先经过引入点，再经过一个或多个控制点。
那为什么大家总是把根因写到控制点上？因为控制点是「自己的、可见的、可改的」。测试没测出来，加用例就行；评审没看出来，加 checklist 就行；检验没检出来，加抽检比例就行。这些动作永远正确、永远能写进报告、永远没人反对，但它们不解决任何问题——因为引入点还在源源不断地生产同类缺陷。这类改进我称之为「永远正确的无效改进」：报告很漂亮，数据很平稳，问题照旧。
模板给了一个例外条款，这个条款极其重要：只有当引入点的质量无法控制、或在能力范围之外时，控制点才会构成根因。它举的例子是来料问题——供应商的源头你管不到，只能靠来料质量管理和来料检验去约束。这个例外的判定标准是「控制权」，不是「方便性」。你能改引入点却选择去改控制点，那不叫例外，那叫回避。
有一个我常用的追问，用来把结论从控制点逼回引入点：如果这个控制环节做到完美，问题还会不会发生？如果答案是「会」，那它就不是根因，只是没兜住。反过来再问一句：如果这个引入环节做到完美，问题还会不会发生？如果答案是「不会」，那基本可以锁定。这两问不需要任何工具，但它能把九成的「测试覆盖不足」式结论打回原形。
还有一层更隐蔽的错位：引入点常常不在你以为的那个阶段。一个线上崩溃，代码是在开发阶段写的，但「允许这样写」的约定可能是在方案评审阶段定下的，而「没人对这个约定负责」这件事可能是在更早的组织分工里埋下的。回溯要往上游走，但不能无限往上走——这正是下一章「根因三个属性」要解决的问题，它给了一个停止追问的判据。
2.3 三类止损手段：控制引入点、切断传播途径、隔离触发条件
搞清楚传播链和引入点之后，防控手段其实只有三条路，模板把它们列得很干脆。
第一条，控制引入点。明确错误是在哪一点引入的，然后规范这个点的活动，防止错误遗留到产品中形成缺陷。落地形态通常是：把这次踩的坑写进该环节的检查项、模板、规范条款。注意关键词是「该环节」——很多团队的改进措施写在测试环节，但引入点在设计环节，这类措施天然失效。
第二条，切断传播途径，也就是通过缺陷控制点来监控，用明确的检查标准或要求防止缺陷流入下一环节。这里有一条配套的成本原则：检查离错误的引入点越近，效果越好，成本越低。代码评审比系统测试便宜，需求评审比线上故障便宜，原因不只是工时，更是「此时上下文还在、改动面还小、没人需要为回滚负责」。所以控制点的布局不是越多越好，而是越靠前越划算。
第三条，规避触发条件，也就是隔离。缺陷虽然藏在产品里，但如果把触发条件隔开，它就不会导致故障或失效。这是给「暂时解决不了的缺陷」准备的兜底手段——老版本兼容、特定配置组合、极端负载场景，短期没法彻底修，那就先在入口处拦住触发路径。模板对这一条的态度很清醒：它是权宜之计，不是终点，因为缺陷还在产品里，触发条件一旦变化就会重新暴露。
三条路对应三种不同的时间尺度和成本结构，实际回溯里往往要组合使用：引入点做规范（治本，慢），控制点做拦截（治标，快），触发条件做隔离（兜底，临时）。判断一份回溯报告是否合格，有个简单办法——看它是不是三条路都想到了，只写其中一条的，多半没想透。
3. 根因的三个属性：什么样的因素才配写进回溯报告
分析会开到最后，白板上通常留着一堆候选原因，这时候最难的不是找原因，而是砍原因。砍多了改进不彻底，砍少了措施落不了地。模板用一组属性定义加一张 Checklist 来完成这次收敛，思路很工程化：先给「根因」下一个可判定的定义，再用属性逐条筛。
3.1 三个硬属性：源头、可识别、可纠正
定义是这样的：导致问题发生的源头或关键因素，同时这种因素能被识别和纠正，消除了该因素，可防止问题的再次发生。拆开看是三个硬属性。
第一个属性是逻辑位置——根因必须在逻辑上是问题原因链的源头，也就是所谓的底事件。判断方法很朴素：继续往下问「为什么」，如果还能问出有意义的一层，说明你停早了；如果问出来的答案已经超出这次问题的边界，或者变成了「行业普遍如此」，说明你走过了。原因链是有边界的，边界由「本次问题的可控范围」划定，不由哲学追问划定。
第二个属性是层次取舍——如果多种原因在逻辑层次上相同，则取关键的那一个。这一条经常被误用成「只写一个原因」。它的本意是：同一层的多个并列因素里，优先处理影响面最大、最可控的那个，而不是把所有并列项都列上然后平均用力。报告里出现七八条同层次的「根本原因」，基本等于没有根因。
第三个属性是「可纠正」——这一条是被低估最严重的。定义原话是：根本原因是一个可以具体描述的因素并可以改进的因素，而不能「放之四海而皆准」。换句话说，「人员质量意识不足」「流程执行不到位」「沟通不充分」这类话，语法上像根因，判定上不是——因为你无法针对它设计一个可验收的改进动作，也就无法验证改进是否生效。一份写着这类结论的报告，真正的功能是结束会议，不是解决问题。
「可纠正」还带来一个副产品：它会反向约束描述粒度。「接口契约中可空字段的约定缺失」是可纠正的，因为可以补一条约定规则并加进模板；「设计能力不足」不可纠正，因为无从下手。同一件事，换个粒度就从废话变成了动作。这就是为什么模板反复强调根因「可以具体描述」——描述粒度本身就是判定标准的一部分。
3.2 分类树：技术、人为、管理三棵子树怎么长
判定完还要归档，归档的目的是让同类问题可检索、可统计、可复用。模板给了一张两层分类表，大类三支，小类若干。
| 根因大类 | 根因小类 | 典型落地形态 |
|---|---|---|
| 技术因素 | 参照技术侧的缺陷分类表细分 | 算法边界、接口契约、并发时序、兼容性 |
| 人为因素 | 技术规范执行不严格、流程管理制度执行不严格、沟通问题、疏忽 | 该走的评审没走、该记的记录没记、信息没同步到位 |
| 管理因素 | 培训不充分、计划不完善、资源分配不适当、监控不充分、流程不完善、管理制度不完善 | 排期挤压验证时间、职责边界不清、缺少监控指标 |
同一套分类思想在偏硬件的制造侧会展开成更细的子树，比如工艺文件类（无工艺文件、文件内容不全、临时技术更改与试制评审缺失）、工艺技术类（工艺流程制定缺陷、工艺参数设置不当）、工艺软硬件环境类（工艺辅料、防静电、工装工具维护使用不当）。看这些子类的命名会发现一个共同点：每一条都是一个可以派人去改的具体物件或具体动作，而不是一种状态描述。这是分类树设计上的用心之处——分类的粒度直接决定了改进动作的粒度，分类写得虚，措施必然虚。
三支里我最警惕的是「人为因素—疏忽」。它太顺手了，几乎任何问题都能塞进去，而且塞进去之后会议就可以结束了。但「疏忽」作为根因是不可纠正的：你没法给「不疏忽」定验收标准。可行的做法是把「疏忽」继续往下拆一层——为什么会疏忽？是这一步操作没有强制校验？是同类操作有两个长得一样的入口？是记录靠记忆而系统不落痕？拆到这一层，它就从人的状态变成了系统的约束，才具备可纠正性。分类树不是给人贴标签用的，是给改进找落点用的。
3.3 判定 Checklist：把「我觉得」变成可复核的闸门
模板提到用「根本原因的判定 Checklist」来筛原因，但没给具体表单。按这类体系的通用做法，Checklist 的实质是把前面那些属性翻译成一串是非题，让不同的人对同一条原因能得出同一个结论。我一般会把它写成下面这种形式，逻辑比形式重要：
def is_root_cause(cause, problem): # 闸门1：逻辑位置——它是不是原因链的底事件 if still_meaningful_why(cause): return False, "还能继续追问，属于中间事件" # 闸门2：可纠正——能否设计出可验收的改进动作 if not has_actionable_fix(cause): return False, "不可纠正，属于状态描述而非根因" # 闸门3：因果强度——消除它之后问题是否不再复现 if not prevents_recurrence(cause, problem): return False, "消除后问题仍会发生，可能是伴随因素" # 闸门4：位置校验——它落在引入点还是控制点 if locate(cause) == "control_point" and controllable(cause, "introduction_point"): return False, "根因在控制点，但引入点可控，需继续上溯" return True, "通过"四个闸门对应四类误判：停得太早、描述太虚、因果太弱、位置太偏。参数上最需要留意的是闸门 3 的prevents_recurrence——它不是问「这个原因是否存在」，而是问「消除它之后问题是否不再发生」，这是一个反事实判断，只能靠推理和小范围验证，不能靠投票。闸门 4 里的controllable就是上一章说的例外条款：引入点确实不可控时才放行控制点作为根因。
提示：Checklist 的作用不是替代判断，而是把判断过程留痕。凡是没通过闸门却被写进报告的条目，应该在报告里注明理由，这一条对后续复查极有价值。
4. 四段式分析流程：从时间线到原因链，每一步在防什么
有了判据还得有流程，否则判据会被跳过。模板把根因分析拆成四段：准备工作、原因分析、根本原因确定、改善行动。这四段的价值不在于顺序本身，而在于每一段都在防一种特定的人性弱点——第一段防信息不全，第二段防结论先行，第三段防各说各话，第四段防改完就忘。
4.1 准备阶段：小组里必须有一个「对引入点负责」的人
准备工作两件事：组建根因分析小组并划分职责，以及数据搜集。
小组构成是整场分析里最容易被凑合的一步。常见做法是拉上问题发现方、问题修复方和一位主管，看起来很齐整，但缺了一类关键角色——对引入点负责的人。如果引入点在需求阶段，就得有当时做需求的人或熟悉那套需求规范的人在场；如果引入点在工艺文件，就得有编文件的人在场。缺席的后果很直接：讨论会自动滑向在场者能解释的那部分，也就是控制点。「测试为什么没发现」永远比「规范为什么这么定」更容易讨论，因为有当事人在场。
数据搜集的范围模板列得比较宽：现场数据、观察和测试资料、书面文件等等。这里有个实操口径值得强调——搜集的不是「能支持某个结论的证据」，而是「那段时间里发生过的所有相关事实」，包括看起来无关的。原因很简单：如果只搜集支持性证据，后面画出来的时间线就是结论的插图，不是事实的记录。采集时最好带三样东西：时间戳、来源、可复核性（谁还能证实它）。缺了来源的记录，在后面对齐时会被反复质疑，非常消耗时间。
准备阶段还有一个常被省略的动作：现场问题的临时处理。模板把它放在准备阶段而非改进阶段，用意很清楚——先把火扑灭，才能冷静查火因。带着「线上还在报警」的焦虑做根因分析，结论一定是「先加个监控」。
4.2 问题定位：画时间线是防「结论先行」的唯一硬约束
原因分析的第一步是问题定位：以具体的方式叙述事情发生始末，包括时间、地点、如何发生，并确认事件发生的先后顺序；画出时间线或流程图，协助小组成员把焦点放在事件的事实上，而不是一下就跳到结论；据此定位出造成问题的直接原因。
这段话里最要紧的是「画时间线」这个动作。人的记忆天然是按因果组织的，不是按时间组织的——你问一个人昨天出了什么事，他会先给你结论，再补理由。这种叙述方式在分析会上的破坏力极大，因为第一个说出口的结论会锚定整场讨论。时间线的价值就在于强制把叙述顺序改回时间顺序：先发生什么、后发生什么、每一步的输入输出是什么、谁在什么时候看到了什么。事实对齐之后，很多争论会自己消失。
一条可用的时间线，我通常要求每个节点满足三条：有时间戳（哪怕是「约当天下午」）、有来源（日志、工单、聊天记录、某人的直接观察）、有可复核路径。不满足的节点标记为「待证实」，不参与因果推断。这个习惯能省掉大量「我记得当时是……」的拉锯。
注意：时间线要写到「直接原因」为止，不要在这一步就开始写根因。直接原因是导致失效被触发的那一环，通常在链路末端；根因在链路源头。两者混写，后面的原因链就建不起来了。
4.3 原因链：发散要宽，收敛要狠
定位完直接原因，进入发散：由小组成员头脑风暴，列出事件的所有可能原因，覆盖设计因素、人为因素、管理因素；然后理清各种原因之间的关系，组成问题的原因链。
这一步的难点是两件事同时做：既要宽，又要狠。宽是指发散阶段不允许否定任何候选原因，尤其是那些听起来「不可能」的——很多真根因就藏在「我们一直都是这么做的」里。狠是指收敛阶段必须砍到只剩能通过第 3 章那四个闸门的条目，不能因为「这条也有点关系」就留下。
原因链和原因列表的区别在于有没有箭头。列表是一堆并列项，链是有向结构：A 导致 B，B 在某个条件下触发 C。实际写出来大概是这个样子（用文本描述，不必画图）：
- 现象：某跨平台系统在特定配置组合下启动失败
- 直接原因：初始化流程读取了一个尚未写入的配置项
- 中间事件一：该配置项由另一模块异步写入，时序上无保证
- 中间事件二：接口契约中该字段标注为「可空」，调用方按「必有值」使用
- 中间事件三：契约评审的检查项里没有「可空字段的调用方约束」这一条
- 底事件：可空性约定只在代码注释里体现，未进入契约模板与评审清单
砍到这里就可以停了。再往下问「为什么模板里没有这一条」，答案会变成「行业里普遍如此」或者「历史原因」，超出本次可控范围，属于无效追问。而停在这里，改进动作是清晰的：把可空字段约束写进契约模板，并加进评审清单——这是一个可验收的动作。
原因链还有一个副产品：它能告诉你优先级。链上节点越靠近源头，改动一次能覆盖的同类问题越多；越靠近末端，改动越快见效但复发性越高。改进方案怎么排，看这条链就大致有数了。
4.4 改善行动：短期止血与长期固化的分层
最后一段是改善行动，模板把它拆成两层。
短期措施对应「对策实施」：列出改进对策，做可行性分析——确定根本原因之间的关系，确定哪些根因值得改进并排出优先级；然后按 SMART 原则拟订改进计划和措施，明确改进人、计划、措施；实施后验证改进结果。这里的 SMART 不是套话，每一条都对应一个常见的失败模式：不具体（Specific）导致措施无法执行，不可度量（Measurable）导致无法验证，无人认领（Assignable）导致三个月后没人记得，不现实（Realistic）导致中途放弃，无时限（Time-bound）导致永远在「推进中」。
长期措施对应「经验固化」：把改进结果中共性的经验固化成标准，在团队内分享。这一步是回溯和普通 bugfix 的分水岭。短期措施解决这一次，长期措施解决这一类。固化的形态可以是失效模式库的新条目、评审清单的新检查项、模板的新字段、自动化校验的新规则——判断标准只有一条：下次同类问题出现时，有没有一个不依赖当事人记忆的东西能拦住它。
模板在流程图上把「经验固化」和「案例宣传」放在改进实施之后，这个顺序是有讲究的。先验证再固化，避免把没生效的措施写进标准；先固化再宣传，避免宣传的内容还没落进流程。
5. 避坑实录：五条把根因分析做歪的常见路径
流程和判据都好理解，难的是执行时那些看起来合理、实际跑偏的动作。下面五条是我见过频率最高、也最容易被忽略的偏差，每条按「现象—原因—解决」拆开。
5.1 五条踩坑记录
第一条：复盘会开成批斗会，最后落在「某人不够仔细」。现象是会议前半段还在讨论技术细节，后半段开始追责，结论写成「操作人员疏忽，已批评教育」。原因是把「人」当成了原因链的终点，而人的状态是不可纠正的，写进报告等于宣布结案但没解决问题。解决方式是把「疏忽」强行再拆一层：为什么会疏忽？是这一步没有强制校验，是两个入口长得太像，是记录靠记忆而系统不落痕？拆到系统约束这一层，才具备可验收的改进动作。
第二条：根因写成「测试覆盖不足」，改进措施是「补充测试用例」。现象是同类问题半年后换一个模块又出现，用例补了一堆但新场景照样漏。原因是把控制点当成了根因——测试只是没兜住，缺陷是在更上游被放进来的。解决方式是走第 2.2 节那两个追问：如果测试做到完美，问题还会不会发生？如果引入点做到完美，问题还会不会发生？两个答案一对比，根因位置就清楚了。
第三条：改进措施列了十二条，三个月后回访，落地两条。现象是报告很厚、决心很大、执行很差。原因是措施没有 SMART 化，没有责任人、没有时间点、没有验收标准，全靠自觉。解决方式是把每条措施压缩成「谁、在什么时间点、交付什么可检查的产物」，超过五条就砍优先级——一次回溯能真正落地三条，已经是很高的产出。
第四条：同一个根因在不同项目反复出现，但没人认得出来。现象是每次分析都像第一次，讨论从零开始。原因是经验没有固化成可检索的形态，改进只停留在「这次改了代码」。解决方式是把结论写进失效模式库，并且写成一个可判定的模式——触发条件、典型表现、判定方法、对应措施。库的价值不在条目数量，在于能不能被下一个人检索到。
第五条：时间线靠回忆拼，关键节点各说各话。现象是分析会开成记忆对质会，两小时还没对齐事实。原因是数据搜集滞后，事发当时没人留痕，等复盘时只能靠脑补。这类问题的本质是把日志和记录当成运维资产而不是质量资产——真出事的时候，没有黑匣子就只能靠玄学。解决方式是把关键环节的留痕做成默认动作：评审结论、变更记录、验证输出，全部带时间戳归档，事后不用问人。
5.2 一份可复用的排查顺序
踩坑踩多了会形成固定的自查顺序，我现在拿到任何一份回溯报告，都按这个顺序过一遍，基本能在五分钟内判断它是不是走过场：
- 先看结论落在引入点还是控制点。落在控制点且引入点可控的，直接打回。
- 再看结论能不能被纠正。「意识不足」「沟通不畅」「执行不严」这类词出现即打回，要求拆到具体动作或具体约束。
- 看原因链有没有箭头。只有并列列表没有因果关系的，说明发散完没收敛。
- 看措施是否分层。只有短期措施没有长期固化的，这一类问题大概率还会回来。
- 看措施是否带责任人和验收标准。缺一项，落地率减半。
- 最后看有没有回灌到库或清单里。没有沉淀的复盘，等于没做。
这套顺序不保证分析一定对，但能过滤掉绝大多数形式主义的报告。血泪经验是：一份报告最容易糊弄的地方恰恰是格式最漂亮的地方，所以别先看排版，先看结论落在哪个点。
6. 设计取舍：为什么这套模板宁愿重流程，也不做成一张填写表
把整套东西看完会发现一个明显的倾向：它几乎没有工具化的野心。没有复杂的评分模型，没有自动化判定，全靠几张清单、几条属性定义、四段固定动作。这在今天看来很「笨」——根因分析完全可以做成一个填表系统，选分类、选引入点、自动生成措施建议。
我认为这个取舍是有意的，理由在于根因分析真正的瓶颈不在信息处理，而在两件事：人愿不愿意说真话，以及不同人对「什么算根因」能不能对齐。第一件事工具解决不了，只能靠流程提供安全感——时间线先对齐事实、结论落在机制而不是人、Checklist 留痕而不追责，这些设计都在降低说真话的成本。第二件事工具也解决不了，只能靠一套共享的判据把「我觉得」变成「可复核」，这就是三个属性和四道闸门的作用。
代价也很明显：流程重、周期长、对主持人的能力依赖高。一个十几人的团队做一次完整回溯，从准备到固化，跨几周是常态。所以它更适合那些「同类问题复发代价极高」的场景——底层平台、量产硬件、对外交付的关键系统。低频、影响面小的问题用这套流程，投入产出比并不划算。这个边界必须说清楚，否则很容易变成为了流程而流程。
验证这套东西有没有生效，我一般看两个指标，都不复杂：一是拿历史缺陷回灌，看现有分类树和失效模式库能不能把它们覆盖住，覆盖不住的说明分类粒度或库的沉淀有问题；二是看半年前那批长期措施现在还在不在生效，很多措施在三个月内有效、半年后就被后续变更悄悄绕过了，这种「衰减」比没做更危险，因为它会给人虚假的安全感。
说个我自己的教训。早年做回溯，我特别迷恋「找到那个唯一的根因」，觉得分析得越深越显功力，结果报告写得又长又玄，措施一条都落不了地。后来才想明白，根因分析的产出不是一份深刻的报告，而是一个能被别人执行的约束。从那以后我每次写结论，都强制走一遍「可纠正」这一关——写不出对应的可验收动作，就说明还没分析到位，回去重拆。希望帮到你。
本文还有配套的精品资源，点击获取
