簡介： 溝通說起來簡單，要做好卻很難。如何把復雜的技術問題通俗易懂地表達出來，讓別人聽懂，是每個技術人都會面臨的難題。本文作者以自身經歷為背景，總結技術人員在日常技術交流過程中，遇到的一些低效的技術溝通方式，嘗試分析溝通雙方的心理狀態，并試圖探討提升溝通效率的方法。

一 一些低效的技術溝通案例

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

原文鏈接?

本文為阿里云原創內容，未經允許不得轉載

?

總結

以上是生活随笔為你收集整理的​如何让技术想法更容易被理解?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。