在專案現場，PM 最常有的一個感覺是：
「我明明把每一步都畫出來了，為什麼 RD 還是說這個流程會出事？」
很多流程圖看起來都很完整：
登入 → 下單 → 付款 → 完成
中間再加幾個判斷條件，看起來就像是教科書裡的標準範例。
可是，系統在實際運轉的時候，並不是照著你畫的箭頭，一路走到終點就結束了。
中間有很多「停下來」「等一下」的地方，
而這些地方，往往就是 bug 的來源。
簡單說，系統不只是 if、else，
更多時候是在處理「現在是什麼狀態」。
◆ 訂單不是「建立就完事」，而是一連串的「階段」
先從一筆最普通的訂單開始看。
在很多 PM 的流程圖裡，訂單大概會長這樣：
建立訂單 → 付款 → 完成
但是在系統裡，訂單真正經過的是一段比較像這樣的生命週期：
- 建立訂單
- 等待付款
- 確認付款
- 完成付款
然後故事還沒結束，後面還有：
- 申請取消訂單
- 審查訂單
- 確認退款
- 等待退款
- 完成退款
這些看起來只是不同的「文字描述」，
在系統裡，其實都是「狀態」。
每一個狀態，都代表系統現在停在某一個「階段」，
而不同的階段，要做的事情完全不同。
如果你只畫了「付款」「取消」「退款」這幾個框，
沒有把中間的狀態想清楚，
RD 看到的，就只會是一張「隨時會卡住」的流程圖。
◆ 同一個畫面，背後可能是完全不同的狀態
舉一個很常見的情況。
後台訂單管理裡，有一筆訂單一直停在「確認付款」。
這時候就會有一堆問號冒出來：
- 是消費者還沒去付款？
- 是金流那邊出了問題？
- 還是其實已經付款成功，只是狀態沒被更新？
畫面上只有四個字「確認付款」，
但對客服、財務、PM、工程師來說，想問的東西都不一樣。
客服會想：「我要跟客人說什麼？」
財務會想：「這筆應該算在已付款，還是未付款？」
工程師會想：「這種卡在中間的狀況，要不要觸發警示？」
如果在設計階段，我們沒有把「確認付款」拆細一點，
例如：
- 已送出金流請求，等待回應
- 金流回應失敗，需要人工處理
- 回應逾時，需重新查詢狀態
那到最後，就會變成所有「搞不清楚發生什麼事」的訂單，
全部都塞在「確認付款」這個模糊的狀態裡。
表面上看起來正常，
實際上就是一堆未處理的風險，靜靜躺在系統裡。
◆ 「取消訂單」看起來一樣，其實是三件完全不同的事
再看另一個大家都很熟的動作：「取消訂單」。
在流程圖上，常常就只寫了一個框：「取消訂單」。
但實際上，至少會有三種完全不同的情境：
- 未付款時取消
訂單還在等待付款，消費者按下取消。
這時候，系統可能只需要：- 把訂單狀態改成「已取消」
- 把庫存加回去
- 紀錄一筆「取消原因」即可
- 已付款後取消
這時候，就不是單純把訂單畫上一條刪除線而已。
系統需要：- 啟動退款流程
- 和金流或銀行互動
- 讓財務可以對帳
- 可能還要處理手續費、發票、報表
- 刷卡授權中就取消
這種情況很容易被忽略。
金流請求已送出，但交易還沒完成，
使用者在這個時間點按下「取消」。 那系統要怎麼做？- 等金流回應再決定？
- 先標成「取消中」，之後再用排程收尾？
- 還是完全禁止在這個時間點取消？
如果這三種情境，在設計時沒有被拆開來，
最後就會全部被塞進一個框：取消訂單。
對 PM 來說，畫起來很省事；
對 RD 來說，等於什麼都沒定義。
◆ 循序圖幫你抓時間線，狀態設計才是下一步
在上一回，我們談到「循序圖」，
用來看整個系統在一段時間內是怎麼互相呼叫的：
- 使用者按下「申請退款」
- 前端呼叫哪一支 API
- 後端做哪些檢查
- 有沒有丟訊息到佇列
- 什麼時候回應前端
- 什麼時候去跟第三方系統互動
循序圖可以幫我們把「時間」拉直，
看清楚哪裡在等、哪裡在跑、哪裡可能會卡住。
但光有時間線還不夠。
下一步要做的，就是把這些時間點，對應回「狀態」。
例如一筆訂單：
- 剛呼叫建立 API 回來那一刻，算什麼狀態？
- 丟給金流之後，還沒拿到結果之前，算什麼狀態？
- 金流回來失敗，但還可以重試時，又算什麼狀態？
這些如果沒有被定義清楚，
系統就很難在對的時間，做對的事。
◆ 為什麼 RD 總說「你這流程會死在這裡」？
很多 PM 都聽過這句話：
「你這裡會死在這一步。」
什麼叫「死在這一步」？
不是畫面不能跳下一頁，
而是這個狀態沒有「出口」。
例如：
- 有「付款中」，卻沒定義「多久算超時」
- 有「審查中」，卻沒想過「審查失敗去哪裡」
- 有「等待退款」，卻沒有「退款失敗怎麼處理」
這些狀態一旦缺少出口，
資料就會卡在那裡不動。
久而久之，你會在系統裡看到一堆：
- 永遠是「處理中」的訂單
- 永遠是「審查中」的申請
- 永遠是「等待中」的退款
客服不敢亂動，
財務不知道怎麼算，
PM 也說不太出來現在到底算成功還是失敗。
這就是 RD 看你流程圖會發毛的地方。
◆ 加上狀態思維，讓你的系統設計直接升級
嗨，我是廣三，
在軟體開發打滾二十年的 PM
回頭看這幾年的專案，
如果要用一句話來整理這一課，我會這樣說：
流程圖，負責告訴大家「接下來要做什麼」；
狀態設計，負責讓系統知道「現在到底算什麼」。
如果你只會畫步驟，
沒有把狀態定義清楚，
那流程圖看起來再順，
在 RD 眼裡還是充滿風險。
對 PM 來說，可以從一個很小的地方開始練習：
下次在畫流程圖之前，
先選一個實體（例如訂單、退款申請、會員資格），
寫下它從出生到結束，可能經過的每一個狀態，
再問自己兩個問題：
- 在什麼情況下會進到這個狀態？
- 從這個狀態出發，可以被允許走到哪幾個下一步？
如果你把這些圓圈（狀態）畫出來，
並用箭頭（條件）把它們連起來，
那就是所謂的「狀態機圖 (State Transition Diagram)」。
當你習慣這樣思考之後，
你會發現 RD 打槍你的理由，會慢慢改變，甚至無法打槍。
從一開始的：
「這樣會有問題。」
變成：
「我覺得這裡要再加一個狀態，之後查問題會比較清楚。」
那時候，你的流程圖就不只是「畫給別人看」，
而是變成一張真的可以拿來討論、實作、排錯的「系統經絡圖」。
而你，也不會是那個，
「畫流程圖一直被打槍的 PM」，
更有可能的是，「專業的技術型PM」。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言