本篇文章旨在探討如何改善專案經理與工程師之間的溝通，以提高專案的成功率和團隊合作效能。
PM 到底要如何與工程師溝通才不會激怒對方呢？這個問題是所有 PM 都會遇到的，經驗不夠或是反應不夠快的人可能剛開始就被討厭了。
打開搜尋引擎，輸入關鍵字 PM RD 溝通，出來的結果滿山滿谷都在教 PM 如何與工程師溝通。這就讓我好奇了，既然溝通技巧是 PM 基本配備，那麼溝通有問題時，是工程師問題還是 PM 的問題？似乎大部分文章都是在告訴 PM 如何不惹怒工程師，那真實問題出在 …
強調：本篇文章討論的是純軟體業。
工程師為主的社群怎麼說
在工程師為主的討論區或社群，「PM」兩個字彷彿是哈利波特中的那個人的名字，千萬不可被提及，一但有人提到了相關議題，肯定是千夫所指、嫌棄聲不斷。總結一下不外乎是沒有專業、只會出一張嘴、傳聲筒、只會改需求，這話題講下去肯定是上百則留言或訊息講不完，那真實的情況真的是如此嗎？
在探究之前，不如我們先來思考一下
工程師心中認為完美的 PM 是什麼樣子？PM 心中認為完美的工程師是什麼樣子？
問題的根本是職能混淆
- 喔不不，我還沒要替 PM 說話呢！
首先對於 PM 這個職位，每間公司都有非常多的定位，就我聽過的就有 Project、Product、People，市場通常會使用 PJM / PDM 來區分，至於 People 通常不會特別強調，畢竟管理，有很大部分就是與人有關了。
在小公司、缺乏制度或者接案公司，通常 PM 身兼數職，對內要管理開發時程，對外要洽談需求細節、設計與安撫客戶等，這些事情其實涉及了很多職務內容，難道一個人能夠做到這麼多事情嗎？在聽到的案例中，確實有，但權衡之下僅能做到「相對重要」的事情。工程師的想法重要嗎？還是先安撫好客戶，讓客戶提高配合度、降低專案允收標準？如果你曾是這個體系下的工程師，隨著工作經歷增加，你一定能理解為什麼 PM 並非不在乎，而是沒能力去善待工程師了。
- 等等，不是還有 SA / SD 嗎？資深的工程師呢？
跟各位分享一個案例，在 A 公司中，這只是一個職稱，用來安撫工程師的。當工程師要求升職加薪，就會替他們放上這個職稱，還代表需要開始分擔設計文件與軟體說明文件等。關鍵問題還是出在缺人、缺乏制度，最終開發程式還是要落在你身上。
當然，我不是說所有公司都是這樣，回頭站在 PM 的角度上，身兼數職多學習沒有不好，但凡事只能做到沾醬油、蜻蜓點水般帶過，那不如請求更專業的人協助，不懂裝懂最終只會落入硬拗的結果。說謊、膨風都是有代價的，「為了圓一個謊，要說更多謊來圓」。
那麼，問題是出在哪？是那個兩邊不討好的 PM 嗎？還是不懂得體恤主管的工程師們？在討論之前應該先思考職務內容是甚麼以及工作範圍是否合理。(這裡我只能先排除公司文化與制度面的問題，否則範圍真的太大、太廣了)
- 見客戶不是還有 Account Manager 嗎？
你很聰明，但是問題太多了，每間公司的制度與職位安排是另一個議題..
破壞 PM 價值的職缺
上面描述的還是一位具有談需求、分析與設計的 PM。打開求職平台，搜尋 PM 職缺，會發現更多的是徵求新鮮人當 PM 的，若有完整的入職訓練可能還說得過去，但以台灣軟體開發的生態，要找到這樣的公司會蠻需要運氣的。
學術教育最常強調的就是「學校並不是職前訓練所」。我能理解這個理念，求學過程是培養學生對於知識追求的態度和方法…等等，這類的話應該很常聽到，但學術與職場過度脫軌是非常糟糕的事，等於大部分公司都不期望一個新鮮人能帶來什麼效益，而新鮮人可能在錯誤的職場環境中被扭曲了正確的態度，到最後受害的還是個人與大環境。
當一個懵懂無知的 PM 進入崗位會發生什麼事情，真的很容易預測。PM 是一個講求多技能的職位，了解產業、了解技術語言、如何管理專案、管理客戶、管理部屬，前面幾項還算是可以硬補，對人的管理可不是剛投入職場就能做得好的。
在初期甚麼都不會的狀況下，就是標準的「傳聲筒」。客戶說甚麼唯唯諾諾，沒有能力分辨需求的必要性，永遠只能說回去和工程師討論看看，久了客戶也會看破手腳，這一來一回不全都是溝通成本嗎？工程師需要不斷地解釋設計，但 PM 仍然是滿頭問號，下一次客戶換一個問法，又要再回頭去問工程師。最後搞得兩邊都不是人，自然這個 PM 就做得很沒價值，不僅是自己，對內對外都是。
- 內憂：工程師永遠不會對你說實話，反正你不懂技術，無法分辨做兩天和做五天的差別
- 外患：客戶永遠知道你只是個軟柿子，用幾句術語或名詞就能讓你打道回府
建議：溝通是一門專業、藝術以及必修課程
前面提到，工程師總是覺得 PM 一點價值都沒有，我認為只是「錯誤的使用 PM 而已」。
PM 最大的價值在於促進專案成功，但絕對不是一個十八般武藝都精通的角色。
- PM 會需要強大的程式技巧嗎？
這是一個非常強大的加分項目，但絕對不是必要項目。你需要了解的是各項技術名詞、工具是甚麼功能，能達成什麼目的，至於如何使用就不是你的事了。即便公司設有好的 DBA、設計師、架構師，你能然需要具備足夠的技術專業，否則只能放任他們隨便做，出事了你來扛。 - PM 的技能樹該點在哪？
技術名詞，只是用來和工程師溝通的工具，你仍然需要具備一定程度的理解。真正的專業應該是與人溝通談判的技巧，這是一個難以量化的技術，很吃個人天賦和歷練的技能，但這個投資是終身受用且走到哪、生活都用得到的技能，絕對是價值最高的。
其次，是管理專案和激勵個人、團隊的技巧，我見過糟糕的管理者，也見過懂得鼓舞、製造向上內捲的主管。當員工不滿情緒持續累積，再好的待遇也會離開的，特別是有思考能力的好員工。強烈建議隨時評估「環境」、「薪資」、「前景」，你能動用多少資源來留住有價值的員工？ - 工程師是非常重要的角色
本篇主軸都圍繞在 PM 身上，那麼工程師有甚麼能夠做的呢？仍舊是做好溝通！且你的溝通對象不僅是工程師，還是管理階層即向上管理。我也曾抱怨主管都聽不懂人話，隨著年紀與閱歷的增加，體會到說出人話是非常重要的，如果無法正確傳達你的意思，那麼擁有完美的設計或技術也只能在象牙塔內獨白。一個領域的專家最容易犯的就是知識詛咒。
這邊提供一個很好的練習方式，準備投影片講解給不懂技術的人聽！努力讓對方充分理解你想表達的內容。 - 對於 PM 還有甚麼建議呢
- 善用資源散熱器(Information Radiators)，現代太多工具能輔佐團隊，不要再去問工程師顯而易見的無意義問題。
- 掌握專案狀況，讓專案順利結案才是最終目標。要了解使用者提出的需求和變更是否合理、重要性和緊急性，適度替開發團隊阻擋不必要的干擾。對於這份需求至少要先思考過目的是甚麼？有沒有其他解決的可能性，一昧的照單全收只會讓自己變得更無價值。
- 尊重工程師。你是在管理專案發展，沒有良好的支持，這一個專案也不會好過。軟體開發是一門藝術創造，工程師心情不好，隨便組裝出來的拼裝車，會大幅增加維護、修改成本，長期來看都是巨大的隱形成本！大家都有眼睛也會觀察，對下輕蔑的態度是得不到由衷支持的。
- 量化數據。無論面對工程師、客戶還是上司，把數據量化才有比較的基準與參考性。
- 批量傳達。PM 必須視開發者狀況以及交辦事項的內容，批次提供給開發者。有時候是很小、不緊急的事情，不需要收到就馬上轉交給開發討論，PM 很大的價值在於減少團隊的干擾，讓開發者專注解決當前問題是很重要的。
對於這個議題，似乎三言兩語無法說完，會寫這篇文章也是之前看到某個討論串很有感。
「抱怨很容易，但無法帶來價值，只有起身去做才能有所改變」
五、六月幾乎被現實生活中的大小事塞滿，等到七月一切都穩定了再來穩定輸出文章！ KEEP FIGHTING！