從 《#056 使用者旅程地圖》 到 《#060 UI 稿沒畫出來的細節》，我們把使用者旅程、資訊架構、UI 原則、例外狀況逐一整理完。接下來團隊開始進入開發，PM 很快會遇到另一種壓力，技術溝通。
API 要怎麼設計？資料要怎麼存？某段邏輯應該放在前端還是後端？許多 PM 不是不願意學，而是名詞一多，討論容易失焦，會議聽起來像在背術語，最後只剩模糊印象。
結果就會變成另一個萬年問題「PM要不要學Coding」？
PM當然可以學Coding，但是學的目的不是變成大神，而是了解程式運作原理就可以，這一篇要談的，也不是怎麼寫Code，而是很多PM面對技術時，需要先釐清的觀念。。
所以先把地基打好。在談前後端分離之前，先把兩組最容易混用的詞釐清。這兩組詞只要講清楚，後面的討論會順利很多。
◆ 名詞先釐清。前台不是前端，後台也不是後端
專案現場最常見的狀況，往往不是技術本身，而是同一個詞在不同人口中代表不同意思。尤其常見的是把「給誰用」和「用什麼做」混在一起。
前台（Front Office）指的是給誰用
前台談的是使用者角色與使用場域，也就是外部使用者會接觸到的那一面。官網、落地頁、App 使用者端、會員中心、下單與訂閱流程，都屬於前台。它可以是 Web，也可以是 App，重點不在技術，而在於這是客人看得到、用得到的界面。
前端（Frontend）指的是用什麼做
前端談的是技術分工，負責畫面呈現與互動邏輯的程式碼。版面如何呈現、表單如何互動、按鈕狀態如何變化、呼叫 API 後畫面如何更新，通常由前端負責。
換句話說，前台談使用者，前端談實作分工。
後台（Back Office）指的是給誰用
後台談的是內部操作場域，也就是公司內部用來管理、查詢、設定、處理例外的那套介面。客服查單、人工退款、內容管理、權限設定、稽核紀錄、報表匯出，都是典型後台功能。後台存在的原因很務實，因為世界一定會出狀況，而你需要有地方能處理。
後端（Backend）指的是用什麼做
後端談的是技術分工，負責商業規則、驗證、資料處理與存取的服務。訂閱資格如何判定、折扣如何計算、權限如何驗證、避免重複扣款、資料庫如何讀寫、第三方金流如何串接，這些大多屬於後端範圍。
同樣一句話，後台談管理者角色，後端談規則與資料如何運作。
把這四個詞放在一起看，其實是兩種分類方式。
- 前台／後台，以使用者角色與場域來區分
- 前端／後端，以技術分工來區分
當團隊在同一套用語下討論，很多誤會會明顯減少。
◆ 讓我們用餐廳來比喻
如果還是覺得抽象，讓我們用餐廳來理解看看。
- 前台像餐廳的用餐區
客人看得到、碰得到、會直接使用的地方。菜單怎麼呈現、動線順不順、資訊清不清楚，決定客人能不能順利完成「點餐」這件事。官網、App 使用者端、會員中心、下單與訂閱流程，本質上都屬於前台。 - 後台像餐廳的內場管理區
店員用來處理營運與例外的地方。查訂單、改訂單、退款、調整座位、處理客訴、看報表、管權限，這些不一定每天都在用，但一旦出狀況就必須能立刻找到資訊、立刻處理。客服後台、營運後台、內容管理、稽核紀錄，都是後台。 - 前端像服務人員
負責接觸客人，呈現資訊，收集點餐內容，把結果呈現出來。客人覺得順不順，往往先反映在這裡。 - 後端像廚房
負責真正把菜做出來，依規則處理食材與流程。口味穩不穩、出菜會不會亂，靠的是廚房的規則與流程。 - API 像菜單
菜單不是裝飾，而是你可以怎麼點、店家會怎麼出菜的規則。菜單寫不清楚，服務人員難以說明，廚房也容易被點到不合理的東西。 - 資料庫像冰箱與儲藏室
食材放哪裡、怎麼保存、怎麼拿、誰能拿，決定出菜速度與一致性，也影響管理成本。
這個比喻的重點可以用兩句話總結。
前台／後台是在區分「給誰用」。前端／後端是在區分「怎麼做」。
而 API 與資料庫，則是讓整間店能穩定運作的共同規則。
◆ 什麼是前後端分離。它真正分開的是責任與合約
不少人聽到前後端分離，第一反應是把事情分開，各做各的。更準確的說法是，把合作方式固定成可討論的合約。
常見做法是，前端依 API 規格開發畫面與互動，後端依同一份規格提供資料與狀態回應。只要合約清楚，兩邊可以平行開發，討論也更容易落在具體細節上。
對 PM 的好處很直接。
第一，需求不再只靠口頭描述。你會更自然地把欄位、狀態、錯誤情境講清楚。
第二，介面迭代比較有效率。只要 API 合約穩定，前端可以調整版面與互動，不必每一次都牽動後端核心規則。
第三，多載體會更合理。同一套後端可以服務 Web、App、後台，甚至外部合作夥伴，差別只在呈現方式與互動設計。
你不必把它當作工程潮流，記住一句話就夠了。
前後端分離的核心，是讓討論從感覺走向規格。
◆ API 文件怎麼看。PM 先看懂 Request 與 Response 就足以應付大多數討論
研發問你 API 要怎麼開，PM 不必回答怎麼寫程式碼，而是要能把需求整理成可實作的規格。API 文件裡最重要的兩塊，是 Request 與 Response。
- Request 是前端送出去的資料
包含路徑、方法、參數、權限、資料格式 - Response 是後端回來的結果
包含回傳欄位、狀態碼、錯誤格式、是否分頁、是否為非同步處理
閱讀方式可以非常務實，先問三件事。
第一，這支 API 的目的。是查詢、建立、更新、刪除，或是觸發一個動作。
第二，前端需要提供哪些輸入。哪些是必填、格式錯會如何回應、是否需要特定權限。
第三，後端會回什麼結果。成功回哪些欄位，失敗時錯誤訊息怎麼呈現，使用者是否能重試。
下面是一個短例子，感受一下結構即可。
// Request (前端點餐)POST /api/subscriptions{ "plan_id": "pro_monthly", // 我要訂專業版月繳 "payment_method": "credit_card" // 我用信用卡付錢}// Response 200 (廚房出菜 - 成功){ "status": "active", // 訂閱成功，生效中 "expiry_date": "2026-03-12" // 到期日是下個月}// Response 400 (廚房退單 - 失敗){ "error": "PAYMENT_FAILED", // 扣款失敗 "message": "餘額不足，請換一張卡" // 給使用者的提示}
不需要背語法，重點是理解這件事。使用者做了什麼，系統收到什麼，系統回了什麼。
◆ 這段邏輯放前端還後端。用信任與一致性當作判準，最不容易走偏
研發常問某段邏輯應該放前端還後端。PM 不必追求工程上的唯一正解，可以先用一個穩定的判準做初步判斷。
只要牽涉到信任與一致性，通常應由後端負責。
例如訂閱資格、金額計算、折扣規則、庫存與扣款、防止重複提交、權限驗證。這些若只放在前端，很容易被繞過介面而改到結果，風險通常不值得承擔。
只要牽涉到體驗與即時回饋，前端可以承擔更多呈現與提示。
例如輸入格式提示、即時字數限制、按鈕狀態切換、載入提示文案。這些放在前端能讓體驗更順，也能減少不必要的請求。
一句話總結就是，前端讓人用得順，後端讓結果可信。
◆ PM 在技術溝通裡，最重要的工作是把問題問成可落地的句子
最後整理一組 PM 常用、也最能讓討論進入細節的提問方式。
- 狀態：這個功能有哪些狀態。成功、失敗、處理中、資料不存在，各自畫面要呈現什麼？
- 必填：哪些欄位是必填。缺少時如何提示，錯誤訊息要給使用者還是只留在系統紀錄？
- 資料來源：這筆資料的來源與主資料在哪裡。避免前端與後端各自解讀，造成資料不一致？
- 防呆：使用者重複點擊時，系統如何避免重複建立或重複扣款？
- 權限：權限控管以頁面為單位，或以功能為單位。哪一種更符合管理需求與維運成本？
這些問題看起來偏技術，本質上仍然是產品。你做的事，是把模糊的需求整理成系統能承受的規則。
◆ 廣三觀點
嗨，我是廣三。PM 不需要會寫程式碼，但也不適合在技術會議裡只剩「我大概懂」。那句話通常代表你無法用一句清楚的句子把需求講完，也無法判斷研發提出的選項差別在哪裡。
我一直認為技術溝通不應該是PM執行專案的痛點。但也不是要你變成工程師，而是把產品語言整理成結構化規格，再把工程語言轉回使用者會遇到的後果。只要先把前台前端、後台後端的用語釐清，並以 API 規格作為共同依據，前後端分離就不再是名詞，而是一種讓團隊更加穩健的合作方式。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言