头图

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 法则往往也会给我们带来思路,加强我们的思维。

----------------【END】----------------

【公开调研】

后续计划做一些个人职业发展相关的总结输出,想要做个简单的调研,希望大家可以共同参与:https://wj.qq.com/s2/12385427/6f37/

欢迎加我v【longyiyiyu】,进行无负担沟通,我会

  • 长期职业发展规划指导
  • 近期工作重点交流
  • 职场解惑
  • 面试辅导

也欢迎关注公众号【潜龙在渊灬】,收获程序员职场相关经验、提升工作效率和职场效能、结交更多人脉。


潜龙在渊灬
11 声望0 粉丝

多年互联网大厂前端小组长经验;分享程序员职场相关的经验,教你如何提升工作效率和职场效能。无论编程开发或者团队管理,都欢迎加v: longyiyiyu 交流,也欢迎关注公宗号: 潜龙在渊灬