如何讓技術想法更容易被理解?

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

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

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字。而後結合客戶場景，雙方展開更詳細的討論，各有收穫。

三、 核心問題（技術決策點）未突出，技術評審效率低下

同窗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。

二、 什麼是註冊中心？

技術解釋

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萬急售，須要通知到全部門店去找客戶。

服務註冊過程（房東賣房子）

服務調用過程（買家詢價）

四 創建本身的場景庫

一、 維護一個本身的術語表，識別出在客戶交流界面的高頻術語

穿過身體的知識才屬於本身，哪怕是看到別人寫得好的材料，抄一遍。

2 、爲高頻術語都分別準備一個有生活場景的介紹

平時多觀察生活中人/事/物之間的關係，道法天然。不少設計模式，好比代理模式（例子：專利申報代理機構）、責任鏈模式（例子：提交購房資格申請，不關心哪一個委辦局來處理，最後能得到購房資格便可）、觀察者模式（例子：某銀行在招標網站發佈一個項目招標需求後，各種乙方廠商訂閱到有新項目招標，一擁而上）等等都能在生活找到類似的影子。筆者愚鈍，此處沒法窮舉全部設計模式。

3 、及時作筆記和持續更新

爲高頻術語準備故事或場景，不是專門花一段時間能夠完善的，有時候是半夜忽然冒出來的靈感，有時候是恰好看到一份資料裏面寫得比較好。

做者：開發者小助手_LS
原文連接本文爲阿里雲原創內容，未經容許不得轉載