文/衛斯理的職場修練與旅行故事

前言:

緊接著又要來到求職旺季，相信許多新鮮人對於電子業PM感到好奇，今天簡單介紹一下在電子五哥內（和碩/緯創/仁寶..等）RD PM工作在做什麼。

▲文組PM在科技業還是大有可為，重點在於自己是否有良好的心態&抗壓力

在系統廠中，RD PM（研發專案管理師） 是相當常見的 PM 職位。為什麼呢？其實不難想像，因為每間系統廠都會依據不同產品類型劃分成多個 BU（事業群），而每個 BU 內又細分成許多小組。這些小組每年都有大量新專案的開案與維護需求，而 RD PM 的核心職責 就是掌管新產品（NPI）的研發專案與進度管理。

推薦文章>>7 年工作經驗，挑戰 9 間科技大廠的 PM 轉職面試！

RD PM 的工作內容

系統廠RD PM工作內容其實就是跟著產品的開發週期走，而最重大的使命當然是將客戶的「新產品」如期/如質/如量的上市，例如：蘋果最新的IPhone每年九月上市，一定要拼死守住這個目標，也因為專案時程緊湊，RD PM的工作可說是相當的操勞，常常需要加班配合專案。

RD PM 的一天可能會這樣度過：

• 早上 9:00：與客戶晨會（新產品需求討論/專案Issue Review）
• 上午 10:30：確認 EVT 進度，與 RD 追蹤問題點，並確保產品能順利進入下一階段。
• 下午 1:00：跟NPI PM與供應商開會，確認物料交期 / 品質問題。
• 下午 3:00：跨部門會議，與品質/售後部門開會，討論產品售後流程。
• 下午5:00：跨部門會議，跟業務/工廠開會，討論產品生產轉廠計畫。
• 晚上 8:00：整理報告 / 準備明天的專案會議

下面用產品的研發階段來介紹RD PM在各個階段要負責的工作，包含但不限於以下內容：

RFI / RFQ 階段

RFQ=報價環節，許多 PM 新手一開始可能會疑惑，報價不是業務的工作嗎？為什麼PM需要報價，確實，最終報價由業務負責，但報價的基礎來自成本，而成本的掌控權通常在 PM 手上。PM 需要先收集成本資訊，最後由業務加上公司毛利目標後，提供報價給客戶。

1. RFI 階段：RFI（Request for Information）是非常初期的階段，此時資訊量少，需求也不明確。客戶可能只有一些初步想法，會先請 ODM 詢價了解市場狀況。
2. RFQ 階段：進入 RFQ（Request for Quotation）階段後，ODM 會針對產品提出各種不同的設計方案，並與客戶進行多輪討論。這個時候關於產品的需求逐步收斂，產品規格（如 ID/ME 尺寸、MB 規格等）也會陸續確定，最終依據這些規格輸出報價資訊給客戶。

正式開案

通常RFQ不會只有一輪，因為規格可能調整，中間會有好幾次輪的報價，在RFQ~正式成案之間，就是RD PM與業務合作的時刻，經過幾輪跟客戶的報價廝殺（砍價）以及schedule（壓時程） 的討論後，專案終於正式award(拿到offer)，這時候的專案才算正式成立了，開發流程隨之展開。

EVT（工程驗證階段）

EVT 是專案的第一個正式研發驗證階段，通常這個階段樣機（prototype）數量較少，因為主要是驗證工程設計的可行性，確保基礎功能正常即可，什麼是工程設計可行性? 舉例說明如下：

• 機構工程師：確認機構零件間有無干涉。
• EE 工程師：確認 PCBA (主機板)上元件溝通是否正常、線路是否無誤、主板能否順利開機。

此階段的重點在於早期發現設計缺陷，因此通常不會進行大規模的系統測試，也不會測試太多細部功能，主要確認產品能夠基本運作，並為後續的 DVT 做準備。

DVT（設計驗證階段）

進入 DVT，到了這個階段的樣品機數量會開始放大，因為開始正式驗證系統的功能了，要驗證的內容就會變得非常的多，以筆電產品舉幾個例子來說，可能會測試：

• 螢幕：色溫、亮度是否符合規範
• 主板：SI（信號完整性）是否正常
• 散熱：CPU/GPU 各元件溫度是否正常

此階段通常問題最多，時常發生各種「鬼故事」，像是某功能異常、系統無法啟動等，需要RD PM 迅速協調客戶、供應商與 RD 進行討論，常見情況例如：EMI訊號Fail，網速下載速率不達標，每天都有不同問題產生，算是最容易崩潰&加班的時期。

PVT（量產驗證階段）

PVT 是量產前的最後一個階段，身為在量產前最後一個階段，這個階段背負著重要的使命，目的就是「要放大產品在工廠生產的量」，試試看工廠大量生產是否有問題，例如：

• 生產面：生產治具是否有問題？
• 產品面：系統穩定性是否有提升？DVT 發現的問題是否收斂？

此外，這個階段也有很多的產品「認證」要展開，例如：環境認證/安規認證/RF認證…足繁不及記載，缺少了這些認證，產品可是無法上市的呢，因此這階段掌握這些認證的進度，對RD PM也是很重要的工作。

正式量產 & 上市

PVT經過之後，產品就開始正式小批量產了，這個階段基本上不應該再出任何問題（邏輯上），如果有問題也僅限於是一些「軟體」的問題，例如：某個driver/App的Bug後續需要透過Windows update更新，這樣的問題可能會被接受，畢竟產品已經到了量產，到這裡還有大問題需要產品重工(Rework)，可能要面臨全球招回(Global product recall)，如果責任在ODM身上的話，對於ODM來說可是一大筆損失。

再來，這個階段RD PM可能需要跟AM/物控/關務/物流team..合作，將準時產品送到客人全球的倉庫/工廠中，接下來就是準備產品正式上市開賣了！
最後RD PM要跟後續負責量產的PM交接案子的大小事，未來產品量產就交給你負責了！後續量產後，客人可能因應市場會有設計上的改變需求，例如：導入新款的CPU /驗證2nd source料件/物料轉廠..等等雜七雜八一堆需求，通通交給量產PM去操心即可。

結語，寫給文組PM新鮮人的一封信：

PM可說是案子的保母，RD PM更是ODM PM之中最熱門的角色之一，也是很多文組新鮮人想踏入科技業的第一站，我個人認為身為文組的PM能做到以下幾點，就是我認為及格的PM：

1. 梳理&搞懂客戶需求：PM身為資訊接收的第一站，最忌諱的一件事就是當傳聲筒/轉信站，客人需求不清不楚，直接轉信給RD，正確的操作方法是抓著客戶問清楚需求目的？最好有辦法收斂需求，提出更好的方案解決客戶問題，另外遇到不合理的需求（客戶想凹），為了保護團隊資源，必須要跟客戶據理力爭。
2. 技術細節不用懂，但大方向要掌握：文組PM弱勢就是技術能力，我個人也曾擔任過軟體開發RD ，我認為PM不需要懂得很細節，不需要會畫圖，或是親自寫Code ，但是至少要能夠跟RD溝通順利，不然兩者永遠在雞同鴨講。 以電腦產品舉例：EC是如何控制風扇轉速？BIOS裡有哪些參數是會影響系統效能的？什麼情境下需要使用示波器？波形圖怎麼看？Driver/OS/FW之間是怎麼溝通？不懂的問題先想辦法自己問AI或google，不要問出蠢問題，我相信RD們都是很願意解答，另外新人不要害怕發問，就算被罵問到了就是自己的東西。
3. 與RD培養好關係，站在同一陣線：我自己擔任RD時，也非常討厭所謂只出一張嘴的PM ，一聲令下就要RD照辦，也不管需求合理性，所以通常發生問題時，我都會跟RD站在同一陣線，一起去產線看問題，一起跟供應商開會，了解是哪個環節出錯，是哪個韌體需要更新？還是EE線路畫錯了？或是某某供應商的程式參數有問題？重點是要讓團隊有種「生命共同體」的感覺，而不是一句話就丟給RD處理。減少可能成為顧人怨PM的機率。

結論，我還是認為文組PM在科技業還是大有可為，重點在於自己是否有良好的心態&抗壓力，包含：不怕困難/挑戰的態度，凡事想辦法搞懂的學習態度，有能力承擔專案最終成敗的責任感，萬事起頭難，相信能做到以上的話，文組在科技業也能大方異彩。

如果你喜歡我的文章，請幫我在下方按讚或幫我註冊Liker ID，免費按讚支持我繼續創作下去！

※本文由 衛斯理的職場修練與旅行故事 授權勿任意轉載，原文《系統廠RD PM在做什麼？流程與挑戰及文組新鮮人建議》