如何當一個技術 PM？從工程師角度來看 PM 需要具備的能力｜專家論點【朱騏】
前言
Arihant Kumar Jain 是一位印度資深後端工程師，這篇文章摘要他在《An Ideal Technical Product Manager, Extract from an Engineer’s Diary》對於技術 PM (Technical Product Manager，簡稱 TPM) 的建議。
我們往往不會珍惜好的人或產出，直到體會到賽的。
這句話是我出社會後幾年的心得。
遇到神隊友不但可以把事情做得又快又好、甚至還可以偷學幾招 ; 遇到雷隊友不但把事情做的又慢又鳥，甚至還可能被拖下水。
神隊友不見得跟我們是同職位的人，也不見得是同年資的人。但只要這個人夠厲害，我們就應該試著觀察與分析、甚至聽聽他們的建議（如果他還願意給建議的話），我有過太多次「聽君一席話，勝讀十年書」的工作場景，因此只要遇到就會特別珍惜。
這篇文章討論的雖然是技術 PM，但內容值得其他 PM 職位的人學習。包含：
- 了解基本的電腦科學
- 注重細節
- 了解組織產品的軟體架構
一、了解基本的電腦科學 (Computer Science)
Product Manager 依據專精的項目不同，可以再分成：
- Business product manager
- Marketing product manager
- Technical product manager (TPM)
從字面上就可以看出， 3 個職位在專業上分別著重於商業、行銷、技術。
以 TPM 來說，至少對於技術討論、解決方案的構想、資訊架構都要有基本了解，例如設計 API 時要知道 REST, CRUD, HTTP status code… 的觀念。
這就像對於 UI 設計，PM 要了解公司目前的 UI Library 大概有哪些 Componet，才不會鬧出像是「PM 想這樣設計，但因公司的 UI Library 不支援，而要花更多時間成本客製化」的窘境。
要了解軟體技術，最基礎的學科就是電腦科學 (Computer Science)。
除了在職場上邊做邊學，也要定期補充學科知識，才能了解軟體技術的基本原理。
二、注重細節
對於一個已經工作 2-3 年的 PM 來說，寫 Spec 應該算是駕輕就熟的事情。但決定「好」跟「專業」的 Spec， 差別就在於文件的細節。
例如寫 UI 的 User Story 時，除了 User Story、Functional Map、UI Flow 之外，記得要規劃錯誤訊息 (Error Message) 這種反面案例。如果 PM 不規劃，就會麻煩到 QA 、Developer 甚至 Designer 幫忙規劃，反而讓其他人有「 PM 是不是都沒先想這塊」的念頭。
如果是 API 的 User Story ，則要先跟 Senior 工程師或是主管確認是否有 API 文件 (例如 Swagger )，仔細考慮每個資料節點的收集與傳送。
「好」跟「專業」的一線之隔，在於細節。
三、了解組織產品的軟體架構
軟體開發除了注重 Coding 的技術細節，設計完善的軟體架構也非常重要。
許多公司開發求快的結果，就是在產品上線後要不斷地花時間進行重構 (refactor)。這就像是蓋一棟危樓，草草成案就動土開工，後續必須花大量時間進行修補工程才能支撐不倒。
TPM 在整個過程中，可以協助當紀錄與畫圖的角色。
透過和工程師一起討論架構、整理結論、用繪圖工具畫成流程圖、系統架構圖，都能夠幫助自己對於組織的產品軟體結構更加了解，在設計產品時能夠更有 Sense。
共同參與技術討論，協助紀錄與整理資訊讓自己更理解產品。
下篇文章繼續講剩下的 3 點訣竅。
瀏覽 2,185 次
