我曾經是那種把人講跑的工程師：談談工程師怎麼跟不懂技術的人溝通

我以前真的把人講跑過

我講一件不太光彩的事。

大概是我入行第四、五年的時候，技術上自認小有底氣，做過撮合引擎的核心，扛過幾次大流量。有一次公司要上一個新功能，PM 來找我估時間，順便問我為什麼前一個版本會卡。我記得我滔滔不絕講了快二十分鐘，從資料庫的鎖講到我們的訂單佇列，講到 Redis 的某個資料結構，講到 GC，講到我覺得某段程式碼寫得很爛應該重構。我講得很爽，覺得自己把事情講得很清楚。

那個 PM 全程點頭。等我講完，他問我一句：「所以……這個禮拜能上嗎？」

我那時候有點不爽，心想我都講這麼清楚了你怎麼還問這個。後來那個 PM 跟別的工程師合作的機會越來越多，找我的次數越來越少。又過了一陣子我才聽人轉述，他私下說過一句話：「跟 Louis 講事情很累，他每次都把我問倒，但我還是不知道到底會怎樣。」

這句話我記到現在。因為它一點都沒講錯。我以為我在溝通，其實我只是在展示。展示我懂很多東西，展示這件事很難，展示「你看吧這不是我的問題」。我把對方聽不懂，當成對方的問題。

很多年後我自己當了主管，被逼著去跟老闆、跟業務、跟客服、跟法務講話，我才慢慢搞懂一件事：技術好跟溝通好，是兩種完全不同的能力，而且後者沒有人天生會。

技術好為什麼不等於溝通好

工程師這個職業，前十年訓練的幾乎都是「對機器精確」。你寫的東西稍微模糊一點、少考慮一個邊界條件，系統就會用最直接的方式懲罰你。所以我們很習慣追求精確、追求完整、追求把每個 case 都講到。

問題是，跟人溝通的目標跟跟機器溝通的目標剛好相反。

對機器，你要把所有細節講完，少一個都不行。對人，你要把對方此刻不需要的細節全部砍掉，留太多反而是雜訊。對機器，正確就是一切。對人，光是正確沒有用，對方要能接收、能記得、能拿去做決定，才算數。

我以前完全沒意識到這個差別。我把跟人講話，當成跟 code review 一樣，覺得只要我講的每一句都是對的、都是嚴謹的，那就是好溝通。結果就是我講出一堆「百分之百正確、但對對方百分之百沒用」的話。

精確的相反不是錯，是抓重點。這件事工程師特別難學，因為我們從小被訓練成「漏掉細節是罪過」。但在跟人溝通的場合，硬要把細節塞給對方，才是真正的罪過。

工程師最常見的幾種溝通毛病

我自己犯過，也帶過很多人犯過，整理下來大概是這幾種。

第一種，一開口就講實作。 人家問你「這個功能多久能好」，你開始講你要怎麼改 schema、要拆哪幾個服務、哪裡有技術債。對方根本沒問你怎麼做，他問的是「會發生什麼事」跟「什麼時候」。你卻自顧自地把整個施工藍圖攤開。這就像有人問你幾點到，你開始講你要走哪條路、哪個路口會塞車、你的車剩多少油。

第二種，術語當母語。 我們講「這個要 mock」「那邊有 race condition」「先不要 over-engineer」，講得很順，完全忘記對面的人聽起來跟外星語沒兩樣。更糟的是，有些工程師會用術語來建立優越感——讓對方聽不懂，好像自己就比較厲害。我年輕時不否認有過這種心態，現在回頭看覺得很幼稚。

第三種，把「你聽不懂」當成對方的錯。 這是最致命的。當對方一臉茫然，我們的反應常常是「唉這個講了你也不懂」，然後就懶得講了。但溝通這件事，責任本來就在傳遞訊息的人身上。對方沒接收到，不管是誰的錯，結果都是你的訊息沒送到。把鍋甩給聽眾，是最廉價也最沒用的做法。

這三種毛病我全中過。而且很長一段時間，我還覺得是這個世界不懂欣賞工程師的嚴謹。

把技術翻譯成業務語言

當主管之後，我最大的功課就是學會「翻譯」。我慢慢摸出一個原則：對非技術的人，不要講你怎麼做，要講這件事的影響、風險、跟取捨。

舉個實際的例子。我們有一次後台的查詢很慢，業務一直抱怨。如果是以前的我，我會說：「因為這張表沒有建對索引，而且我們 join 了四張表，又沒做分頁，資料量大的時候掃全表會爆。」

這段話，每個字都對，但業務聽完只會更焦慮，因為他完全不知道這到底嚴不嚴重、要等多久、會不會再發生。

現在我會說：「這個慢是因為資料量長大了，原本的設計撐不住。我有兩個做法：一個是先做個小調整，今天就能讓它快很多，但只能撐三個月；另一個是重做一版，要花我兩週，之後一兩年都不用再碰。你比較在意現在馬上不卡，還是不想三個月後又來一次？」

你看差別在哪。後面這段我一個技術名詞都沒講，但我講了影響（資料長大撐不住）、講了取捨（快但短命 vs 慢但長久）、講了風險（三個月後會復發），最後把決定權交還給他。業務聽完不只懂了，他還覺得自己被尊重，因為這個決定是他能參與的。

這就是翻譯。翻譯不是把術語換成白話而已，而是換一個維度去講同一件事——從「我要動哪裡」換成「這對你的世界意味著什麼」。

為什麼這個要做這麼久

工程師最常被問、也最容易講壞的一題，就是「為什麼這個要做這麼久」。

我以前的回答都是防衛性的，會開始解釋這裡多複雜、那裡有多少坑。但對方要的根本不是你的辯護，他要的是理解，是一個他能拿去跟上面交代的說法。

我後來學會的講法是，把時間拆成對方能理解的幾塊。不要說「要兩週」，要說「這兩週裡，大概有三天是真的在寫新東西，剩下的時間是要確保它不會把現有的東西弄壞，還有測試跟上線」。當你把時間花在哪裡攤開，對方對「久」的感受會完全不一樣。因為大部分人以為工程師的時間都花在「打字」，他不知道改一個東西，最花時間的常常是確認它沒有副作用。

還有一個關鍵：講做這件事的後果，比講做這件事的過程更有說服力。 與其說「這個很難所以要兩週」，不如說「如果我們硬要一週趕出來，我大概只能跳過一半的測試，那上線之後出事的機率我估三成，到時候修起來會花更久，還可能擋到你後面的檔期」。把趕工的代價講清楚，對方自然會重新衡量那個「久」值不值得。

估時為什麼總是不準

講到時間，就不能不講估時。

工程師估時不準是出了名的，而且通常是低估。原因不是我們不會算，是工作的本質就充滿不確定性——你以為要改一個地方，結果牽動五個地方；你以為某個套件能用，結果它有個 bug 害你卡兩天。這些是事前真的看不到的。

但這裡有一個溝通上的陷阱：當你給一個數字，對方會自動把它當成承諾。你說「大概一週」，他聽到的是「一週」，然後他拿這個「一週」去跟客戶、跟老闆排程。等你做到第十天，你變成那個失信的人，即使你一開始就講了「大概」。

我現在的做法是，主動把不確定性講出來，而不是藏在一個數字後面。 我不會只說「一週」，我會說「如果一切順利大概三、四天，但我還沒確認某個第三方的東西可不可靠，如果那邊有狀況，最糟可能到一週半。我兩天後可以給你比較準的數字。」

這樣講有兩個好處。第一，對方拿到的是一個區間跟一個風險點，他排程的時候會自己留 buffer。第二，我給了自己一個「兩天後再確認」的回報點，這讓不確定性變成一個可以被追蹤、被更新的東西，而不是一張會在最後一刻跳票的支票。

不確定性不可恥，假裝沒有不確定性才會出事。會溝通的工程師不是估得比較準，是讓對方一起承擔了那份不確定。

講「不行」的藝術

很多工程師覺得自己很有原則，因為他敢說「不行」。需求不合理，他直接打槍；要求趕工，他直接說做不到。我以前也覺得這叫專業。

後來我發現，光是說「不行」，幾乎沒有任何溝通價值。對方帶著一個需求來，你還他一個句點，他的問題一個都沒解決，他只會覺得你這個人很難搞，然後下次繞過你去找別人，或是直接壓著你做。

真正有用的「不行」，後面一定接著「但是」。 「這個照你要的時間做不到，但如果我們把這三個功能裡的第三個砍掉，剩下兩個我趕得上。」「這個技術上做不到，但你真正想解決的問題，我有另一個方式可以達到八成的效果。」

關鍵在於，你要先聽懂對方「為什麼要這個」。很多時候對方提的是一個解法，不是他真正的問題。他說要一個按鈕，他要的其實是某個操作快一點。當你抓到背後的需求，你拒絕的就只是那個具體做法，而不是他這個人，而你給出的替代方案，反而讓他覺得你站在他那邊。

說不出替代方案的「不行」，常常代表你根本沒搞懂對方要什麼。

寫文件跟寫訊息，要有同理心

溝通不只是用講的。我們每天寫一堆東西——規格、文件、Slack 訊息、PR 說明，這些其實都是溝通，而且大部分工程師寫得很糟。

最常見的問題是，寫的人完全活在自己的脈絡裡。他知道前因後果，所以他寫「修好了那個問題」，但讀的人根本不知道是哪個問題、原本怎樣、現在怎樣。一則好的訊息，應該讓一個沒有背景的人，讀完就能行動。

我給自己定的習慣是，寫完任何要給別人看的東西，重讀一遍，假裝自己是那個什麼都不知道的人。這個詞他懂嗎？這個結論他知道是怎麼來的嗎？我要他做什麼，講清楚了嗎？光是這一個動作，就能讓我的訊息品質好上一截。

還有一個小事但很重要：把結論放最前面。 工程師寫東西很愛照時間順序，先講背景、再講過程、最後才講結果，像在寫推理小說。但讀的人大部分時候只想知道結果。把「所以呢」放在第一句，後面才補「為什麼」，讓想深入的人自己往下讀。尊重別人的時間，是同理心最具體的展現。

開會怎麼講重點

最後講開會。

工程師開會常有一個毛病，就是把腦袋裡的思考過程，原封不動地講出來。「我本來想說用 A 方案，可是後來發現 A 有個問題，然後我又想到 B，但 B 要改的地方比較多，所以我又回去看 A……」講了三分鐘，全場一頭霧水，因為你把整個草稿紙都唸出來了。

開會不是直播你的思考，是把你思考完的結論，用對方能接住的方式講出來。

我現在開會前會逼自己先想一件事：這場會，我希望別人聽完記得哪一句話、做哪一個決定。然後我就從那句話開始講。「我建議用 B 方案，原因有兩個，第一……第二……如果大家同意，我這禮拜就開始。」先給結論，再給理由，最後給下一步。需要細節的人會問，不需要的人不會被你淹沒。

講重點不是把話講少，是把對方需要的那部分，放在他最容易聽到的位置。

寫在最後

回頭看那個被我講跑的 PM，我其實很感謝他。是他那句「我還是不知道到底會怎樣」，多年後才在我心裡發芽，讓我意識到我引以為傲的「講得很清楚」，從來都不是為了對方，是為了我自己。

溝通這件事，工程師沒有任何豁免權。我們不能躲在「我是技術的，這種事不是我的強項」後面，因為你越往上走，技術本身佔的比重越小，能不能把對的事情讓對的人聽懂、願意做，才是真正決定你影響力的東西。

而且這是可以練的。我不是天生會講話的人，到現在開會前我還是會緊張、還是會先在心裡打草稿。但我至少不再是那個一開口就把人講跑的工程師了。對我來說，這個進步比學會任何一個新技術都還要難，也還要值得。