在上一篇，我們提到系統思考的第一課，是先搞懂「實體」。
知道這個系統裡，到底有哪些角色、有哪些輸入、會產出哪些東西。
聽起來好像有比較踏實一點。
但很快你就會遇到下一個問題：
明明有照流程在做需求訪談，
有問「需求是什麼」、有問「痛點在哪裡」，
文件也寫了好幾頁，結果一丟給團隊，
設計師看不懂，工程師覺得怪怪的，
客戶看到畫面，又說「不是這個意思」。
你會開始懷疑：
我是不是哪裡沒問好？
還是訪談對象講得不清楚？
很殘酷的答案常常是：
不是他們講不清楚，
而是你一直停在「聽他怎麼說」，
卻從來沒有真正去看「他怎麼做」。
你聽到的是主觀，
你缺少的是場景。
◆ 只聽「需求」，你看到的永遠是別人內心的小劇場
多數的需求訪談，長得都很像。
對方會跟你說：
「退款流程要再簡單一點。」
「現在處理太慢，客人會抱怨。」
「我們需要可以快速查詢退款狀態。」
如果你比較認真一點，會追問：
「那現在最大的痛點是什麼？」
「哪一個步驟最常卡住？」
對方也會很努力回答：
「客人常常打電話來問進度，客服很累。」
「財務那邊說，要一張一張核對，很花時間。」
這些內容都很重要。
但有一個問題。
這些描述，全部都是
「他記得的片段」
「他在意的部分」
「他習慣怎麼說」
也就是，全部都很主觀。
你沒有親眼看過實際怎麼發生，
就很容易只抓到他講的那一塊，
然後用你自己的想像，把剩下的空白補滿。
最後畫出來的流程是：
一半是他的印象，
一半是你的腦補。
這樣做出來的需求，
要團隊「完全看懂」其實很難。
◆ 真正要看的，是「人在現場到底怎麼做事」
所以在有了「實體」的概念之後，
下一步不是再去多問幾個問題，
而是要開始練習看「場景」。
所謂的場景，指的不是一句「退款流程」。
而是：
平常真的有人按了什麼按鈕、
填了什麼東西、
把資料交給誰、
去哪一個系統查、
印出什麼表、
再拿去給誰簽名、
最後怎麼結案。換句話說，就是那一整套「實際的工作流程」。
你不是只聽他怎麼形容工作，
而是要知道，
他每天真的在位置上，
是怎麼一步一步把事情做完。
一旦你把場景拉出來看，
你就會發現一件事：
真實世界的流程，
很少只發生在一個人身上。
◆ 一個看似簡單的「退款」，本質上就是跨單位戰爭
以「訂單退款」為例，看起來只是一個按鈕。
實際上大概會長這樣：
1. 消費者到「訂單管理」，送出退款申請。
2. 客服在後台看到這筆申請，先確認內容。
3. 客服覺得合理，就送交財務審核。
4. 如果不合理，就回覆給消費者，說明退款未通過的原因。
5. 若是信用卡付款，財務需要透過金流或發卡行，處理退刷。
6. 若是現金或匯款，財務要再走一套內部流程，安排轉帳或退款作業。
7. 退款完成後，系統要更新訂單狀態，可能還要通知倉儲、出貨或相關單位。你會發現，光是一個「退款」，就牽涉到：
-消費者
-客服
-財務
-金流業者或信用卡公司
-甚至還有倉儲、出貨系統有前台畫面，有後台介面，
有內部系統，也有第三方服務。
如果你只問客服，
你會拿到「客服視角的退款」。
如果你只問財務，
你會拿到「財務視角的退款」。
如果你只問老闆，
你會拿到「理想中應該長這樣的退款」。
哪一個都是真的，
但哪一個都不完整。
所以當你只拿其中一個視角，
就開始畫圖、寫需求、排時程，
很容易就會發生這種事：
客服說「這個流程我要怎麼聯繫消費者？」
財務說「這樣我們對帳很麻煩？」。
工程師說「你這個退款流程，退費計算是寫死，還是要可以參數控制？然後誰可以控制？設定錯了怎麼辦？」。
於是流程一改再改，
所有人都覺得自己在救火，
沒有人覺得自己在做產品。
◆ 在談系統設計之前，你需要一張「大家有共同理解」的圖
這時候，就需要一個工具，
把這些散落在不同人腦袋裡的流程，
收攏成一個「可以一起看的東西」。
這個工具，就是「泳道圖」。
很多人聽過流程圖，
卻很少好好用過「泳道圖」。
甚至根本沒聽過，
更別說要在專案上使用。
兩者的差別可以簡單這樣想：
一般流程圖，只是在畫事件的順序。
泳道圖，除了畫事件的順序之外，
還會把「這一步是誰在做」畫出來。
所以在退款例子裡，
一張簡單的泳道圖，至少會有這幾條泳道：
-消費者
-客服
-財務
-金流或銀行
-系統每一條泳道都代表一個「實體」或「角色」，
你會把每一個動作，放到對應的那一條線上。
比如：
消費者那條線上，是「送出退款申請」。
客服那條線上，是「檢查申請內容、決定是否通過」。
財務那條線上，是「執行退款作業、完成帳務處理」。
金流那條線上，是「接受退刷請求、回傳結果」。
系統那條線上，是「更新訂單狀態、發送通知」。當你把所有動作，
一個一個放進這張圖裡，
你會開始看到很多以前沒注意到的東西：
哪一段流程完全靠人工記憶。
哪個步驟沒人負責，只是大家以為「應該會有人做」。
哪裡有來回溝通很多次，但文件上完全看不出來。
哪個地方其實根本不需要人做，只是被歷史流程綁住。
這些，都是單看一條「主流程」看不出來的。
◆ 泳道圖的價值，不在於畫得多漂亮，而在於「終於講的是同一件事」
嗨，我是廣三。
一名在軟體開發打滾二十年的 PM。
回頭看這幾年的專案經驗，
我發現一件對系統分析非常關鍵的小事。
當我們只用一份需求文件，
試圖去說明一個跨單位的流程時，
每個人腦中想的畫面都不一樣。
客服看到的是畫面和按鈕。
財務看到的是帳務和報表。
工程師看到的是欄位和 API。
老闆看到的是體驗和風險。
大家都在看同一份文件，
但其實在看不同的世界。
而一張畫好的泳道圖，
做的事情其實很單純：
強迫大家把自己那一段「實際在做的事」放上來，
也強迫大家看到「別人在同一條流程裡做了什麼」。
你會發現，很多討論會變得比較具體：
「原來你這邊還會印出來給主管簽名。」
「難怪你說很慢，因為這裡其實每天都要人工核對。」
「如果我們這一步改成系統自動通知，你那邊就不用再打電話。」
這種討論，
跟那種只有一句「退款流程要優化」的會議，
完全是不同層級的對話。
對 PM 來說，泳道圖還有一個很實際的好處。
當你把場景畫成泳道圖之後，
你再回頭去看「實體」：
使用者有哪些角色
輸入的文件有哪些
系統會產出哪些紀錄或報表
這些東西就不再是抽象名詞，
而是你在圖上看得到、講得出例子的東西。
接下來你要設計資料流程、
要拆功能模組、
要規劃誰在什麼時間點收到什麼通知，
就會有一個比較穩的基礎。
簡單說，
泳道圖是一座橋，
一邊連著真實世界的工作流程，
另一邊連著後面要談的系統設計、資料流程、循序圖。
◆ 從「聽人講流程」，到「看見整個場景」
如果你現在在做的專案，
常常出現這些情況：
每個人都說自己流程講很多次了，但還是有誤會。
同一個功能，不同單位講出來的版本都不太一樣。
需求文件改了又改，但工程師還是說「這裡沒寫清楚」。
每次開會都在吵「到底誰該負責這一步」。
也許，你不是文件寫得不夠多，
也不是你問問題的態度不夠謙卑，
而是你還欠了一張東西。
那張東西，叫做場景，
具體來說，就是一張畫好的「泳道圖」。
當你願意花一點時間，
帶著各個角色，
一起把實際的工作流程攤開來看，
你會發現兩件事：
第一，很多吵不完的爭執，其實只是大家站的位置不同。
第二，很多說不清楚的需求，其實只是還沒回到場景裡看。
而當你開始習慣用場景來理解需求，
用泳道圖來對齊各個實體之間的關係。
你就不再只是在聽一個人講他的感受，
而是在看整個系統怎麼真實運作。
你會發現，你手上的那枝筆，
不再只是用來做會議記錄，而是進行戰略布局。
你不再是被動聽故事的人，
你是那個看見全景、串聯角色、定義規則的導演。
這，才是系統思考的下一課。
畫出那條所有人都能依循的清晰路徑。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言