程式做完了、但驗不了收——當「做完」跟「做好」差了十萬八千里
「做完了」跟「做好了」,到底差在哪？
最近協助一位客戶處理一個卡關的專案。老闆找了外包團隊做一套訂單管理系統,合約寫「三個月交付、功能包含訂單匯入、庫存更新、報表輸出」,看起來很清楚,預算也談好了。
三個月後,工程師交付了系統,老闆打開一看：訂單是能匯入,但只支援特定格式的 Excel、一次只能 100 筆；庫存會更新,但沒有低於安全存量的提醒；報表能輸出,但只有 PDF、不能自訂欄位。老闆覺得「這根本不能用」,工程師卻說「合約上的功能都做了」。
這就是台灣中小企業在軟體專案裡最容易踩到的地雷：沒有明確的驗收標準。
根據國際軟體開發合約實務的觀察 (來源),許多專案糾紛的核心不是技術能力,而是雙方對「什麼叫做完成」的認知從一開始就不同步。合約上寫了功能清單,卻沒寫清楚每個功能要做到什麼程度、用什麼標準來判斷能不能驗收。
什麼是驗收標準？為什麼重要？
驗收標準 (acceptance criteria) 是一組具體、可測試的條件,用來判斷系統是否達到約定的品質與功能要求。它不是事後才補的文件,而是專案一開始就應該跟工程師一起定義清楚的「完成的樣子」。
舉個實際的例子：
- 模糊的功能描述：「系統要能匯入訂單」
- 明確的驗收標準：「系統需支援 Excel (.xlsx) 與 CSV 兩種格式,單次匯入上限 5,000 筆,若格式錯誤需在 3 秒內顯示錯誤訊息並標示錯誤欄位,匯入成功率需達 99% 以上」
前者看起來很清楚,但實際驗收時雙方很容易各說各話；後者雖然花時間定義,但驗收時就很難有爭議。
許多專案卡關的原因,不是工程師技術不好,而是雙方在「好到什麼程度才算好」這件事上從來沒有共識。如果您有一套系統卡在驗收階段、不知道該怎麼判斷能不能上線,建議先盤點目前的程式碼能不能安全上線,再決定下一步怎麼走。
沒有驗收標準,會發生什麼事？
我們遇過的真實案例：
-
無限修改迴圈
老闆說「這裡不符合我的需求」,工程師改了;老闆又說「那裡也不對」,工程師再改。最後雙方都覺得對方在刁難,專案拖了半年還驗不了收。 -
付款卡關
合約寫「驗收後付尾款」,但沒寫驗收標準是什麼。工程師覺得功能都做了、要求付款,老闆覺得系統不穩、不願付錢,最後鬧到要打官司。 -
接手困難
系統交付後才發現沒有文件、沒有測試、程式碼寫得很亂,但因為當初沒約定「要附完整文件」、「要通過測試」,老闆也不知道能不能拒收。
這些問題的共同點都是：當初沒有把「做好」的標準寫清楚。
驗收標準不只是保護您的權益,也是保護工程師——讓雙方都知道做到什麼程度算是完成、可以進入下一階段。如果您正在接手他人寫的程式碼,更需要先盤點現況、重新定義「上線前要達到什麼標準」,才不會讓交接變成另一場災難。
實務上,驗收標準應該包含什麼？
根據我們的經驗,一份完整的驗收標準至少要涵蓋以下幾個面向：
功能面
- 每個功能的預期行為是什麼？
- 支援哪些情境、哪些不支援？
- 錯誤處理要做到什麼程度？
效能面
- 回應時間要多快？
- 能同時支援多少使用者？
- 資料量到多大還能正常運作？
品質面
- 需要通過哪些測試？
- Bug 的容忍標準是什麼？（例如：不能有 critical bug、minor bug 不超過 5 個）
- 是否需要提供測試報告？
文件面
- 需要哪些文件？（使用手冊、技術文件、部署文件等）
- 文件的完整度要到什麼程度？
交付面
- 原始碼要放在哪裡？
- 是否需要協助部署到正式環境？
- 保固期多長、保固範圍是什麼？
這些條件不需要全部都寫得很細,但至少要讓雙方在專案開始前就知道「做到什麼程度才算完成」,也知道「用什麼方式來驗證」。
如果您的系統已經做到一半、卡在不知道該不該繼續,可以參考我們的服務內容,了解我們如何協助您盤點現況、定義上線標準、安全收尾。
如果已經沒有驗收標準了,怎麼辦？
實務上很多專案都是「先做了再說」,根本沒有事先定義驗收標準。如果您現在就是這種狀況,建議可以這樣做：
-
先盤點現況
找一個懂技術、也懂業務的人,幫您盤點目前系統做到什麼程度、還差哪些才能上線。 -
補寫驗收清單
把「上線前必須要有的功能」、「必須通過的測試」、「必須修正的問題」列成清單,讓雙方有共同的目標。 -
分階段驗收
如果系統很大,可以分成幾個階段驗收,每個階段通過了再付一部分款項,降低雙方風險。 -
找第三方協助
如果雙方已經談不攏,可以找中立的技術顧問協助盤點、給出客觀的建議,避免爭議擴大。
驗收標準不是要刁難誰,而是要讓雙方都能安心——工程師知道做到什麼程度可以收款,您也知道收到的系統是真的能用的。
──
如果您手上有個系統卡在驗收、不知道該怎麼判斷能不能上線,歡迎預約免費健診。我們會協助您盤點現況、釐清問題,並給您一份客觀的建議,讓您知道下一步該怎麼走。