【转】如何让技术想法更容易被理解?【费曼4步学习法】

转载文章，原文来自阿里云云栖号，地址：https://mp.weixin.qq.com/s/TXX7OTnxa8iiENMOJr3-cQ

我这里是对原文的摘录，删掉了一些内容，只保留了我觉得有收获的地方。

原文采用的是一种很经典的写作手法。（我忘记叫什么了，姑且叫做三段式、 小故事、或者Q&A的写作手法吧～～）

首先， 描述一个故事，引出一个问题。其次，就该问题指出应该要做的心态和方法的转变。最后，给出一个可行的行动方法或方式。

所以，我摘录的时候几乎舍弃了全部的故事描述，或者仅用一句话来总结，使得文章尽可能的精简。

有需要的同学可自行去阅读原文～

---

一、实际案例和解析

1、当需要找上下游环节的同学帮忙解决问题时，该怎么描述清楚问题，告知对方需要帮助的地方、问题的紧急和重要性？

同学A心态和方法需转变：谁的问题不是最要的，最重要的是我如何让下一个环节的接口人，在最短的时间内丝滑般地理解这个问题是什么？让他知道我是等米下锅的着急心情。

可行的提问方式：比如把需要钉钉上爬楼看到的碎片信息，提炼后这么提问：“这里有一个问题需要你解决，问题现象是xxx，我们的预期是xxx，实际看到的是xxx，不符合预期，从日志和报错看可能是xxx出问题了。我们xx项目在线等，急需解决。”

 

2、当技术方案太抽象，跨部门/团队复用性有限时，如何给出更容易理解的讲解说明？

一次在线技术分享直播，会后有同学就培训细节进行咨询，觉得方案太抽象，可复制性有限，需要大量的文字细节补充。

讲师C的心态需转变：最好的学习方法就是用通俗的语言教会别人，如果不能让别人容易理解，那说明自己还没有掌握透彻。

可行的交流方式：上次分享时间比较有限，没说得很透彻，用一个通俗的例子来说，可能更好理解，......此处省略500字。然后结合客户场景，双方展开更详细的讨论，各有收获。

 

3 、当需要做技术决策时，如何突出核心问题（技术决策点），提高技术评审效率？

可行的交流方式：在方案介绍后，整理2个候选方案的优劣势，标红加粗决策点是什么。

 

总结下这三个场景，概括下来有2个问题需要解决：

• 换位思考做得不够。只考虑了自己需要什么，没考虑到对方利益和风险。

• 没有用对方能理解的语言来表达。

 

二、 解决案例中问题的办法

• 换位思考，是意识的转变，这个转变说起来容易，做起来难。《终生成长》这本书里面有个核心的观点：比起“证明我比别人更厉害”和“这不是我的问题”的想法，“一起解决问题并学到更多东西”的想法，更有助于成长。

• 借用费曼学习法来解决，核心观点是"如果你认为自己学会了某个专业知识，看看能否把这个知识教会10岁的孩子就知道了"。

费曼本人是诺贝尔得奖者，也是著名的教育学家，他的学习方法分为四步：

1 选择一个概念

选一个你想学习的概念。

2 讲授这个概念（费曼技巧的灵魂）

设想，你面对这个领域的菜鸟，甚至面对十岁的孩童，试图解释清楚这个概念，并让对方完全听懂。

一方面加深你的理解，另一方面，找到不明白的节点或卡点。

3 查漏补缺

当你无法解释的时候，重新回头找答案。

回到书上去，回去找同学、找老师、找已经懂的人，把这个概念重新研究一遍。

结果要求，你能够把这个概念重新流利地解释出来。

4 简化语言和尝试类比

继续升华。假若是一个学术化或抽象化的词语，尝试用简洁词语来解释，用别的东西来类比它。特别注意的是，类别的目的是更好地理解核心观点，允许和技术原意有小差异。

 

三、 作者的实践经历：体验费曼学习法的过程

笔者第一次听别人介绍微服务中注册中心的功能介绍和实现原理时，对于RPC、RS、SessionServer、DataServer、MetaServer术语，有点懵的感觉。笔者当时有一个想法，如果我来向客户介绍微服务的产品时，怎么让他们更容易理解呢？于是开始先找官网文档、研发团队的文档理解后，然后用生活中的小故事小场景来介绍。

1 什么是RPC？

技术解释

RPC（Remote Procedure Call）的本质是为了屏蔽网络的细节和复杂性，提供易用的api，让用户就像调用本地函数一样实现远程调用，所以RPC最重要的就是“像调用本地函数一样”实现远程调用，完全不让用户感知到底层的网络。Sofa产品里面不同容器间，通过RPC调用，实现的“高内聚，低耦合”的效果。

通俗介绍

几个闺蜜在逛街，有人说突然想起快递没收，要回去收快递。另外一个人说，打个电话回去给老公去收快递就行了。提前和老公说明收快递的信息（哪个快递公司、快递点在哪里、快递里面是什么、收件人姓名和电话），打电话远程操作老公收快递这个过程，叫RPC。

2 什么是注册中心？

技术解释

Registry 是指具有承载海量服务注册和订阅能力的、高可用的服务注册中心。Registry 服务注册中心分为四个角色：客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力。

Registry 服务注册中心的主要组件有：

• Client：提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。

• SessionServer：会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。

• DataServer：数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。

• MetaServer：元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。

技术角度理解的架构图：

 

 

通俗介绍

注册中心产品可理解为二手房中介机构，微服务架构中的服务注册/发现/调用，可类比买家和卖家通过中介完成房产交易的过程。

• Client：客户端可以是买房者，也可以是房东。

• SessionnServer：类似于中介的门店，负责接待买房者和房东。门店可以根据业务增长而加门店。

• DataServer：类似于中介公司后台的数据库，记录所有门店的客户数据，含买房者和房东。

• MetaServer：类似中介公司的门店系统，维护门店和客户数据，对买房者和房东不可见。当有门店或客户信息发生变化时，及时通知所有的门店。比如有个房子突然降价20万急售，需要通知到所有门店去找客户。

通过房东卖房子的类比 来讲解给客户听的-服务注册过程：

 

服务订阅过程（买房者购房）：

服务调用过程（买家询价）：

 

四、 建立自己的场景库：妙解来自日常的积累

1 维护一个自己的术语表，识别出在客户交流界面的高频术语

穿过身体的知识才属于自己，哪怕是看到别人写得好的材料，抄一遍。

2 为高频术语都分别准备一个有生活场景的介绍

平时多观察生活中人/事/物之间的关系，道法自然。很多设计模式，比如代理模式（例子：专利申报代理机构）、责任链模式（例子：提交购房资格申请，不关心哪个委办局来处理，最后能获得购房资格即可）、观察者模式（例子：某银行在招标网站发布一个项目招标需求后，各类乙方厂商订阅到有新项目招标，蜂拥而上）等等都能在生活找到相似的影子。笔者愚钝，此处无法穷举所有设计模式。

3 及时做笔记和持续更新

为高频术语准备故事或场景，不是专门花一段时间可以完善的，有时候是半夜突然冒出来的灵感，有时候是刚好看到一份资料里面写得比较好。