自訂CMS開發指南：甚麼需求值得建立專用後台

自訂CMS開發真正要解決的業務任務

由一個可觀察的動作開始

自訂CMS開發要先釐清訪客任務、內容責任和驗收條件，再按業務流程安排設計與程式。這樣能避免用大量外掛或一個長文字欄處理所有情況，亦令測試、上線和移交有共同依據。

例如需要常改服務、文章、案例或活動資料的團隊常把不同訪客混作同一類人，結果首頁和表單都不能回答真正問題。把CMS內容管理系統的頁面任務列成一句動詞，才能分辨資訊展示與下一步動作。這樣才能把資訊展示和下一步動作分開驗收。

不要把模糊偏好當需求

「想要高級感」可以是視覺方向，卻不是可驗收條件。可驗收的說法應包括誰會看、要看甚麼、完成後要交給誰處理。這亦是用大量外掛或一個長文字欄處理所有情況最早出現的位置。

用資料界定範圍，而非憑印象加功能

資料不足時，先縮小決定範圍

動工前應收齊內容模型、欄位名稱、編輯角色、圖片規格和舊資料。資料未齊不必假裝已確認；應標明缺口、負責人與截止日。在整理時，可用WordPress與自訂CMS選擇作為頁面資訊取捨的參考。

把資料轉成欄位與責任

每個輸入資料都要知道誰提供、誰核對、何時可更新。圖片若沒有比例和用途，設計稿完成後仍會在上線前被迫重裁。資料表不只是技術文件，也是避免口頭遺漏的工作清單。

WordPress 的既有能力與自訂 CMS 的資料控制的取捨怎樣落地

比較時要比較日後工作，不只第一版

WordPress 的既有能力與自訂 CMS 的資料控制各有適合位置。選項的差異通常會出現在內容是否常改、流程是否有例外，以及日後誰負責維護。處理這些分界時，CMS需求分析提供的流程觀點比單看截圖更有用。

選型要連同驗收方式一起決定

任何平台或程式架構都要列出可驗收的輸入、輸出和失敗情況。若只寫功能名稱，供應商與客戶會各自理解成不同畫面。要把選型落地，應先預演一個正常流程與一個例外流程。

角色、交稿與決策權如何埋位

決策人不等於每頁撰稿人

專案應分開內容負責、業務拍板、技術核對和最終驗收四種角色。同一人可以兼任，但不能不寫清楚。若要預先看見改版的協作節點，可參考WordPress內容模型。

修改要有原因、影響與去向

每次改動應寫明要解決哪個任務、會影響哪些頁面及是否改動時程。單靠「幫我改靚啲」會令設計意見無法收斂。把變更留在同一份紀錄，可減少口頭要求在交付時消失。

• 指定每類內容的一位最終負責人。
• 把修改意見合併後才交出，不用逐人零散傳達。
• 任何新增流程先寫使用情境，再判斷是否納入首版。

把WordPress、PHP、MySQL、自訂欄位與角色權限放進正確的位置

技術是為流程服務，不是功能名單

WordPress、PHP、MySQL、自訂欄位與角色權限的組合要配合資料如何進出與誰會操作。PHP 和 MySQL 適合把內容、表單或訂單資料放在可管理的結構內；但欄位設計必須先反映業務語言。當技術範圍和服務責任需要對照，可查看自訂CMS開發服務內容。

把不可見的失敗情況提前寫出來

例如資料未填、權限不足、重複提交或回傳延遲，都應在測試表內有預期處理。這些情況平日不常出現，卻最容易令前台和後台的說法不一致。技術文件至少要記錄欄位、狀態、通知對象和手動處理方法。

測試時要找出的不是版面喜好

用真實內容、真實帳戶和真實裝置測試

空白示例很少揭示真正問題。測試應把長標題、缺圖、錯誤輸入和重複操作都放進去，才看得到流程是否完整。這時安排需求交流所列的準備項目可幫團隊預先分工。

驗收問題要能重現

一個有用的問題紀錄包括裝置、操作步驟、預期結果、實際結果和截圖。「有時不行」不能讓開發者定位原因。驗收會議應先處理阻斷任務的問題，再處理文字與視覺微調。

1. 以一個新用戶完成主要任務。
2. 以一個已有資料的用戶改動或取消。
3. 以一個錯誤輸入確認提示與紀錄。
4. 由非項目成員按說明重做一次。

不同行業會令流程在哪裡改變

行業差異會改變欄位，不只是改圖片

需要常改服務、文章、案例或活動資料的團隊的客戶決策速度與所需資料不同。餐飲較重視時段和菜單狀態；專業服務要先建立問題脈絡；零售則要把商品選擇和訂單例外寫清楚。當流程需配合其他數碼接觸點時，電商流程的設計邊界的規劃能避免網站單獨運作。

不要把敏感或例外資料藏在備註欄

若某資料會影響誰可見、何時處理或能否提交，便應成為明確欄位與規則。備註只適合保留補充說明，不能代替狀態設計。行業專有資料越早命名，後期改程式和補資料的代價越低。

上線前要留住哪些可追蹤紀錄

網址與內容關係要在改版前對照

如果舊站已有被搜尋或被分享的頁面，改版時要列出舊網址、對應新頁和是否需要 301 轉向。沒有去向的連結會令訪客走到不存在頁面，也會令過往內容失去脈絡。內容與推廣的連動可從流動應用的產品取捨開始規劃。

追蹤應只量度可回答的問題

例如表單是否成功送出、哪類服務頁帶來查詢、哪個內容促成下一步，都是可檢視的問題。不要把一長串數字當作成果；先約定哪個動作需要改善。上線後的第一輪檢查應定在內容和技術仍可快速調整的時間。

• 保存上線前的網址對照與帳戶清單。
• 記錄主要表單、電話和重要按鈕的測試結果。
• 把待觀察問題寫成下一輪更新項目。

移交後誰負責甚麼才不會失控

移交不只是交出登入帳戶

真正可用的移交文件要說明誰可改甚麼、改動後怎樣檢查、遇到例外找誰處理。若內容人員沒有看過真實流程，網站很快又會回到只能找開發者的狀態。需要安排交接方式時，可由推廣渠道和登陸頁協作開始列出聯絡與決策安排。

把下一階段留在已知邊界內

首版未做的功能應保留原因、優先次序和需要補的資料，而不是用一句「日後再加」帶過。這樣下一輪啟動時可從既有紀錄判斷，而非重新猜測。當需求增加，先看它是否改變主要任務，再決定是否另開變更工作。

常見誤解如何在動工前拆開

有後台便代表任何資料都可隨時安全更新嗎？

這個想法忽略了把內容類型、資料欄位、權限與日常編輯流程定義好。真正決定品質的，是每個角色能否在預定狀態下完成自己的工作。外觀、平台或功能只是在清楚任務之後才有意義的選擇。

一個可執行的判斷方法

把一項要求寫成「誰在甚麼情況下，輸入甚麼，應看到甚麼，之後誰要處理」。若寫不出來，代表仍未可交給設計或開發。這個方法同時適用於首版功能、內容修改與上線後的改善。

把決定保留成下一輪可用的資料

在實務規劃型的工作方式裡，最有用的不是多一份漂亮文件，而是每個決定都能找到來源。把訪客任務、資料欄位、負責角色和驗收條件放在同一張工作表，討論便不會不停回到個人偏好。這種紀錄也讓日後接手的人知道某項設計為何存在。

上線窗口前的例外核對

上線窗口接近時，最容易被忽略的是例外情況：文字未完成、圖片替換、帳戶權限缺失、舊網址仍被分享，以及某位決策人不在場。把每一項標成可上線、需修正或需延期，比口頭說「應該沒問題」更可靠。

讓技術與業務使用同一套描述

技術團隊不應替業務猜測規則；業務團隊也不應假定程式會自動理解口頭習慣。只要把正常、失敗與人工覆核三種情境各走一次，很多看似複雜的問題都會在開發前變得具體。

權限交接不能只留下帳戶名稱

每個帳戶應列明擁有人、使用目的、可做的操作和外判結束後的處理方式。把權限分層，反而能令內容修改與技術調整不會互相阻塞。

資料欄位要有可閱讀的定義

欄位名稱應讓業務與技術人員看見同一件事，例如狀態、日期、負責人和備註各自代表甚麼。若一個欄位同時承載三種意思，日後統計、客服和修正流程便會各有一套答案。

內容變更也要納入測試範圍

不是只有新增功能才需要測試。服務名稱、圖片比例、長標題和已刪內容都會影響導覽與表單操作；把這些視為可驗收資料，才能避免改字後破壞版面。

例外處理需要看得見的紀錄

遇到資料缺漏、重覆提交或需要人工覆核時，後台要留下時間、操作人和處理結果。沒有紀錄的例外很容易在下一位同事接手時再次出現。

上線日應預留回退與核對時間

上線不是把檔案放上去便完結；要預留時間核對重要網址、表單、通知和主要裝置。若任何一項未過關，應有清楚決定是即時修正、暫停功能還是延後公開。

自訂CMS開發常見問題

動工前要預備甚麼？

應先整理內容模型、欄位名稱、編輯角色、圖片規格和舊資料，再標示每份資料的負責人和可交付日期。若未能一次過備齊，至少要先確認首版必需內容與不能延後的帳戶權限，避免設計和開發在錯誤假設下前進。

應該何時確認範圍？

範圍應在架構與設計開始前確認，並用頁面、欄位、流程和驗收條件表達。完成後若新增任務，應記錄它影響的內容、測試和上線安排，而非直接插入已排好的工作。

內容未齊可以開始嗎？

可以先做資料盤點、導航和首版流程，但不應假裝空白位置日後自然會補好。內容未齊時要保留真實長度與缺口，並指定最後交稿時間，否則手機版和測試都會失真。

怎樣安排驗收才有效？

有效驗收要由一位不參與製作的人按真實步驟操作，並紀錄裝置、輸入、預期結果與實際結果。應先處理阻斷任務的問題，再討論文字或視覺微調，避免不同嚴重程度混在一起。

日後誰可以更新內容？

日後更新權限要按角色分配：內容人員可改文字和圖片，決策人核對發佈，技術人員處理欄位或流程改動。每次更新後應有一個簡短檢查步驟，確保前台顯示與後台資料一致。

出現例外流程怎樣處理？

例外流程應有明確狀態、負責角色和手動處理方法，例如資料不全、提交重複或需要覆核。不能只在備註寫「跟進」，否則不同同事會以不同方式處理，紀錄也無法重現。

怎樣開始與團隊溝通？

開始前先帶同業務目標、現有資料、需要處理的問題和可決定的人出席。需要正式討論時，可聯絡 TERO 網頁設計公司；電話 6205-3555，地址：上環干諾道中 130 號誠信大廈 8 樓 806 室。