如何让技术想法更容易被理解？
简介： 沟通说起来简单，要做好却很难。如何把复杂的技术问题通俗易懂地表达出来，让别人听懂，是每个技术人都会面临的难题。本文作者以自身经历为背景，总结技术人员在日常技术交流过程中，遇到的一些低效的技术沟通方式，尝试分析沟通双方的心理状态，并试图探讨提升沟通效率的方法。
一 一些低效的技术沟通案例
1 、技术问题描述不清，解决效率低下
同学A在交付现场遇到技术问题，在项目群里面求助同学B的解决过程。
同学A：大佬，云架构改了之后，数据库规划不了。同学A：解决方案导不出来。其他同学CDEF：其他问题讨论，冲乱了上下文。同学A：数据库不能规划，报风险。同学B：先把问题描述清楚。
同学A可能的心理状态：这个是产品的问题，不是我的问题，我已经把日志和截图发群里面了。你负责的问题你自己爬楼看。
同学B可能的心理状态：这啥问题啊，还得爬楼看，现在没空，先不处理。...... N小时后，纳尼，刚才是哪个群在@我了，群太多找不到了，没电话，看来不着急，先去吃个饭。
同学A心态和方法需转变：谁的问题不是最要的，最重要的是我如何让下一个环节的接口人，在最短的时间内丝滑般地理解这个问题是什么？让他知道我是等米下锅的着急心情。
可行的提问方式：比如把需要钉钉上爬楼看到的碎片信息，提炼后这么提问：“这里有一个问题需要你解决，问题现象是xxx，我们的预期是xxx，实际看到的是xxx，不符合预期，从日志和报错看可能是xxx出问题了。我们xx项目在线等，急需解决。”
2 、方案太抽象，可复制性有限
一次在线技术分享直播，会后有同学就培训细节进行咨询。
讲师C：咱们这个方案，controller调用apiserver进行调度，然后apiserver去数据库里面查询元数据配置信息后，向业务服务器发送请求。巴拉巴拉，我不耽误大家太多时间，讲快点。培训结束，一片掌声。同学D：这个方案我需要拿去和客户交流的，得把原理弄清楚一点，加一些文字描述方便客户理解。
一次电话交流
讲师C可能的心态：已经画清楚了，还做了培训，听完得自己思考消化啊 。
同学D可能的心态：这些框框画起来容易，没有相应的说明，在客户那里交流效果可能会很差，需要找不同的人交叉验证下，然后重新完善材料。
讲师C的心态需转变：最好的学习方法就是用通俗的语言教会别人，如果不能让别人容易理解，那说明自己还没有掌握透彻。
可行的交流方式：上次分享时间比较有限，没说得很透彻，用一个通俗的例子来说，可能更好理解，......此处省略500字。然后结合客户场景，双方展开更详细的讨论，各有收获。
3、 核心问题（技术决策点）未突出，技术评审效率低下
同学E去跟客户介绍了一个三机房的方案，需要客户做决策选择是物理第三机房还是逻辑第三机房，但是客户听完后，没有get到决策点是啥？
一次决策汇报会
可行的交流方式：在方案介绍后，整理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 、及时做笔记和持续更新
为高频术语准备故事或场景，不是专门花一段时间可以完善的，有时候是半夜突然冒出来的灵感，有时候是刚好看到一份资料里面写得比较好。
作者：开发者小助手_LS
本文为阿里云原创内容