產品經理如何與工程師高效溝通?打造順暢開發流程的心法|EP77

更新於 發佈於 閱讀時間約 6 分鐘

產品經理如何和工程師順暢溝通協作?幾乎是每個 PM 都會遇到的問題,有效溝通不僅能加速開發進度,更能確保產品品質和團隊士氣,這篇想記錄過往我觀察到的特定溝通方式,讓我在工作中比過往更順暢,從建立共同語言到打造互信關係。

raw-image

一、理解開發流程:熟悉團隊文化和流程

⠀⠀

每間公司的工程語言都不太一樣,在我加入各產品團隊的過程中,產品經理初期要先掌握的是「溝通語言」。

這裡指的不是「程式語言」,而是工程師們交流的「思維方式和專業術語」,掌握足夠的詞彙,就能讓 PM 初期更快融入團隊。

  • 系統架構:了解該公司的前端、後端、資料庫的運作方式,雖然不同公司大同小異,但初期可以先了解「哪種情境要找前端、哪種情境是後端資料問題」等基礎情境,方便未來遇到 bug 或要釐清時,可以更快找到問題源。
  • 開發流程:了解工程團隊的上版 / 上線規律,像是固定哪天 Release、或 Code Review 流程、或上線流程,方便之後要提供專案時程時,可以依照團隊流程對外喊出真實且正確的時程。
  • 功能限制:了解現有功能的限制和開發過程,像是現有的功能支援與不支援的情境,並理解過往開發遇到的效能、擴充性、邏輯卡控等技術考量,確保未來規劃新功能或舊功能迭代時,能更貼近功能現況。

⠀⠀

上述需要透過不斷閱讀過往產品文件(技術文件、功能教學文件、客服抱怨文件等),加上參與各項站立會議、技論會議,並實際操作功能,才能陸續掌握該產品的全貌,以利了解產品的前世今生。

⠀⠀


⠀⠀

二、跳脫傳聲角色:定義情境與溝通需求

⠀⠀

掌握第一點的溝通語言後,產品經理最重要的職責之一是將業務需求轉化為清晰的需求,這個過程中,產品經理不應該成為單純的「傳聲筒」,而是要扮演「需求過濾器」的角色。

當收到利害關係人的需求時,產品經理需要進行分析和篩選,包含:

  1. 使用者對原本操作流程哪邊不滿意?其他競品的類型情境怎麼處理?
  2. 使用者最終想獲得什麼結果 / 看到什麼畫面?
  3. 為什麼要現在做 / 不做會怎麼樣?
  4. 做此功能的效益是?影響多大?

⠀⠀

透過上述的初步篩選後,才能確保傳遞給工程師的需求是脈絡清晰、明確目標的,在和工程師開需求時,也要留意:

除了描述使用者遇到的痛點,也要多描述身為 PM,經過分析和整理後,你預期的操作結果是什麼?所以你的目標是要調整成什麼?

因此在整理需求文件時,產品經理要留意:

  • 描述需求痛點:不要直接轉述客戶或主管的原始需求,而是要自己也操作過功能,重現出使用者遇到的場景,深入理解使用者流程和他原本想達到的任務(Jobs-to-be-done),才能明確指出本次專案的修改範疇。
  • 定義驗收標準:掌握專案修改範疇後,就能依此訂出驗收標準,向工程師說明「最終產生什麼結果 / 看到什麼畫面或資料」才算是驗收通過可以上線,避免籠統或模糊的需求表述,也能確保不會一直來回改需求。
  • 開發優先順序:需求範圍定義玩,接著要明確標示各項需求的優先程度,以及它們之間的相互依賴關係,確保在時間有限的前提下,必要的功能能被先執行。

⠀⠀


⠀⠀

三、熟悉溝通語言:使用工程常用語言

⠀⠀

有效的溝通需要使用對方熟悉的語言,雖然有些文章提到產品經理不需要懂技術,但我在和工程師溝通時,發現若能多懂一點技術術語,能讓我和工程師更順暢,特別是在討論資料源、功能邏輯時,例如:

  1. 要壓資料或希望透過 API 取資料時,使用實際的資料庫欄位名稱(e.g. salepageidproposalidproductname)而不是模糊的業務用語,可以幫助工程師快速撈出相關資料,減少重複確認的時間。
  2. 要修改功能邏輯時,使用「當 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 點,以工程師視角可能會有其他看法,未來再持續繼續這方面的工作心得。

如對這系列文章有興趣可以再觀看:

《思維的創意想像》是工作之餘發起的 Side Project,因為近期快速吸收各種資訊跟商業知識(Input),但一直沒有地方輸出(Output),因此想透過這系列記錄學到的內容,包含商業知識、產業洞見,或是職場分享等等,目前已有產品開發、客戶成功、社群行銷、思維增長、職場日記等系列文章。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
產品經理(Product Manager, PDM)在不是工程師、設計師的直屬主管,但在敏捷開發團隊中卻扮演關鍵領導角色,這篇想記錄之前聽到的 PM 講座心得,講師分享產品經理如何展現領導特質和溝通技巧,在沒有傳統管理職權的情況下,如何帶領團隊實現產品願景與目標。
產品經理在評估 AI 解決方案時,除了關注表層的功能應用,也需要提出底層技術架構對產品實際效能的關鍵影響,像是 AI 生成商品敘述、AI 客服聊天機器人、AI 店員等,在各種 AI 應用的場景,都需要讓 B 端企業願意為 AI 解決方案付費,才能算是一個健康的產品商業模式。
隨著 AI Agent 逐漸發展,人資日常工作的履歷審核和面試篩選也會藉由 AI 來加速作業,但 AI Agent 要如何設計才能讓人資更有效的進行招募,這篇想以產品經理角度切入產品規劃、流程設計,初步說明 AI Agent 的潛在應用。
在準備產品經理面試時,產品數據指標的 Case Study 一直是訓練產品思維的方式之一,像是遇到「用戶活躍數下降、訂閱數下降、月營收下降」等,身為產品經理會如何提出對策,這篇會藉由「當音樂平台的訂閱數下降,該如何拆解現況和提出策略」。
前提到《電商平台在產品規劃如何導入 AI?》的潛在應用,這篇想針對 AI 商品敘述來拆解規劃一個 AI 功能會經歷的產品細節,包含 Prompt、Token、和商業考量。
產品經理在排序開發優先順序時,會面臨哪些利害關係人?在決定需求要做與不做前,又會需要經歷什麼溝通談判?這篇想記錄我在不同產品團隊學到的「掌握籌碼、洞察動機、取得平衡」談判經驗。
產品經理(Product Manager, PDM)在不是工程師、設計師的直屬主管,但在敏捷開發團隊中卻扮演關鍵領導角色,這篇想記錄之前聽到的 PM 講座心得,講師分享產品經理如何展現領導特質和溝通技巧,在沒有傳統管理職權的情況下,如何帶領團隊實現產品願景與目標。
產品經理在評估 AI 解決方案時,除了關注表層的功能應用,也需要提出底層技術架構對產品實際效能的關鍵影響,像是 AI 生成商品敘述、AI 客服聊天機器人、AI 店員等,在各種 AI 應用的場景,都需要讓 B 端企業願意為 AI 解決方案付費,才能算是一個健康的產品商業模式。
隨著 AI Agent 逐漸發展,人資日常工作的履歷審核和面試篩選也會藉由 AI 來加速作業,但 AI Agent 要如何設計才能讓人資更有效的進行招募,這篇想以產品經理角度切入產品規劃、流程設計,初步說明 AI Agent 的潛在應用。
在準備產品經理面試時,產品數據指標的 Case Study 一直是訓練產品思維的方式之一,像是遇到「用戶活躍數下降、訂閱數下降、月營收下降」等,身為產品經理會如何提出對策,這篇會藉由「當音樂平台的訂閱數下降,該如何拆解現況和提出策略」。
前提到《電商平台在產品規劃如何導入 AI?》的潛在應用,這篇想針對 AI 商品敘述來拆解規劃一個 AI 功能會經歷的產品細節,包含 Prompt、Token、和商業考量。
產品經理在排序開發優先順序時,會面臨哪些利害關係人?在決定需求要做與不做前,又會需要經歷什麼溝通談判?這篇想記錄我在不同產品團隊學到的「掌握籌碼、洞察動機、取得平衡」談判經驗。
你可能也想看
Google News 追蹤
Thumbnail
/ 大家現在出門買東西還會帶錢包嗎 鴨鴨發現自己好像快一個禮拜沒帶錢包出門 還是可以天天買滿買好回家(? 因此為了記錄手機消費跟各種紅利優惠 鴨鴨都會特別注意銀行的App好不好用! 像是介面設計就是會很在意的地方 很多銀行通常會為了要滿足不同客群 會推出很多App讓使用者下載 每次
Thumbnail
專案工作型態很需要「溝通」,特別是每次交替時期需要與新的合作對象建立關係的時候,對方可能是你從不認識的同事或主管也可能是廠商。除非你是專職的專案經理,否則這種突然爆增的「初次溝通」聯繫的工作、會大量壓縮到你專案執行時間。在這種情況下要如何達到高效率的溝通,我們可以朝兩個面向來思考看看...
Thumbnail
業務與研發之間的溝通是職場一大挑戰,常因認知差異產生誤解,影響工作氣氛與專案進度。 透過本文提出的三點提醒,設定對應方案來打破專業壁壘,就能建立起有效的跨部門合作關係。
Thumbnail
溝通是職場成功的重要關鍵,但並非只有說出自己的想法。要建立有效的溝通技巧,我們需要學會理解他人的需求以及他們如何接受信息。這篇文章帶來了一個項目經理的案例,通過他的自我學習和實踐,讓我們看到了有效溝通的重要性。建議大家努力提升溝通能力,學會說、是聽、學會理解,這樣我們就能在職場上達到真正的有效溝通。
Thumbnail
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力,以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性,並強調從工程師升遷為專案經理並非易事,需要不斷學習與努力。
Thumbnail
近期在準備產品經理的職涯訪談,剛好把一些產品思維紀錄一下,包含對於產品工作的理解、產品規劃流程、和產品經理的自我反思,這篇不代表最正確的答案,僅代表個人在產品經理道路上的思維。
Thumbnail
產品經理做每個產品決策時,都不斷會被客戶、客戶經理、產品主管詢問各種為什麼,像是為什麼這樣設計?出發點是什麼?影響是什麼?因此這篇想記錄我在工作中遇到的各種產品問答,包含影響我哪些產品思維和框架。
作為一位產品經理(PM),了解並優化公司的流程是提高工作效率的關鍵。以下是五個步驟,幫助你系統性地改善流程、加速產品處理時程,提高公司的效率。
Thumbnail
擔任產品經理常常反思自己哪邊可以更好,以及要加強哪些產品思維或技能,和工程師、設計師互動時有沒有可以改善的地方,制訂策略和規劃時有沒有遺漏什麼環節,因此這篇想記錄近期的產品反思。
Thumbnail
不得不說,因為技術背景的關係,我一直在與工程師的溝通算是順暢。甚至有遇過技術能力比工程師更好的情況。所以我們不能也不應該強求PM要有多專業的技術能力,所以本文要說明工程師需要什麼?PM怎麼樣培養與工程師的合作默契。
Thumbnail
/ 大家現在出門買東西還會帶錢包嗎 鴨鴨發現自己好像快一個禮拜沒帶錢包出門 還是可以天天買滿買好回家(? 因此為了記錄手機消費跟各種紅利優惠 鴨鴨都會特別注意銀行的App好不好用! 像是介面設計就是會很在意的地方 很多銀行通常會為了要滿足不同客群 會推出很多App讓使用者下載 每次
Thumbnail
專案工作型態很需要「溝通」,特別是每次交替時期需要與新的合作對象建立關係的時候,對方可能是你從不認識的同事或主管也可能是廠商。除非你是專職的專案經理,否則這種突然爆增的「初次溝通」聯繫的工作、會大量壓縮到你專案執行時間。在這種情況下要如何達到高效率的溝通,我們可以朝兩個面向來思考看看...
Thumbnail
業務與研發之間的溝通是職場一大挑戰,常因認知差異產生誤解,影響工作氣氛與專案進度。 透過本文提出的三點提醒,設定對應方案來打破專業壁壘,就能建立起有效的跨部門合作關係。
Thumbnail
溝通是職場成功的重要關鍵,但並非只有說出自己的想法。要建立有效的溝通技巧,我們需要學會理解他人的需求以及他們如何接受信息。這篇文章帶來了一個項目經理的案例,通過他的自我學習和實踐,讓我們看到了有效溝通的重要性。建議大家努力提升溝通能力,學會說、是聽、學會理解,這樣我們就能在職場上達到真正的有效溝通。
Thumbnail
專案經理與工程師在工作上面對的挑戰和需求截然不同。專案經理需具備溝通、督促、認知及行政等四種核心能力,以便成功轉型。文章中舉例以生動的故事來說明這四種能力的重要性,並強調從工程師升遷為專案經理並非易事,需要不斷學習與努力。
Thumbnail
近期在準備產品經理的職涯訪談,剛好把一些產品思維紀錄一下,包含對於產品工作的理解、產品規劃流程、和產品經理的自我反思,這篇不代表最正確的答案,僅代表個人在產品經理道路上的思維。
Thumbnail
產品經理做每個產品決策時,都不斷會被客戶、客戶經理、產品主管詢問各種為什麼,像是為什麼這樣設計?出發點是什麼?影響是什麼?因此這篇想記錄我在工作中遇到的各種產品問答,包含影響我哪些產品思維和框架。
作為一位產品經理(PM),了解並優化公司的流程是提高工作效率的關鍵。以下是五個步驟,幫助你系統性地改善流程、加速產品處理時程,提高公司的效率。
Thumbnail
擔任產品經理常常反思自己哪邊可以更好,以及要加強哪些產品思維或技能,和工程師、設計師互動時有沒有可以改善的地方,制訂策略和規劃時有沒有遺漏什麼環節,因此這篇想記錄近期的產品反思。
Thumbnail
不得不說,因為技術背景的關係,我一直在與工程師的溝通算是順暢。甚至有遇過技術能力比工程師更好的情況。所以我們不能也不應該強求PM要有多專業的技術能力,所以本文要說明工程師需要什麼?PM怎麼樣培養與工程師的合作默契。