小心踩雷！新手 PM 與工程師溝通要注意的三件事｜經驗談
已更新：4月29日
工程師的禁忌，你踩好踩滿了嗎（誤
前陣子久違地參加了社群聚會，當時有機會與一些後端工程師們交流，無意間談到了他們在職場上的一些心路歷程，恰巧他們知道之前自己有從事過短暫的 PM 工作，也就從他們的口中得到了很多對於 PM 的抱怨與建議。
這篇文章不僅適合 PM，凡是會與工程師共事的任何人，相信這篇文章都能對你有所幫助！
I、不會寫程式沒關係，溝通能力最重要！
相信想從事軟體 PM 的新鮮人應該最常有的疑問是：
「軟體 PM 需要會寫程式嗎？」
其實不然。
PM 角色的核心價值在於確保專案執行順暢，在中間擔任溝通與管理的角色。
溝通對象主要為「需求端」與「執行端」，前者通常是老闆或是公司客戶，後者則是我們的工程師大大們。PM 需要將老闆或是客戶想要達成的事情定義清楚，轉換成工程師能理解的方式後，讓工程師能順利將需求達成。
管理對象則是專案進程，細節包含：專案在上線後（Go Live）需要哪些功能，上線後第一階段（Phase 1）需要修正哪些問題、追加哪些新功能，以及每一項進度的時間掌控，都是 PM 需要掌控的。而管理這些項目，則需要基於「需求端」與「執行端」兩方溝通後，方能訂定的。
也因此，PM 工作其實和寫程式的關聯性不大，「溝通」反而是 PM 的主要工作內容。
綜上所述，對工程師而言，他們不要求 PM 理解專業術語，只求你願意傾聽與溝通。
當開發需求來的時候，工程師通常會針對該特定功能給出評估時間。而當開發時間 PM 不能接受時，工程師期待一個好的 PM 不能只是死壓著需求端給的時間死線，而是必須試著了解開發的難處，並與需求端溝通。
例如，倘若客戶端的截止時間不能調整，PM 應該換個角度，和工程師商討現行做法所需時間為何這麼久？有沒有其他 Workaround 是可以採用以降低工時的？
又或者客戶端雖無法延長期限，但我們是否能夠和客戶談好條件，做功能 A 就延後功能 B 的優先順序，等等方式，讓工程師知道你是願意換位思考、替他們著想的。
此外，最不及格的 PM 遇到上面的情境，又會是怎麼處理呢？ ─ ─ 需求端要什麼死線和功能，就直接丟給工程師，完全沒有考量開發時程合不合理；當工程師對 PM 爭取更多開發時間時，只會被搪塞：「功能延遲我就和老闆說我們開發團隊能力不足、做不到，責任你扛嗎？」
II、不要只當個傳聲筒
延續上面的案例，PM 要有評估專案時程與功能合理性的能力，並適當地擋下需求。
不要需求端要做什麼，就一股腦答應！
接到需求後，首先，請 PM 好好衡量開發團隊的人力與時間！倘若你沒辦法準確評估也不要緊，一定要和開發團隊的 Team Lead 討論怎麼樣的時程對他們而言最妥當。
我們都知道 PM 深怕拒絕客戶就喪失了外部合作機會，但 PM 同時也得考量開發品質。要是往往都用壓時間的方式做 Workaround 來達成客戶需求，不理會工程師的提議的開發時間，只會讓服務品質每況愈下；你說事後再找工程師來維護？別傻了，屆時要不是開始一場踢球大賽，要不就是你會看到一票工程師寧願離職也不願再踏進這個坑裡。
III、請把需求「一次」定義「清楚」
接收到客戶或老闆需求後，假若評估後認為時間和功能沒什麼大問題，接下來就是得要準備給工程師的「規格文件」（Specification Documents）。
規格文件主要是為了將抽象的需求轉化為工程師能執行的一個操作手冊（強烈建議要圖文並茂！）。例如，今天客戶可能只簡單說了他們需要改良「使用者註冊頁面」，PM 要做的不僅是定義清楚註冊的 User Journey、需要使用者提供哪些資訊，也要對其中的資訊做逐項定義。
就舉其中一個資訊「使用者名稱（user name）」做為案例，PM 可能需要去定義的項目就包含：
使用者能否輸入特殊字元？
最少與最多能輸入幾個字元？
使用者名稱可否與密碼相同？
若出現錯誤格式應該顯示什麼提示？
….. 其他條件
因此，倘若 PM 在請工程師開發功能時沒有明確定義規格，容易造成工程師一頭霧水、不停來回確認每個細節。不只是浪費工程師和 PM 的時間，嚴重時更會影響整個專案進程。
同樣地，寧願 PM 晚一點給規格文件，也別一直修正工程師正在進行（甚至是做完）的功能的規格。
這同樣會讓工程師很惱火。
請想像今天你身為餐廳主廚，有客人進到餐廳：
第一次點餐告訴你：「牛肉蛋炒飯，飯少、不要蔥」 當你剛備好料後，才被告知：「啊抱歉我要改成豬肉」 你準備起鍋裝盤時，又被改：「還是改成牛肉炒麵好了」
對工程師而言，PM 來回改規格，大概就是這樣的感覺（苦笑）
所以，請切記──
規格請在發需求的當下就定義清楚！
結語
自己當時身為超菜的 PM，也確實踩過上面的一些雷點，但很幸運地是合作的工程師理性地點出這個問題，才讓我們後續共事沒再發生一樣的問題。
多數工程師要的很簡單，他們自己也說自己其實很好收買（？）通常多和他們聊點屁話、關心一下他們工作狀況，很容易就能和他們打成一片。假如有能力請他們喝飲料吃雞排，他們更會覺得你是百年難得一見上道的 PM（誤）
工程師也知道你夾在需求端和執行端的難處，所以當案子時程真的壓的很緊，開發人員找你要求延長時間的時候，就算你做做樣子說你會去協商，他們也會很感謝你的（就算實際你沒辦法再爭取更多時間）。
說白了，PM 工作面對的大多都是「人」的問題。
怎麼與人相處、溝通，是這份工作最困難也最關鍵的。
最後，以我自身的經驗做個結尾：
真正厲害的 PM 都不是那些很懂技術的人；而是那些願意聽取需求端與執行端兩邊想法，跟兩邊都能打成一片的人。