一个不好的提问

最近在和团队一起进行Bug分析，期间经常会听到一句话，如果再来一次，我们该怎么避免这个问题？ 起初，我并没有觉得这句话有什么不对。它是让我们想象一下，如果回到当时的场景，我们该采取哪些措施来避免这个问题的发生，从而找到避免问题在将来再次发生的解决方案。但在分析了几个Bug之后，我发现这个提问并不是一个好提问。

首先，它会把团队引导到低效的解决方案上。所谓低效的解决方案就是头痛医头，脚痛医脚，治标不治本的方案。它的一个特点就是依靠增强动机来避免问题，例如仔细检查、加强沟通、反复确认等，不同的人在执行这种方案时会有较大的差异，且在精力下降时会出现顾此失彼的情况。究其原因，我们会在这个提问的语境下采取错误的问题处理方式。Bug应该是一个known-unknown的问题，我们可以通过分析来找到合适的解决方案。但在这个提问的语境下，我们会在潜意识里认为Bug是一个known-known的问题，通过分类就能找到解决方案。这样我们就很容易为这个Bug单独设置一个类别，从而得到一个只解决该Bug的低效的解决方案。

其次，它会禁锢团队的活力。这个提问会让我们在潜意识里假设问题是完全可以被避免的，我们肯定是哪里做的不对才导致了问题的产生。但是，按照问题的分类，不管我们能力有多强，团队实践有多优秀，总会有一些只有在发生后我们才知道的问题存在。所以，严格来说，我们并不能确定当前问题是不是可以被完全避免，我们需要不断的尝试来理解问题，从而解决问题，一味强调问题不能再次发生会让团队过于谨小慎微，不利于问题的有效解决。

最后，它会增加团队的压力。这个提问会让我们觉得我们应该立即给出解决方案，从而把Bug分析从不紧急变成了紧急，不得不立即进行应对，进而增加了团队的压力。

如何进行Bug分析？

Bug分析的目的是什么？

有的人认为是为了给Bug分类，有的人认为是为了避免Bug的再次出现，而有的人认为是为了提升项目的交付质量，笔者倾向于最后一种说法。给Bug分类，除了做报告好像没什么其他用处。每个Bug基本都是独一无二的，如果只是想避免Bug再次出现，只要解决Bug就好了，不需要做进一步分析。但是，能够解决所有Bug并不能给我们带来好处，因为每个Bug都意味着浪费和损失，真正能给我们带来好处的是避免Bug的产生，第一次就把事情作对，也就是保证高质量的交付。

那么，我们如何通过Bug分析来提高交付质量呢？笔者认为我们通过从Bug分析中得到高效的解决方案来提高交付质量。

什么是高效的解决方案？

高效的解决方案是指通过提升能力或优化流程来解决问题的方案。这里的能力是指团队成员拥有的知识，技能，工具等解决问题的要素。流程是指团队成员之间的合作方式，它可以是一些规则，例如部署流程，分支管理策略等，也可以是一些实践，例如敏捷，Scrum，XP等。它们也可以分别对应到福格行为模型中的能力和提示。

假设我们项目的状态如下

低效的解决方案虽然可以解决当前问题，但可能会遗漏其他问题。

提升团队成员的能力可以避免更多问题

在团队成员能力无法快速提升的情况下，如果我们可以通过优化流程将团队成员的能力有效组织起来，也可以避免更多问题

如何得到高效的解决方案？

要得到高效的解决方案，就要对Bug进行根因分析，但并不是所有根因分析都能得到高效的解决方案，这取决于根因分析的质量。判断根因分析质量高低的一个指标就是我们寻找到的根因是否在能力或流程上，能力或流程上的根因才有可能得到高效的解决方案。

根因分析的重点在于其结构化的根因寻找方法，我们不能因为感觉Bug不严重或解决方案很简单而跳过这个分析过程。如果出于成本考虑，我们无法让所有团队成员都参与每个Bug的根因分析，那么可以让AI帮助我们。

在得到高效的解决方案后，我们可以采用事前验尸法对方案进行进一步检验。这里我们可以把开头的提问修改为，如果再来一次，在我们采取这个解决方案后问题还是发生了，可能是哪些原因导致的？ 任何我们能想到的能力或流程上的原因都可以补充到当前方案中来。

总结

在Bug分析中听到最多的词就是尽力，尽力检查，尽力沟通，尽力提高，尽力完成等，那么到底什么叫尽力？我们该如何衡量它？记得在复盘宣言里有一句话，我们理解并坚信：每个人对自己的工作都已全力以赴。我们与其思考该如何衡量尽力，不如选择相信，相信每位团队成员都已尽最大努力，把Bug分析的重点放在能力和流程上，而不是积极、主动、谨慎等个人动机上。