​如何让技术想法更容易被理解?

 

凌云时刻 · 技术

导读:本文作者以自身经历为背景,总结技术人员在日常技术交流过程中,遇到的一些低效的技术沟通方式,尝试分析沟通双方的心理状态,并试图探讨提升沟通效率的方法。

作者向迪

来源|阿里技术

一些低效的技术沟通案例

 技术问题描述不清,解决效率低下

同学 A 在交付现场遇到技术问题,在项目群里面求助同学 B 的解决过程。

同学 A:大佬,云架构改了之后,数据库规划不了。

同学 A:解决方案导不出来。

其他同学 CDEF:其他问题讨论,冲乱了上下文。

同学 A:数据库不能规划,报风险。

同学 B:先把问题描述清楚。

同学 A 可能的心理状态:这个是产品的问题,不是我的问题,我已经把日志和截图发群里面了。你负责的问题你自己爬楼看。

同学 B 可能的心理状态:这啥问题啊,还得爬楼看,现在没空,先不处理。...... N 小时后,纳尼,刚才是哪个群在@我了,群太多找不到了,没电话,看来不着急,先去吃个饭。

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

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

 方案太抽象,可复制性有限

一次在线技术分享直播,会后有同学就培训细节进行咨询。

讲师 C:咱们这个方案,controller 调用 apiserver 进行调度,然后 apiserver 去数据库里面查询元数据配置信息后,向业务服务器发送请求。巴拉巴拉,我不耽误大家太多时间,讲快点。

培训结束,一片掌声。

同学 D:这个方案我需要拿去和客户交流的,得把原理弄清楚一点,加一些文字描述方便客户理解。

一次电话交流

讲师 C 可能的心态:已经画清楚了,还做了培训,听完得自己思考消化啊 。

同学 D 可能的心态:这些框框画起来容易,没有相应的说明,在客户那里交流效果可能会很差,需要找不同的人交叉验证下,然后重新完善材料。

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

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

 核心问题(技术决策点)未突出,技术评审效率低下

同学 E 去跟客户介绍了一个三机房的方案,需要客户做决策选择是物理第三机房还是逻辑第三机房,但是客户听完后,没有 get 到决策点是啥?

一次决策汇报会

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

上述场景中,有 2 个问题需要解决:

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

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

解决办法

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

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

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

 选择一个概念

选一个你想学习的概念。

 讲授这个概念(费曼技巧的灵魂)

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

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

 查漏补缺

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

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

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

 简化语言和尝试类比

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

体验费曼学习法的过程

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

 什么是 RPC?

 技术解释

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

 通俗介绍

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

 什么是注册中心?

 技术解释

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 万急售,需要通知到所有门店去找客户。

服务注册过程(房东卖房子)

服务订阅过程(买房者购房)

服务调用过程(买家询价)

建立自己的场景库

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

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

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

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

 及时做笔记和持续更新

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

END

新年礼物第四弹,精品机械键盘抽奖中!!

邀请伙伴助力中奖几率翻倍

开奖时间:2021 年 1 月 25 日

赶紧转发至朋友圈,呼唤好友一起

抽  奖 吧 !


长按扫描二维码关注凌云时刻

每日收获前沿技术与科技洞见

相关推荐