今天就讓我們來聊聊「專案執行」時，如何讓合作的過程更加順利。

以筆者過去的經驗來說，團隊合作免不了要「溝通」，但每個人的溝通能力落差極大，有些人總覺得對方是自己肚子裡的蛔蟲，因此詢問問題、交付任務都沒說明細節，時常需要你來我往的多次確認。

為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

工作記錄（Work Log）

如果團隊有使用專案管理系統，為了日後方便追溯與釐清狀況，建議填寫的內容如下：

• 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
• 如果使用到特別的演算法、技術、套件，請特別附註。
• 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關文件。
• 如果發現 Ticket 完成的時間與估計的不同，請與 PM 討論並調整。

工程師之間的合作

律定格式，讓溝通有一定的品質。

• 明定 Ticket 執行順序：一個 Sprint 中，每個工程師手上有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，為了減少等待的空窗期，工程師要在「 Sprint Planning 時溝通好」。
• 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
• 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「如何操作」會發生。
• 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。

工程師與 PM 的合作

工程師與 PM 合作時，千萬不要惜字如金，大家都要把話講清楚；工程師要求 PM 做到的事，自己也要做到。

• 如果 PM 請工程師完成 Sprint 以外的需求：請說明「任務優先度」、「為什麼會有這個需求」、「可以將哪個 Ticket 排後面一點」。
• 如果工程師在開發過程中收到其他團隊的需求：請將對話窗口轉移到「PM」，由他來統一處理。
• 如果工程師請 PM 開 Ticket：需描述「哪個系統」、「為什麼會有這個需求」、「需求描述」、「估計時數」。
• 若 Loading 太重無法負荷：請說明「原因」，如：掛的 Ticket 數量太多、任務分配不均、某個 Ticket 實作遇到困難。
• 若多個專案同時發起高優先度的任務：有些工程師身上會掛多個專案，若不幸有兩個以上的專案同時發起高優先度的任務，就需要請「PM」協助排出優先順序。

為什麼都要由 PM 來開 Ticket？

有些工程師覺得自己開 Ticket 比較快，資訊多轉一手給 PM 根本是浪費時間，但這個制度是有原因的，如果不這樣做就可能導致：

• PM 對專案的掌握度下降：如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
• 專案進度偏離原定計畫：很多時候，工程師心中的任務優先順序跟 PM 是不一樣的，這導致最後在核對完成的任務時，會因為彼此的認知落差而產生爭執。
• 勞逸不均：有些工程師發現問題就想解，導致身上背了一堆 Ticket 天天加班，而其他工程師閒閒沒事做。
• 做了徒勞無功的任務：有些功能從專案的角度來看，可能不重要，甚至是不需要的。

為了避免上述的狀況發生，如果有任何想做的需求，請先與 PM 討論，讓 PM 從整體的角度來判斷（ex：如果你的 Loading 太重，PM 就可能將你提出的 Ticket 分配給其他人做）。

結語

筆者透過 3 個主題（專案啟動、初始任務、專案執行），與讀者分享制定工作流程的重要性。

制定工作流程是為了讓團隊運作更為順利，所以其中的規範、格式都要與成員充分討論；在彼此有共識的狀態下，工作流程才有存在的價值，否則會變成一種負擔。

最後再次提醒大家，文章的流程未必適用於每個團隊，但可以做為參考方向。

PM 雖然被稱之為專案「經理」，但在大多數的公司並沒有管理實權；如果想讓 RD 跟你配合，至少要對技術要有一定程度的了解，並能聽懂對方想表達的內容。

本篇文章會分享一些實用技巧，讓 PM 獲得更精確的資訊來判斷 RD 的估時是否合理，並告訴你遇到不配合的 RD 該如何應對進退；話不多說，讓我們看下去！

了解對方的專業真的很重要嗎？

筆者很負責任的跟你說：「超級重要！」

當然這不是要你成為該領域的專家，但至少要具備「溝通、評估」的能力。

以 Web 開發舉例，如果你不具備前端、後端、資料庫的概念，你怎麼評估及分配任務？難道只靠感覺來判斷工程師的估時是否合理？

就拿筆者過去的經驗來說，儘管我有全端開發經驗，但在擔任公司 PM 時，因為缺乏與設計師合作的經驗，導致合作初期無法判斷設計師的估時是否合理。

了解專業是為了評估出「合理時間」，並在遇到不合理的狀況時，能適時提出自己有疑問的觀點。

在此特別強調「不要亂估時」！一但被發現會破壞彼此的信任，也是不尊重自己專業的表現。

如果 RD 的估時超出 PM 心中的時程

原則上，PM 都是秉持相信 RD 的態度請他估時的；但有時 RD 估出來的時數，會讓人懷疑自己是不是被糊弄了。

如果專案有時程壓力，PM 會需要更精確的資訊來協助判斷，比如：

1. 向 RD 詢問該 Task 的細節：就像標題所述，PM 需要了解這些時間花在哪裡，是否需要拆成多個 Subtask？因為有時一行字的需求，背後可能涉及到資料庫的遷移、後端 API 改寫、前端畫面調整。
2. 是否有擅長這個領域的人：有時會有這麼長的估時，是因為指派對象不擅長這部分的技術，或是缺乏相關經驗；如果時程寬鬆，那是一個很好的學習機會，但如果有時程壓力，還是看誰擅長就由誰負責（如果 PM 不清楚每位成員擅長的領域，在 Planning 階段可以請資深工程師 or Tech Lead 從旁建議）。
3. 如果是全新領域：RD 在面對陌生的技術時，也只能憑感覺亂估；因此建議開一個「研究新技術」的 Task，讓 RD 先對技術有基礎的認知，在這之後估出來的時間才有參考價值。
4. 是否有最小可行性方案：如果不是技術達不到，而是時程根本不夠，那就要考慮縮減非必要功能，或是採用替代方案。比如說有個需求是「使用者列表」，在 API 設計上，工程師會覺得除了「查詢」外，應該還要有「新增、修改、刪除」的功能，但如果客戶沒有這些需求，那或許先階段用 Seeder 把使用者寫入資料庫就可以了。

RD 估時較長，還有一個常見原因，那就是面對「需求變更」時的緩衝時間；理想上需求變更應該要延長專案時程，但實務上專案的截止日期很難調整，因此在估時上多少會預留一點空間來保護自己。

這個部分涉及到組織文化、公司面對客戶的話語權、主管態度等多個方面，如果讀者對這個話題感興趣，筆者會在獨立一篇與大家分享。

適當的借勢

如果 PM 初來乍到，而 RD 年資很深，那有可能遇到 PM 叫不動 RD、RD 明顯亂估時的狀況。

在職場上我們盡量與人為善，但假使對方就是很皮，你以禮相待他還是使勁搞破壞；那適時的請主管協調也是有必要的，不過這個方法偶爾為之還行，如果常常使用不但會被 RD 討厭，還會讓主管懷疑你的工作能力。

每間公司的文化不同，但拿人手短、吃人嘴短幾乎是共通的；有時請 RD 喝個下午茶，你會發現大家突然變得很好溝通（每個人的社交方式不同，也歡迎讀者分享自身經驗）。

結語

有些 RD 被詢問估時的細節時，會覺得 PM 不尊重專業；但 PM 真的是只是想了解細節，並尋求更好的方案。

筆者認為 PM 與 RD 是平等互助的關係，只是彼此的立場與看事情的角度有些許差異；如果總是刁難對方，其實是在損害自己的 Credit，並讓主管難做人。

「RD 與 PM 的攻防戰」這個議題就先講到這邊，希望有讓大家看到不同角度的思維模式，如果喜歡類似的內容也歡迎留言告訴我～

RD 與 PM 如果有默契，那會是一個很好的組合；但如果彼此水火不容，專案絕對會各種出包。

為什麼會出現標題的對話？

有些公司請 PM 更像是在找秘書，基本上不太管專業背景、從業經驗，只是找一個會紀錄需求，安排時程的人。

在這樣前提下找到的 PM，說實話 RD 真的心很累，大家都是出來打工的，憑什麼要我成為你增加經驗的工具人。

因為沒有專業背景，所以 PM 問的問題通常沒有什麼 Sense，甚至類似的問題還會重複問；而這個狀況除非 PM 有自知之明去學習相關知識，否則未必會隨時間改善。

大部分 RD 會服從有專業能力的人，然後看不起那些什麼都不懂，只會一直塞工作給他們的人。

有些比較情緒化的 RD 在不爽的時候，就算看到專案規劃有問題，也不會出言提醒（不過這樣做也會害到自己，筆者建議要保持工程師的專業素養）。

面對專業的 PM

當然業界也有很多專業的 PM，實務經驗豐富的他們對時程尤其敏感。

通常 PM 在收到需求後，會先請 RD 評估需要的工時；如果 RD 評估的工時超過 PM 心中的時程，那 PM 接下來就會詢問為什麼要花這麼多時間？

這裡我們先分析 RD 估時較長的幾種原因：

1. 之前沒有使用過這項技術，在未知的狀態下，會先拋出一個較長的時程。
2. 即使遇到需求變更，專案的截止日期也不會改變，所以先給自己預留一份緩衝時間。
3. 前段時間工作 Loading 太重，想在淡季為自己爭取一點喘息空間。

關於第 1、2 點，我們放到下一個 PM 篇再來討論；今天這篇文章先來聊聊 RD 如何用好的理由實現第 3 點。

RD 如何用好的理由為自己爭取喘息空間

有經驗的 PM 會適時地讓 RD 有喘息空間，但 RD 也要給 PM 一些好的理由，讓他可以跟老闆交代，這就是筆者說的「默契」，比如說：

• 重構程式：快速開發容易累積技術債，可以趁淡季的時候進行重構，以維護專案程式碼的品質；而多少程式需要重構，每個功能重構所需的時間都是很有彈性的。
• 研究新技術：評估未來專案可能會用到的技術、套件，並提前研究，避免日後專案執行時卡關。
• 整理技術文件：在有時程壓力的狀況下，常常 API 文件、部署文件、使用說明文件的內容不齊全，可以趁這個時機點更新到最新版。

筆者只是舉出 3 個常見例子，歡迎讀者留言補充自己是如何爭取「喘息空間」的。

結語

「專業」為自己贏得尊重，彼此的「默契」讓合作更加順利。

撰寫需求規格時，PM 很難把每個面向都考慮得很完整，因此開發時，需要 RD 適時地與 PM 溝通，或是用自己的經驗補齊不足之處；但具體做到哪個程度，也要參考到專案的時程。

下篇文章，就讓我們改由 PM 的角度來討論這個話題吧。

如果在過往的工作中只遇過 1、2 次不愉快的經驗，那應該是主管偏心、公司制度有問題；但如果你過去的每間公司都遇到類似的狀況，那問題可能出在自己身上。

如果你覺得現在過得不好，不妨參考文章中的方法，也許裡面有些觀點能給你的職涯帶來不一樣的啟發。

1. 做好份內的事
   • 1.1 勇敢拒絕非本職工作，持續加強自己的專業
   • 1.2 不要什麼事情都攬下來，學習當溝通的橋樑
   • 1.3 拒絕承擔與職位不符的責任
2. 讓自己獲得好的工作狀態
   • 2.1 提升工作品質的小技巧
   • 2.2 下班後好好休息
3. 職場禮儀
   • 3.1 避免當個讓人討厭的主管
   • 3.2 詢問別人問題時不要犯的禁忌
   • 3.3 詢問別人問題時該有的禮儀
   • 3.4 給出具體時間，避免使用模糊用語
4. 建立友善的溝通環境
   • 4.1 面對想法意見不同的人，不要先入為主
   • 4.2 不是所有人都跟你有相同的知識背景

1. 做好份內的事

筆者過去非常認真工作，面對主管交代的事從不拒絕，同事需要幫忙時也傾力協助；就算下班時間同事都走光了，我還是獨自加班完成工作。

當時我覺得應該是自己的能力受到肯定，才會被分配到這麼多工作；但過了一段時間後，身體漸漸無法承受這麼高強度的工作，對公司不滿的情緒也越來越多：「為什麼主管只把困難的任務丟給我做？為什麼其他同事都能準時下班？為什麼我要一個人處理這麼多的事情？」然後不久後我就離職了。

直到現在回頭看當年的這段故事，才了解原來「能者過勞」最大的元兇是自己。

1.1 勇敢拒絕非本職工作，持續加強自己的專業

如果你是後端工程師，那就請把自己後端的能力鑽研到頂尖的水準；如果指派給你非本職工作的任務時，盡可能地拒絕。

如果你不懂得拒絕，你就會變成「全包」工程師，同事有事情第一個都先想到你；這容易導致你原本的專業技能停止成長，甚至每天都有做不完的事。

就算你擔任的是全端工程師的職位，我相信一定還是有偏重前端或是後端；筆者建議要認真鑽研偏重的部分，因為絕大多數人都做不到全能，謹記主武器負責殺敵，副武器用來輔助；如果你的主武器已經生鏽，那副武器再多也沒有任何意義。

從高手變成庸才的故事

筆者有個朋友曾經是業界非常優秀的後端工程師，但他在入職新公司兩年後卻變得很平庸；因為除了後端開發外，他還要負責前端網頁開發、公司內部 Server 管理、專案管理系統架設、程式碼版控系統架設、雲端 Server 部署、專案管理、內部教育訓練、Android APP 撰寫…；這些瑣事不僅填滿了上班時間，也讓他下班後沒有體力繼續提升自己，導致技術停留在兩年前毫無進步，而當年落後的人已經可以跟他並駕齊驅，甚至比他更優秀了。

備註：如果在自己手上有事情忙的狀態下，還被強制分配非本職工作的任務；可以趁這個時候跟上級交易，畢竟大家上班都是來賺錢的，如果要我多負擔一份壓力，那也要付出相應的代價。

1.2 不要什麼事情都攬下來，學習當溝通的橋樑

• 將對話窗口轉移
  在非純軟的公司裡面，大部分的部門都搞不清楚前端、後端的差別，因此遇到問題他們不是找主管就是找「全端」工程師；就算你真的能幫他們解決問題，但只要你當了一次的窗口，他們之後遇到問題都會來找你；為了避免日後工作時被其他部門頻繁打擾，筆者的處理方式為：

  • 如果不是本職工作，我會用 Email 告訴其他部門的同事，遇到問題時可以找哪些對應的窗口（ex：如果要提需求可以跟產品經理討論、想知道專案進度請去找專案經理）。
  • 如果是本職工作，但手上工作滿檔；我會將 Email 轉發給其他工程師並描述事情經過，請他協助處理。

  如果你接到問題就處理，那只會是「能者過勞」；你要學習將任務分給同事。

• 不要把別人的問題變成自己的問題
  能力越強，責任越大；當你擔任 Senior Engineer 或是 Tech Lead 時，時常會有同事請你幫忙解決 Bug；如果時間允許，忙當然是要幫的，但請謹記你是幫人，不是攬過來做。
  有些工程師問完問題看到有人幫忙後，就會回到座位一副事不關己的樣子；所以幫忙時請注意界線，以引導為主，不然最後出包，對方可能會把責任直接推到你的頭上。

1.3 拒絕承擔與職位不符的責任

• 背高價、沒看過的資產
  個人資產應該是公司配給你的電腦、螢幕；但有些爛主管會把一些自己不敢背的高價資產掛到下屬身上，如果主管要你在資產轉移單上面簽名，一定要堅定的拒絕。
  大部分的高價資產，只有該領域的工程師才知道如何檢測；所以資產轉移這件事通常有鬼，如果你沒搞清楚就簽下去，很可能成為主管的替死鬼。

• 要你幫忙做不符職權的重要決策
  有些爛主管會將做決策的任務推給下屬，如果你發現這個決策的影響範圍已經超過了你的職權，甚至涉及到多個部門、公司預算；筆者強烈建議你要裝傻推掉。
  他把決策的任務交給你，通常不是為了重用你；只是單純的想要逃避責任跟栽贓嫁禍而已。

  小提醒：假設 1 個決策的失敗率是 20%，你幫忙做了 5 次決策；主管會獲得那 4 次決策正確的獎勵，而你則會承受那 1 次決策失敗的後果。

當然也是有善良的主管，但社會上陰險的人太多，遇到不合理的事你要想辦法拒絕才能保護自己；有的時候不是你比較倒霉，而是因為你沒有拒絕不該由你承擔的責任。

2. 讓自己獲得好的工作狀態

讓我們還回想一下，同樣是工作一整天；有時你回到家時感到沮喪，而有時卻覺得非常充實。

如果你仔細觀察，會發現會造成這兩者差異的主要原因，是因為前者做了太多的雜事，而後者則是去完成有挑戰性的事。

在上個小節已經分享了許多避免雜事的技巧，這個小節就讓我們來了解，如何讓自己有能量去完成有挑戰性的事情。

2.1 提升工作品質的小技巧

你是否曾經工作到一半突然覺得所有事情做起來都非常流暢，在這個狀態下遇到的難題都能迎刃而解、而且能在短時間完成非常多的事，更神奇的是這段時間你的注意力完全不會渙散，甚至會忘記時間的流逝。

筆者周圍有蠻多朋友都體會過這個狀態，它有一個專有名詞 ──「心流」；雖然可遇不可求，但能透過一些小技巧增加它出現的頻率，這些技巧就算無法讓你進入心流，也能提升不少工作品質：

• 給自己一個完整的工作區間，在這個區間內拒絕一切外界聲音；這樣做可以避免你的注意力被打來的電話、訊息的提示音所干擾。

• 給任務設定一個期限，必須在時間內完成某件事；讓大腦把所有精力只投入到一件事情上面。

• 在開始前用一個儀式，暗示自己就要進入無敵模式；透過這個儀式把自己從混亂的思緒中抽離，切斷大腦之前的思緒。

  筆者的儀式是在開始做事前，聽 Victory 這個激昂的音樂。

2.2 下班後好好休息

很多人的下班不是下班，讀者可以回想一下，自己是不是下班後大腦還在思考著剛剛會議的事項，今天尚未完成的工作？

這樣的過度努力，有時會導致你隔天早上到公司的時候昏昏沈沈，做事沒有動力；過去筆者一直以為會這樣是因為工作倦怠、前一晚沒睡好；但後來發現主要是因為在下班後並未將大腦抽離工作環境。

筆者建議在下班前把尚未完成的工作記錄下來，現在有許多筆記軟體都可以幫助你完成這件事，完成後就讓大腦關機，給它喘息的時間；如果讀者願意嘗試看看這個方法，在幾天後你會發現這個細微的調整，竟然能讓隔天上班的時候更有精神、做事效率更高。

3. 職場禮儀

與其說是禮儀，不如說是同事間的互相尊重；如果你有給長官、同事、下屬該有的尊重，彼此的合作會輕鬆許多。

這個小節筆者主要分享不要去踩的地雷，讀者可以從範例中看看自己是否有需要調整的地方；很多時候我們一直在犯錯卻又毫不自覺。

3.1 避免當個讓人討厭的主管

朋友的故事很經典，又符合這個主題，所以就直接拿他來當範例了。

朋友公司的 MIS 部門離職率很高，有多高呢？10 個人的 MIS 部門，一個月可以走 2 個！招募的速度都趕不上離職的速度，部門內除了主管外，最資深的員工還沒待滿一年。

所以時常會找其他 IT 部門來支援業務，而我朋友很不幸的被抓去支援，進去後他瞬間理解為何會有如此高的離職率，簡單幾個例子：

• 在錯誤的時間點發布任務
  除了上班時間會指派任務外，他在禮拜五下午、下班前一小時、下班後還會指派任務給下屬；讓部門每個人的工時超長。

• 光說不練
  一直說自己超級強，但從來沒有看過他自己動手操作，連機房都不太敢走進去；讓下屬對他的能力充滿質疑。

• 推卸責任，陷害同仁
  朋友進去支援，在做交接時身上還要背一堆公司資產；但交接時間只有半小時，資產根本不可能在這麼短的時間內盤點完（當時朋友菜逼巴，不知道一個人背這麼多資產根本不合理），當時他就非常不安；果然隔天就出事了，公司在做資產盤點時發現有些東西不見了，這個主管立馬把鍋甩到我朋友身上要他賠償；一台伺服器就要 20 萬，我朋友現場崩潰大哭。

  如果你只是支援，千萬不要在身上掛賬；就算對方階級比你高，直接請主管幫你擋掉，這是上司應該對下屬的保護。

• 分不清輕重緩急
  凌晨 12 點突然打電話給我朋友，我朋友當時還以為發生了什麼重大事故；結果只是要我朋友幫忙把防火牆重新啟動。因為主管怕自己做出事，所以連小事都要在凌晨打擾下屬。

• 用考績來威脅做事
  在打考績的時期，這名主管在下班時間是這麼交代事情的：「XXX 你幫忙處理一下這個問題，我現在要打考績沒時間處理。」

• 不管團隊承受能力狂接需求，甚至未經討論直接壓任務死線
  這位主管好大喜功，為了討好各個部門，只要有需求就先接再說，完全不考慮團隊的承受能力；為了達成自己的績效，他甚至直接壓死線，要求做不完就全部留下來加班。

看完上面的敘述後，有沒有覺得這個部門根本是地獄？每個人在未來都有可能擔任主管，當你覺得這個故事荒謬的同時，請謹記：「不要變成自己曾經討厭的樣子。」

3.2 詢問別人問題時不要犯的禁忌

如果你問問題的方式讓同事感到不舒服，他們可能之後就不想再幫你了。

• 訊息太過零散
  現在普遍是用通訊軟體來問問題的，如果你沒有把問題整理好再發送，會導致對方電腦一直跳彈窗，非常干擾工作。筆者建議詢問別人問題前，要先整理好訊息且內容要包含：

  • 在哪個地方遇到問題
  • 我搜尋了哪些相關資源
  • 過去有沒有可以參考的範例

• 對方沒馬上回，就一直發訊息
  有些人認為在上班時，同事的訊息應該要秒回，如果超過 5 分鐘沒回就一直敲他。
  我相信會這樣做是因為事情很緊急，但這個做法非常討人厭；對方沒有立刻回訊息，可能是手上也有緊急的事情在處理，如果真的有時間壓力，筆者會建議直接打電話。

• 在下班時間或假日打擾對方
  如果是你個人在專案遇到的問題，建議上班時間處理。

• 訊息只有：「請問你現在有時間嗎？」
  很多人的訊息只有：「請問你現在有時間嗎？」這樣的詢問方式讓收到問題的人沒有辦法預估這個問題將會佔用他多少時間，所以有些人就當成沒看到這則訊息。

• 在開頭說打擾 3 分鐘，結果打擾了 30 分鐘
  如果你的問題其實不小，千萬不要騙對方說只打擾 3 分鐘；這樣很容易打亂他這一天的計畫。

  很多業務開頭的話術就是：「請問可以打擾您 3 分鐘的時間嗎？」如果你有停下來聽他們講解過，就會知道 3 分鐘都是騙人的。

• 拖到最後一刻才問人
  如果最後一刻才求救，不但你緊張，被你求救的人也很緊張；在雙方壓力都很大的狀態下，工作效率實際上是更低的。

• 問重複的問題
  如果詢問重複的問題，除了造成同事的困擾外，還會被質疑你的能力是不是有問題。

• 對方不知道你什麼時候會過來詢問
  如果問問題時對方正好在忙，千萬別說：「我晚點來問你。」因為不明確的時間會給對方帶來更多壓力，應該問：「我什麼時候方便來請教？或是等您有空的時候跟我說一聲？我再過來這邊。」這樣會讓對方比較舒服。

3.3 詢問別人問題時該有的禮儀

有時同事會說：「你幹嘛這麼客氣，直接問就好了啊！」筆者建議你就算聽到這段話，還是要保持該有禮貌，畢竟禮多人不怪。

• 無論是否得到你想要的解答，記得感謝對方
  對方願意幫你，是他人很好而不是義務，就算沒有得到解答也要記得感謝對方，有禮貌對方下一次才會幫你。
• 在打電話給對方前，請先用文字簡述要討論的問題，並確認方便詢問的時間
  如果你直接打電話過去，對方可能在洗手間、會議中…無法及時接電話，並且也不知道接了這通電話要處理什麼事情，而且未經詢問直接打電話有點沒禮貌。
  筆者建議先用文字說明問題，讓對方有思考的時間，這樣可以有效提升討論品質。
• 如果真的有緊急事件需要用通話
  有時會開到一半發現需要某個成員的參與，所以臨時把他拉到會議室。
  若有這種突發狀況，請記得開頭要先說一聲抱歉，並說明要找他討論的主旨，讓他知道突然被加入的會議要討論哪些內容。
• 不要問：「這個要怎麼做？」而是詢問：「這樣做的方向對嗎？」
  第一種詢問方式就像是自己沒有做過功課，第二種詢問方式則是讓對方做修正；大家都很討厭沒做功課就來問問題的人。

3.4 給出具體時間，避免使用模糊用語

當同事問你：「什麼時候東西才會完成？」請不要回答：「等一下就好！」而是說再等 30 分鐘這類具體的時間，因為每個人對「一下」是多少時間的認定是不同的；如果回答的人認為是 1 小時，而發問的人認為是 5 分鐘，就會造成不必要的摩擦。

有些主管在找下屬討論問題時會說：「下午幫我空出一個時間，要找你討論前端設計的問題。」此時千萬不要回答：「好！」你應該要直接提出一個具體時間詢問主管是否方便，如果沒有明確的時間，會導致你無法安排需要高度專注力或是長時間作業的任務。

4. 建立友善的溝通環境

不要說新手，就算是職場上的老鳥，在與同事溝通這塊也經常碰壁；這種情形在跨團隊溝通時遇到的頻率更高，總覺得其他團隊的人在針對我們。

這邊先排除辦公室政治那種拒絕溝通的情境，而是去思考：「如果我們的共同目標是希望讓公司更好，有什麼方法能創造出共贏的局面呢？」

4.1 面對想法意見不同的人，不要先入為主

如果想透過說服對方達成共識，那很容易就把彼此拉到了對立面；即使你成功說服對方，他也未必會真心一起共事。

很多時候在談判前，我們會很自以為是的覺得自己已經了解對方在想什麼了，然後很急迫地把自己的想法加諸到對方身上，不給對方開口的機會。

也許你曾經透過這個方法獲得談判的勝利，但你勝利的原因可能只是因為你的口才比較好；過去的經驗告訴我，這個方法是在封閉彼此溝通的橋樑。

與其一直表達自己的想法，不如嘗試另一條路，詢問對方為何會這麼想，讓對方描述更多想法的細節；在了解對方完整的想法後，用討論的方式詢問對方是否有思考到完整的情境；也許深入探討後你會發現自己的想法是有漏洞的，討論的目的是做出更好的決定，在討論後選擇對方的意見不是認輸，而是達成彼此的共識。

4.2 不是所有人都跟你有相同的知識背景

有時你會在心裡 OS：「這東西這麼簡單，為什麼跟其他部門解釋了好幾次他們還是聽不懂？」會這樣是因為你認為簡單的東西，對其他領域的人而言可能是天書。

每個行業都有自己的專業術語、不同的部門對同一個名詞也會有不同的解釋；如果你今天擔任的角色需要協調各部門的資源，你就要像是個翻譯員，把資訊轉換成他們可以迅速理解與吸收的語言；有時不是其他部門不想配合，而是因為他們真的聽不懂，所以無從配合，資訊轉換也絕對不是一門簡單的功夫，因為你需要對合作部門的業務有一定程度的理解。

備註：筆者認為資深員工最大的價值並不是他擁有的技術，而是他在這間公司的影響力、人脈，以及對各部門業務的熟悉與理解，有能力串連各部門共同完成任務的員工，是公司寶貴的資產。

後記

不會永遠都會有人給你合適的職場建議。

工程師剛進入職場時，能夠在帶你的前輩身上學到很多的技術與經驗。

在你成為老鳥後，你可能要獨自負責一個專案，此時主管能給你一些戰略上面的建議。

但當你成為主管後，你需要同時處理多個專案；到了這個階段，比你更高階的長官因為不了解這些專案的細節，所以很難給出有效的建議。

職涯的前期你會獲得解決問題的標準答案；但隨著你的成長，在未來無論是專案的決策、還是做事的方法，都不會有一個標準答案。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

也許很多人文章寫到一半都曾冒出過這個念頭，就像是我今天原本打算要寫一篇跟工程師溝通有關的文章，結果沒想到 Google 出來的第一篇文章才看不到三篇就讓我把寫好的草稿默默地刪除了…

今天推薦的系列文，可以說是我近年來看過舉例最真實、系統最完整、描述最白話的好文，我相信無論你是工程師、專案經理、產品經理都能從中獲取非常寶貴的經驗及知識。

雖然文章標題是菜鳥工程師必修的30堂溝通課，但裡面很多談到的東西都是資深工程師甚至資深PM都沒有做到的：

• 菜鳥工程師：能從中了解在初入職場時該如何溝通，讓自己儘速成為公司戰力與前輩們合作愉快
• 資深工程師：可以來審視自己有沒有養成一些不好的習慣，造成 PM 以及同事間合作上的困難
• PM：這系列文簡直是職涯上的救贖，你可以搞懂工程師的大腦到底在想什麼東西

在文章中也解答了許多人的共同疑惑，如：

• 為什麼工程師沒辦法準確的估計作業時間？
• 身為工程師如何讓非專業領域的人理解自己表達的內容？
• 工作與興趣是有結合的可能性嗎？
• 如何提高效率讓自己提早下班？
• 怎麼做到職場上的情緒管理？

如果你已經看膩了職場雞湯文，這個系列文章的思路絕對讓你耳目一新，當然我的描述不及文章之萬一，趕緊手刀點下去拜讀吧！！！