產品經理如何和工程師順暢溝通協作?幾乎是每個 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 點,以工程師視角可能會有其他看法,未來再持續繼續這方面的工作心得。
如對這系列文章有興趣可以再觀看: