初次見面。我是 PRUM 株式會社的工程師瞳。
我平常會整理並分享在程式學習與實務中容易卡關的地方，
以及工作中常出現的「落差」。
希望能對某些人有所幫助。
值得信賴的工程師實踐的「傾聽技巧」4選
前言
之前有一次在做進度報告時。
當我開始說明時，組長中途打斷了我。
「也就是說，是這個意思對吧？」
但其實那時我還沒有說完。
之後對話也照著組長的解讀繼續下去，
等我回過神來，我們已經在講不同的事情了。
彼此對齊認知花了很多時間，
會議時間也不夠用了。
那時候我心想：
「至少先把話聽完再說」
。
但後來我才發現。
其實我自己，
在和客戶開會時也可能做過同樣的事。
對方話還沒說完，就先思考解決方案。
只聽到一半就決定結論。
這些全都是在
「以為自己有在聽」
時產生的認知落差。
這次，我想整理一下
值得信賴的工程師所實踐的
「傾聽技巧」。
為什麼人們會「聽不到最後」？
這其實比想像中常見。
不只工程師，
越是對某件事有了解的人，
越容易有「得趕快講出來」的心情。
接著就會不自覺地開始：
- 思考解決方案
- 補完對方的意圖
- 套用自己的經驗
但在那個瞬間，
對方的話其實還沒說完。
對方真正需要的，
不一定是立刻得到答案，而是
「先被理解」
。
其實，值得信賴的工程師共同點
不是「說話方式」，
而是
「聆聽方式」。
現場常見的「沒有聽進去」模式
這樣的會議情境，
你有沒有似曾相識？
模式 1：太急著提出解決方案
客戶：「現在的庫存管理，每到每個月月底都真的很麻煩……」
工程師：「啊，那只要改資料庫的結構就能解決了！」
對方話還沒說完，
就先給出了解決方案。
模式 2：用專業術語讓對方跟不上
工程師：「如果透過 API 串接，並把基礎架構遷移到雲端，可用性就會提高」
客戶：「……（雖然不太懂你在說什麼，但先點頭好了）」
兩者共同的問題是：
在對方覺得「自己被理解了」之前，對話就已經往前推進了
。
建立信任的「傾聽技巧」4選
那麼具體該怎麼做呢？
以下介紹我在現場實踐過的 4 個技巧。
技巧 1：用點頭與附和傳達「我有在聽」
不論是線上會議還是面對面，
對方說話時都要有意識地點頭。
「原來如此」
「那真是辛苦了」
即使只是這樣，
對方也會感受到「有被好好聽見」。
技巧 2：用「鸚鵡式回應」減少認知落差
也就是把對方的話原封不動地回應一次。
客戶：「庫存管理非常混亂……」
工程師：「您的意思是，庫存管理很混亂，對嗎？」
即使只是把關鍵字回覆一次，
也會成為「我有在聽」的訊號。
技巧 3：長篇內容先摘要，再確認
客戶：「因為 A 部門和 B 部門的資料保存方式不同，所以每個月都得人工對齊。」
工程師：「也就是說，因為各部門的資料格式不同，所以每個月都需要人工整理成一致，對嗎？」
透過摘要後再回應，
可以在早期就避免認知落差。
技巧 4：不要害怕沉默
提問之後的沉默，
總讓人覺得有點尷尬。
但其實，
沉默是對方正在思考的時間
。
有時候在那之後冒出的話，
反而才是真正的困擾。
總結
值得信賴的工程師，
不是擅長說話的人。
而是能讓對方感受到
「真的有被好好聽見」 的人。
不妨先從下一場會議開始，
練習在對方把話說完之前不要打斷他。
光是這樣，
對話就會有驚人的變化。
PRUM 的工程師有 95% 以上是從零經驗錄用的。
如果你對我們公司有興趣，歡迎來看看。
原文出處：https://qiita.com/prum_hitomi/items/77e2a48e4189bd5ddc3b
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
