- 程度顺序：某公司存在的最严重的3个问题。
时间顺序
====
时间顺序，是最容易理解的逻辑顺序，也是使用最广泛的思想分组。在要按照采取行动的顺序（第一步、第二步、第三步…）依次表达达到某一结果必须采取的行动。
例如，你准备负责一个线下活动的安排，那么就可以考虑按照时间顺序，从活动前、活动中、活动后这种流程的思考方式入手，梳理每个流程中能做什么事，并将之拆解为可执行的细节。这种有思考方向有条理的思维方式能让你更有效率地解决工作上遇到的难题。
空间顺序
====
空间顺序，是一种化整为零的分解，比如对公司组成部门和地理位置的分解。再将整某个整体（不论是客观存在的还是概念性的整体）划分为不同的部分时，你必须保证划分后的各部分符合以下要求：
-
各部分之间相互独立（mutually exclusive），没有重叠，有排他性。
-
所有部分完全穷尽（collectively exhaustive），没有遗漏。
这两个要求简称是MECE原则。
例如，我们要对衣服进行分类，如果按照季节和风格进行分类，就会出现互相重叠，并且不能穷尽的情况，也就不满足MECE。这种分类是逻辑混乱的。
我们可以按季节分：春秋装，冬装，夏装。除了这3类之外，没有其他季节了，这个就是穷举不遗漏，彼此之前又相互独立没有交叉。
程度顺序
====
程度顺序，也称为重要性顺序。是你对一组因为具有某种共同特点而被聚集在一起的事务所采用的顺序。如：3个问题，3个原因，3个因素等。在为事物分组时，你可能会说：“这家公司存在3个问题。” 这时，你的大脑自动将这个3个问题和其它问题 隔开。也就是说，这个3个问题是你认为这个公司最严重、最迫切需要解决的问题，于此同时，公司可能还存在很多其它的问题，你只挑选这3个，是因为这3个最重要。在排序的时候，最好是先重要后次要（first thing first），先强后弱。
实际上，我们大脑能进行的逻辑分析活动只有4种，演绎（演绎推理）、归纳（发现因果关系）、分析（化整为零）和综合（总结概括）。比如我说电脑是有显示器、主板、硬盘、显卡等组成的是合乎“化整为零”逻辑的。我说苹果、鸡蛋都是水果，是不合乎“归纳”逻辑的。苹果和鸡蛋不是一个类别的，不是一个范畴的东西。 逻辑是我们构建结构的底层基础，缺少逻辑的结构是经不起推敲的。明晰了结构中的逻辑关系之后，是时候该搭建结构，利用结构化思维解决问题的时候了。
如何构建结构
======
我们在解决问题的时候，一般有两种方法：一种是从目标出发沿着不同的路径分解，探求问题的答案；另一种是把各种信息聚合起来，得出一个正确结论或解决方案。这两种方法也是我们构建金字塔结构时仅有的两种方法：一是自上而下的搭建金字塔结构，即问题分解，也叫疑问回答分解；二是自下而上搭建金字塔结构，即概括总结做聚合。
自上而下
====
当我们明确知道要解决的问题是什么的时候，可以考虑自下而上的方式，对问题进行拆解。比如你要去准备竞聘，这是一个非常的明确的目标，就比较合适做自上而下的分解。
2W1H法
=====
对于写一篇有明确主题的文章也是一样。比如前段时间，阿里技术协会的同学邀请我写一篇教技术同学“如何写好技术文章”的文章。对于这样的命题作文，我们就可以通过自上而下的方式对问题进行拆解，对于大部分的技术文章，我们都可以通过What（是什么），Why（为什么），How（怎么做）来构建结构，也就是2W1H。2W1H是构建结构最常用，也是最有用的框架之一，因为它涉及到一个问题的最核心的3个要素。
有了2W1H这个思考框架，我对“如何写好技术文章”进行了自上而下的结构搭建，接下来，写出这篇元技能文章，也就不是什么难事了：
-
为什么写文章：1）写文章是费曼学习法。2）写文章可以增加影响力。
-
什么是好文章：1）内容有价值。2）结构要清晰。
-
如何写好文章：1）选择好内容。2）搭建清晰的结构。3）刻意练习。4）迭代优化。 2
W1H实际上是对5W2H（Why、Who、When、Where、What、How和How much）的简化和提炼，如果需要更加全面的思考，我们需要尽量满足MECE法则，此时，5W2H可能是更好的选择。
5Why分析法
=======
另外，我们还可以用“疑问解答”的方式来自上而下的构建我们的结构，这样做的好处是，一方面可以通过设置悬念抓住听者的注意力，另一方面这种不断问“为什么？”的方式，也是在帮助我们更加深入的理解问题，让我们的论证更加有说服力。
比如你要给大家分享“猪应当被当作宠物来养”，听众肯定会很疑惑“为什么猪可以当宠物呢？”，你接着说“猪很漂亮，所以可以当宠物”，这回答了前面的疑问，当又引发了大家新的疑问：“猪怎么能漂亮呢？”，然后你说“猪很肥”，大家的疑问更大了：“肥为什么还漂亮呢？” 这样一步一步往下走，紧扣着听众的好奇心，这种先抛结论的倒序方式，通过提出疑问——回答疑问的悬念方式自然是非常有吸引力的，于此同时，因为你对对方关心的问题进行了一个一个的解答，其说服力也会比较高。
实际上，对于大部分的问题，如果你能连续追问5个why（为什么），一般都能触及问题的本质，所以这种通过疑问——解答的方式自上而下的构建结构，不仅是一种构建结构的方法，也是一种发现问题根源的强大武器——5why分析法。
例如，丰田汽车公司前副社长大野耐一曾举了一个通过5why分析法来找出停机的真正原因。
-
问题一：为什么机器停了？ 答案一：因为机器超载，保险丝烧断了。
-
问题二：为什么机器会超载？ 答案二：因为轴承的润滑不足。
-
问题三：为什么轴承会润滑不足？ 答案三：因为润滑帮浦失灵了。
-
问题四：为什么润滑帮浦会失灵？ 答案四：因为它的轮轴耗损了。
-
问题五：为什么润滑帮浦的轮轴会耗损？ 答案五：因为杂质跑到里面去了。
经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑帮浦上加装滤网。 如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。
自下而上
====
有些时候，我们要解决的问题并没有那么明确，或者面对的是一堆零散的元素，比如我们在头脑风暴的时候，产出了很多想法，我们要如何整理这些想法，此时，我们要如何构建清晰的结构呢？
试想这样一个场景，假如客户最近对销售报告和库存报告很不满意，需要你去调查一下原因。
你是一个执行力很强的人，接到任务后，很快开始展开信息收集工作，通过客户访谈，产品调研，很快找到了一堆客户不满意的原因：
-
提交报告的周期不恰当；
-
库存数据不可靠；
-
获得库存数据的时间太迟；
-
库存数据与销售数据不吻合；
-
客户希望能改进报告的格式；
-
客户希望除去无意义的数据；
-
客户希望突出说明特殊情况；
-
客户希望减少手工计算。
面对这一堆信息，你千万不要急着打报告交差，因为这些信息是零散的，老板没有那么多时间去逐条理解，这些信息的罗列，让人摸不着头脑，抓不住重点，也理不清头绪，也不能做决策。
那如何才能让报告更清晰、更容易理解呢？我们可以用结构化思维，对同类信息，进行归纳分组，向上聚合形成一个金字塔的结构。分组的逻辑是要找到共性，比如“周期不恰当”和“时间太迟”都是报告产生的时机不好，可以归为一类。
通过逐条分析原因，我们可以将8个问题概括为3组：
-
时机不好：产生报告的时间太晚，无法采取有效措施。
-
数据质量不好：报告中含有不可靠的数据；
-
格式不对：报告的格式混乱； 进行分组之后，我们就可以得到如下的金字塔结构： 这种结构化的表达，很明显让问题的表述更加清晰。领导也可以很快抓住问题的要点，并作出相应的决策。
代码晦涩难懂，很多时候也是源于“没有结构”的混乱，长方法之所以是典型的代码坏味道，正是因为它把过多的信息放在了一起，前面说过了，我们人类的大脑不是CPU，一次容不下过多的概念，我们构建结构的目的就是为了更加清晰的表达，减轻大脑负担。这和我们如此强调代码可读性的要求是一致的。
商品是电商系统中最重要、也是最复杂的业务之一。在发布商品的时候，我们需要组装offer（商品）的各种参数，因为offer需要的信息特别多，导致组装offer的代码也特别长。随着时间的推移，还不断有新的信息在往这个方法中添加。如果把这个代码类比成文章，这是一篇没有章节、没有段落的文章，其可读性和可维护性可想而知。
public Offer assembleOffer(Context context){
Offer offer = new Offer();
// 1. 核心商品信息
MyCspu myCspu = context.getMyCspu();
MySpu mySpu = context.getMySpu();
SupplierItem supplierItem = context.getNormalItemAggregateRoot().getSupplierItem();
ProductAttributeParam productAttributeParam = new ProductAttributeParam();
try {
List productAttrList = OfferPostBiz.buildAttributeParamList(myCspu,
supplierItem.getCargoNumber());
productAttributeParam.setAttributes(productAttrList);
} catch (ArrayIndexOutOfBoundsException ex) {
throw new ServiceException(“CSPU_CHECK_ERROR”,
“Sku规格属性不一致，请检查sku规格数据. [id:” + supplierItem.getId() + “]”);
}
offer.setProductAttributeParam(productAttributeParam);
// 2. 产品属性信息
DescParam descParam = new DescParam();
// offer标题
descParam.setSubject(myCspu.getTitle());
// offer图片
if (CollectionUtils.isNotEmpty(myCspu.getImgList())) {
List cspuImgUrl = Lists.newArrayList();
for (String img : myCspu.getImgList()) {
cspuImgUrl.add(serverImgUrl + img);
}
PictureParam pictureParam = new PictureParam();
pictureParam.setPictures(cspuImgUrl);
descParam.setPictureParam(pictureParam);
}
// offer详情
DetailParam detailParam = new DetailParam();
String detailDesc = null;
if (!StringUtil.isEmpty(myCspu.getBigTextUrl())) {
detailDesc = bigTextBiz.get(myCspu.getBigTextUrl());
}
//…此处省略一万字
return offer;
}
面对这些零散的“素材”，我们有必要对其进行归纳整理，构建一个更加清晰的结构。通过简单归纳，我们不难发现商品信息主要包括商品核心信息、商品描述信息、产品属性信息、销售属性信息、系统属性信息、商品扩展信息等。其中，扩展信息又可以进一步拆分成产品信息扩展（比如，是否进口）、销售信息扩展（比如，销售单位规格）、供应链信息扩展（比如，仓库类型）等等。形成一个如下的结构：
public Offer assembleOffer(){
Offer offer = new Offer();
// 1. 核心商品信息
assembleCoreInfo(offer);
// 2. 产品属性信息
assembleProductInfo(offer);
// 3. 商品描述信息
assembleOfferDescInfo(offer);
// 4. 商品销售信息
assembleOfferSaleInfo(offer);
// 5. 商品系统属性
assembleOfferSysInfo(offer);
// 6. 商品扩展属性
assembleOfferExtInfo(offer);
return offer;
}
private void assembleOfferExtInfo(Offer offer) {
// 6.1. 产品扩展信息
assembleProductExtInfo(offer);
// 6.2. 销售扩展信息
assembleSaleExtInfo(offer);
// 6.3. 供应链扩展信息
assembleSupplyChainExtInfo(offer);
}
同样的业务逻辑，对比两种不同的实现方式，不难看出结构在里面起到的重要作用。
上下结合
====
自上而下的分解，自下而上的归纳，二者不是你有我无的关系。更多的时候，是两个方法都会用到，构建结构的过程，不是一次性的从上到下，也不是一次性的从下往上，而是上上下下，来来回回，反复修改，反复优化的过程。
了解我的人都知道，我一直在致力于控制软件复杂度，写过一篇文章——一文教会你如何写复杂业务代码，文章的核心思想就是提出了通过自上而下的结构化分解+自下而上的抽象建模，通过上下结合来治理复杂业务的方法论。实际上，这就是典型的结构化思维，是演绎法和归纳法的完美结合。天下的道理都是相通的，结构化思维本来是教人清晰表达、写作的，然而同样的道理在软件设计和代码实现中，同样适用。
自上而下的分解可以帮助我们更好的理清业务逻辑，更清晰的表达业务过程，这种分解非常有必要，只是太面向过程了，导致代码的复用、扩展和语义表达能力偏弱；因此，我们还需要自下而上的抽象建模，帮助我们提升代码的复用性、扩展性和业务语义表达能力。
我记得有一次在分享的时候，有一个同学问我：“分解必须是自上而下，建模必须是自下而上的吗？” 当然不是，在分解之前，我们可能已经初步构建了模型，同样，在建模的同时，我们也可以同步实施业务过程分解。这两个步骤是相辅相成的，是螺旋式上升的过程。步骤可以交替进行、也可以同时进行。随着我们对问题域理解的更加深入，我们很有可能在某个时间点，重构我们的结构和模型。分开介绍自上而下和自下而上的方法，是为了说明演绎思维和归纳思维的区别，至于在使用的时候，通常都是上下结合一起使用的。
更多有用的结构
=======
通过前面的介绍，我相信你在学习结构化思维的同时，应该也感受到了思维框架在结构化中的作用，比如2W1H就是非常有用的框架，因为它涉及到大部分问题的本质——“是什么”，“为什么”，“如何做”。
5W2H也是解决一般问题非常有用的思维框架，5W2H分别代表Why、Who、When、Where、What、How和How much，很多问题都可以拆解成这7个要素，如果你知晓这个结构，在分析问题的时候，就比不知道这个结构的人要更加全面和体系化。知晓框架的好处是，别人的难题，只是你的“填空题”，别人在感叹你思考为什么如此全面的时候，你会心一笑，这只不过是一个“套路”。
举个例子，最近系统不稳定，连续出现了一些比较严重的P1故障，老板让你组织开一个全员大会，提升大家的质量意识。你准备发出一个会议通知：
为了提升质量意识，召集大家在10月22日下午3点在3号楼205培训室召开全员大会。会议议程是首先复盘一下最近故障出现的原因，然后制定策略防止类似故障再次出现。目标是为了在下半年不再出现P1故障，确保线上系统稳定性。
然而，这个内容不够清晰，更好的做法是可以使用5W2H对内容进行结构化的表达：
-
目的：提升全员质量意识。
-
目标：下半年不再出现P1故障。
-
时间：10月22日下午3点。
-
地点：3号楼205。
-
议程：1）故障复盘。2）制定故障防控策略。
-
对比两个会议通知，不难发现，5W2H的结构让我们的表达更有条理，更加清晰。
幸运的是，针对不同的问题场景，前人们已经总结出很多解决特定问题的结构框架，我们不用绞尽脑汁地去寻找分析问题的角度，拿来即用即可，比如：
-
制定市场营销策略的“4P”模型：即产品策略（Product Strategy）、价格策略（Price Strategy）、渠道策略（Place Strategy）、促销策略（Promotion Strategy）。
-
思考组织战略的“7S”模型：即经营策略（Strategy）、组织结构（Structure）、运营系统（System）、经营风格（Style）、职员（Staff）、组织技能（Skill）和共享价值观（Shared value）。
读者福利
更多笔记分享
）制定故障防控策略。
- 对比两个会议通知，不难发现，5W2H的结构让我们的表达更有条理，更加清晰。
幸运的是，针对不同的问题场景，前人们已经总结出很多解决特定问题的结构框架，我们不用绞尽脑汁地去寻找分析问题的角度，拿来即用即可，比如：
-
制定市场营销策略的“4P”模型：即产品策略（Product Strategy）、价格策略（Price Strategy）、渠道策略（Place Strategy）、促销策略（Promotion Strategy）。
-
思考组织战略的“7S”模型：即经营策略（Strategy）、组织结构（Structure）、运营系统（System）、经营风格（Style）、职员（Staff）、组织技能（Skill）和共享价值观（Shared value）。
读者福利
[外链图片转存中…(img-WPo3lfmb-1720124164916)]
更多笔记分享
[外链图片转存中…(img-yXvofR8y-1720124164916)]
扫一扫
988
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
