我们经常说软件开发中，没有银弹。的确，单看软件领域，很少有什么方法论是普适的。然而再拔高一些，跳出软件的范畴，是有一些东西是普世的，比如老子说的“道”。

好吧，“道”说的有点大。不过，最近我的确有一个新发现——我发现“归类分组”在我们解决问题中起着巨大的作用。而这里的“问题”不仅仅限于软件设计，从日常生活、产品设计到公司战略、生物分类。都有它的身影。

这是为什么呢？究其原因可能有两个：

一、归类分组是抽象的重要方法，解决复杂问题我们离不开抽象。

二、归类分组是结构化的重要步骤，结构化的表达离不开归类分组。

当然，归类分组要先有素材可以“归类”才行。因此，完整的方法论是这样的，我给他起了一个好听的名字——解决问题黄金三步：定义问题——分解问题——归类分组。

这三步的详细操作如下：

    第一步，定义问题：也就是要清楚我们要解决的问题是什么？
    第二步，分解问题：对问题进行分析拆解，形成平铺的多个子问题，此步可以尽量发散。
    第三步，归类分组：对子问题进行归纳、剪枝，将趋同的子问题，合并成一类问题。

image.png

如上图所示，通过黄金三步以后，我们就可以得到一个形同“金字塔”的结构，也就是我们经常说的金字塔结构。根据问题的复杂程度，这个金字塔结构可能是三层，也可能是二层和多层。

看似简单的三步操作会有那么大的作用吗？废话不多说，直接上案例。
在日常生活中的运用

你出门买报纸，你老婆说家里冰箱空了，顺便带点东西回来吧。她给你列了一个清单，里面有葡萄，橘子，咸鸭蛋，土豆，鸡蛋。你说就这么多了吗？她说苹果和胡萝卜也可以买一点。当你准备出门的时候，她说家里的牛奶和酸奶也没有了，最好也买一点回来。

你觉得你能把老婆交代的东西都买齐吗？我看很难，因为我们的大脑短期记忆无法一次容纳7个以上的记忆项目，超过5个时，我们就会开始将不同的项目归类到不同的逻辑范畴，以便于记忆。

如果我们将葡萄，橘子，牛奶，咸鸭蛋，土豆，鸡蛋、胡萝、苹果，酸奶。按照逻辑关系，进行下归类分组，比如把葡萄、橘子、苹果归为水果类，把土豆、胡萝卜归为蔬菜类，便可以大大帮助我们提高记忆效率。

注意，这里分类的作用不只是将一组9个概念，分成每组各有4个、3个和2个概念的3组概念，因为这样还是9个概念，你所要做的是提高一个抽象层次，将大脑需要处理的9个项目变成3个项目。

如果你已经这么做了，恭喜你，你已经在实践黄金三步了：

    定义问题：冰箱空了，需要购买补给。
    分解问题：你要分析购买哪些东西呢？
    归类分组：为了方便记忆，你将要买的9个东西按性质分成了三组，形成如下的金字塔结构。

image.png

这就是结构化思维，下次你再接到老婆这样的“需求”，记得把这个方法论用上，她一定会对你刮目相看。
在工作汇报中的运用
定义问题

“小张，客户对销售报告和库存报告不满意，你去看一下什么原因。” 面对这种典型的工作问题，你打算怎么处理呢？
分解问题

首先，你肯定要去调研客户不满意的原因，经过调查你发现，客户不满意主要有以下原因造成的：

    提交报告的周期不恰当；
    库存数据不可靠；
    获得库存数据的时间太迟；
    库存数据与销售数据不吻合；
    客户希望能改进报告的格式；
    客户希望除去无意义的数据；
    客户希望突出说明特殊情况；
    客户希望减少手工计算。

虽然你做了大量的工作，调查也很充分。但是，如果你要是把这8个原因直接给老板汇报，估计效果不会太好。 你可以自己做个试验，仔细阅读上面的列表3分钟，你能从中获得什么？同样的，你老板看到这样的罗列也会是一脸懵逼，不知道重点在哪。
归类分组

所以我们有必要加上第三步，对问题进行进一步的归类分组，我们可以将8个问题概括为3组：

    报告中含有不可靠的数据；
    报告的格式混乱；
    产生报告的时间太晚，无法采取有效措施

进行分组之后，我们就可以得到如下的金字塔结构：
image.png

这种结构化的表达，很明显让问题的表述更加清晰。领导也可以很快抓住问题的要点，并作出相应的决策。当然，这里是为了着重介绍归类分组，真正的汇报你还要提供对应的解决方案，然后让老板做“选择题”。
在写代码时的运用

你遇到一个相当复杂的业务场景，在这个业务操作中，涉及到大量的校验和执行操作。这种代码，如果没有一定的策略，很容易写成大泥球。
定义问题

例如，在我们的业务中有一个商品上架的操作，是一个非常复杂的业务操作。
分解问题

对这种业务问题的分解，通常是产品经理的职责，但是作为工程师也不能完全依赖PRD。因为产品视角和工程视角还是有差别的。

针对“商品上架”，我们做了如下的功能分解：
image.png
归类分组

同样，在分解之后，我们需要有一个归类分组的过程。否则，这些步骤的平铺会让代码显得凌乱，不方便记忆和维护。通过分析，我们可以把分解后的步骤分成三个阶段：

    初始化阶段
    校验阶段
    执行阶段

通过黄金三步，我们可以得到如下的金字塔结构：
image.png

最后，我们按照这个结构去组织我们的代码，整个代码结构会更加清晰，代码的可维护性也会好很多。
image.png
在应用架构中的运用

应用架构主要解决的是模块、组件定义和模块、组件关系的问题。
image.png

从宏观层面来说，架构设计也是遵循这三个步骤的。比如，我们的架构要如何分层，分模块、分组件就是在做问题分解。然后，模块和组件要归属在哪个层次，要如何命名，就是在做抽象，在做分类归组。

在综合考虑功能属性+质量属性，然后通过黄金三步，就能得到我们想要的架构设计。例如，我们的COLA 2.0架构也是在这个方法论的指导下完成的。

image.png
在产品架构中的运用
定义问题

“小张，为了做新零售，我们打算做一款智能互联网POS机，你先做一下产品设计。”
分解问题

通过调研你发现，作为POS机，其核心功能是收银和经营管理。所以至少需要包含收银的功能、服务核销的功能、商品管理的功能、库存管理的功能等等。

但如果仅仅是满足这些功能，和传统的POS并没有多大的区别，为了满足“智能”和“互联网”的要求，你去深入百度了一下智能POS应该具备的功能，大致包含以下功能：

    刷脸支付；
    支持品牌商营销；
    支持自主营销；
    智能定价；
    外卖对接；
    彩票对接；
    虚拟充值等等。

在问题分解阶段，我们应该尽量多的收集信息，多发散，多头脑风暴。
归类分组

发散完，我们还是要收回来。在收敛之前，我们先看一下产品框架应该包含哪些东西，通常，一个产品架构至少要包含三个层次：

    用户感知层（在何种场景下通过何种方式触达用户）；
    功能模块层（通过哪些功能模块实现产品的核心功能，和哪些外部平台功能有信息交互）；
    数据层（产品的数据从哪里来、产品的数据沉淀到何处去）。

在这三个层次的基础上，我们再对每个层次内的模块进行分组。例如在功能模块层，我们要对功能进行分类，让分散的功能点内聚成更大的产品模块（体现在用户界面上，往往是一级菜单和子菜单的关系）。

比如对于POS的收银产品模块，我们可以提供以下的产品功能：

    支付宝收银
    现金收银
    微信收银
    刷脸支付
    记账等

通过层次划分，模块划分我们就可以得到一个相对清晰的产品架构，以智能POS为例，我们可以画出如下的产品架构：
image.png
分类是科学也是艺术

通过上面的案例，我想你已经领会到黄金三步：定义问题——分解问题——归类分组的要义了。其中前两步相对比较直观，而第三步往往是不容易做好，也容易被忽略的关键步骤。

实际上，对事物的归类分组是我们人类的天性。人类大脑会自动将发现的所有事物以某种持续组织起来。基本上，大脑会认为同时发生的任何事物之间都存在某种关联，并且会将这些事物按某种逻辑模式组织起来。

比如，下面这张图片：
image.png

无论是谁，乍一看到上面的六个黑点，都会认为共有两组墨点，每组三个。造成这种印象的原因主要是有些黑点之间的距离比另一些黑点之间的距离大。

空间是一个相对比较直观的逻辑关系，然而，并不是所有的逻辑关系都是如此的显性化。实际上，很多的概念会在多个维度进行交叉耦合，这就给我们的归类分组带来了很大的挑战。
生物分类学

生物分类学通常直接称分类学（Taxonomy），是一门研究生物类群间的异同以及异同程度，阐明生物间的亲缘关系、基因遗传、物种进化过程和发展规律的基础科学。

最流行的分类是五界系统。通常包括七个主要级别：界（Kingdom）、门（Phylum）、纲（Class）、目（Order）、科（Family）、属（Genus）、种（Species）。种（物种）是基本单元，近缘的种归合为属，近缘的属归合为科，科隶于目，目隶于纲，纲隶于门，门隶于界。

不过分类学到不是一门很严谨的“科学”。就像比尔.布莱森在《万物简史》里说的：

    分类学有时候被描述成一门科学，有时候被描述成一种艺术，但实际上那是一个战场。即使到了今天，那个体系比许多人认为的还要混乱。以描述生物基本结构的门的划分为例。许多生物学家坚持认为总数30个门，但有的认为20来个门，而爱德华在《生命的多样性》一书里提出的数字高达令人吃惊的89门。

由此可见，分类并不像我们想的那么简单。我们观察事物的视角不同，对问题的认知程度不同，得出来的分类很可能也完全不同。

特别是当概念之间有交叉情况，分类就会变得更加棘手。比如，在你的笔记本中，有“读书笔记”和“哲学笔记”两个平级的分类，此时你阅读了一本哲学书籍，那么你会把这本书的读书笔记放在哪个分类里呢？
分类的原则

分类的基本原则是MECE法则。透过结构看世界，说的就是MECE法则。

    MECE法则即mutually exclusive collectively exhaustive的缩写，是麦肯锡咨询顾问芭芭拉·明托在《金字塔原理》中提出的一个思考工具，意思是“相互独立，完全穷尽”，也常被称为“不重叠，不遗漏”。

image.png

MECE原则的思想精髓，就是全维度的去分析一件事情，不要有遗漏和重复的部分。

我们可以借助已有的结构化思维模型（分类的框架）来分析问题，确保每一层要素之间“不重复、不遗漏”。
分类的思维模型

实际上，在上文中我们已经提到了一些分类的思维模型。比如，在应用架构中，我们通常有展现层、控制层、应用层、领域层和基础实施层；在产品架构中，有用户感知层、功能模块层、数据层。这些框架可以有效的指导我们在各自领域中开展工作。

类似于这样的分类思考模型还有很多，比如：
1、制定市场营销策略的“4P”模型，即产品策略（Product Strategy）、价格策略（Price Strategy）、渠道策略（Place Strategy）、促销策略（Promotion Strategy）。

2、分析问题的“5W2H"模型，即Why、What、Who、When、Where、How和How much。

3、思考组织战略的“7S”模型，即经营策略（Srategy）、组织结构（Structure）、运营系统（System）、经营风格（Style）、职员（Staff）、组织技能（Skill）和共享价值观（Shared value）。

4、分析竞争力的SWOT模型，SWOT分析代表分析企业优势（Strengths）、劣势（Weakness）、机会（Opportunity）和威胁（Threats）。

5、制定目标的SMART模型，即制定目标要满足确定性（Specific) 、可度量性（Measurable）、可实现性（Attainable）、相关性（Relevant）和时效性（Time-based）。

这些思维模型都是宝贵的经验总结，相当于已经帮我们做好了第三步“归类分组”的工作，我们只需要按照模型制定的框架往里面填充要素即可。

因此擅用模型，活用框架。可以极大的提升我们解决问题的效率，同时帮助我们做更加全面的、更加结构化的思考。做了“无遗漏，不重复”。