有一段時間，只要專案進到比較後面一點，我就會開始有一種微妙的不安感。
文件寫了、流程也畫了、跨單位的泳道圖也整理好了，看起來好像很完整。
但只要專案一進到「串接」階段，問題就會像從地板縫裡冒出來一樣。
前端說：「這裡我有塞一個暫時用的參數。」
後端說：「這個欄位先寫死，以後再改。」
第三方金流說：「我們 API 回傳失敗時，不一定會回 error code。」
然後你就會看到一個很熟悉的畫面：
測試環境一直轉圈圈，
正式環境偶爾翻白或是顯示500，
工程師皺著眉頭地看著 log，
PM 站在中間不知道要先回應客戶，還是先找大家開會。
那時候我才慢慢意識到一件事：
前面那些實體圖、泳道圖，
確實幫助我們看清楚「誰在系統裡」，「大概會做什麼」。
但它們還少了一塊關鍵的拼圖：
這些東西，到底是「怎麼互相叫來叫去」的。
這就是循序圖要處理的事。
◆ 當 PM 只看到畫面，RD 已經在想「資料怎麼跑」
多數 PM 在思考系統時，第一眼看到的都是畫面：
使用者按哪個按鈕、看到哪一個頁面、下一步去哪裡。
這沒有錯，這是我們的工作。
只是，當你只停在這個層次的時候，你看到的是「使用者的操作順序」，
但工程師在意的是另一件事：
-每按下一個按鈕，
-背後會觸發哪幾個請求、
-這些請求之間有沒有順序，會不會衝突、
-有沒有彼此依賴、
-會不會在某個地方卡死。你腦中的是介面跟流程，
RD 腦中的，是一串又一串的「呼叫關係」。
循序圖，其實就是把這些「呼叫關係」攤開來給大家看。
◆ 光有泳道圖不夠，還要看清楚「誰先叫誰」
在上一回我們談到泳道圖，用退款當例子：
-使用者按下退款申請、
-客服審查、
-財務確認、
-金流或銀行處理、
-最後再回寫結果。泳道圖很適合拿來看「跨單位流程」：
誰先、誰後、輪到誰接球。
但當你開始進到實作細節，問題就變成另一種：
-使用者按下「申請退款」的那一刻，
-前端到底呼叫了哪一支 API？
-那支 API 有沒有再去丟訊息到排程？
-排程有沒有再去打第三方金流？
-第三方金流回來的結果，是直接回前端，還是先寫資料庫？
-如果第三方沒有回應，系統要等多久？
-等不到要不要 retry？retry 幾次？這些東西，用泳道圖很難畫清楚。
你會發現線條畫到最後，只剩下一張混亂的蜘蛛網。
這時候，就輪到循序圖出場了。
◆ 一個「申請退款」背後，其實是兩條時間線
我們用最簡化的退款場景來看。
對使用者來說，他只看到一件事：
按下「申請退款」 → 等一下 → 畫面出現結果。
但在系統裡，至少會有兩條時間線同時存在：
-前端介面的時間線
-後端處理的時間線如果你只畫：
使用者 → 後端 → 回傳結果
看起來好像很單純。
但只要情況稍微複雜一點，就會完全不是這麼回事。
例如：
-使用者按下「申請退款」之後，
-前端立刻把按鈕鎖住，顯示 loading 動畫，
-同時呼叫「建立退款申請」的 API。後端收到請求後：
-先檢查訂單狀態，
-再檢查是否已經有退款申請在處理中，
-再建立一筆「退款申請中」的紀錄，
-再丟一個訊息到「金流處理」的佇列，
-最後才回給前端一個「申請已送出」的狀態。
前端收到這個狀態後，
把畫面改成「退款審核中」，
使用者關掉頁面去忙別的事。
真正的退款處理，可能還在後面幾分鐘才慢慢發生。
這整個過程，如果沒有用循序圖拉成一條線，你很容易只會描述到：
「按了之後，狀態變成退款審核中。」
聽起來合理，
但對 RD 來說，等於什麼都沒講。
◆ 系統真正會出事的地方，往往都藏在「間隔」裡
循序圖有一個好處，就是會逼你去面對那些平常會略過的細節。
例如：
當後端在處理退款時，
使用者如果又重新整理畫面，畫面要長什麼樣子？
當第三方金流延遲很久才回應，
這段時間內，客服如果查詢這筆訂單，要看到什麼狀態？
當後端已經把退款狀態改成「失敗」，
但前端因為網路狀況不好，沒有收到這個結果，
使用者看到的會是舊資料還是新的訊息？
這些問題，在腦袋裡想一想，很容易就跳過。
但當你拿起筆開始畫循序圖時，你就會被迫問自己：
這邊要不要多一個「查詢最新狀態」的呼叫？
這裡是不是需要一個 Timeout 的機制？
這個錯誤是要回前端，還是只記在 log 裡？
很多「一開始沒想清楚，後面瘋狂補洞」的狀況，
其實都可以在畫循序圖的時候被挖出來。
◆ 循序圖不是給工程師看的，是拿來救 PM 自己的
很多 PM 一聽到「循序圖」、「UML」，
直覺反應就是：「這應該是工程師要學的東西吧？」
老實說，一開始我也這樣想。
直到有一次，專案後期一直在修「串接上的 bug」。
明明大家嘴巴上說的流程都一樣，
但前端以為：
「只要後端回成功，我就顯示成功。」
後端以為：
「只要第三方金流回 200，我就寫成功。」
金流那邊的文件寫著：
「我們會盡可能回 200，但實際狀態請再透過查詢 API 確認。」
結果就是：
有些退款其實沒成功，
但我們系統卻顯示成功，
最後還得一筆一筆打電話去跟客人道歉。
那次之後，我開始強迫自己
在面對「會牽涉到多個系統、多人角色」的需求時，
先把循序圖畫出來，再開需求會議。
我發現一件很有趣的事：
當我拿著循序圖跟 RD 討論時，
他們問我的問題變少了，
也比較不會用那種「你這根本還沒想清楚」的眼神看我。
因為循序圖讓我先把自己腦袋裡的模糊想像，
變成一條條明確的時間線。
而 RD 要做的事情，是在這條時間線上補充他們看到的風險。
你會從「被挑錯的那個人」，
慢慢變成「一起找出盲點的那個人」。
◆ 循序圖對 PM 來說，最實際的三個用途
如果你現在覺得循序圖還有點抽象，可以先抓這三個方向來用：
-串接第三方服務時
只要牽涉到金流、物流、簡訊、Email、外部 API，
都很適合先用循序圖拉一次整個流程，
把「誰先叫誰」、「誰等誰」、「失敗怎麼辦」寫清楚。
-會影響多個畫面的操作
例如：一個「變更會員方案」的功能，
可能會影響訂單列表、帳單頁、報表、權限。
用循序圖把「按下去後，背後有哪些資料要一起更新」整理出來，
比單純在 wireframe 上貼備註有效很多。
-專案已經常常在「改來改去」時
當你覺得自己一直在補洞、撞牆，
很有可能就是系統背後的呼叫關係從來沒有被攤開講過。
這時候先停下來，選一個核心流程，
用循序圖把它畫出來，
你會看到過去很多「莫名其妙的 bug」其實都有脈絡。
◆ 從「畫流程」到「畫循序」，是 PM 進入系統世界的關鍵一步
嗨，我是廣三。
一名在軟體開發打滾二十年的 PM。
這幾年回頭看，我發現自己有一個很大的轉變：
以前我習慣先畫畫面、畫流程，
現在我會先問自己三個問題：
「這個功能會牽涉到哪些實體？」
「這些實體跨了哪些部門、角色？」
「它們之間，實際上是怎麼互相叫來叫去的？」
前兩個問題，對應的是實體圖、泳道圖。
第三個問題，則是循序圖要幫你解決的。
當你開始願意用循序圖去看系統：
你不只是在畫一張給工程師看的技術圖，
你是在逼自己，把那些模糊的想像講清楚；
你也在練習，用系統的語言去思考這個產品。
到那個時候，
你的規格書就不會只是「畫面＋流程」，
而會慢慢長出一個完整的樣子：
有實體、有關係、有跨單位的場景、
也有清楚的時間線和呼叫順序。
而當你看得懂這些東西，
循序圖就不只是一個工具，
它會變成一種新的「思考方式」。
你不再需要等到系統上線轉圈圈時才慌張，
你早在畫那條線的時候，
就看見了那個可能會斷掉的連結。
它讓你從一個「事後救火」的 PM，
變成一個「事前避雷」的 PM。
也是讓你從「需求搬運工」，
變成「一起設計系統」的PM。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言