◆ 你以為系統難在流程，其實在資料「落地」
在很多專案裡，PM 最常盯著的是「流程」，
什麼時候登入、什麼時候下單、下一步去哪一個畫面，
一路畫到完成訂單，看起來很完整。
可是專案真正出事的時候，
很少是「流程畫錯」，
更多時候，是「資料不知道去哪裡」，
或是「去了，但沒人說得出去哪裡」。
那種感覺很像是你把血管都畫好了，
卻忘了裡面要有血液流動，
而且還沒想好「血最後要回到哪裡」。
系統裡的那個「血」，就是資料。
而資料真正的關鍵，不只是流動，而是
最後到底「落地」在哪裡。
流程圖先畫出血管，
資料流程圖（DFD），在看血怎麼流、怎麼存。
◆ PM 習慣描述畫面，卻很少問存到哪
很多 PM 在開需求會議時，習慣這樣描述系統：
使用者會按哪個按鈕。
按完會跳到哪個頁面。
這個頁面要顯示什麼欄位。
活動頁怎麼導流到結帳。
這些都很重要，但大多都停留在「畫面」和「動作」。
如果這時 RD 問一句：
「那這一步的資料，從哪裡來、要寫到哪裡去？」
現場通常會稍微安靜一下。
你腦袋裡浮現的，可能是：
「欸…這部分還沒討論到。」
「應該會有一個欄位可以放吧。」
「這應該是後端在想的，不是嗎？」
對 PM 來說，流程已經有了。
對 RD 來說，資料還是散的，
尤其是——沒有被明確說出「要存在哪裡」。
◆ 一筆訂單的誕生：Input、Output 和落地點
以一筆訂單為例，很多人腦中想的是：
建立訂單 → 付款 → 完成
但如果用資料的角度看，同一件事會長得不太一樣。
「建立訂單」這個 process，
它的 input 是什麼？
可能是前台送過來的購買品項、數量、金額、會員資料、優惠券資訊。
那 output 是什麼？
不是一句「建立成功」，
而是一筆在資料庫裡真正存在的「訂單紀錄」，
有訂單編號、有初始狀態，
而且清楚知道——
這些資料「落地」在哪一張表、哪些欄位。
之後所有流程都會靠這筆資料活下去。
如果你只說「按下確認，就會建立訂單」，
沒有把 input、output 和「落在哪裡」講清楚，
對 RD 來說，就會變成：
「那到底要存什麼？」
「缺欄位時，是 PM 沒講到，還是可以自己猜？」
再往後一點，「確認付款」也是一個 process。
它的 input 是什麼？
是那一筆處於「等待付款」狀態的訂單，
再加上金流回來的交易結果。
它的 output 應該是：
訂單狀態更新成「付款成功」或「付款失敗」，
多一筆付款紀錄、對帳用的欄位，
而且一樣要說清楚——
這些資料最後是「落在付款紀錄表」，
還是「直接寫回訂單表」。
如果這些沒在設計階段被說清楚，
最後就會變成：
畫面顯示「付款成功」，
後台查不到任何實際付款資料，
報表也對不起來。
◆ 退款流程：最容易看出資料有沒有家
退款的流程更容易暴露這件事。
很多人畫退款，只畫成幾個簡單的框：
申請退款 → 審核 → 退款完成
看起來流程很順，但換成 DFD 來看就完全不一樣。
「申請退款」這個 process，
input 不是只有「使用者按了一個按鈕」，
它應該包含：
是哪一筆訂單、申請原因、申請時間、申請人身分、退款方式。
那 output 呢？
至少要有一筆「退款申請紀錄」，
裡面記載這些資訊，
而且要跟原本那筆訂單有關聯。
更重要的是——
要說明清楚這筆紀錄「落地」在什麼 Data Store：
是專門的退款申請表？
還是訂單表裡的一個獨立明細？
「退款審核」這個 process，
input 就是前一個 output：
這一筆處於「申請中」狀態的退款申請，
再加上審核者的決定。
output 是什麼？
要不是「通過」，變成等待退款，
要不就是「不通過」，並留下原因，
同時更新原訂單的狀態，
讓前台不要再顯示「退款處理中」卡在那邊。
如果我們在規劃時，只討論流程順不順，
沒有去想每一個 process 的 input、output，
更沒有問清楚「最後存在哪裡」，
最後就會變成：
畫面看起來有流程，
但資料沒有一條完整、可追蹤的路可以走。
◆ 資料沒地方放，問題不會自己消失
資料沒有地方去，系統真的會壞掉，不是比喻。
有幾種狀況，現場應該都不陌生：
資料進來時，沒有地方放。
欄位不存在、沒有主鍵、沒有關聯，只好先塞在某個備註欄。
久了之後，誰也說不出那個欄位到底裝了什麼。
資料存進去，但不知道怎麼讀。
報表需要的欄位沒存、客服查詢查不到、
為了臨時應付，就開第二套查詢邏輯，再存一次。
資料被讀出來，但沒有一致的用法。
不同系統各自存一份會員資料，
A 系統改名字，B 系統改電話，
最後誰也不敢保證哪一份才是準的。
這些絕大部分，
不是「技術太差」，
而是當初在談需求的時候，
沒有人從「資料流」跟「資料儲存點」這兩個角度去把關。
流程圖只負責告訴你「下一步要幹嘛」，
資料流程圖在看的，是：
每一個步驟，資料怎麼進來、
怎麼被處理、
最後落在哪個 Data Store，
之後又被誰拿出來再用。
◆ Process 不只要做事，還要說清楚進出
如果用 DFD 的思維來看，我會這樣拆：
每一個 process，只要被畫出來，就要能回答幾件事：
這一步「要靠什麼資料」才能開始（Input 是什麼）。
中間會對資料做什麼處理或轉換（Process 做了什麼）。
這些處理後的資料，最後會「落地」在哪裡（Data Store 在哪）。
未來是誰、用什麼情境，會把這些資料拿出來再用（Output 給誰）。
假設你在畫「批次對帳」，
input 可能是：
每天金流商回傳的一個檔案、
加上系統裡先前記錄的付款紀錄。
process 做的事是：
比對這兩邊的資料，有沒有遺漏、錯誤、重複。
Data Store 是：
把對帳結果、差異清單、異常筆數，
落到一張對帳結果表或 log 表裡。
output 則是：
財務隔天一早打開系統，
可以直接看到「哪幾筆需要人工處理」，
報表系統也可以讀這些資料，
拉出一個「對帳狀況月報」。
如果沒有這樣拆，
對 PM 來說只是「每天會有一個對帳排程」，
對 RD 來說就是「那我要自己想像這些資料要怎麼走、怎麼存」。
久了，系統裡就會越來越多
「看起來有在跑，但誰也講不清楚在幹嘛」的程式。
◆ 畫 DFD 不用精美，但要畫出資料的家
我後來的做法是，
只要是跟資料有關、又會跨好幾個流程的功能，
就會自己先在紙上畫一個「簡易版 DFD」。
不用畫得很精美正確，
但至少把這幾件事寫出來：
這個功能一開始要吃什麼資料（Input）。
中間會被拆成幾種不同的資料型態、會被怎麼處理（Process）。
處理完的資料，最後會「落地」在哪幾張表、哪幾個檔案（Data Store）。
未來是誰、在什麼狀況下，會把這些資料拿出來再用（Output）。
畫到這裡，
你會開始看到一些以前沒發現的洞：
原來這裡少了一個欄位，後面根本無法查。
原來這個畫面顯示的資料，沒有任何地方真的落地。
原來兩個部門各自維護一份一樣的東西，只是欄位名稱不同。
這些東西，如果在設計階段就被看見，
改一個欄位、多加一個關聯，也許就解掉了。
如果等到上線兩年後才發現，
你就會開始聽到那句很熟悉的話：
「這個要改底層才有辦法處理。」
◆ 從畫流程的人，變成看得懂 Data Store 的人
對 PM 來說，
把「流程」畫清楚是一個基本盤，
但如果你願意再往前一步，
開始去看每一個 process 的 input / output，
開始問「這些資料最後到底存在哪裡」，
開始試著用資料流和 Data Store 的角度，
打量同一個需求，
你會發現，
RD 問你的問題會不太一樣，
從「這個資料要存去哪」
慢慢變成「這樣設計的話，之後查問題比較好查」。
那個時候，你就不只是把流程接起來，
而是真的在幫系統找一條穩定、有落地點的「資料路」。
嗨，我是廣三。
在軟體開發裡繞了二十年，
花了很久才慢慢意識到一件事：
系統難，不只是因為畫面多、流程長，
而是因為只要資料沒有一個清楚的「家」，
其他所有東西，看起來再漂亮，
都只是暫時沒問題而已，隨時都有可能爆掉。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言