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】,进行无负担沟通,我会
- 长期职业发展规划指导
- 近期工作重点交流
- 职场解惑
- 面试辅导
也欢迎关注公众号【潜龙在渊灬】,收获程序员职场相关经验、提升工作效率和职场效能、结交更多人脉。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。