產品經理如何和工程師順暢溝通協作？幾乎是每個 PM 都會遇到的問題，有效溝通不僅能加速開發進度，更能確保產品品質和團隊士氣，這篇想記錄過往我觀察到的特定溝通方式，讓我在工作中比過往更順暢，從建立共同語言到打造互信關係。
一、理解開發流程：熟悉團隊文化和流程
⠀⠀
每間公司的工程語言都不太一樣，在我加入各產品團隊的過程中，產品經理初期要先掌握的是「溝通語言」。這裡指的不是「程式語言」，而是工程師們交流的「思維方式和專業術語」，掌握足夠的詞彙，就能讓 PM 初期更快融入團隊。
- 系統架構：了解該公司的前端、後端、資料庫的運作方式，雖然不同公司大同小異，但初期可以先了解「哪種情境要找前端、哪種情境是後端資料問題」等基礎情境，方便未來遇到 bug 或要釐清時，可以更快找到問題源。
- 開發流程：了解工程團隊的上版 / 上線規律，像是固定哪天 Release、或 Code Review 流程、或上線流程，方便之後要提供專案時程時，可以依照團隊流程對外喊出真實且正確的時程。
- 功能限制：了解現有功能的限制和開發過程，像是現有的功能支援與不支援的情境，並理解過往開發遇到的效能、擴充性、邏輯卡控等技術考量，確保未來規劃新功能或舊功能迭代時，能更貼近功能現況。
⠀⠀
上述需要透過不斷閱讀過往產品文件（技術文件、功能教學文件、客服抱怨文件等），加上參與各項站立會議、技論會議，並實際操作功能，才能陸續掌握該產品的全貌，以利了解產品的前世今生。
⠀⠀
⠀⠀
二、跳脫傳聲角色：定義情境與溝通需求
⠀⠀
掌握第一點的溝通語言後，產品經理最重要的職責之一是將業務需求轉化為清晰的需求，這個過程中，產品經理不應該成為單純的「傳聲筒」，而是要扮演「需求過濾器」的角色。
當收到利害關係人的需求時，產品經理需要進行分析和篩選，包含：
- 使用者對原本操作流程哪邊不滿意？其他競品的類型情境怎麼處理？
- 使用者最終想獲得什麼結果 / 看到什麼畫面？
- 為什麼要現在做 / 不做會怎麼樣？
- 做此功能的效益是？影響多大？
⠀⠀
透過上述的初步篩選後，才能確保傳遞給工程師的需求是脈絡清晰、明確目標的，在和工程師開需求時，也要留意：
除了描述使用者遇到的痛點，也要多描述身為 PM，經過分析和整理後，你預期的操作結果是什麼？所以你的目標是要調整成什麼？
因此在整理需求文件時，產品經理要留意：
- 描述需求痛點：不要直接轉述客戶或主管的原始需求，而是要自己也操作過功能，重現出使用者遇到的場景，深入理解使用者流程和他原本想達到的任務（Jobs-to-be-done），才能明確指出本次專案的修改範疇。
- 定義驗收標準：掌握專案修改範疇後，就能依此訂出驗收標準，向工程師說明「最終產生什麼結果 / 看到什麼畫面或資料」才算是驗收通過可以上線，避免籠統或模糊的需求表述，也能確保不會一直來回改需求。
- 開發優先順序：需求範圍定義玩，接著要明確標示各項需求的優先程度，以及它們之間的相互依賴關係，確保在時間有限的前提下，必要的功能能被先執行。
⠀⠀
⠀⠀
三、熟悉溝通語言：使用工程常用語言
⠀⠀
有效的溝通需要使用對方熟悉的語言，雖然有些文章提到產品經理不需要懂技術，但我在和工程師溝通時，發現若能多懂一點技術術語，能讓我和工程師更順暢，特別是在討論資料源、功能邏輯時，例如：
- 要壓資料或希望透過 API 取資料時，使用實際的資料庫欄位名稱（e.g.
salepageid、proposalid、productname）而不是模糊的業務用語，可以幫助工程師快速撈出相關資料，減少重複確認的時間。 - 要修改功能邏輯時，使用「當 A 則 X，當 B 則 Y，當 C 則 Z」等 if / else / or / and 條件敘述，可以讓工程師更直覺了解每個情境的各自產出目標。
⠀⠀
溝通策略包括：
- 資料用詞：在討論時使用工程師熟悉的專業詞彙，減少翻譯成本，像是「客戶有一個壓資料的需求，請幫我將賣場選項序號 (SalepageSkuID) 的 A 改成 B」。
- 資料來源：在需求文件中使用準確的文字，包括 API 名稱、table 名稱、欄位名稱等，像是「API [GET/salepage/details] 的 response 希望多增加一個 OO 欄位，而 request 不變」。
- 技術討論：在需求前期提早和工程師討論架構，像是「A 功能我想要額外支援 OO 情境，預期 "當 A 則 X，當 B 則 Y"，請幫我確認若要加入此邏輯，原本功能的程式碼是否可直接加入，以及修改範圍多大、以及調整的工時」
⠀⠀
⠀⠀
四、結論
⠀⠀
在公司觀察不同產品經理與工程師的互動過程，發現有些 PM 每次提需求都會被質疑很多，但有些 PM 則能非常順暢和工程師討論，因此我也不斷思考如何維持更好的溝通默契，因此有了這篇文章。
上述僅為我觀察到的 3 點，以工程師視角可能會有其他看法，未來再持續繼續這方面的工作心得。
如對這系列文章有興趣可以再觀看：
