iSpiik产品说：MECE法则在产品设计中的应用

【MECE原则】

MECE原则，即Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。这是麦肯锡咨询顾问巴巴拉·明托在《金字塔原理》中提出的一个重要原则。

【MECE原则的应用场景】

MECE原则可以应用在多个场景中，如切分一个群体或市场时，保证切分的标准不重复、不遗漏；在安排工作时，可以通过MECE原则对工作进行分类，如重要紧急、重要不紧急、不重要但紧急、不重要也不紧急等。

【MECE原则的具体实施方法】

实施MECE原则的方法主要包括两种：

一是在确立问题的时候，通过类似鱼骨图的方法，在确立主要问题的基础上，再逐个往下层层分解，直至所有的疑问都找到，通过问题的层层分解，可以分析出关键问题和初步的解决问题的思路；

二是结合头脑风暴法找到主要问题，然后在不考虑现有资源的限制基础上，考虑解决该问题的所有可能方法，在这个过程中，要特别注意多种方法的结合有可能是个新的解决方法，然后再往下分析，每种解决方法所需要的各种资源，并通过分析比较，从上述多种方案中找到目前状况下最现实最令人满意的答案。

【为了生动，先分享过往的实战案例一则】：

2023年在某次库存管理链路优化的迭代中，在ERP对商品入库节点增加了A信息校验，并且支持在特定情况下自动创建B数据信息，帮助库存的正常入库，使得业务不会因为库存数据入库失败导致的后续系统操作阻断。

基于团队集体共识，也就是大家的知识图谱最大边界，识别判断出来调用范围如下：a、b、c外部系统，系统内部1、2、3点，随即coding，test，preproduct，上线发布。

结果第二天下午，突然接到服务台的反馈，全国零散出现书店门店库存查询故障，导致零售系统无法下单、盘点系统也无法正常使用。

上述是对零售现场的影响，最为直接。关联的还有周边多系统受到关联影响，比如订单中心。一时间无人能定位到原因，只能119式救急救火，结果反反复复，下午频现流量高峰。据说开发者当天晚上搞到10点多终于找到根因解决。

次日早上开发leader跑到工位和我摆根因，回忆说昨天是因为另外同事无意提到新门店开业的业务场景可能会有大量数据操作，随即展开了排查，果真是那个场景导致。而关联的就是前面上线的功能，原来在根因的业务场景中也使用到了新功能的数据逻辑判断，而那里的查询逻辑导致巨量数据查询，直接造成流量高峰，数据拥堵，几近拉跨库存中心数据库。

消防事件后，从个人角度总结几点：（如何有效规避由于信息不对称导致的质量问题？）

【文档沉淀、知识管理很重要】

根因业务场景存在对于**信息的查询调用，这个是在目之所及的文档上没有任何痕迹的，团队知识图谱里面、以我当时在团队2年多的时长，竟然无人提及过的。知识丢失，导致前期范围识别的缺失；

【摸底排查必须有】

产品设计过程、coding过程中，测试用例设计过程中，也许就是个不能再普通的ctrl+f，但它的意义和战略地位却是非常有必要的。大胆的使用计算机的能力进行逻辑点自查，辅助产品、开发者、测试者信息的获取和识别；

【feature生命周期管理】

总有一些feature具有自己历史约束条件下的使命，完成使命之后，就毫无意义。产品经理也好、开发者也好，对自己的产品规划、代码规划，都需要做好必要的生命周期管理，描述清楚产生的环境约束是什么？当下承担的使命是什么？演进和消亡的条件又是什么？过渡承接取而代之的又是什么？

【把MECE带到思考的方式里】

完全独立，互不相关，多么美妙的划分啊！这座灯塔的指引下，构建自己的信息框架、思维框架，支撑具象的产品和feature以及日常的功能优化。虽然很难，但这也是指导的原则，将意识贯穿到团队成员的思维和日常工作才是可以落地的抓手，最终为改善和保障质量服务。