驗收怎麼設計才驗得下去：從場景到簽名

先說結論：驗不下去的驗收，都是開案時寫壞的——條款要可量化（場景＋標準＋方法）、階段要切開（過了就簽、簽了就結）、簽名的重量要調到敢簽的程度。
先看那個經典僵局：系統做完了，顧問等驗收請款、天天催；key user 抱著滑鼠不敢按確認——他隱約覺得哪裡怪怪的，但講不出具體是什麼；老闆每週問一次「到底驗完沒」。三方僵持，案子在終點線前趴著。
回去翻合約，兇手通常就一句：「系統功能正常運作，即視為驗收通過。」『正常』是各自表述的：顧問覺得能開單能過帳就是正常，課長覺得要跟他用了十年的舊系統一樣順手才叫正常，兩邊都沒有錯，因為當初根本沒有人定義「正常」。我看過卡死的驗收，九成不是死在結案，是死在開案那天的合約條款。所以這篇的核心觀念是：驗收要在【開案】那天就設計完——條款寫好的那天，結案的架已經吵完了。

條款寫法：跟驗屋學

台灣人驗屋的時候最專業：帶著清單逐項來——門窗開關十次、硬幣敲磚聽空心、衛生紙測排水、插座逐一插電。沒有人會簽「房子整體正常」；驗過的打勾、有瑕疵的列表限期改善、複驗再簽。這套功力原封不動搬進系統驗收，就是可量化條款的三要素：

再給兩組對照，感覺一下粒度：「出貨流程順暢」→「連續三個營業日，實際出貨單全數由系統開立，並實測一次急件插單全流程」；「權限功能正常」→「依權限對照表逐角色抽測，抽測之越權操作全數被阻擋並留有紀錄」。
寫條款時的心法：想像驗收當天，兩個立場相反的人拿著這句話，會不會吵起來？ 會吵的，就是還沒寫完的。順帶一提，瑕疵要先分級（擋驗收的重大瑕疵 vs 限期改善的一般瑕疵 vs 列入待辦的優化建議）——沒有分級的驗收，一顆按鈕顏色都能擋住請款，那對誰都不公平。
我以前的做法是：只要案子輪得到我出聲，我都願意參與合約制定過程——以免驗收不成白做工又傷和氣。你如果進場時合約已經簽了，至少把驗收腳本的粒度補回來，能救多少是多少。

分階段驗收：別把所有的架留到最後一天

一次性大驗收的結構問題：問題全部堆到最後才現形（改起來最貴的時候）、責任糊成一團（這個錯是規格錯、開發錯還是資料錯？半年前的事沒人記得）、然後整包卡住請款，三方關係瞬間緊繃。
切階段，常見四段：模組驗收（單一功能照腳本走）→ 整合驗收（跨模組串流程：接單到出貨到請款一條龍）→ 上線驗收（平行期真實運轉，新舊系統對帳）→ 終驗（守護期滿、遺留瑕疵清零）。案子規模小可以併段，但至少要有「功能」跟「實戰」兩段——功能過了不代表實戰能活，這是無數案子用眼淚驗證過的。
兩條配套紀律：過了就簽、簽了就結——每階段的簽核封存該階段，之後發現的新問題走變更或瑕疵流程，不准翻舊帳重驗（沒有這條，分階段就是假的，最後一天照樣全部重吵）；錢跟階段挂鉤——顧問的付款節點對齊驗收階段，這是雙向的健康設計：他有動力配合驗收節奏，你有籌碼要求品質。付款結構的談法跟顧問費的攻防，顧問費那篇寫得完整，可以轉給你老闆。

簽名的重量：減到敢簽的程度

最後處理那個抱著滑鼠的 key user。他不敢簽，不是龜毛，是他把那個簽名讀對了：簽名＝以後這裡出事，算我的。 一個月薪水領多少、要替一套系統的未來背書，他當然抖。
解法三層，全部是把簽名的重量調到合理：

• 簽核範圍寫清楚。 簽核欄上方加一段話：「本簽核確認上列場景於指定資料下測試通過；未來新增情境與資料變化不在本次確認範圍。」——他簽的是「今天驗的這些是過的」，不是「這系統永遠不會出事」。範圍講清楚，敢簽的人立刻變多。
• 驗的人跟簽的人分開。 課員照腳本執行、記錄結果；課長依結果簽核。執行者不用扛簽名、簽核者有依據可簽——重量被制度分攝了。這順便解決另一個問題：驗收不再依賴某一個人的膣量。
• 拖著不簽的，給流程不給壓力。 條款裡先寫好：「驗收結果送出後 X 個工作天內未回覆意見，視同該階段通過。」搭配溫柔提醒與升級路線（逾期未決那套，有責無權那篇拆過）。注意順序：先確認他不簽的原因是「有真瑕疵」還是「單純怕」——真瑕疵照分級處理，單純怕就回到前兩招。

本篇工具帶走：驗收條款自檢四題

開案時，對著合約草稿問：

1. 每一條驗收條款，都有場景＋標準＋方法三要素嗎？（缺一要素，補到兩個立場相反的人不會吵架為止）
2. 瑕疵分級了嗎？（重大／一般／建議，各自的處理路徑寫了嗎）
3. 階段切了嗎？每階段「過了就簽、簽了就結」寫進去了嗎？（付款節點對齊了嗎）
4. 簽核範圍與逾期條款寫了嗎？（簽名的重量，調到人敢簽的程度了嗎）
   四題都過，恭喜——你的驗收會像驗屋一樣，是個流程，不是一場仗。
   最後說一句：驗收設計的本質是公平——讓做的人知道標準、驗的人有依據、簽的人不揹冤枉債。公平的規則寫在前面，後面的每一方都輕鬆。點交愉快！