[PMORY - 4] 你以為大家都知道現在做到哪？其實每個人腦中的版本都不一樣
做專案有一個很有趣的現象，大家明明都在同一個群組，也一起開過會、需求文件有寫、Task 也開了，甚至昨天才剛同步過一次，結果今天再問一句：
「所以這件事情現在到底做到哪？」
你可能會得到三個不同答案，
PM 說：「差不多了，應該快可以送測。」
RD 說：「主要功能好了，但還有兩個例外流程沒處理。」
QA 說：「我還沒拿到可以驗的版本耶。」
營運則可能以為：「不是說這週要上嗎？」
大家都沒有說謊，也都沒有偷懶，只是每個人腦中的「做到哪」，其實不是同一件事。
專案最麻煩的地方，不一定是沒有資訊
很多時候反而是：
資訊太多，但彼此沒有對齊。
例如一個功能從需求到上線，中間可能經過：
需求確認
↓
技術評估
↓
開發
↓
整合
↓
送測
↓
Bug 修正
↓
複驗
↓
允收
↓
上線但每個角色關心的節點不一樣。
對 PM 來說：RD 做完，可能已經覺得「進度差不多」。
對 RD 來說：Code 寫完、自己測過，也許就算完成。
對 QA 來說：沒有正式送測，就代表還沒開始。
對營運來說：正式站還沒看到，就等於「還沒做完」。
所以同一句：「完成了嗎？」
其實每個人的完成定義都不一樣。
最常見的問題，是大家都在講自己的進度
這件事在跨部門特別明顯。
RD 說：「我這邊好了。」
QA 說：「但還不能測。」
PM 說：「那現在到底算好了還是沒好？」
RD 覺得自己明明已經做完。
QA 也覺得自己說得沒錯，PM 最後只能開始翻聊天紀錄。
才發現：
原來 RD 所謂的「好了」，是開發完成，但還缺一個測試環境設定，設定要另外找系統部，系統部還不知道這週要處理。
所以問題根本不是「誰沒有做」，而是：
我們把不同階段的完成，全部用同一個字在描述。
「做到哪」如果只能靠人解釋，PM 就會一直當翻譯機
這也是 PM 很常做的一件事，
RD 說：「已經 Merge。」
PM 要翻譯成：「開發完成，但目前還沒有送測。」
QA 說：「還有兩個 Case Fail。」
PM 又要翻譯成：「目前正在驗收，還有兩個問題要處理，所以暫時不能上線。」
營運問：「星期五能不能上？」
PM 再把所有人的資訊重新拼一次。
有時候我會覺得，PM 很像人肉 API，不同部門講自己的語言，PM 負責把這些資訊轉成另一個人聽得懂的版本。
偶爾做當然沒問題，但如果每一次進度查詢都要靠 PM 現場翻譯，久了就會非常累。
最危險的不是「紅燈」，而是大家以為是綠燈
真正讓專案容易出事的，通常不是明確知道有問題的東西。
如果大家都知道：「這個版本現在卡住了。」
反而很好處理，因為至少會有人注意。
比較危險的是：
PM 以為 RD 已完成。
RD 以為 QA 已經知道。
QA 以為這一版還沒正式送測。
營運則以為星期五照常上線。
每個人的畫面看起來都沒有大問題，直到星期四下午才有人發現：
「欸？這版不是明天要上嗎？」
這種事情我相信很多人都遇過，而且通常不是因為某個人忘記做，是因為：
每個人看到的專案狀態都只是一小部分。
一張 Task 很難代表整個專案真實狀態
很多團隊會用 Task 狀態來判斷進度。
例如：
Todo
Doing
Done很簡單，也很好用，但事情一複雜，就開始不太夠。
假設 Task 已經 Done，可是它關聯的 Bug 還有三張沒修完。或者功能開發完成了，但 SOP 還沒更新。又或者 QA 已經通過，但 Production 的設定檔還沒準備。
這時候 Task 是 Done，那這個版本到底算不算準備好了？
很難說。
這也是我後來覺得，專案管理不能永遠只從「任務」往下看。
有時候要往上一層看：
這些 Task、Bug、SOP、文件、版本，到底共同組成了什麼狀態？
同一件事情，最好只有一個「現在」
我自己越來越在意一件事情：
專案裡可以有很多不同人的觀點，但最好不要有很多個不同的「現在」。
例如：
Release 目前是：送測中。
那大家看到的就應該是送測中。
如果還有兩個 High Priority Bug，也應該一起看得到。
如果 DB Change 還沒確認，就應該明確掛在這個版本下面。
如果上線日改過，歷史要留下，但現在的正式日期應該只有一個。
不是：
PM 的 Excel 是 9/18。
群組公告是 9/20。
Google Calendar 是 9/22。
主管腦袋裡還停在 9/15。
這種情況其實比沒有排程更麻煩。
我覺得「資訊透明」不是把東西全部公開
有時候大家聽到資訊透明，會想到：所有人都看所有資料。
但我覺得不是。
真正有用的資訊透明比較像：
需要這個資訊的人，可以在需要的時候看到正確版本。
例如，RD 不一定需要看完整商業談判內容，QA 也不一定需要知道所有客戶細節。
但如果一個需求改了，會影響測試範圍，那 QA 就應該知道。
如果某個 Bug 會影響這次 Release，那負責版本的人就應該看到。
如果上線日期改了，跟這版有關的人應該看的是同一個日期。
所以透明不是「什麼都給你看」。
而是：
該被看到的東西，不要靠問人才知道。
這也是為什麼我會希望 Task、Bug、Release、SOP、文件不是各自獨立
以前用工具時，我自己也常常有這種情況。
Task 在 A 系統，Bug 在另一張表，Release 日期在 Google Sheet，SOP 是一份文件，測試結果在群組，正式規格又在 Google Drive。
每一份都管理得很好。
問題是：它們彼此不知道對方存在。
所以每次要回答：「這個版本現在到底能不能上？」
然後PM 就要開始拼圖，先看 Task、再看 Bug、再問 QA、再確認文件，最後看一下群組有沒有突然出現新問題。
如果每次都要人工拼一次，代表我們其實沒有真正的「版本狀態」，我們只是有很多資料。
所以我後來在 PMORY 裡，想讓資料彼此有關係
例如一個 Release 不只是日期和名稱。
它應該可以看到：
這一版有哪些變更項目
↓
有哪些 Task
↓
有哪些 Bug
↓
有哪些 SOP
↓
有哪些文件
↓
目前驗收到哪
↓
還有什麼風險這時候 PM 不用自己在腦袋裡拼，其他人也不用一直來問 PM，因為大家看到的是同一個專案脈絡。
儀表板真正的用途，也不是讓畫面看起來很專業
很多系統都很喜歡做 Dashboard。
圓餅圖、長條圖、紅黃綠燈，看起來很厲害。
但我覺得 Dashboard 真正有價值的地方，不是圖表很多。
而是它能不能回答幾個很普通的問題：
現在有沒有事情要擔心？
哪個版本可能有問題？
哪個人手上的事情太多？
哪些 Bug 還沒解？
哪些事情已經停很久？
下一個需要決策的是什麼？
如果一個儀表板不能幫忙回答這些問題，再漂亮也只是裝飾。
PM 最常被問的，其實就是幾個問題
主管來問：「現在進度怎麼樣？」
營運來問：「這週會上嗎？」
RD 來問：「這個需求確定了沒？」
QA 來問：「現在可以測了嗎？」
客戶來問：「什麼時候會好？」
你會發現大家其實一直在問同一件事情：「現在到底是什麼狀態？」
只是每個人站的位置不同。
所以好的專案系統不應該只是幫 PM 保存資訊，而是要讓同一份資訊，可以被不同角色理解。
如果資料整理得夠好，AI 才真的能幫忙解釋「現在」
這也是我覺得 AI 在專案管理裡很實際的一個用途。
例如主管不一定想打開 20 張 Task。
他可能只想問：「這週 Payment 版本有沒有風險？」
如果系統本身知道：
Release 日期
Task 狀態
Bug 狀態
SOP 完成度
QA 結果
最近戰情訊息
歷史類似問題
AI 就可以幫忙整理：
「目前主要功能已完成，但還有兩個 High Priority Bug 尚未複驗，另外正式環境 whitelist 尚未確認，因此目前上線風險偏高。」
這種回答有價值，因為它不是自己猜，它只是把原本散落的狀態，整理成人看得懂的語言。
但如果底層資料本身就不同步，AI 只會把混亂講得更漂亮
這也是為什麼我一直不太相信：
只要加一個 AI Chat，就算 AI 專案管理。
如果 Task 說完成、Bug 表說還沒修、Release 日期有三個版本、文件又沒更新，那 AI 再聰明，也只是從不同的錯誤答案裡挑一個講給你聽。
所以 AI 之前還是要先做一件很樸實的事情：
讓大家看的是同一份現在。
我覺得專案管理真正難的，不是記錄過去，而是維持共同現況
過去發生什麼，可以慢慢整理。
但專案正在跑的時候，大家對「現在」的理解如果不一樣，問題會一直累積。
而 PM 最消耗的地方，就是不停地修正這些理解差異。
「那個不是完成，是開發完成。」
「日期後來改了。」
「那張 Bug 跟這次版本有關。」
「那份文件不是最新版。」
「這個需求昨天已經改掉了。」
如果這些話每天都在重複出現，其實代表系統沒有幫我們維持共同狀態。
最後
我現在越來越覺得：
專案管理裡真正重要的，不只是每個人有沒有把自己的事情做好。
而是：我們是不是都知道現在真正發生了什麼。
三個人可以有不同工作，五個部門可以有不同角度，但到了某個專案、某個版本、某個重要需求時，最好還是能回到一個共同的答案。
現在在哪裡、下一步是什麼、誰要處理、還有什麼沒完成、有沒有風險，如果這幾件事情清楚，很多跨部門溝通其實會自然變少。
因為大家不需要一直問：「現在到底做到哪了？」
而當系統真的能回答這個問題時，PM 才有機會把時間從「一直同步狀態」，移回真正更重要的事情：判斷接下來應該往哪裡走。
下一篇，我想開始談一件我覺得比 Task 本身更重要、但很多團隊最容易忽略的事情：
同樣的坑，為什麼每半年都要再踩一次？
留言
張貼留言