[PMORY - 3] 同一個產品有三個 PM，為什麼反而更容易漏事情？
照道理來說，一個產品如果有三個 PM，應該會比只有一個 PM 更安全。
人變多了可以分工，有人顧版本、有人顧需求、有人顧營運、有人顧外部廠商，看起來事情應該比較不容易漏掉。
但實際上，很多團隊反而會遇到另一種狀況：人變多了，資訊也跟著分散了。
然後最可怕的事情就開始出現，每個人都以為：「這件事應該有人在處理吧？」
三個 PM，不代表有三倍的掌握度
假設一個產品目前有三位 PM。
PM A 主要負責版本上線。
PM B 比較常接營運和客戶需求。
PM C 負責日常 Bug、優化和一些跨部門協調。
表面上看，分工很清楚，但現實通常不是這麼整齊。
營運可能直接私訊 PM A、客戶在群組裡 @ PM B、RD 發現一個風險，順手跟 PM C 說了一句、主管臨時想到一個方向，又直接找其中一位 PM 討論。
最後就會變成：每個人手上都有一部分資訊，但是沒有人真的知道全貌。
問題通常不是「沒有人負責」
而是：大家都負責一點。
這種狀況其實比完全沒有人負責更麻煩，因為完全沒有人負責時，至少很快就會爆出來，但「大家都有碰到一點」時，事情很容易進入一個灰色狀態。
例如：
PM A 以為 PM B 已經跟營運確認需求。
PM B 以為 PM C 正在問 RD 技術可行性。
PM C 則以為 PM A 會在排版本時一起處理。
三個人都沒有真的忽略它，但三個人也都沒有把它完整接住。
直到兩週後有人問：「那個需求現在怎樣？」
大家才開始互看。
這時候最常出現的一句話就是：「我以為他有在處理。」
多人協作最容易漏的，不是大事，而是交界處
我覺得多人 PM 最難管理的地方，不是各自負責的事情。
反而是那些：不知道算誰的事情。
例如：
這是一個客戶需求，但又可能影響版本。
這是一個 Bug，但又需要營運確認。
這是一個版本風險，但根本原因是外部廠商。
這是一個產品優化，但需要先確認是不是共用需求。
這些事情很容易卡在角色交界，因為它不是百分之百屬於任何一個人，而只要責任沒有明確到「下一步誰要做什麼」，事情就很容易停住。
資訊透明，不等於大家都在同一個群組
很多團隊會覺得：「我們都在同一個 Slack 群、LINE 群啊，資訊應該是透明的吧？」
但其實不一定，
群組只代表：資訊有出現過。
不代表：每個人都看過。
更不代表：每個人理解的是同一件事。
同一段對話裡：
PM A 看到的是「這個客戶很急」。
PM B 看到的是「這個需求還沒確認」。
PM C 看到的是「這個版本可能會延誤」。
大家看到的是同一串訊息，但每個人帶走的重點可能完全不同。所以資訊透明真正困難的地方，不是訊息有沒有公開，而是：
現在這件事情的狀態、責任、下一步，有沒有被整理成大家都看得懂的樣子。
私人筆記越完整，有時反而越危險
這件事我自己也很有感。
做 PM 久了，每個人都會養成自己的管理方式。
有人很愛記事本、有人用 Excel、有人把 Slack 訊息 pin 起來、有人每天早上自己整理 Todo、有人乾脆把所有事情都記在腦袋。
單人作業時，這些方法都可以很好用，但只要進入多人協作，就開始有問題，因為你的筆記越完整，不代表別人看得到，你自己覺得：「我都有記。」
但團隊真正需要的是：「我們都有看到。」
這兩件事差很多。
最容易出事的是「你知道，但我不知道你知道」
多人 PM 很常出現一種資訊落差。
PM A 知道客戶已經確認，但 PM B 不知道 PM A 已經知道。
PM B 知道 RD 有技術風險，但 PM C 不知道這個風險已經被提出。
PM C 知道某個 Bug 會影響 Release，但版本負責人以為只是一般 Bug。
資訊本身都存在，只是沒有被連起來。
這時候真正的問題不是缺資訊，而是缺乏：共同的專案視圖。
每個人都很忙，所以「同步」本身也會變成成本
多人一起管理產品時，最直覺的解法就是多開會。
週會、Daily、版本會議、Bug meeting、需求會議、同步會，確實可以降低很多資訊落差，但另一個問題又出現了。
如果所有資訊都只能靠會議同步，那 PM 的時間很快就會被會議吃掉。
而且開會同步完以後，如果沒有留下結構化紀錄，三天後又要再同步一次。
所以我後來會覺得：好的協作，不是大家一直互相報告，而是系統本身就能讓大家知道：現在發生了什麼。誰在處理、卡在哪、下一步是什麼。
多人 PM 真正需要的是「共享工作桌」
我很喜歡把這件事情想成「工作桌」。
一個 PM 自己工作的時候，桌上可能有很多東西：
待確認的需求
正在追的 Bug
還沒發案的事項
等別人回覆的事情
本週的版本風險
主管剛提到的新方向
如果三個 PM 各自有一張私人工作桌，就算每張桌子都整理得很好，彼此還是很容易漏資訊。
所以多人協作需要的，不只是三張漂亮的桌子，而是：有一塊大家都看得到的共享區域。
知道：
這件事情現在在哪、誰在看、誰下一步要動、跟哪些 Task、Bug、Release 有關、是否需要別人接手。
我後來在 PMORY 裡很在意「狀態」和「人」要一起被看見
很多看板很重視狀態，Todo、Doing、Done，但多人 PM 的情境裡，只知道狀態還不夠。
更重要的是：誰正在消化這件事？
例如一張卡片是「待確認」。
但到底是：等 PM A 確認客戶？等 PM B 問營運？還是等 PM C 找 RD？
這三種雖然都叫「待確認」，實際上完全不同。
所以我會希望系統能同時看見：
目前狀態
負責人
所屬產品線
來源
下一步
是否需關注
關聯 Task / Bug / Release
讓大家不是只看到：「這張卡還沒動。」
而是知道：「它為什麼還沒動。」
另一個很常見的問題：同一件事被做兩次
多人 PM 不只容易漏事，也很容易重複做事。
PM A 收到需求，開始找 RD 評估。
PM B 後來也收到類似需求，不知道 A 已經問過，又再問一次。
RD 就會開始覺得：「你們 PM 彼此有沒有在講？」
這其實很傷協作品質。
因為對 RD、QA 或其他部門來說，他們不一定知道 PM 內部怎麼分工。
他們看到的只有：同一件事情一直有人來問。
所以多人 PM 的資訊透明，不只是 PM 自己方便。
也是對其他協作單位的一種尊重，讓別人不用一直重複回答一樣的問題。
產品越大，這個問題只會越嚴重
一個小產品，可能一個 PM 就能全部掌握。
但當產品慢慢變大：
功能越來越多
外部供應商變多
活動變多
版本頻率提高
Bug 增加
客戶增加
PM 人數增加
這時候就不可能再靠：「大家彼此記得就好。」
因為人的記憶會開始變成系統瓶頸，越資深的人越忙、越重要的人越容易變成資訊中心，最後所有人都跑去問同一個人。
這個人就會變成：人肉資料庫。
真正成熟的協作，不應該什麼都問資深 PM
我覺得這也是很多團隊很容易忽略的地方。
如果所有資訊都只能問某個資深 PM 才知道，其實代表資訊還沒有真正變成團隊資產。
例如：
「這個供應商以前有出過問題嗎？」
「這版為什麼延？」
「這個需求是不是以前討論過？」
「這個 Bug 是不是重複的？」
如果每次都要找一個人問，代表知識還鎖在人身上。
多人 PM 的最大價值，不應該只是多幾個人幫忙追事情，而是讓整個產品的資訊與經驗，可以被共同管理。
這也是我覺得 AI 未來很有意思的一個地方
如果多人 PM 的資料都有被整理好，AI 就不只是個人助理，它可以變成團隊的共同助理。
例如 PM A 問：
「這個需求最近有人處理嗎？」
AI 可以找到 PM B 已經建立的相關事項。
PM C 問：
「這版有哪些還沒解決的風險？」
AI 可以一起看 Task、Bug、Release、SOP 和最近的戰情訊息。
甚至有人問：
「為什麼這件事一直卡？」
AI 可以從歷史紀錄裡整理：
現在卡在哪個人、哪個外部依賴、哪個決策。
這時候 AI 的價值就不是「幫我寫東西」。
而是：幫團隊減少彼此不知道對方知道什麼。
但 AI 之前，還是同一件事情最重要
這系列我好像一直在講一個很無聊的結論：先把資料整理好。
但我真的越來越覺得，這才是核心。
如果 PM A 的資訊在私人筆記、PM B 的資訊在 LINE、PM C 的資訊在自己的 Excel，那不管 AI 多厲害，都很難真的理解這個產品，AI 最後看到的只是碎片。
所以多人協作真正要做的第一步，不是先買更強的 AI，
而是讓重要事情：進入同一個可理解、可關聯、可追蹤的專案脈絡。
最後
同一個產品有三個 PM，不一定會比較不漏事。
如果資訊還是分散在三個人的腦袋、三份筆記、三個聊天視窗裡，反而可能多了更多資訊縫隙。
真正有用的不是：「我們有幾個 PM。」，而是：我們是不是在看同一張專案地圖。
知道誰在處理什麼、知道哪些事情還沒有人接、知道哪些其實是同一件事、知道目前真正卡在哪裡、知道別人已經知道什麼。
如果可以做到這些，多人協作才真的會從「多幾雙手」，變成「多幾個腦袋一起工作」。
而不是三個人各自忙得要死，最後一起問：「欸，這件事到底誰在處理？」
下一篇，我想繼續聊一個很常見的問題：
你以為大家都知道現在做到哪？其實每個人腦中的版本都不一樣。
留言
張貼留言