PM is not PJM

信任建立與觀察期#

我想，任何一個人剛到一間公司入職的前半年，可以說是一個重要的信任建立期，同時也是彼此的觀察期。

我還記得，在第一個半年時就遇到了連續的加班需求。
大概是因為兩個 campaigns 跟一個較大的功能需求，導致我第一週加班了 20 小時，第二週則工作了 120 小時。

有人能接受一週工作 120 小時的工作嗎？
至少我是不行的。

當你過勞時#

而在面對這樣的環境下，如果是你會怎麼做呢？

• A：這個環境有毒，塊陶阿
• B：指出當前團隊的問題，看看誰來改變
• C：研究看看怎麼改善吧

我想，我是 C 的實踐者。

當然，這不是說每週都是這種瘋狂的 120 小時耐力賽，但光是「三不五時來一下」就已經讓人覺得無可救藥。

所以，在精疲力竭加班後，我讓自己好好休息，接著開始對當初的專案做 retrospection，思考到底是什麼導致了這樣可怕的工作型態。

那誰該管理需求？#

我發現最主要的核心問題是：沒有人在管理需求。
那麼，誰該被期待來管理需求呢？

PM，應該是吧。（註：這裡的 PM 指的是 Project Manager）

沿著這條線思考下去，我開始懷疑——
那些掛著 PM title 的人，為什麼不做專案管理？

是因為沒這方面的知識，不會？
還是因為這不是他們的主要產出，所以不想做？

PM 是誰？#

我決定直接約了 CTO，討論這次加班過勞的經驗，並分享我的分析結果。

在想要改善未來之前，得先搞清楚這件事：
PM 是不會，還是不想？

我記得 CTO 對我的角度算是支持的，不過他淡淡地說了一句：「我不知道這個答案對妳有沒有幫助，但我想這裡的 PM 不是 PJM。」

坦白說，我當時是驚訝的。

我的背景與期待落差#

在前一份工作中，我遇到了一位令人敬佩的 Principal PM。
她同時具備 Product Management 和 Project Management 的能力，讓我開始思考：

到底什麼是 PM 該有的技能與視角？

因此我花了一些時間和資源認真學習，這些知識也在後來的工作和生活中發揮了不少作用。

但話說回來，如果這裡的 PM 是只負責或專注在 Product Management，那也代表：

這家公司並不真正重視 Project Management，否則早就會投資資源，甚至跟升遷掛鉤了。

所以如果我要推動改變，就得確保推動專案管理的成本 不能高到會影響到別人原本的工作目標。

試著建構解法#

我開始去了解公司裡其他工程師的交付經驗。

發現除了專案管理是個掉下來的球，還有很多背景不同的同事會對工程師下需求，
但這些人往往 沒有完整的軟體交付知識流程。

如果無法直接改變人與知識，那麼建立一個 完整的流程 template，由各個團隊調整出適合自己的樣子，也許是可行的方向。

我當時就是這樣想的。

從觀察到 RFC 提案#

我不認為自己所經歷的開發流程能代表全部工程師的理解或共識。
所以，我做了一個規模不小的 RFC（Request for Comment）。

我先把過去的經驗整理成一份 有時間順序性的 task template，每個步驟都附上明確的說明與參考資料。

接著在提案文件中交代前因後果，邀請全公司的 engineers review。
一來一往中，回應同事的意見與建議，並根據討論不斷調整。

在三週搜集時間裡，我把這份文件迭代到了第 15 個版本。
我知道它不完美，也不需要完美。
因為它的目的就是讓我們能夠開始討論與改善。

實踐的開始#

我們團隊開始使用這份 task template 做為專案管理的基礎。

雖然這不能像專職 PM 一樣即時應變所有狀況，
但在開發工作體驗上有了顯著改善：

• 提需求前，該準備的資料有了檢核點
• 開發與討論中，有了依據與明確的歸納方向
• 若流程不完善，可以針對 template 進行修正，而不是對人究責

這樣的中介層，讓我們能把精力放在具體改善行動，而不是內耗與誤會。

從一人到多人#

後續其他團隊也開始導入並 PR（Pull Request）更多檢核點回來，
不同團隊依據風格與合作方式做出屬於他們的流程版本。

後來，這份 template 的概念也延伸到不同層級的需求管理與討論中，
讓具備特定領域知識的夥伴能更清楚說明需求，也幫助跨職能的同事順利交付。

看到這樣的成果，我感到非常樂意，甚至比一開始的預期還要滿足。

這還是你期待的嗎#

有同事問我：「以一己之力改變公司的開發流程很厲害，但現在變成不同流程的樣子，有符合你當初的期待嗎？」

我記得我是這樣回答的：

有的。因為我不覺得所有人長得一模一樣是好的。
而是能持續長出不同的樣子，這樣變成一種文化，
我覺得比我一開始單純想解決工作不舒適的期待還要好上 100 倍。

結語#

當然，並不是說從此以後日子就一帆風順。
畢竟關關還是得關關過。

只是我當時還不知道的是——
這段經驗背後，其實揭示了我未來的主要工作方向：塑造團隊文化。

而這，也正是我後來被 promote 為 Staff Engineer 的其中一個核心原因。

以下是依據原文語氣與內容，進行段落優化與排版調整的版本，適合部落格閱讀，無刪減或語意修改，僅做分段與標題建議，提升可讀性：