◆ 只看畫面順不順，其實骨頭早就長歪了
當 PM 當久了，你大概說過很多次這幾句話：
「這邊欄位再加一個就好。」
「這個狀態要新增，之後報表會用。」
「那就加一個條件，就可以判斷了。」
表面上看起來，只是多放一點資訊。
但在系統的世界裡，每一次的「加一下就好」，
其實都在動到底層的架構，於是你就會常常聽到：
「這要改底層喔!!」
如果你腦中只有「畫面長什麼樣」、「流程怎麼走」，
卻沒有一個很粗略的「資料表會長什麼樣」概念，
很多規格在設計的那一刻，就已經註定：
操作不順、效能不好、維護也會很痛。
◆ 懂資料庫，你看到的是一個有結構的世界；不懂資料庫，那將是一個恐怖的世界
多數 PM 看資料表，只看到一格一格的欄位：
訂單編號、會員姓名、地址、金額、狀態、備註……
工程師看資料表，看的比較像是：
這張表在描述「哪一種東西」？
跟其他表是「一對一、一對多、多對多」哪一種關係？
誰是主角（主鍵），誰只是描述用的配角？
這個欄位是用來「當下運作」，還是「歷史紀錄」？
如果缺少這些概念，PM 很容易做出一種規格：
畫面看起來合理，
實際上所有東西都被塞進同一張「萬用大表」裡。
一開始查得到、改得動，
等功能多兩輪、報表加三種、條件多幾組，
整個系統就會開始出現那種：
怎麼查都慢、
欄位一堆但就是缺你要的、
狀態互相打架、
報表永遠對不起來的狀況。
◆ 正規化不需死背，只要理解概念
學生時期學資料庫，
老師一定講過「第一正規化、第二正規化、第三正規化」。
那時候大概只覺得很抽象，很像在背名詞。
但進了職場之後，你會慢慢發現：
這些東西如果完全不懂，
你在畫 wireframe 和寫需求的時候，就會不停踩雷。
用白話講，正規化大概就是幾個原則：
一個欄位只放一種東西，不要塞一串逗號分隔的值；
一張表只描述一種主體，不要把訂單、會員、付款、物流全部堆一起；
同一個資訊不要在兩個地方各放一份，
不然改一個忘記改另一個，資料一定打架。
當你在設計畫面時，如果腦中沒有這些基本概念，
就很容易做出這種畫面：
一個畫面什麼都想顯示、
一個欄位想塞兩種意義、
一個「狀態」想對應所有結果。
看起來欄位很少、畫面很「乾淨」，
實際上是把未來幾年的維護成本，先打包丟給工程師。
◆ 壞掉的 wireframe，往往是從一張壞表長出來的
舉個簡單的例子。
假設你在做電商系統，
最常見的幾個東西：訂單、訂單明細、付款、出貨。
如果你沒有「資料表關係」的概念，
很容易畫出一個看似清楚、實際很危險的設計：
在訂單表裡，
放訂購人資料、收件人資料、所有商品名稱、
每次付款資訊、退款紀錄、出貨紀錄，
再加一堆「付款狀態、物流狀態、退款狀態」欄位。
然後，你的 wireframe 也會跟著長成這樣：
畫面上只畫一個區塊放「付款資訊」，
假設一張訂單一輩子只會有一次付款。
但如果你腦中有一點 ER-Model 的概念：
訂單下面會有多筆「訂單明細」；
付款可以有多次，應該是另一張表；
這時候你就會發現，
你的 wireframe 不能只畫「一個欄位」放付款資訊，
而是要畫一個「列表（List）」或「展開區塊」，
來放多筆付款紀錄。
這就是資料結構對畫面的限制：
如果資料是「一對多」，
你的畫面就不能硬把它當成「一對一」。
硬塞在一個欄位裡，
短期看起來省事，
長期只會變成——
只要一有第二筆、第三筆付款，
整個畫面和資料結構都得打掉重練。
◆ 效能不好，不一定是 RD 寫爛，是規格一開始就長錯
很多 PM 在專案後期，都聽過這種話：
「這頁查詢會有點慢，因為條件太多。」
「這個報表會跑比較久，因為欄位太雜。」
聽起來很像工程師在找理由，
但有一部分，其實是規格一開始就長壞了。
當你在一個畫面裡，
要求要一次查出 N 個條件、比對 M 種狀態、
還要能依照不同欄位排序、再加上模糊搜尋，
背後如果對應的是一張「全部堆在一起的大表」，
欄位又多又雜，又難下 index，
工程師就算再怎麼調效能、加快取，
整體體驗也很難真的順起來。
很多時候，效能不好，不是 RD 不會寫，
而是資料從一開始就沒有被拆乾淨，
wireframe 在設計時也沒意識到：
「這樣查下去，畫面一定會轉圈圈。」
最終，就會出現白畫面。
◆ PM 不必畫 ER 圖，但腦袋裡一定要有「表」
嗨，我是廣三。
在軟體開發裡繞了二十年，
一開始我也覺得：
「資料表設計不是 RD 的事嗎？」
後來才發現，
如果 PM 在談需求、畫 wireframe 的時候，
腦中完全沒有「資料大概會拆成幾張表」的輪廓，
最後做出來的系統，多半會長成：
畫面看起來勉強能用，
操作上總覺得卡卡的，
資料結構難維護，效能也撐不起來。
你不一定要親自畫 ER-Model，
也不一定要自己下 SQL。
但至少在想需求的時候，可以多問自己幾句：
這些欄位，背後大概會落在哪幾張表？
哪一些是「這張表的事」，哪一些應該拆出去？
哪一些資訊只會有一筆，哪一些天生就是「一對多」？
這個畫面是「一次只看一筆」，還是本來就該用「列表」來呈現？
當你開始用這種方式想，
你畫出來的 wireframe，就不只是「看起來合理」，
而是比較有機會長成：
好操作、好維護、效能也站得住腳的規格。
資料庫不一定是你要精通的專業，
但如果你完全不理解它，
很多問題其實在你畫第一個畫面、
第一張流程圖的那一刻，
就已經悄悄被寫死在系統裡了。
後來，經常性要去接手各種系統，
我最先做的事情只有兩個，
一是了解「系統架構」，另一個就是了解「資料表結構」。
讓我可以在最短的時間對「系統」與「資料」有初步的認識。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言