工程師如何和 PM 共事？PM 親自來解答！

古古

2024/10/15

哈囉大家好，我是古古。身為一個工程師，在工作上多多少少都得和 PM 打交道，可能有的人會好奇 PM 的工作內容是什麼、或是不知道怎麼跟 PM 相處比較好。

所以這篇文章，我們邀請到了 PM 大大來為我們工程師們解惑一下，分享 PM 的工作內容是什麼、以及工程師如何和 PM 共事，所以我們就開始吧！

前言 #

Hello 我是 Eileen，目前任職於 Hahow 好學校的產品經理，約擔任 PM 經歷 4 年，同時也是 Taiwan Product Managers 臉書社團 的管理員，近一年舉辦了許多產品經理及軟體產品從業者的小聚，希望透過這篇文章跟大家分享及交流。

也容許我在開始前打個預防針，產品經理的日常幾乎沒有正確答案，只有最合適的答案，因此在不同團隊中可能有所差異。本篇文章僅能代表我自身體驗及所觀察到周遭產品經理的經驗！那就讓我們開始吧～

本文問題集：

  1. 若要成為一個及格的產品經理，對技術的了解要有多少？
  2. PM 的工作範圍到哪裡？如果遇到灰色模糊地帶的事情，如何權責劃分？
  3. PM 都是如何規劃一個專案的發想到執行？有沒有推薦的課程或是文章可以參考？
  4. 想知道 PM 的職責會幫忙拆分 User Story 嗎？
  5. PM 是如何評估專案工時的？
  6. 請問 PM 面對比較陌生的開發專案，例如：要修改很陳舊的專案，接手的工程師都不知道要怎麼抓開發時間，PM 要怎麼抓時程？
  7. RD 後期真的都會轉 PM 嗎？網路上看到不少案例
  8. 當 PM 說「他不懂技術」、或是「不要跟他說技術」時，該怎麼辦？
  9. RD 和 PM 之間應該如何和平相處呢？有時候和 PM 溝通都會很無力...

1. Project Manager（PJM）和 Product Manager（PDM）的差異 #

這題問題是我在擔任 PM 第一年，最常被 PM 前輩問到的 101 問題，「你覺得產品經理跟專案經理有什麼不一樣」？網路上有許多文章說明產品經理與專案經理的差異，以下先列出普遍對於專案經理及產品經理職務上的要求差異。

產品經理（PDM）：

  • 主要負責產品的整體策略和方向
  • 關注產品的長期發展和市場需求
  • 決定產品功能和優先順序
  • 與各個部門協調，確保產品符合公司目標和用戶需求

專案經理（PJM）：

  • 負責具體專案的執行和時程管理，以確保專案按時完成
  • 管理專案資源和團隊協調
  • 控管專案中的風險和問題

簡單而言，產品經理（PDM）專注於「價值交付」，專案經理（PJM）則專注於「專案交付」。

舉例而言，如果是一個串流影音平台，產品經理可能會負責與營運、業務行銷單位討論預計推出新的影片類型、預計在市場上的定位及策略進而思考對應功能（如互動式影片、離線觀看等），以滿足用戶需求並提升平台競爭力。而專案經理則可能負責管理這些新功能的開發進度，確保各個團隊（如開發、設計、內容）能夠協調一致，按時完成專案。

雖說如此，在實際的日常中，這兩個職稱的界限可能會有所模糊。許多公司的PM職位可能是複合型的，例如：在多數公司並沒有額外招募專案經理，而是由產品經理身兼專案經理的角色。或雖然職稱掛產品經理，卻實際上被期待作為客戶經理、業務的角色。

各家 PM 實際要負責的範圍五花八門，我和幾位 PM 朋友也常開玩笑說「工程師不做的事就是 PM 的守備範圍」，因此當在分工有疑惑時，建議大家可以參考自己公司的 PM 的 JD（職缺敘述） 或直接跟自己主管、或 PM 聊聊！

2. PM 的工作範圍到哪裡？如果遇到灰色模糊地帶的事情，如何權責劃分？ #

延續上題，由於各個產品團隊所包含的成員不同，例如是否擁有 UI designer、UX Researcher、數據分析師、測試工程師等，影響了 PM 所扮演的角色。而當 PM 所需擔任的角色越多，時間固定情況下，可以做到的顆粒度，與勢必有所影響。

我自己認為 PM 的工作在一個專案中（Epic 或 Story），為了避免認知不同造成誤會或浪費工程資源，至少須確保以下內容有被定義：

  1. 目標定義： 開發這個功能是為了達成什麼目的？我們的專案規模是多大？是 POC 或是一個長期使用的功能？了解目標也可以幫助工程師想到更好的解法及考慮維運性。
  2. 功能想像對焦： 不管是流程圖、PRD（規格文件）、wireframe、設計稿、技術開發文件，目的都是用來對齊團隊成員對於功能的想像跟期待，最終期待是所有人能夠具備共識。
  3. 驗收條件定義： 驗收的內容包含但不限於：開發是否如設計稿、是否使用者正向流程及負向流程都被考量、Bug 的優先序定義等，甚至如果公司內有多個團隊，本次上線是否對於其他產品或功能造成影響，都是 PM 在功能發布前須考慮的內容。

即使如此我想大家還是有很多疑問，常見的灰色地帶，例如：帶領會議究竟是技術主管還是 PM 負責？PM 到底要不要畫出流程圖？萬一沒有設計稿，工程師要自己做嗎？ 答案是「都可以」（被揍）XD

在不同的公司、不同團隊甚至同一個團隊的不同專案都有可能有所差異，這一切都要取決於 「團隊所擁有的資源」。例如：我們有一位 App 工程師主管為了讓使用者體驗更好，在沒有設計資源的情況下，主動發起了 Dark mode 的導入，再請設計師做 design review ，反轉了由 PM 主導需求的角色。

因此，如果遇到灰色地帶時，最好的方式就是在 retro 當中提出，甚至工程團隊也可以發起討論會議，了解彼此的期待及難處。希望能讓大家理解，讓開發順利推動是所有專案成員的責任，大家的付出都會幫助團隊運作更為順暢！

3. PM 都是如何規劃一個專案的發想到執行？有沒有推薦的課程或是文章可以參考？ #

古古補充：這段比較多專有名詞，如果覺得有點複雜可以先跳過這題

在目前的公司，我們透過公司層級定義的 OGSM（年度目標）來制定產品部門及組別層級的 OGSM。這包含了目標、策略（如何實現）以及衡量指標（如何確認完成）。

舉例來說，今年的一個目標是能夠檢驗和衡量使用者的學習成效。經過對國內競品、市場分析、國外領導產業的研究，以及團隊腦力激盪後，我們選擇了透過「測驗」功能來量化學習效果作為策略。考慮到 Hahow 現有的技術架構、使用者和創作者的使用習慣，我們發現要提供「測驗」服務，需要完成 A、B、C 三項任務。為了在目標期限內完成這項策略，我們還定義了這三個專案各自的目標、時程安排，以及可用的工程資源和時間。

接下來，PM 會根據這些資訊進行更深入的競品調查和使用者研究，以了解「測驗功能」（Epic）需要滿足哪些使用者情境（Story）及其具體流程。這個階段也就是撰寫「產品規格文件」（PRD，Product Requirement Document）的必要環節。由於這個專案預計運用 AI 技術，我們還額外進行了工程 POC 來評估新技術的可行性。確認可行後，我們將任務交給產品設計師進行 Wireframe 和設計稿的繪製，並反覆討論使用者體驗和操作介面。在這個過程中，我們也邀請工程師評估設計流程的開發可行性。

最後，我們進入 Scrum 流程中的 Pre-refinement、Refinement 和 Planning 會議，將任務交給工程團隊進行 Task 的切分和開發實作。但這還不是終點。為了確保測驗功能上線後能達到目標使用人數並驗證假設，我們還需要規劃數據埋點，以及與行銷團隊討論產品行銷策略。上線後，PM 還需要負責數據分析和後續迭代規劃。

每一個大型專案上線都像生了一個孩子，從發想到執行的過程總是充滿驚喜（嚇）。也幸好團隊中擁有產品設計師、工程師和測試工程師各自的專業，透過不斷的討論，才能確保產出最佳的解決方案。

如果想瞭解 PRD 如何撰寫，歡迎參考以下優秀文章：

4. 想知道 PM 的職責會幫忙拆分 User Story 嗎？ #

PM 在撰寫 PRD 時通常會羅列本次上線須包含哪些 User Story（使用者情境）。

如同第二題中提到我們近期開了 DOR 定義會議，其中討論了 Story 應包含的內容時，有提及拆分 Story 其實是一門藝術（技術）。在過往經驗中，遇過 Story 拆分過細，導致兩張 story 之間有耦合，工程師在開對應 Task 時會不確定應該關聯於哪張 Story。也有拆分顆粒過大，導致 Story 包含 Task 數量過多，Story 較難在一個 Sprint 內被完成。

目前我們在開完 Story 之後開卡前都會請工程師夥伴協助檢視是否方便理解及開發，在開發過程中也會動態調整，以確保協作順暢。

5. PM 是如何評估專案工時的？ #

在我工作的第一年，我無數次好奇資深 PM 們如何估計時程及列出目標，而當時前輩跟我說：「這是個感覺」。當時的我 be like 🤔😦🫠，在經過幾年後，我也必須說這是個玄學（大笑）。

具備經驗的 PM 通常能夠透過過往團隊消耗點數、本次合作工程師的消化速度、對於專案複雜度的理解，由此推斷出預估花費時間。如果有一個公式的話，大概是：

藉此可以在專案開始前推斷出預計花費時間。

在這之中，工程師的估點對 PM 至關重要，即使估的是複雜度，當複雜度高時長短和複雜度低時長長相互平衡配合估點足夠細緻及平均消化點數穩定的情況，就能幫助 PM 更準確的判斷工時。

在專案開始前，我們目前通常透過工程師 Spike (技術研究)，了解潛在複雜度及工時的合理性，若有明確交付時間，則會因此決定是否要縮小專案規模或拆階段上線。當然專案開發中的動態調整也是時常發生，回扣到第一題，如何掌握且降低專案風險、協調團隊資源，這件事就是「專案管理」的專業！

6. 請問 PM 面對比較陌生的開發專案，例如：要修改很陳舊的專案，接手的工程師都不知道要怎麼抓開發時間，PM 要怎麼抓時程？ #

看起來時程真是大多數人的痛。不管是在前一份工作或是目前的工作，拆除和重寫了許多「古蹟」，遇過的情況，如原始的 PRD 沒有被維護，開發的人已經離職，只好抱著工程師的腿一起翻 code，重新梳理後發現未爆彈越來越多，上到測試站發現其他地方也要修改，只能說滿紙辛酸淚 (?) 你各位古蹟維護員都辛苦了！

回到時程的預估，面對陌生的專案，通常不會先對外承諾時程及可行性。作為 PM，我們會至少安排 1–2 個 Sprint 的研究時間，請工程師撰寫技術文件。研究文件中包含了 PM 設想的預期結果、希望確認的內容或滿足條件，以及是要先了解技術架構還是確認可行性。同時，我們也會把「研究任務」納入估點，避免工程師後續開發時間被壓縮。

研究結束後，通常能確定需要如何動工——是重寫還是修改。在衡量可投入的時間資源及調整範圍後，我們才決定下一步。有時也會發現要花費的功夫和效益不如預期，而決定暫不執行。

為了避免憾事重演，我強烈建議大家要記得同步討論結果，針對研究結果提供說明文件。未完成的部分也可以標示清楚，幫助後人能順利銜接！

7. RD 後期真的都會轉 PM 嗎？網路上看到不少案例 #

我認為 RD 會不會轉為 PM 取決於工程師的職涯安排。我遇過工程師轉 PM 或 Technical PM 成功的案例或是因為擔任 RD Manager 或 Product Diretor 而需要擔任部分 PM 工作，也遇過轉職後因為受不了 PM 日常頻繁的 Context Switch 轉回工程師的案例。因此這題沒有固定答案，只有適不適合！

8. 當 PM 說「他不懂技術」、或是「不要跟他說技術」時，該怎麼辦？ #

關於「PM 要不要懂技術」的主題，網路上有許多文章討論，節錄我很認同其中一篇 《產品經理需要懂技術嗎？》 的內容：

將問題拆解後，我們背後真正想問的是：

  1. 若要成為一個及格的產品經理，對技術的了解要有多少？
  2. 產品經理有那麼多種技能要點，技術在這所有技能中有多重要？

一般來說：PM 對技術的理解，要足夠跟工程師溝通、安排資源、解決問題。

我的答案也是相同的。PM 通常被公司期待「為達成策略目標而確保專案交付」，因此 PM 需要多了解技術也取決於「做決定時多需要仰賴對技術的理解」。當然擁有的正確知識越多，能夠做出的判斷也越正確，但萬一 PM 擁有的知識不夠正確呢？

在剛當 PM 時曾與工程師討論這題，工程師夥伴說「如果你知道我們在做什麼當然是最好的，但如果你知道的不是最正確的，我反而會誤會你就是希望我這麼做，最後做出來的是我們都不想要的結果。」因此後來我的做法是告訴工程師我想達成的目的、滿足的情境，由工程師告訴我方案及每個方案所需的 trade-off，再一起做決定。

我也必須感謝在當 PM 過程中遇到許多願意用白話文解釋工程架構的工程師，讓技術不再遙不可及。讓我也逐漸理解網站的邏輯、在遇到 Bug 時嘗試重現，開啟 inspect 模式試圖看 error code ，而不是一有問題就抓著工程師。也因為經過了前公司面對瞬間流量、 DDOS 經驗、重構經驗後，在設計功能時不自覺得會想考慮維護性、對於潛在風險的應對，試圖降低未來的風險。

如果你遇到這樣的 PM 不妨試試用白話文或日常的例子解釋工程邏輯，就像把難以下嚥的生紅蘿蔔變美味一樣，像我這樣（遇到太困難的技術就當機）的 PM 會超感謝你的！

9. RD 和 PM 之間應該如何和平相處呢？有時候和 PM 溝通都會很無力… #

回顧上面的內容，有許多情境都沒有標準答案，在團隊協作上更是。更多是人與人之間的頻率、溝通技巧等問題，如果有一個解法可能就是「更多的溝通」和「同理心」。

我相信幾乎沒有人會刻意的想「不和平相處」，想謝謝每位願意看完這篇文章的你，感謝你願意試圖了解 PM ，這是建立同理心的第一步。透過同理心可以降低對於彼此錯誤的期待，例如：時程其實 PM 沒有控制權，業務已經跟客戶談好了，會有違約賠償問題，老闆也答應了對方客戶。

目前工作中，我固定每半年會約團隊內每位工程師 1 on 1 ，期待能夠了解在過去合作期間能夠互相調整的地方。(即使如此，我仍舊經常感覺到自己做得不夠好就是了XD) 人際相處一直是互相的，通常是兩個人都需要調整，如果真的無法相處就事論事吧！

總結（by 古古） #

看完了上面這麼長的文章，希望能夠讓大家對於 PM 這個職業有更多的了解！我自己在工作的時候，對 PM 也是又愛又恨🥹。但我必須說 PM 真的是有好 PM 也有壞 PM（就跟工程師有好工程師和壞工程師一樣），在開發過程就是不斷的團隊合作，誰也不是故意來迫害誰的（沒那麼閒吧XD），一切都只是因為角色定位問題而已。

在我們努力充實自己的硬實力的同時、也要精進自己的軟實力，當到將來有能力能夠跟 PM 獨自打一架時，就表示你已經成為資深工程師了！

最後這次真的感謝 Eileen 願意熱情支援來解惑🥹，大家對 PM 話題有興趣的話，也可以追蹤 Taiwan Product Managers 臉書社團 ～

如果你對後端技術有興趣的話，也歡迎免費訂閱 《古古的後端筆記》電子報 ，每週二為你送上一篇後端技術分享，那我們就下一篇文章見啦！