工程師所需要的「溝通力」究竟是什麼
「工程師需要的是溝通力」
這句話很常聽到，但我覺得相當籠統，你不會覺得很有違和感嗎？
這裡所說的溝通力，並不是擅長閒聊、能夠開朗地說話，或是在聚餐時能炒熱氣氛之類的事。
工程師所需要的溝通力，簡單來說就是：
減少誤解、對齊論點、推動工作前進的能力
更進一步來說，就是降低工作不確定性的能力。
這次，我將「工程師的溝通力」具體化地整理出來。
工程師的工作，往往在寫程式之前就已經很模糊
在現場，從一開始就把需求定得清清楚楚的情況幾乎不存在。
常見的是這種狀態：
・要做什麼很模糊
・為什麼需要也很模糊
・由誰來決定也很模糊
・要在什麼時候前完成也很模糊
・要做到什麼程度也很模糊如果在這種狀態下直接開始實作，之後通常會變成這樣：
「不是那個意思」
「沒有要求到那個程度」
「為什麼不先確認？」
「技術上是對的，但業務上不能用」這不是技術能力的問題。
只是在對齊期待值時失敗了而已。
溝通力1：把技術翻譯成對方聽得懂的語言
如果是工程師彼此之間，這樣說就能理解。
DB 查詢很重，索引沒有生效。
還有 N+1 問題。
但如果對象是業務端，光這樣是沒辦法判斷的。
應該傳達的是這樣：
搜尋畫面的顯示變慢了。
如果使用者持續增加，之後可能會更慢。
處理大約需要半天到 1 天。
這次想在正式上線前修好，還是上線後立刻處理，希望能先做決定。重點不是要做出技術上正確的說明。
而是轉換成對方可以做判斷的形式。
溝通力2：整理論點的能力
會議中講很多的人，不代表溝通力就高。
真正有價值的，是能把會議目的說清楚的人。
例如，能這樣說的人：
今天要決定的是要採 A 案還是 B 案，這樣沒錯吧？或者：
今天要決定的是要採 A 案還是 B 案，這樣沒錯吧？
技術上的論點有三個。
分別是實作成本、維運負擔、以及未來擴充性。
今天需要判斷到什麼程度才算足夠？會議的價值不在於講了多少話。
而是哪些事情被決定了，以及接下來要做什麼變得清楚。
溝通力3：不是直接否定，而是提出替代方案或條件
在現場，常會接到不合理的需求。
下週前可以完成嗎？
也能加上這個功能嗎？
可以簡單做一下嗎？
這時候如果直接說「辦不到」，就會變成對立。
另一方面，如果直接說「可以」，自己又會很辛苦。
真正需要的是提出條件或替代方案。
下週前交付是有可能的。
但如果這樣做，範圍必須縮小到 A 和 B。
如果連 C 也要包含進來，就需要再多 2 週。工程師的角色，不是把需求照單全收。
而是提出能成立的條件與替代方案。
溝通力4：及早傳達壞消息的能力
- 看起來可能會延遲。
- 對品質有疑慮。
- 規格不夠明確。
- 外部 API 的行為怪怪的。
這種時候，拖到最後一刻才說是最危險的。
壞消息早一點講，就會變成討論與諮詢。
太晚才講，就會變成藉口。
例如這樣分享就已經足夠：
目前來看，按原定時間上線有風險。
外部 API 串接比預期花了更多時間。
我會在今天內釐清原因，並在明天上午提出處理方針。
最糟的情況下，可能會延後 1 到 2 天上線。不需要等到完全查明原因後才回報。
重要的是：
・發生了什麼事
・目前已經知道到什麼程度
・還有哪些不確定之處
・下一次什麼時候回報
要把這些資訊講出來。
總結
工程師所需要的溝通力，不是指親和力好不好。
真正需要的是以下幾種能力：
・把技術翻譯成對方可以判斷的材料
・整理論點的能力
・調整期待值的能力
・及早共享風險的能力
也就是說，工程師的溝通力其實是：
降低工作不確定性的能力
程式寫得好很重要。
但在現場真正讓人信賴的工程師，不只會寫程式，也會整理認知、期待值與決策。
「溝通力很重要」不是叫你要很會講話、很開朗。
它的意思是：為了讓工作往前推進，你必須設計資訊。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
