7、举例，有时候一个现象背后隐藏多个问题，如某个操作反应比较慢，背后隐藏着SQL使用不合理、并发死锁问题、接口调用问题等等，在写回溯时，把这些问题放在一个回溯报告中。结果搞得异常复杂，问题分析不清。
分析:这种情况显然低估了质量回溯的复杂性，一个问题要从需求到交付全部分析清楚，要把相关的关键材料列举清楚，是很复杂的。我们大多数情况下单独分析清楚一个问题都很难，何况这么多问题纠结在一起呢。因此，回溯不要针对一个现象，而且应该针对一个具体的问题。
8、举例:一个问题由于需求分析存在问题，导致某些场景考虑不到，这时，往往会导致需求评审以后的所有控制环节都失效、引入环节也很难弥补前面已经引入的问题。但是，在做质量回溯审核时，往往会get不到这里面的这个关键逻辑，反复的去纠结设计、实现等环节可能存在的问题。最终导致回溯报告成了一个面面俱到的反思文档。
分析:根因分析要找的是问题的根源因素，而不是所有原因，更不是所有原因都要进行改进。根因的确定还要看是否可改进及改进效果等。所以，回溯时应该紧紧围绕根因，抓住重点，不要过分铺开。
9、举例:某个问题影响比较大，问题比较低级，回溯发现主要是相关责任人意识淡泊、疏忽导致的。并对相关责任人进行了惩罚，也建立了一些可以杜绝类似问题发生的制度、规范。但评审人员依然认为达不到要求，具体为什么，也说不清楚。
分析:首先，很大一部分问题是意识不够导致的，但一次问题的处罚对意识的建立起到的作用很小，的确不能从根本上解决意识问题。意识的建立很多要从文化方面着手，建立持续的，真正落地的、明确的奖惩措施。但另一方面，质量工作者也需要注意客观看待回溯过程，在判断回溯是否达到目的是尽可能不受问题严重程度的影响，不带入主观情绪。问题严重程度只是惩罚的主要参考依据。
