原因分析是对选定的现象进行全面深入的研究，找到现象背后的真正原因与深层次原因，然后采取合适的措施纠正问题、预防问题。如果没有找到真正的根因就采取措施，往往事倍功半，浪费了投入。那么在原因分析时，有哪些成功要点呢？基于我多年的咨询与引导经验，我总结了如图1所示的十个要点。

图1 原因分析的十个成功要点

1 先澄清事实，再寻找原因。

原因分析的第一步就是要澄清事实，即弄清楚问题到底是什么，问题是如何发生的，把问题定义清晰，才能避免南辕北辙，方向有误。

爱因斯坦曾经说过:“如果给我一个小时解答一道决定我生死的问题，我会花55分钟来弄清楚这道题到底是在问什么。一旦清楚了它到底在问什么，剩下的五分钟足够回答这个问题。”可见澄清事实对于解决问题的重要性。

【案例1】张三在2023年一季度销售业绩和2022年一季度相比下降了50%。对于业绩下降这个问题拟进行原因分析。我们需要把这个问题发生的背景信息进行进一步澄清：

1） 2023年一季度张三的销售业绩为100万，2022年一季度张三的销售业绩为200万。

2）2023年一季度整个公司的销售业绩为1000万，2022年一季度整个公司的销售业绩为1600万。

基于上述的信息，我们看到的现象是：

1. 整个公司的销售业绩与上年对比，从1600万降到1000万，下降幅度为37.5%。
2. 张三的销售业绩与去年相比也下降了，从200万降到100万，下降幅度为50%。
3. 张三业绩下降的幅度超过了整个公司的业绩下降幅度，多下降了12.5%。

因此我们要研究的问题转化为：

1. 为什么整个公司的业绩下降了37.5%？
2. 为什么张三的业绩比公司的业绩下降的更厉害？

要区分“现象”和“原因”，有些“问题”表面看起来是“现象”，实际可能也是某个“现象”的原因。

【案例2】 某一在建项目里程碑延迟一月有余，项目组对现存问题复盘后，总结了若干“问题”，并对这些“问题”排定了优先级，拟对优先级TOP2的两个“问题”进行根因分析。“问题”描述如下：

1）开发测试过程中识别到很多新的需求（如增加鉴权管理，AR报警等），导致研发工作量评估不足，研发工作超期无法完成。

2）某开发小组4月份任务冲突，临时定制、现场技术支持类任务较多，导致主版本研发投入时间占比仅30%左右 ，导致原本应完成的研发任务延期未完成。

对本案例中的两个“问题”进行澄清后，发现其表象问题是同一个：项目进度延期。而导致延期的原因包括但不限于此案例中描述的1）和2）两种原因，现在项目组希望针对这两种“原因”进一步进行原因分析。针对问题1），需要项目组进一步澄清开发测试过程中识别的新的需求有多少，约占总体需求的比例为多少，新增需求识别的时间点是在何时。

2 先拆分问题，再量化问题。

把问题进行整体部分拆分，通过数据刻画事实，找到关键的少数，进一步定位问题。

【案例3】某项目上线后暴露的问题比较多，对所有的问题进行分类汇总发现性能问题最突出，则可以对这部分问题进行原因分析，如图2所示。

 

图2 上线后发现缺陷的类型分布

 上述案例2中提到的问题1），项目组进一步拆分后发现：

• 大部分新增需求（80%以上）是已有需求的细化，是在需求分析阶段没有考虑到的细节，严格来说不算是需求变更。
• “新增”需求60%左右在测试阶段被提出。

所以针对本案例所述问题进行原因分析时，分析的对象转变为：

• 为什么在需求分析阶段没有考虑到需求的细节，而在开发和测试阶段被识别了出来。
• 为什么在测试阶段会提出大量的“新增”需求。

3 先经验分析，再数据验证。

在分析原因时，可以基于经验进行原因分析，画出因果图，然后再通过已有的数据检验假设的正确性。正如我们去看病时，医生先听我们陈述病症，然后大夫根据经验推理我们可能得了什么病，开出化验单，通过化验结果求证其推理的正确性。数据可能证明了假设的正确性，也可能推翻了我们的假设。如果推翻了我们的假设，则可以采用排除法，排除某种原因后再探索其他原因，缩小了原因分析的范围。

【案例4】某公司发现2022年下半年之后事故发生比例大幅提升，比2022年上半年增加了3倍。针对该问题团队做了经验推理：2022年下半年版本上线发版次数太多。然而，实际统计了2022年的上线版本数量，发现下半年上线发版120次，上半年80次，下半年比上半年增加了0.5倍，从数据来看发版次数多并不是造成事故频发的根本原因。 可见数据验证对辅助经验分析的必要性。

上文案例2中，【问题1）开发测试过程中识别到很多新的需求（如增加鉴权管理，AR报警等），导致研发工作量评估不足，研发工作超期无法完成】，项目组在进行原因分析时，从经验上判断认为是产品经理或客户提出了新的需求变更导致， 但对数据分析后发现，大部分新的需求都是已有需求的实现细节，严格意义上其并不属于需求变更，而是设计实现的调整。

4 先技术原因，再管理原因。

在识别原因时，应该先考虑技术上的原因，再考虑管理上的原因，两个维度都要思考原因，采取措施。

比如，如果系统上线失败了，要从技术上去分析，究竟哪些技术问题导致上线失败，从技术上进行修复和预防，同时，也要考虑这些技术问题，通过哪些管理措施可以检查和预防。不要仅仅从技术维度找解决方案，否则可能是治标不治本。

同样，对于某些管理类问题也要思考是否有技术手段进行检测或预防，比如，有的项目组不做代码的静态扫描就直接提交测试人员进行测试，如果从技术上找解决方案，则可以在系统里强制要求进行静态扫描，否则代码就无法提交到配置库中。

有的时候技术与管理措施的区别可能没有那么明显，但这并不妨碍其发挥作用。

5 先广度穷举，再深度挖掘。

原因的挖掘是一个迭代的探索过程，有可能一次分析未必找到真正的原因，需要多次尝试。正如我们去看病，大夫也可能不能一次性找对病根。在识别原因时，可以先对原因的类型进行分类思考，找到每一类可能的原因，比如按照人机料法环来思考各类原因，避免思维盲点，然后再对主要的原因，采用5-whys法深入挖掘根本原因。

【案例5】一家公司的产品出现了质量问题，客户投诉率上升。公司决定进行原因分析以寻找问题的根本原因和解决方案。

首先，公司需要从广度上寻找问题的原因，考虑所有可能的因素和影响因素。公司可以考虑以下因素：

- 供应商是否提供了质量不稳定的原材料？

- 生产设备是否存在故障或质量问题？

- 生产过程中的操作流程是否存在问题？

- 操作人员是否受到充分的培训和监督？

- 是否存在设计或工程方面的问题？

- 是否存在测试或检验程序的问题？

然后，公司需要从深度上寻找问题的根本原因。公司可能会发现：

- 供应商提供的原材料批次不稳定，导致产品质量不稳定，这是主要原因，为什么会出现这个问题呢？

- 因为对长期的供应商没有针对每个批次进行质量测试，为什么呢？。

- 因为检验的成本比较高，如果每个批次都检验，时间成本与金钱成本都比较高，为什么呢？

- 因为检验的方法太落后，没有采用最新的检验设备。

在识别原因时，也可以按照事件发生的流程顺序进行分类思考，从而找到可能的原因。

上文案例2中提到的问题， 项目组针对问题1）分析时首先从需求获取、需求分析、需求描述、需求评审、需求跟踪的流程顺序来逐一分析各环节可能存在的导致问题出现的原因，并用鱼骨图记录其潜在原因，如图3所示。

图3 某项目原因分析的鱼骨图

从广度上找原因有助于发现所有可能的因素，避免遗漏了重要原因，而从深度上找原因则有助于找到问题的根本原因。

6 先体系原因，再个体原因。

上述案例2中的问题2）客户在进行根因分析后反馈给我们的咨询师，最后找到的大部分是人的问题，无法解决。这恰恰反映了进行原因分析时很容易出现的一大误区：找到的问题都归结到个体能力或态度问题上。

识别原因时要建立起对事不对人的文化，怎么做才能对事不对人呢？要识别体系的问题、流程的问题、制度的问题，要找到体系的改进点，而不是追究个人的责任，否则就会形成推诿的文化，每个人都怕被追责，所以在分析原因时就会甩锅。有时出现的问题是人的能力问题，人的能力问题也是体系问题，因为需要通过完善人员能力培养的体系如培训、通过人员能力的互补来弥补人员的能力不足如结对编程、师徒制等。有时出现的问题可能是人的态度问题，此时可以启动行政的奖惩机制，用以解决态度问题。

在找原因时要避免陷入到死循环中，对于在组织范围内确实无法改变的原因，不必纠结于细节。如某企业运维部门对其逃逸缺陷进行原因分析后，发现50%以上缺陷是由于程序错误引起的，而程序错误是研发部门导致，对于运维部门来说非其能力范围能改变，这种情况下不要纠结于如何优化程序，将问题及时反馈给相关部门即可。

7 先反思自己，再改进他人。

在找原因时，通常要让一线的各个作业环节的人员参与进来，为了找到真正的原因，每个环节的人员要先思考本环节的原因与改进点，把其他环节作为前提条件，在这些前提条件下思考本环节的改进措施。当本作业环节的潜力已经挖尽时，再考虑改变外部的前提条件，再去思考其他环节的原因与改进措施。比如当软件系统上线后出了质量事故，开发人员要思考我为什么犯了这个错误，我如何规避此类错误的再次发生；测试人员要思考我为什么没有发现这个错误，以后如何能测试出来此类错误，而不是互相指责，开发抱怨测试不完备，测试抱怨开发犯的错误太多。

8 先近期原因，再远期原因。

先识别离结果时间最近的影响因素，再识别时间较久的影响因素。通常情况下，近期的影响因素对结果影响更大，更容易识别出来，采取的措施更容易见效。

比如有项目上线后缺陷比较多，在识别原因时，可以先识别为什么测试阶段未发现，再识别为什么开发时注入了这么多缺陷。测试活动距离上线活动时间上更近，开发活动距离上线活动时间更久远，最后再识别设计与需求活动的原因。

9 纠错、预防、检测、固化措施四步走。

原因分析后找到的措施分四类：

• • 纠错措施：就事论事地解决出现的问题。比如，血压高了，就吃降压药。
  • 预防措施：预防此类事情的再次发生。比如，平常多锻炼身体，增强免疫力，避免各种疾病的发生。
  • 检测措施：为了及时发现问题所采取的监测手段。比如，每年都要进行体检。
  • 固化措施：把预防措施形成为习惯的措施，比如，定好闹钟，每天早晨6点提醒自己去跑步，去锻炼身体。

识别措施时要把四类措施都识别出来，先解决问题，再预防问题，然后通过检测手段查漏补缺，最后固化为习惯。不能浅尝辄止，一定要找到预防措施，并固化下来。

对于原因要问多个why，以识别其根本原因，对于措施要问5个how to do，以识别可以落地的措施。

10 先简单措施，再复杂措施。

识别出措施后，对措施划分优先级时，要考虑措施实行的难易程度，简单易行的措施应该优先级更高，它们短期内可以见效，可以建立起大家成功的信心。

【案例6】一个软件开发团队在项目中遇到了严重的延期问题。经过原因分析，团队发现问题的根本原因是项目需求变更过于频繁和不充分的需求调研。团队可以首先考虑采取一些简单的措施来解决问题。例如，团队可以加强需求变更的管理，确保变更的需求得到充分的评审和确认，并避免不必要的变更。此外，团队可以加强项目管理和沟通，确保团队成员之间的协作和沟通畅通。这些措施相对简单，容易实施，并且可以在短期内产生效果。

如果简单的措施不能解决问题，团队可以考虑采取更复杂的措施。例如，团队可以采用敏捷开发的方法，以更快的速度响应需求变化，并提高项目的可控性和质量稳定性。此外，团队可以对需求调研的流程进行改进，确保需求的充分性和准确性。这些措施可能需要更高的成本和更长的时间来实施，但可以在长期内产生更有效的效果。

另外，无论简单措施还是复杂措施，都应该明确清晰地定义，即达到可落地的程度，明确什么时间完成、谁负责完成、计划的步骤是什么、达成的标准是什么、需求哪些资源等。应避免原因分析活动开展得虎头蛇尾，进行了大量的原因分析，却并未制定切实可行的纠正措施、预防措施等。

基于上述的十个要点，我设计了如下的记录表格，并举例填写如下：

表1 原因分析的案例

原因分析案例：上线后缺陷比较多
现象描述	上线后缺陷比较多，导致客户满意度下降。
现象的定量刻画	1. 2023年1季度上线了20个版本，比2022年4季度暴露的缺陷密度增加了50%。 2. 客户三次找公司领导抱怨系统的问题。 3.  对缺陷类型做了80-20分布分析，易用性问题的数量超过了30%，是客户抱怨最多的问题，其次是软件的性能问题，超过了20%。
技术	技术原因	1 软件的功能设计不合理，导致软件难用。 2 对于大数据量的处理算法不合理，没有对大数据表进行拆分、数据表的索引设计不合理。
	纠正措施	1 对功能设计重构，减少菜单嵌套层次，减少操作步骤。 2 优化数据库设计与查询算法。
	预防措施	1 在设计指南中增加关于易用性设计、数据库设计的指南。 2 在需求文档中给出非功能性需求的描述案例。 3 对需求人员、开发人员、测试人员进行非功能性需求描述、设计、实现与测试技术的培训。
	检测措施	在设计评审检查单、代码评审检查单及测试用例评审检查单中增加关于非功能性需求的检查项。
	固化措施	1 需求文档、设计文档中非功能性需求章节不允许为空。 2 非功能性需求的测试用例不允许为空。
管理	管理原因	1 在功能设计时忽略了对易用性与性能的设计。 2 在设计评审时，没有评审易用性设计与性能设计。
	纠正措施	记录上线后的问题，并对这些问题跟踪技术纠正措施的关闭情况。
	预防措施	1 修改组织级的设计指南、需求模板、测试用例编写模板、测试报告模板，体现出来非功能性需求的应对。 2  在需求评审、设计评审、测试用例评审中将对非功能性需求的评审列为一个单独的活动。
	检测措施	1 在测试策略与测试计划中单独识别对非功能性需求的测试活动。 2 在确认测试时，必须增加对非功能性需求的测试。
	固化措施	1 QA检查时，增加对非功能性需求的描述、设计、测试的检查项。 2 EPG定期采集在非功能性需求方面的经验教训。