[PMORY - 2] 每天事情很多，但到底有哪些事真的需要做？
做 PM 或企劃久了，應該都很熟悉一種感覺。每天都很忙，訊息很多、需求很多、問題很多、會議很多、待辦也很多。
早上才剛開始工作，手上可能就已經有：
昨天還沒追完的事情
今天臨時冒出來的需求
老闆突然想到的功能
客戶希望「順便」加上的東西
RD 說可能有風險的地方
QA 說還要再確認的問題
其他部門問你什麼時候可以做
每一件看起來都不能不管，但真正讓人累的不是「事情很多」，是那些「到底哪些事情真的需要做」？
忙，不代表所有事情都同樣重要
以前有一段時間，很容易把「有人來問」理解成「這件事我要處理」。
有人來問，就記下來。
有人催，就往前排。
老闆問，就標高優先。
客戶問第二次，就覺得是不是很急。
久了之後，待辦越來越長，事情明明一直有在做，但很奇怪，整體卻沒有比較輕鬆。
每做完一件，又會有兩三件補進來，甚至有些事情做到一半，才發現這個其實好像不用做。因ˋ為對方只是想先知道可不可行，又或者這件事情另一個團隊已經在做了。
最尷尬的是那種，你花了兩天整理、評估、找人確認，最後得到一句「喔，那先不用。」
如果你常有這種現象，下次事情進來前，你先好好確認你自己，是不是直接進入了「執行模式」?略過了應該先有的「判斷模式」?
PM 很重要的一個工作，其實是幫事情排隊
如果所有需求都有無限的人力、時間和預算，那專案管理大概會簡單很多。
但現實通常剛好相反。
五件事情同時來，RD 只有兩個人，QA 也有別的版本要驗，這個月還已經排了兩個 Release。
已經一堆接了一大堆問題還沒消化，還要不要繼續收下任務?
這件事情要不要做？這件事情，現在要不要做？
有些事情值得做，但不是現在。
有些事情現在很吵，但其實不重要。
有些需求聲音很大，只是因為提出的人剛好比較積極。
有些真正重要的問題，反而沒有人一直催。
所以我後來會覺得，PM 有點像交通警察，每一台車都想先過，
但如果你真的全部一起放行，最後就是全部塞住。
事情的「聲量」和「重要性」常常不是同一件事
這件事情我自己很有感。
工作上最容易被優先處理的，通常是：
最常被問的
最常被催的
聲音最大的人提出的
現在看起來最急的
今天剛好發生的
但這不代表它一定最重要。
例如有人突然來說「這個按鈕顏色可以今天改嗎？客戶覺得不好看。」
另外一邊，其實有一個月底要上線的功能，還有一個 API 規格沒有確認。
如果單純看誰催得比較急，按鈕顏色很可能先被排進去，但對整個專案來說，真正可能造成延期的，是那個沒有人一直問的 API。
這也是我後來覺得，待辦不能只是一張清單，因為清單只能回答「我有哪些事情？」
但PM 更需要的是「這些事情之間，誰應該先？」
我現在比較習慣先問幾個問題
收到一件事情時，我現在比較不會馬上想「要不要開單」，我會先問：
Q1.這件事情是真的問題，還是只是一個想法？
有些人說「如果這邊可以多一個篩選好像不錯。」，這不一定代表「請幫我做一個篩選功能。」
可能只是分享使用感受。
Q2.如果現在不做，會發生什麼？
這題我覺得很好用。
如果答案是「其實也沒什麼。」，那大概真的不用立刻插隊。
如果答案是「月底 Release 會卡住。」，那優先度就完全不一樣。
Q3.這件事情影響多少人？
一個人偶爾遇到一次。
和五個不同客戶一直遇到同樣問題。
看起來都是「一個需求」。
實際上重要程度差很多。
Q4.有沒有前置依賴？
有些事情看起來不急，但其實現在不開始，兩週後就會出事。
例如：
等外部廠商
等 API
等 Design
等法務確認
等 Production credential
等資料準備
這類事情最容易被低估。
Q5.它是不是其實跟別的事情一樣？
這也很常發生。
A 客戶說登入很麻煩。
B 客戶說希望登入步驟少一點。
客服又收到玩家抱怨驗證流程很複雜。
如果三件事情分開看，很像三個小問題，
放在一起看，可能其實是同一個產品問題。
有些「待辦」真正需要的不是完成，而是決定
我以前會把 Todo 想得很單純，就是還沒做完的事情，但現在我會把它拆成很多不同狀態。
例如：
待釐清
待確認
待評估
等回覆
等決策
暫緩
待發案
正式執行
因為有些事情的下一步不是「做」，而是「做一個決定」。
比如，「這個需求要不要進下一版？」
它現在最需要的不是 RD 寫 Code， PM 需要的是能不能找到正確的人，把需求範圍確認完。
又例如：「供應商說最快兩週後才能提供 API。」
這件事情現在也不是工程師可以解決，它需要的是重新判斷時程。
如果所有事情都只叫 Todo，很容易讓人誤以為只要努力做，就會變少。
其實很多時候，真正卡住的是「沒有人做決定」。
多人一起管同一個產品時，這件事會更明顯
如果只有自己一個人管理，至少腦袋裡還知道自己最近在追什麼，但只要變成多人 PM、多人企劃一起管同一個產品，問題會突然放大。
PM A 收到客戶需求，PM B 收到營運回饋，企劃 C 又從客服那邊知道類似問題，三個人都先各自記著，過兩週才發現，大家其實在追同一件事情。
另外一種狀況是反過來，大家都以為「應該有人在處理」，最後沒有人真的在處理。
所以多人協作時，比「誰手上有多少事情」更重要的是「大家能不能看見彼此正在消化哪些事情」。
哪些已經確定要做、哪些還在等答案、哪些其實可以合併、哪些目前根本不需要動。
這些資訊如果只存在每個人的私人筆記裡，協作成本會非常高。
我後來在 PMORY 裡，刻意讓「還沒做」也有不同意思
這也是我在整理 PMORY 時很在意的一件事，我不想讓所有事情進來之後，都只剩Todo / Doing / Done。因為對 PM 來說，事情在正式執行之前，其實已經有很多狀態。
例如一件需求可以先是：
收到
↓
待整理
↓
待釐清
↓
待評估
↓
等待決策
↓
待發案
↓
正式任務
這樣做把流程搞複雜?
不，反倒是減少一種很常見的焦慮「我的 Todo 怎麼永遠這麼多？」
當你看清楚每一件事情現在到底需要什麼，會發現很多事情其實不是「等你去做」。
它可能只是在等別人的資訊，可能暫時不值得投入，也可能還沒到現在，甚至可能可以直接不要做。
對 PM 來說，「不做」其實也是很重要的決策
這一點我覺得很難，因為「接受一個需求」通常比「拒絕一個需求」容易。
接受只要說「好，我先記。」，拒絕則要回答：
「為什麼？」
「那什麼時候做？」
「別的事情為什麼比我重要？」
所以很多需求最後不是被拒絕，而是進入一種神秘狀態「先放著。」
然後半年後還躺在 backlog。
其實好的專案管理，不一定是把 backlog 變得越來越完整，有時候在於你敢不敢把不重要的東西移出去的管理。
因為每一件留下來的事情，都會佔用一點注意力，即使沒有真的執行，它還是會讓人覺得「這件事情我是不是漏了？」
所以整理待辦，不只是排優先順序，也包含讓一些事情有資格離開清單。
如果系統可以幫忙看出「重複出現的事情」就更有意思
這也是我最近覺得 AI 真正有價值的地方。
不是幫 PM 自動排一個 1、2、3、4。
因為優先順序最後還是跟商業策略、人力、時間有關，不能完全交給 AI。
但 AI 可以幫我們看到一些平常很難察覺的訊號。
例如：
「這三個月有四個不同來源提到相似需求。」
「最近兩週跟 Payment 相關的問題明顯增加。」
「這個需求跟去年做過但後來暫停的功能很像。」
「這件事情雖然沒人催，但它關聯到下週的 Release。」
這些不是決策資訊，是把 PM 原本要自己花時間翻聊天、翻 Task、翻 Bug、翻文件才能發現的東西，先整理出來。
對我來說，這種 AI 比「幫我寫一段需求描述」更有價值。
所以真正要管理的，可能不是待辦，而是注意力
我後來慢慢覺得，PM 的工作不是把所有事情都做掉，那是不可能的。
PM 更像是在管理團隊有限的注意力，哪些事情現在值得大家看、哪些可以先放、哪些要追。
哪些要問、哪些已經有答案、哪些應該正式進入執行、哪些其實可以放棄。
如果這些事情沒有被整理，再強的執行團隊也會一直被插單和雜訊拖著走。
當這些事情整理得夠清楚，後面的看板、版本、Bug、SOP、報表，才會真的開始有意義。
最後
每天事情很多，大概不會因為用了什麼工具就突然變少。
需求還是會來，客戶還是會問，老闆還是會突然想到新東西。
Bug 也不會因為我們有一個漂亮看板就自動消失。
但至少我們可以讓自己更清楚現在真正需要處理的是什麼。
不是誰講得最大聲，也不是誰最後來問，更不是因為它剛好出現在今天。單純只是經過系統性的整理之後，我們清楚知道了：為什麼現在要做這件事、又為什麼另外一些事情，現在可以先不要做。
這其實就是 PM 很重要的一種能力：不是把事情全部接住，而是幫事情找到正確的位置。
系統真正應該幫忙的，不只是記錄我們有多少待辦，好的系統是讓那些原本只存在 PM 腦袋裡的 判斷、排序、等待、取捨，慢慢變得看得見。
下一篇，我想聊聊另一個多人協作後很容易遇到的問題：
同一個產品有三個 PM，為什麼反而更容易漏事情？
留言
張貼留言