外包專案最容易翻船的一段，不是開發，是驗收。前面談得再好、做得再認真，只要驗收沒有清楚標準，最後常變成兩種結局：客戶覺得「跟我想的不一樣」死不付尾款，或廠商覺得「你根本是換需求」不肯再改。這篇從外包商的角度，給你一份中小企業能照著走的 UAT（使用者驗收測試）清單，以及付款節點該怎麼綁驗收，讓雙方都有安全感。
為什麼驗收最容易吵架
因為多數爭議的根源，是「當初沒把『做完』的定義寫清楚」。需求文件寫得模糊，驗收時每個人心中的標準就不一樣。解法不是驗收時才來吵，而是把驗收標準前置——在開發前就把「哪些情境要能跑、達到什麼結果算通過」寫進需求文件，驗收只是照表打勾。
UAT 驗收清單：五大面向
- ☐ 功能：真實使用者情境逐條走通（註冊、下單、付款、收信、後台操作），結果符合需求。
- ☐ 效能：主要頁面載入速度達標，要求廠商提供 Core Web Vitals（LCP 等）檢測結果。
- ☐ 相容性：主流瀏覽器與手機／桌機都正常，可對照 MDN 瀏覽器相容性資料。
- ☐ 安全：至少涵蓋 OWASP Top 10 常見風險，敏感資料加密、後台有權限控管。
- ☐ 交付物：原始碼、帳號密碼、部署文件、後台操作說明都交齊（別讓自己被綁死）。
付款節點怎麼綁驗收才公平
| 里程碑 | 交付內容 | 驗收條件 | 建議付款比例 |
|---|---|---|---|
| 簽約 | 需求文件、時程、範疇確認 | 雙方確認範疇與規格 | 訂金 20–30% |
| 開發中期 | 核心功能可展示（Demo） | 主要流程能跑通 | 20–30% |
| 驗收通過 | 完整系統＋測試環境 | UAT 清單逐項通過並簽字 | 30–40% |
| 上線＋保固 | 正式上線、交付所有交付物 | 過保固期無重大問題 | 保留尾款 10–20% |
常見爭議 × 怎麼預防
| 爭議 | 預防做法 |
|---|---|
| 「跟我想的不一樣」 | 需求文件附畫面稿或原型，驗收標準前置寫清楚 |
| 「這是 Bug 還是新需求？」 | 合約先定義：不符需求＝免費修、新增＝變更計價 |
| 驗收拖太久、尾款遲遲不付 | 訂明確 UAT 期限與『視同驗收通過』條款 |
| 交付物不齊、被廠商綁住 | 把原始碼與帳號交付列進驗收與尾款條件 |
驗收 SOP（照著跑）
正確順序是：拿到可操作的測試環境與測試帳號 → 照真實使用者情境逐條測、記錄預期與實際 → 把問題分成「不符需求」與「新增需求」兩類 → 廠商修正後逐項複驗簽字 → 驗收通過對應里程碑付款、再安排正式上線。全程不要在正式資料上驗收，正式資料一進去，很多問題難以回復。
常見問題 FAQ
我不懂技術，怎麼驗收外包做的網站或 App？
你不需要看程式碼，只需要照「使用者情境」驗收：把真實會發生的操作一條條走過（下單、付款、收信、後台改資料），看結果對不對。技術面的效能、安全、相容性，要求廠商提供檢測報告或當場示範，你負責確認『有沒有做、結果達不達標』，而不是自己動手測。
驗收要抓多久？可以邊上線邊驗嗎？
建議保留一段明確的 UAT（使用者驗收測試）期，通常數天到兩週，視系統大小。不建議『邊上線邊驗』——正式資料一進去，很多問題會變得難以回復。正確做法是先在測試環境驗完、簽字，再安排正式上線。
付款節點怎麼綁驗收才不會被卡款、也不會被落跑？
用里程碑付款，每個節點對應明確交付與驗收條件，通過才付該期款。常見結構是簽約訂金、開發中期、驗收通過、上線後保固各一筆，最後保留一筆尾款綁過保固期。這樣雙方都有安全感：你不會一次付光，廠商也不會做白工。
驗收發現一堆問題，是廠商爛還是我要求太多？
先分類。分成『不符合當初需求（Bug／缺漏）』與『我後來才想到的新需求（變更）』。前者廠商該免費修，後者屬於範疇變更、要另外計價。把這條界線在合約與需求文件裡先畫清楚，驗收時就不會變成各說各話的吵架。
行動呼籲
要接手驗收一套外包做的網站或 App，卻不知道從何驗起？我們可以幫你把驗收清單與付款節點對到你的專案，做一次獨立技術驗收。先免費諮詢：
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p