再谈逻辑(9.6)

对于思维类文章，最近博客上更新的比较少，今天想再谈下思维里面的逻辑，简单来说逻辑是关于思维形式和规律的科学，也可以理解为思维的一部分。网上有一段详细关于逻辑的描述摘录如下：

狭义上逻辑既指思维的规律，也指研究思维规律的学科即逻辑学 。广义上逻辑泛指规律，包括思维规律和客观规律。 逻辑包括形式逻辑与辩证逻辑，形式逻辑包括归纳逻辑与演绎逻辑。 逻辑指的是思维的规律和规则，是对思维过程的抽象。 从狭义来讲，逻辑就是指形式逻辑或抽象逻辑，是指人的抽象思维的逻辑；广义来讲，逻辑还包括具象逻辑，即人的整体思维的逻辑。

而我们 谈的最多的仍然是形式逻辑方面的内容，即最基础的归纳和演绎逻辑，基于三段论的推理逻辑 ，这个也是逻辑里面最核心的内容。在日常工作和生活里面，我们经常回遇到的就是你写的方案或文档逻辑性不强，或者你讲的话得出的结论不合逻辑，而对这些判断和检查的基础仍然是形式逻辑的基础，即应该去分析大前提，小前提，推理过程究竟是哪里有漏洞，是否是以偏概全，还是本身就是大前提不成立等。

结合到日常，今天谈逻辑，我准备把结构也纳入到逻辑的范畴，因为很多时候我们说逻辑不强都是在基础结构上就有问题。同时在原来我谈分析和解决问题的时候，在解决问题的过程中有一个核心逻辑，就是匹配逻辑，因此准备也讲匹配逻辑纳入到逻辑范畴。那么基于上面这个思路，我们日常谈的逻辑就应该包括三方面：

1. 结构逻辑： 结构包括了静态结构和动态结构

2. 形式逻辑： 最基础的归纳和演绎逻辑，三段论的匹配逻辑

3. 匹配逻辑： 最核心在于分解后的细粒度同类映射匹配

以上三个方面是逻辑的基础，同时也可以看到出现逻辑性的问题基本都是上面三个方面出现了问题，需要去找出问题并解决。

结构逻辑

说到结构逻辑大家估计一定会首先想到《金字塔原理》这本书，确实这本书给出了一个最基础最核心的结构就是从顶向下，逐层展开的金字塔结构，这个是我们进行文档方案写作，PPT内容呈现的基础。即所有的内容都应该紧密的围绕核心主题这个树状结构逐层展开，不应该有脱离这个结构的内容。

举个简单例子来说，我们在一个方案文档里面的第三章会谈到数据架构，那么这个数据架构不应该凭空出来，而应该在总体架构里面先出现，即常说的承上能够追溯；其次在数据架构里面我们要讲到数据治理，那么数据治理本身又应该在数据架构里面先出现，再逐层分解演绎，这个即启下。所有的内容都满足这个承上启下，那么整个方案的内容就是结构完整，合乎逻辑的。

对于实际的结构逻辑，我们的理解应该包括两个方面的内容：

1. 静态结构逻辑： 所有的静态结构都可以转换为树状结构或者是表格结构，基于空间和维度

2. 动态结构逻辑： 所有的动态结构基本都可以转换为流程和方法步骤，基于时间维度

你在写方案行文的时候你就要注意，你当前描述的章节和内容是否是按照流程的顺序在描述，还是说按照结构展开的顺序在描述，如果两者都不是，那么这个章节就是很突兀的出现，让人摸不着头脑。简单来说就是为何要在这个地方写这个章节内容呢？

形式逻辑

形式逻辑和推理可以说是逻辑中最核心的内容，一个人的逻辑性是否强很多时候都体现在这个地方。逻辑性不强的人往往没有完整的三段论推理思维，而滥用逻辑的人往往又偷梁换柱或以偏概全，这些都会导致逻辑思维上出现问题。

你这个结论怎么得出来的？这个往往是我们经常在写作或叙事的时候被问到的事情。这不是我们推理出现问题，而往往是我们没有给出大家公认的大前提规律，也没有给出我们对一件事情认知的小前提陈述，那么自然我们给出一个结论就会出现问题。

我们在写一个方案文档的时候，会写到我们的需求调研方法，那么为什么要用这个调研方法？真正合乎形式逻辑的思路应该是业界基于某种行业某种业务流程，推荐的调研方法是什么？而当前我们咨询的企业本身属于这种业务流程，因此建议采用这种调研方法。那么这就是基本的逻辑，这样得出的结论才不突兀。

讲任何结论都要又大前提和小前提，而且要先确保大小前提先正确，这样才谈得上进一步的推理。

匹配逻辑

在分析和解决问题里面，除了前面将到的结构逻辑和形式逻辑外，最核心的就是匹配逻辑。而这个匹配本身又是建立在前面的问题分解，知识库的建立，问题和知识经验库的细粒度映射上面。这个问题分解，问题知识库的细粒度映射本身即问题分析过程。

我们很多时候写解决方案文档或PPT，最常犯的逻辑性错误在于问题分析和匹配逻辑缺失 。即你看方案文档的时候发现问题调研和问题描述也有，解决方案和总体架构设计也有，但是最关键的内容遗失了，就是如何从问题得出解决方案的，里面的分析过程没有了。

问题描述了一大推，然后一下就给出了完整的解决方案架构，那么这个架构如何得出来的？里面如何进行问题和经验的匹配的，如何在细粒度匹配完成后再朝上抽象和聚合得出最终的解决方案架构的。这个没有描述清楚那么给人的感觉就是完全脱节，方案架构看起来高大上，但是是否真正解决了问题并不清楚。

很多人在写方案的时候，对于很多技术知识点和底层技术细节不清楚，也没有真正做过大项目的现场一线实践锻炼，而是简单的基于已有的方案进行拼凑和加工，这样出来的方案文档可以说是经不起任何推敲的。看起来出了好几百页的文档，但是你会发现很多都是标准内容，都是粘贴拷贝，而真正和本身企业项目需求相关的内容却少之又少，或者完全无法匹配上。那么这样的方案基本没有价值。

在写任何方案文档的时候，我们一定要注重匹配逻辑，注重问题分析过程。即使是你经验丰富一眼就能够得出最终的方案和结论，那么也得以逆向的思路将前面的分析和匹配逻辑写清楚 ，否则看你文章的人就很难真正了解清楚这个关键脉络。