專案管理最累的，其實是那些根本還不能叫「任務」的事
星期一早上，電腦才剛打開，LINE 群組先跳出一個訊息：「這個活動下週有辦法上嗎？」
Slack 另外一邊有人問：「昨天正式站那個問題是不是還沒完全好？」
坐在旁邊的同事順口補了一句：「對了，老闆上禮拜有提到那個功能，好像希望這個月可以先評估一下。」
然後信箱裡還躺著一封廠商寄來的新規格。
這時候如果你打開 Jira、Trello、Asana、ClickUp，甚至是自己公司的任務系統，常常會遇到一個很尷尬的問題。
我要開什麼單？
因為這些事情，現在其實都還不能算是一個真正的「任務」。
任務出現以前，其實已經做了很多工作
我以前一直覺得，專案管理工具最重要的事情就是把任務整理好。
誰負責、什麼時候做、做到哪裡、什麼時候完成。
後來做久了才慢慢發現，真正讓人累的，很多時候根本不是那些已經被整理好的任務。
反而是任務「還沒成立以前」的那一大段。
例如營運突然丟來一句：「最近玩家一直在問能不能增加這個功能。」
這到底是正式需求嗎？不知道。
有多少人需要？不知道。
是不是現在最重要？不知道。
技術上能不能做？也還不知道。
可是你又不能直接把它忘掉。
於是 PM 腦袋裡就多了一條暫存資料。
過幾天商務又說客戶也問到類似的東西。
這時候你才開始覺得，好像值得認真看一下。
接著你去問 RD。RD 說可以做，但如果這個月要上，可能會影響另外一個版本。
你再回頭跟營運確認優先順序。營運說：「沒有一定這個月啦，但最好不要拖太久。」
看到這裡，事情依然還沒有變成正式 Task。
但 PM 已經處理它一個禮拜了。
這就是我後來很常想到的一件事：
很多專案管理系統，是從任務成立之後才開始工作；但 PM 的工作，往往早在任務成立之前就已經開始了。
那些「先放著」的事情，最後到底都放去哪裡？
每個人其實都有自己的方法。
有人放在記事本。有人丟自己的 Slack。有人用 Google Sheet。有人在 Trello 開一個「待確認」。
有人直接靠腦袋。還有人最乾脆：傳訊息給自己。
我自己也做過差不多的事情。因為這些東西很難分類。它可能是一個需求。也可能只是一個想法。可能過幾天就不了了之。可能突然被老闆問一句：「上次那件事後來怎樣？」
然後你才發現，糟了，它已經在聊天訊息裡沉下去三個禮拜。
所以問題其實不完全是「有沒有記錄」。而是：
這些還沒有成形的事情，我們有沒有一個地方可以暫時管理它？
不是一收到就逼自己開成正式任務。也不是什麼都丟進 backlog，最後變成一個沒有人想看的垃圾場。而是允許它處在一個：「我知道這件事存在，但我還在消化。」的狀態。
PM 很多時間，其實花在「把模糊變清楚」
我覺得這也是 PM 很容易被低估的地方。外面看到的是：「開了一張單。」
但那張單出現之前，可能已經經歷了很多事情。
需求到底想解什麼問題？是真的需要，還是只是某個人隨口提出？現在做重要嗎？會影響誰？
有沒有其他事情已經在做？這件事情跟之前某個需求是不是其實一樣？有沒有歷史問題？是不是以前做過，後來失敗？要找誰確認？
確認完以後，是現在做、下個版本做，還是乾脆不做？
PM 很多價值，就發生在這些看不見的判斷裡。
只是這些工作通常很難留下紀錄。
最後系統裡只會看到：「TASK-1024：新增 XXX 功能」
然後大家以為這張 Task 就是故事的開始。
其實不是。
它通常只是前面一大串事情整理完之後的結果。
如果什麼都立刻開單，也不一定比較好
有人可能會說：「那全部都先開 Task 不就好了？」
這也是一種方法。
但做過一陣子以後，很容易遇到另一個問題。
任務清單會越來越肥。一堆：待確認、待評估、有空再看、可能會做、老闆好像有提過、客戶曾經問過。最後真正要執行的事情，反而被淹沒。
久了之後，看板就會開始失去可信度。
你看到 200 個 Todo，也不知道裡面到底有多少是真的要做。
所以我後來會比較傾向把兩件事情分開。
一種是：我現在正在整理、判斷、等待確認的事情。
另一種才是：我們已經決定要做，可以正式進入執行流程的任務。
這兩種東西看起來很像，但管理方式其實不太一樣。前者比較像 PM 的工作桌。後者才比較像團隊的施工單。
這也是我後來在 PMORY 裡很想先處理的一件事
做 PMORY 的時候，我最早在想的其實不是 AI。也不是要做一個比 Jira 更完整的 Task 系統。
我一直在想的是：那些還沒有資格成為 Task 的事情，到底應該放在哪裡？
因為這才是我自己工作裡最常出現的狀態。
所以在設計上，我希望一件事情可以先很單純地存在。先記下來、知道它從哪裡來、知道是哪一條產品線、知道誰正在看。知道它目前是待釐清、待評估，還是已經差不多可以發案。
等資訊慢慢補齊，真的確定要做了，再把它帶進正式的任務流程。
也就是：收到訊號 → 先整理 → 再判斷 → 最後才變成任務。
這個順序聽起來很普通，但其實跟很多工具的思考方式剛好相反。
很多系統是：先建立 Task，再管理 Task。
我比較想處理的是：先管理那些可能成為 Task 的事情。
對 PM 來說，這可能比再多一個漂亮看板更重要
看板當然重要，甘特圖也重要，報表、版本、Bug、SOP 都重要。
但如果最前面的需求入口本身就是亂的，後面的管理通常也很難真正乾淨。
一個不清楚的需求進入系統，最後就會變成一張不清楚的 Task。
一張不清楚的 Task 交給 RD，RD 就會做到一半開始問問題。
PM 回頭找營運，營運又說：「我原本不是這個意思。」
然後 QA 最後再發現規格和理解不一樣。
很多專案後面的混亂，其實早在任務成立以前就開始了，只是當時沒有被看見而已。
所以我現在反而越來越覺得，專案管理真正值得管理的，不只是：「現在做到哪裡？」
還應該包含：「這件事情到底是怎麼變成現在這個樣子的？」
有些事情，不需要現在決定，但不能讓它消失
這大概是我自己現在對「待辦」比較不一樣的理解。
待辦不是所有東西都一定要做，它更像是一個：我暫時不做決定，但我不要失去這個訊號。
的地方。
也許一週後你會刪掉它。
也許一個月後它會變成重要需求。
也許半年後你會突然發現：原來三個不同客戶，其實都在問同一件事情。
當這些訊號有被留下來，我們才有機會看見一些原本看不到的東西。
而我覺得，這才是 AI 未來真正有意思的地方，不是 AI 幫我寫一張 Task，而是有一天它可以告訴我：
「你這三個月已經收到第六次類似需求了。」
「這件事情跟上次那個 Bug 其實可能有關。」
「你原本覺得這只是小問題，但最近出現頻率正在增加。」
不過要走到這一步以前，第一件事情還是最無聊、也最重要的：先把事情好好留下來。
因為沒有資料，再聰明的 AI 也只能猜。
最後
如果你也是 PM、企劃，或者工作內容常常介於「有人提出事情」和「真的有人開始做事情」之間，我猜你應該很熟悉這種感覺。
每天收到很多訊息，不是每件都能立刻決定，但每一件又都有可能在某一天突然變重要。
我們真正需要的，也許不只是另一個幫我們管理「已經確定要做什麼」的工具。
而是一個可以陪我們把：模糊的事情，慢慢整理成清楚的事情的地方。
這也是我開始整理 PMORY 時，很想先解決的第一個問題。
下一篇，我想再聊聊另一個很常見的狀況：
明明每天做很多事，但到底哪些事情真的值得排進來？
留言
張貼留言