系統開發費用容易漏算什麼？多人編輯衝突與資料復原的驗收規格

系統報價單上有「編輯資料、儲存、刪除」，未必包含多人同時操作時的處理。承辦人開啟資料後，主管先修正了其中一個欄位；承辦人仍看著舊畫面，按下儲存時把主管的更新蓋掉。每個按鈕都能正常操作，資料卻已經遺失，這正是只測單人正常流程容易漏掉的問題。

評估系統開發費用時，可以把多人編輯衝突與復原列成獨立規格。需要估算的不是多一行提示文字，而是資料版本、伺服器寫入條件、使用者草稿、差異比較、操作紀錄與復原方式。這篇聚焦同一筆資料的編輯安全，不把庫存扣帳或付款交易當成相同問題。

先辨認哪些資料可能被交錯修改

訪談時不要只問「有多少使用者」，而要問「誰可能同時打開同一筆資料」。課程團隊可能修改報名者的聯絡資料，另一位同事修正梯次說明；不同資料之間互不影響，但若兩人更改同一梯次的開課時間，就需要確認第二次儲存該怎麼處理。

建議整理三個欄位：資料種類、常見操作角色，以及更新衝突的影響。備註可採取新增紀錄的方式，避免把所有留言放在同一欄反覆覆寫；課程名稱可能需要整筆版本比對；核定結果則可能要禁止已送出的舊畫面再改動。這些是設計選項，必須由實際流程決定，不能用「有後台」推定已全部包含。

以森嶼環境學苑展示案例為例，案例資料包含課程梯次、名額狀態、站內報名與「我的報名」查詢。它提供的是示範介面與互動，不能證明已實作正式環境的並行寫入控制。若以此類功能發案，可進一步提出情境：承辦人正在改梯次說明時，另一位管理者已改開課時間，第一人的儲存是否應被拒絕？哪些輸入要保留？這些提問才會形成需要另外設計與驗證的範圍。

版本比對要發生在寫入端

MDN 的 HTTP conditional requests說明，條件式請求可避免修改文件時發生遺失更新。使用 ETag 與 If-Match 等機制時，如果請求所依據的版本不符合目前資料，就可拒絕更新，讓用戶重新讀取或比較差異。

將這個原理轉成需求，可以寫成：「儲存時必須確認編輯者開啟的版本仍有效；如果版本已變，舊內容不能直接覆蓋新資料。」至於採用 HTTP 標頭、資料列版本或其他方式，可由開發團隊依架構決定。重點是比對與更新要能共同保證一致性；單純在前端提醒重新整理，仍不足以防止其他視窗或直接 API 請求寫入舊資料。

MDN 也描述了條件不符時回傳 412 Precondition Failed 的做法。不過案主無需強制每個系統都採相同介面，只需要求供應商說明失敗回應、前端處理與資料未被覆蓋的證據。報價應包含伺服器規則、介面狀態和必要測試，而非只列「新增版本欄位」。

衝突發生後，使用者的工作不能一起消失

遇到衝突時直接清空表單，可能避免覆寫，卻讓使用者重新輸入一整份內容。建議至少定義：本次輸入是否留在畫面、能否複製成草稿、如何看最新內容，以及重新提交時是否再次檢查版本。若需要逐欄比較或人工合併，畫面與資料模型都會增加工作，應明確列成選配或基礎範圍。

W3C 的 User Notification要求表單送出後提供成功或失敗的回饋，通知應清楚，必要時指出相關欄位。據此提出的介面建議是：不要只顯示「錯誤」，而要說明資料已由其他人更新、本次變更尚未儲存，以及可以採取的下一步。衝突與必填欄位錯誤是不同問題，兩者不能共用讓人誤解的訊息。

例如可以提供「查看最新資料」與「保留本次草稿」兩個動作，但要交代其效果。查看最新資料是否會取代目前輸入？草稿留在瀏覽器還是伺服器？共用電腦離開時如何清除？這些決策應由資料敏感程度與使用方式決定。需要長期草稿時，還應估算存取權限、過期與移除功能。

驗收要用兩個視窗，刻意製造舊版本

多人編輯最有價值的測試，不是按很多次同一個按鈕，而是保留舊版本後依不同順序送出。驗收時可以使用兩個具備修改權限的帳號，按以下情境確認結果：

操作紀錄建議記下操作者、資料識別、時間與變更範圍，並依需求決定是否保存完整內容。並非每項資料都必須做逐欄歷史或無限期保存；若只是一般內容管理，保留必要版本與可查詢紀錄可能就足夠。重要的是能確認誰完成修改，以及有權限的人如何找到復原依據。

把費用拆成可選擇的復原能力

邀請廠商報價時，可分別列出衝突偵測、草稿保留、差異比較、歷史查詢與復原。每一項寫適用資料、操作角色、保存方式及驗收情境。若初版只做衝突拒絕與草稿複製，就不要把複雜合併介面當成已包含；若資料一旦誤改會影響實際服務，就應先確認更完整的復原安排。

另外要區分備份與版本復原。整體備份通常用於災難回復，回復一筆使用者剛誤改的資料則需要不同的操作路徑。讓供應商示範「找到舊內容、比對、確認、復原」的一次完整流程，比只勾選「有備份」更能驗證這筆系統開發費用買到了什麼。把交錯修改提前寫進規格，才能在多人真正開始使用之前，處理資料互相覆蓋的風險。