系统工程师的视角看逻辑思维，逻辑思维和技术一样重要！

逻辑思维重要的事情无需再次强调，无论从事哪行哪业都需要逻辑思维。从系统工程师的视角，聊一聊逻辑思维的重要性。

系统工程师所处的环境

主要从以下3个层面看一下。

• 技术层面
• 文档层面
• 沟通层面

技术层面

随着技术的发展，系统工程师要面对的问题也越来越复杂。其中很重要的原因是，随着客户的业务逻辑越来越复杂，系统也随着变得复杂。系统的复杂性意味着系统工程师需要掌握客户系统的特性之外还需要掌握更多的技术。

这几年迅速崛起的云服务虽说各大厂商的服务大同小异，但是每个厂商提供的服务都有其特点，更重要的是提供的服务在不断迭代。这意味着系统工程师也需要不断地迭代自己学习新知识。

下面是常用领域的一些服务。

文档层面

上面仅是技术层面，当新项目实施时需要写各种文档(调研，提案，要件定义，基本设计，详细设计等)，并向客户进行说明。这时需要的是写文档的能力。写文档的本质是让看文档或者听讲解的人，”以最小的负担，理解我们想说的事情”。使用列表形式进行描述，还是使用图片(流程图，结构图等)，本质是为了让人更加容易理解。

当我们开始写50页甚至100页的PPT文档时，不会直接打开PPT就开始写内容。一般写文档的流程如下。

1. 确定该文档要写的范围及内容
2. 确定文档的目录(文档结构及每个章节里需要写的内容，需要在这里明确)
3. 撰写每个章节

文档的范围是根据项目背景及需要撰写的文档(提案书，设计书)不同，需要跟项目发起人及相关人员了解情况，确定项目的范围。就如”在其位，谋其政”一样，需要明确地知道自己所负责的范围。超出范围的话，可能学到新东西也可能感觉做了无用功，范围内的事情没做的话，可能会给同事甚至甲方留下不靠谱的印象。因此理解写文档的目的及确定范围是第一步。有些大厂甚至提供文档的模版(比如PPT的模版)，需要提前确认。

沟通层面

当系统发生宕机时，系统工程师需要快速地定位问题，并进行修复。快速定位问题，需要理解系统的架构并根据报错内容，能够预估可能发生的组件并进行确认。

解决系统故障之后，需要分析问题发生的原因，针对问题进行分析及提供解决方案。这些部分是需要向内部相关人员及客户进行说明，毕竟谁也不想同样的问题再次发生。下面是系统宕机报告书，需要包含的内容。解决方案无法短期实现时，需要跟踪至至解决方案落地。

MECE法则

MECE是Mutually Exclusive Collectively Exhaustive的缩写，即所谓的 “无重复、无遗漏”。MECE主要包括以下4种方法。

1. 要素法
2. 流程法
3. 公式法
4. A, not A

技术可以使用要素法进行分层，撰写文档可使用流程法一步一步地做下去。

有用的框架

掌握框架可让我们更加快速地实践MECE，让我们快速套用模版，节省从零开始思考的时间。下面的框架是在商务，调研，做产品及方案比较时有用的框架，供参考。

在越来越复杂的IT环境，技术并不能解决所有问题(或许该领域的顶尖大牛能解决)，通过有效地说明及沟通解决技术解决不了的问题。

从系统工程师的视角来看，逻辑思维能力和技术一样重要。