前言
Arihant Kumar Jain 是一位印度資深後端工程師，這篇文章摘要他在《An Ideal Technical Product Manager, Extract from an Engineer’s Diary》對於技術 PM (Technical Product Manager，簡稱TPM) 的建議。
我們往往不會珍惜好的人或產出，直到體會到賽的。
這句話是我出社會後幾年的心得。
遇到神隊友不但可以把事情做得又快又好、甚至還可以偷學幾招 ; 遇到雷隊友不但把事情做得又慢又鳥，甚至還可能被拖下水。
神隊友不見得跟我們是同職位的人，也不見得是同年資的人。但只要這個人夠厲害，我們就應該試著觀察與分析、甚至聽聽他們的建議 (如果他還願意給建議的話)，我有過太多次「聽君一席話，勝讀十年書」的工作場景，因此只要遇到就會特別珍惜。
這篇文章討論的雖然是技術 PM，但內容值得其他 PM 職位的人學習。包含：
- 了解基本的電腦科學
- 注重細節
- 了解組織產品的軟體架構
- 掌握排序
- 高度文件化
- 掌握大事
1. 了解基本的電腦科學 (Computer Science)
Product Manager 依據專精的項目不同，可以再分成：
- Business product manager
- Marketing product manager
- Technical product manager (TPM)
從字面上就可以看出，三個職位在專業上分別著重於商業、行銷、技術。
以 TPM 來說，至少對於技術討論、解決方案的構想、資訊架構都要有基本了解，例如設計 API 時要知道 REST, CRUD, HTTP status code… 的觀念。
這就像對於 UI 設計，PM 要了解公司目前的 UI Library 大概有哪些 Componet，才不會鬧出像是「PM 想這樣設計，但因公司的 UI Library 不支援，而要花更多時間成本客製化」的窘境。
要了解軟體技術，最基礎的學科就是電腦科學 (Computer Science)。
除了在職場上邊做邊學，也要定期補充學科知識，才能了解軟體技術的基本原理。
2. 注重細節
對於一個已經工作兩到三年的 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)，仔細考慮每個資料節點的收集與傳送。
「好」跟「專業」的一線之隔，在於細節。
3. 了解組織產品的軟體架構
軟體開發除了注重 Coding 的技術細節，設計完善的軟體架構也非常重要。
許多公司開發求快的結果，就是在產品上線後要不斷地花時間進行重構 (refactor)。這就像是蓋一棟危樓，草草成案就動土開工，後續必須花大量時間進行修補工程才能支撐不倒。
TPM 在整個過程中，可以協助當記錄與畫圖的角色。
透過和工程師一起討論架構、整理結論、用繪圖工具畫成流程圖、系統架構圖，都能夠幫助自己對於組織的產品軟體結構更加了解，在設計產品時能夠更有 Sense。
共同參與技術討論，協助記錄與整理資訊讓自己更理解產品。
4. 開發排序
排序 (Prioritization) 是 PM 最重要的工作之一，這項技能也決定了一個 PM 是否有好的產品管理 Sense。
排序其實是由多項子技能組成，包含產品決策、利害關係人管理、責任感、邏輯推理、成本與效益衡量…。對於 TPM 來說，還加入了技術方面的考量，除了考量商業利益，也必須考慮到系統是否會產生過多的技術債 (Technical Debt)。
對於 TPM 來說，必須多分析技術方面的效益與成本，與商業決策作權衡後再做開發排序。
5. 高度文件化
不論是軟體開發還是其他領域的工作，都一定會有「問題-討論-決策-行動」的步驟，且都會面臨到「到底當初這個決策是怎麼做出來的？」問題。場景通常會像是：一群人開始翻箱倒櫃，找 Email、找線上文件區、找桌子旁的紙張、找通訊軟體的對話…這個現象你在公司中一定不陌生。
一個好的 PM 要非常重視「寫文件」這件事情，因為有事情別人第一個就是找 PM 確認。
對於 TPM 來說，還要多紀錄「功能技術決策」的原因。例如：
- 這個功能最後決定不多開資料庫欄位是因為…
- 前後台將透過這 3 隻 API 進行溝通，因為…
事實上公司中的每位角色都要有「寫文件」的意識，否則發生上述問題的時候，就只會有一句：「我不知道，那是 xxx 叫我做的。」
6. 掌握大事
身為 PM，組織中的利益關係人有事沒事都會第一個想到你，因此重要的事情都必須要能大致掌握。舉例來說：
- 工程師會質疑你的決定還有產品需求細節
- 主管會確認產品開發進度
- 老闆會詢問這個專案的成本與效益
這麼多的事情，PM 要做的就是 Get shit done。這仰賴於對大局的理解、對資訊的掌握。
當然人的大腦也沒辦法記那麼多事情，因此我們只要知道需要的時候去哪裡查就好，這件事的前提是有做好「文件化」這件事。
我不需要知道所有的事情，只要知道在我需要的時候去哪裡找到它。 — 愛因斯坦
( I don’t need to know everything, I just need to know where to find it, when I need it — Albert Einstein )
總結
最後我將 Arihant Kumar Jain 提的六個建議，總結成下方三點：
1. 多跟不同職位的人學習，聽聽從他們的角度是怎麼需要你的
我們以為自己做到的，可能跟別人實際感受到的不同。一個有效的策略是跟不同職位的人聊天，問問他們：你覺得一位 PM 應該要能夠做到什麼事情？
2. 親自參與討論，才能培養專業的 Sense
身為一個 TPM 要參與重要的技術決策、身為一個 Marketing Product Manager 要參與市場行銷的討論、身為一個 Business Product Manager 要參與公司商業策略的制定。
只有實際參與才能獲得深入的洞察。
3. 注重細節，多想一點
「好」跟「專業」的一線之隔在於細節，細節來自於規劃時的多方面考量，多方面考量來自於過往經驗的總結。
定期做工作成果盤點，將收穫應用在下一次的規劃上。
本文轉貼自：PM 的學習力工具箱（原文連結）
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
