我還記得我前半年進入公司的時候，整個菜逼巴，尤其是在提問問題上面，回想到十幾年前的自己，真的想抽好幾個巴掌給自己，分享一些例子吧，我同事當我在提問的時候，最喜歡講下面這幾句話：

「洧杰你可以直接講重點嗎？」
「我沒有很多時間，你可以盡快長話短說嗎？」
「你真的廢話很多耶...你大學都沒在跟人講話的嗎？」

在那時候我就會很掙扎，因為我自己的工作是必須從其他同事上獲得資訊，才可以繼續往下步走。或者是要其他同事一起協助才可以交付專案。

但我又很顧及別人的感受，不想讓同事不開心，但那時自己的溝通能力又很差，所以那時每天都在跟自己天人交戰，當我要走去別人的座位討論事情前，我真的不誇張，自己都必須花 半小時~一小時做心理建設，才敢去找同事或老闆討論事情。

所以這篇也是寫給十幾年前的自己看得，如果我那時知道這些細節，或許工作上就可以更順利不少。

讓對方感受到你有尊重他的時間

每個人在公司工作時間至少有 8 小時，如果因為你頻繁打擾到對方，就會壓縮到對方的辦公時間。首要的課題就是當你在進行溝通的過程中，務必要讓對方有覺得你有尊重他的時間。

在以前我還是死新手的時候，我曾經一個下午瘋狂去找後端工程師問問題，一有個小問題我都會下意識去找對方問個到底，直到後端和我抱怨說：「都回你問題我就飽了，也不用寫程式啦~」。我才意識到自己好像過度打擾了。

我那時也花了很多時間去思考，到底要怎麼辦才好而傷透腦筋，最終我歸納出了以下方法來解決：

溝通頻率不宜過於頻繁，一天 1~2 次，最多不宜超過 3 次以上

當你打算找其他窗口討論事情前，先整理好你要提問的項目清單，你可以寫在筆記本或在 todolist 軟體上後，再一口氣問個明白。當對方窗口跟你討論完一個重點時，你就畫線掉表示結束，對方也會認為跟你討論是有共識的，而且你是有備而來的，這點至關重要，因為這樣對方才會認為你是有尊重對方的時間，自己先做好要問的順序後才去找他。

找同事討論時，可先問對方有沒有空，以及預期討論時間

有些工作項目是需要高度專注才可完成，所以如果臨時被打斷時，集中力也會因此而喪失。所以我會先詢問對方有沒有空，以及預期討論的時間，讓對方有個心理準備。如同以下的對話

洧杰：「 後端你現在有空嗎？我想跟你討論一些 API 的事情，大概需要 20 分鐘左右」
後端：「我正在測試金流服務誒，大概 15:30 分再跟你討論可以嗎？」
洧杰：「好啊，這個討論完我明天就可以把 XX 功能做好了」
後端：「ok，等等聊」

以上的對話也是在一個大立場上，也就是有「尊重對方的時間」，確保他工作到一個段落後，再與他進行討論，畢竟讓同事腦袋同時卡太多事情時，溝通品質也會比較低落，與其如此，我自己是先了解對方的工作狀態後，再詢問何時溝通較於方便。

另外一點就是，如果公司有使用通訊軟體，例如 Slack、Line 的話，或者是 issue 系統，也可以先用發訊息的方式，因為訊息內容是屬於被動式接收訊息，干擾上自然會比實體詢問還要來得低。

要讓對方認為，每次的溝通上都是有助於整體專案推動

今天一個比較複雜的專案，絕對不會是一兩個人單兵作戰就可以完成，有很多項目都是必須倆倆組隊去挑戰，所以在每次溝通上，都要讓自己的隊友知道說，這次的作戰討論，是為了要攻克某個 BOSS 或任務才需要的，這樣你的隊友才知道為何而戰。

以下我就舉兩個正反案例給各位參考：

A場景
洧杰：「後端我想問你這個 API 一直有問題誒」
後端：「是什麼問題？你詳細描述一下，這很重要嗎？」
洧杰：「有啊..這樣我就做不下去了，因為接不起來」
後端：「可是我自己的東西都做不完了，也沒辦法幫你誒..」

B場景
洧杰：「後端我有個狀況想請你看一下，這問題解了後，週五我們做的東西就可以交付給客戶了」
後端：「好，是 API 有問題嗎？」
洧杰：「對，有兩點只要我搞通以後，之後我自己就可以解決了」

上面的對話，各位可以看得出差異了嗎？一個是以「自己」為中心，另一個是以「團隊」為中心，另外就是當對方認為說，跟你溝通是有助於整個進度發展時，也跟對方工作有息息相關時，對方才會認真聽你對話。

提問技巧

在上面我們已經掌握到如何「讓對方感受到你有尊重他的時間」，這樣至少在一開始接觸有邁進很大一步，但接下來的溝通該如何順暢，就讓我們繼續講解下去。

所謂的溝通，我自己的見解是，「你問的問題是否足夠精準」，例如以下情境：

• 你問網站企劃人員，這個案子什麼時候結案？
• 你問後端工程師，這個地方有個 BUG，什麼時候可以解掉？
• 你問前輩一個程式碼問題，因為你有觀念一直轉不過來？
• 你問 UI 設計師說，某個 UI 介面的動線該如何運作，流程上才比較順暢？

所以這裡分享幾個小技巧，以幫助你提問時能夠有 87% 精準。

超出預期事件提問法：當要從對方獲得資訊時

這裡的對話 SOP 是 「你原本認知的事情是要跑 A 流程，但試著執行後卻發現出現預期外的 B 結果，想詢問自己認知是否有錯」。

如果是程式出錯，沒依照自己的預期來運作時，你想問其他工程師同事時，你就可以說：「原本我預期他會跑 A 結果，但我使用 某某程式碼時，卻出現了我預期外的 B 結果。」

再來更多情境舉例：
「我改了 PHP template，本來想要讓這裡的 li 跑 for 迴圈顯示資料，所以在 77~80 行這裡寫了這段語法，但前台卻顯示紅字出錯畫面，log 是顯示 xxxx，想問問這行程式碼是哪裡錯了？」
「我看了你的 UI 畫面，本來是認為從 A 頁面要連到 B 頁面應該是用 slide 轉場，但是我看到了 C 頁面好像跟我預期想像的動畫轉場好像不一樣，你可以描述你心目中的正確轉場方式嗎？」
「我看了服務建議書裡面提到的時程是 8/10，但是看到你跟客戶對話的內容，時程卻改到了 8/5 ，想確認正確的時間是什麼時候？」

提供選擇題問法：當要請別人替你處理事情時

通常在溝通項目時，為了要讓事件可以有效推動，所以也必須讓對方窗口也必須花自己的時間一起同步處理時，我就會這樣子做，因為如果你直接問說：「這東西什麼時候給我？」、「你可以幫我處理一下嗎？」，對方也會增加思考時間，所以我蠻常用提供選擇題的方式加速對方思考。

例如當我有個東西要請對方協助處理時，我會直接說：

「這個東西你下班前可以給我嗎？還是明天中午呢？這樣我都能在明天下班前，準時交辦項目給主管，看你方便的時間為主。」
「我想了下， A 跟 B 方法都 ok，那你傾向用哪個方法來解這個 BUG 呢？依照你比較好解決的方式為主。」
「這個問題困擾了我很久，我想到 A、B、C 作法，但不知道哪個比較好，你可以幫我看看哪個比較適合呢？」
「主管你臨時插件的 B 案子我覺得沒問題，那你要先做這個 B 案子嗎？如果是這樣 本來 A 案今天下班前就可以給你，就會變成 後天下班前才能給你，這樣 ok 嗎？」

這個方法很不錯的地方在於說，可以順便壓交辦時間，能夠預期讓對方將你交辦給他的事情，知道何時可以拿到東西。同時在有選擇題的情況下，對方也可以從中挑選適合他的方案。

總結

如果以養成遊戲來說，如果每次的溝通都是順暢的，你針對特定同事的好感度就會提升，而同事也會認為跟你討論是有助於快速推動專案時，自然就會對你產生信賴感，

最後再幫大家總結意見

• 在每次開啟對話前，要讓對方感受到你有尊重他的時間
• 如果你想從別人身上獲得正確資訊時，請用 超出預期事件提問法
• 如果你想試著交辦事項給別人，不妨試試選擇題提問法