编辑导语：MECE分析法也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类；而且能够借此有效把握问题的核心，并成为有效解决问题的方法；本文作者方向了关于MECE的解释与分享，我们一起来看一下。

几乎所有数据分析的书、教程、文章，都很政治正确写上MECE作为数据分析的准则。

这东西很快又成为一个数据领域的“咕咚来了”：

• 到底啥是MECE？
• 为啥非得MECE？
• 我做的是不是MECE？

一大堆问号没人回答，今天我们系统讲解一下。

一、什么是MECE

MECE，是Mutually Exclusive Collectively Exhaustive的缩写，简单归纳成8个字：相互独立，完全穷尽；听起来就很厉害呀，如果能完全穷尽，那分析肯定是无懈可击。

问题是：怎么做到呢？来个最直观的例子：

问题场景：项目组的张雨萱小妹纸又迟到了！上个月居然迟到了19天！原本同事们迟到个两三天，HR是不会管的，可这一个月19天迟到也太夸张了，于是告到领导那里。

妹纸哭得梨花带雨地来投诉：

• 那项目组好多人都迟到呀，你们也不管；
• 那遇到下大雨全程堵车呀，你们又不管；
• 那临近项目上线，就是搞到很晚呀；
• 那前一天加班了，就是会到的晚呀……

问：该咋分析实际情况？

二、不用MECE的恶果

新手数据分析师，马上拿个笔在这列清单：

• 迟到原因1：堵车
• 迟到原因2：下雨
• 迟到原因3：项目上线
• 迟到原因4：加班
• 迟到原因5：自己懒
• 迟到原因6：其他

这么干的话，他们很快会发现：各种原因是交织在一起的！下雨了又自然会堵车，加班和项目上线也是经常重叠的，懒和所有问题是重叠的；然后又有可能既下雨又加班又很懒……根本扯不清到底影响多少，即使都扯清了，还有个其他在等着呢。

于是又情不自禁的想要百度《多因素独立检验模型如何构建》，或者去微信群问“有没有头腾阿公司的HR分析大佬，急，在线等！”了。

这就是没有用MECE法则拆解问题的坏处：数据分析毫无逻辑，变成了单纯的拉交叉表；实际上很多新人就是这么干的，遇到问题，把渠道、时间、产品、用户等维度拉出来，和问题指标一一交叉，交叉完看到哪个柱子低了：就它了！最后被人质问：多种原因交织的时候怎么区分？就回答不上来了。

三、MECE如何操作

1. MECE第一步：确定目标

注意，现实中就是一个问题多个因素缠绕在一起的，因此到底怎么把问题归类，首先取决于决策的目标：想赶尽杀绝还是可以放人一马；比如眼前的问题，首先要做的是分清楚：到底是想怼妹纸，还是帮妹纸。

• 怼人：严格要求，只要参合一点个人因素，就是你的问题！
• 帮人：宽松要求，只要发现能用外因解释，就不会归罪个人。

明确了目标，就能在多因素混杂的时候把握好尺度，从而避免思路跑偏，直扑核心问题。

2. MECE第二步：分步骤梳理问题

注意，相互独立，完全穷尽，是MECE操作完的最终结果；并不是要求一步到底，一下就能穷尽所有原因。

在每一层原因分解的时候，用二分法才是最便捷的实现相互独立，完全穷尽的要求，因此分析问题的逻辑层次可以很多，但每一层用的指标尽量少，切分的清晰一点。

比如，如果定了：帮人，看看是不是真的工作量太多，这个大目标；那么分解问题的时候，第一层可以切：加班/未加班；这是一个二分类，肯定是独立+穷尽了；然后把所有前一日有加班记录的日期，都标为：有加班（如下图）。

第二层，可以把大家集体加班，还是只有一个人加班区分出来；这又是个二分类，在这一层还是独立+穷尽哦（如下图）。

第三层，自己加班，也有可能是工作量太大引起的，所以这一层可以再分解（如下图）。

注意：分析的最终目的是能指导业务改善，因此分析逻辑应指向业务可以落地的地方；比如这一条逻辑的拆解，是完全没有考虑天气问题的。

因为工作量多少，是领导可以安排的；法不责众，是领导可以接受的；在业务能动性范围内讨论的时候，尽量不要扯业务不能控制的因素，这样能直接导向一个有用的业务结论；而不是一上来就扯天气，最后结论是：“请领导学习如何呼风唤雨的魔法”——这样铁定被批。

类似地，在分解第二逻辑分支的时候，既然大目标已经定了：要帮人；就可以用“下雨了，全城堵车”之类的理由来开脱。

注意，这里又有个小技巧：选择切入维度，选可量化的维度。

比如下雨“下雨了，全城堵车”听起来是个好理由，但是：

• 如何量化下雨？
• 小雨、大雨、暴雨？
• 小雨也堵车？
• 堵车就一定迟到？

这些都很难量化清楚，所以可以换个更简单的量化方法；“下雨了，全城堵车”指向的结果是：“大家都会迟到”；那就直接看“大家是否都迟到了”就好了（如下图）。

3. MECE第三步：代入数据量化

做数据分析，不谈数据就是耍流氓，定好分类逻辑以后，就得按逻辑填入数据，最后数据说话。

脱离计量谈毒性就是耍流氓，因此代入数据后，首先得看各类型问题的占比；问题比例本身就能很大程度上说明问题。这也是用MECE法拆解问题的最大优势：避免被个例子带歪，大家看着数说话（如下图）。

4. MECE第四步：导出业务结论

最后，可以导出业务结论了。业务结论包含两个方面：

• 来自整体结构的判断，小妹纸到底是主观懒，还是客观原因多。
• 对每一个细化问题点的小结论，到底要辅导工作，还是简单放过去。

做完了推断，还能直接设定观察指标，持续观察问题走势。

观察包括：

• 数量变化：是不是迟到天数减少了。
• 结构变化：是不是因为客观原因的天数减少了。
• 细化问题点变化：因为工作分配导致加班天数，是不是在消减工作量后减少了。

这样分析逻辑+业务行动+数据跟踪，就能很清晰的看到是否在数据指导下解决了问题，从而达到良好的数据驱动的作用。

四、阻碍MECE发挥作用的障碍

对数据分析师而言，最大的障碍来自：不懂业务，不会沟通业务，不会推动业务；把数据分析当写作业，反正数据库里有这几个现成的维度，我把所有的对比都做出来，哪个低了就说哪个有问题好了。

对业务方而言，最大的障碍来自：特立独行，不看数据；逮住几个个案讲的头头是道，怎么用数据量化，怎么用数据考核，一概不谈；要么干脆不动动上升到态度层面，更没法量化考核了。

数据分析的优势，正是能够对抗业务发展中个案、情绪所带来的判断失误；因此认真梳理业务逻辑，清晰目标，逐级推导直到落地监控，才是拨云见日的好办法。

当然，看完以后，有同学会说：能举个运营的例子不？下一篇见。

#专栏作家#

接地气的陈老师，微信公众号：接地气学堂，人人都是产品经理专栏作家。资深咨询顾问，在互联网，金融，快消，零售，耐用，美容等15个行业有丰富数据相关经验。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。