《程序员职场工具库》你的分析是否错漏百出 —— MECE 法则

MECE 法则是 Mutually Exclusive Collectively Exhaustive 的首字母缩写词，中文意思是：相互独立、完全穷尽。说人话，应该是 无重复、无遗漏 的意思。

MECE 法则主要的应用场景是分类。在思维导图工具的开篇文章中提到过，我们的思维方式主要分为 2 种：分类&梳理 和 发散&联想。因此，在我们的日常工作中，分类的场景是非常多的。举几个简单的例子：

• 工作拆解：把复杂的工作任务拆解成多个原子工作项。
• 代码模块化：把复杂的代码划分模块，让代码更容易维护。
• 问题分析：造成一个复杂问题的原因会有很多，要进行归类分析。
• 优化分析：把一个复杂的优化任务进行合理的划分，找到关键点或者每个局部进行优化，比如首屏加载优化。

我们在做这些分类的工作或者分析的时候，需要遵循 MECE 法则：无重复、无遗漏。

• 无重复：我们拆分的同一维度的各部分之间，是相互独立、没有重复的。如果我们在做工作拆解的时候，2 个任务有重复的地方，那我们分别评估时间，那重复的地方就评了 2 份工时了。如果我们在做代码的模块划分的时候，2 个模块还有重复的代码，那肯定是有问题，为什么不把重复的代码再抽离成一个模块呢？
• 无遗漏：我们拆分的同一维度的各部分之间，是完全穷尽、无遗漏的。这是显而易见的，遗漏就代表了功能缺失，分析不完全，肯定是有问题的。

MECE 法则还有助于我们做 review，比如工作评估 review，code review 等，要思考是否遵循MECE 法则，可以帮助我们检测是否有重复的错误和遗漏的不完美。

在我的实践经验中，最常用的 MECE 分类方法有以下 2 种：

• 流程法：按照事物发展的时间、流程来进行拆解。比如研发流程、页面加载流程等等。
• 要素法：按照事物由哪些要素组成来进行拆解。比如，研发团队主要有前端、后端、测试；某个服务由哪些模块组成等等。

假设我们做了一个持续 2 个月的大需求，期间出现了许多问题，在上线之后，我们进行需求复盘。

这个虽说也是遵循 MECE 法则的，但是感觉太简单了。我们按照需求的生命周期来分析会更好。

然后，我们再针对每一个流程阶段进一步分析问题：

比如，在需求评审阶段，我们进一步按照参与的角色来进行划分。可以看到这里的每一层都是独立的，并且都遵循 MECE 法则。

最后复盘结束，我们也可以按照 MECE 法则来进行 review，看下我们的复盘是否存在遗漏。比如在需求评审阶段，还有哪些角色参与？对了，还有 PM，PM 这里就不存在问题吗？有哪些是 PM 可以改进的？

最后做个简单的小结，在我们做一些分类或拆解的工作时，需要遵循 MECE 法则，有没有重复的地方？有没有遗漏的地方？在 review 别人的方案时，检查是否遵循 MECE 法则往往也会给我们带来思路，加强我们的思维。