軟體外包
先把做到什麼算完成寫下來
軟體外包合約最該寫清楚的，是「做到什麼算完成」：範圍、驗收標準、變更怎麼算、原始碼與著作權歸屬、付款節點和維護期。
這些先寫下來，後面才不必靠記憶吵架。
先講結論：七組條款，把「做完」寫下來
一份能執行的外包合約，至少要對齊七組事情：範圍與交付物、驗收、變更、著作權與原始碼、付款節點、維護期，以及保密與資料處理。條款不用故意寫得艱深，但要能回答誰做、交什麼、何時確認、出現差異時如何處理。評估奧微軟體的軟體外包服務或其他委外方案時，都應先用這七組問題檢查附件是否完整。
合約正文、需求書、報價單、原型與會議確認可能共同構成專案依據，因此要寫清楚文件名稱、版本、日期和優先順序。若正文說法與附件不同，沒有優先規則就可能讓雙方各自引用有利版本。
範圍與交付物：做什麼、不做什麼、交什麼
範圍不要只列會員、訂單、報表等模組名稱。至少要補上使用角色、主要流程、資料欄位、權限、裝置、整合對象與例外情境。相同的訂單管理，可能只是人工建立與查詢，也可能包含庫存、付款、通知和跨系統同步；名稱相同，工作內容完全不同。
不做項目也要列出。它可以是延後功能、由業主提供的內容、第三方申請、既有系統修改或超出首版的情境。交付物則應對應每一階段，例如範圍文件、規格、設計稿、可測試版本、測試紀錄、部署資料與操作文件。寫清格式、版本位置及交付方式，避免最後只剩一個能開啟但無法接手的系統。
驗收：標準、期限、沒通過怎麼辦
驗收條款要同時寫驗什麼、誰驗、如何驗、何時提出結果，以及不符合時如何修正與重測。標準最好能觀察，例如指定角色在特定前提下完成操作後，畫面、狀態與紀錄應出現什麼結果。只寫符合需求或運作正常，仍不足以處理邊界案例。
測試與驗收也要分開。開發方的測試是交付前品質控制，業主驗收則是依約定確認成果。官方採購規則也把品質要求、檢查與驗收放在契約符合性脈絡中；民間專案雖不直接套用同一制度，仍可借鏡先定義契約要求，再保留檢查結果和差異紀錄的做法。
若驗收不通過，條款要說明問題如何列冊、修正後如何重測，以及爭議功能回到哪一版文件判斷。整體階段可搭配軟體外包流程怎麼走？從一句需求到上線，每一關都要交出東西，避免把驗收孤立成最後一次看畫面。
變更需求：追加的範圍怎麼算
需求改變很常見，真正的風險是沒有變更流程。合約可約定由誰提出、廠商要說明哪些影響、誰有權核准，以及核准後更新哪些文件。變更單至少應包含原需求、調整內容、受影響的功能或交付、版本安排與雙方確認紀錄。
先判斷是原約定未達成，還是業務想法新增。前者回到驗收與修正，後者走變更評估。不要因為功能看起來只多一個按鈕，就假設影響很小；它可能連動權限、資料、通知和測試。也不要把所有新想法都視為爭議，清楚流程能讓必要改變被正常討論。
著作權與原始碼：誰擁有、交什麼、第三方元件怎麼處理
著作權法第 12 條明定，出資聘請他人完成的著作，著作人及著作財產權歸屬可以依契約約定；未約定時，法律另有預設規則。因此不要只寫系統歸業主所有，而要把著作人、著作財產權、使用範圍與交付內容分開寫清楚，實際條款仍應依專案情況由專業人士審閱。
原始碼交付也不等於全部權利自動移轉。請列明版本庫、分支、建置方式、設定範本、資料庫結構、部署腳本、設計資產與技術文件是否交付，交付時間及可使用範圍。第三方套件、字型、圖片、雲端服務和商用元件可能有各自授權，應列出名稱、用途、授權來源、帳號持有人與後續費用責任。
專案資產的完整盤點可參考原開發者不做了，接手前要拿回哪些資料？原始碼只是六類資產之一。真正的交接不是收到壓縮檔，而是另一個合格團隊能依文件取得權限、建立環境並理解目前版本。
付款節點：和階段交付對齊
付款節點應對應可辨識的階段與成果，不要只用模糊進度比例。可將需求與範圍確認、原型確認、階段版本、驗收與交接等里程碑寫入，並說明觸發付款所需的文件或確認。這樣付款反映的是已完成的交付，而不是某一天到了。
同時要處理等待業主確認、第三方延誤、變更暫停及部分成果可先確認等情況。若需要保留款項或分段確認，應由雙方依專案風險與契約安排協議。本文不提供特定比例，因為資料敏感度、整合難度、交付方式與責任配置不同，適合的節點也不同。
維護期與上線後問題
維護條款先定義範圍。缺陷修正通常是已約定功能未符合規格；操作協助是使用者不知道怎麼做；環境事件可能來自主機、網路或第三方服務；新增欄位和流程則可能是新需求。四者的判定與處理方式不同，不能全部用有問題再說帶過。
還要約定回報入口、必要資訊、問題等級、確認方式、版本安排與維護結束後的選項。官方品質規則將保固目的描述為界定缺陷發生時雙方權利義務，並要求期間與通知方式清楚；實際民間軟體維護仍應按雙方契約設計。若要了解規劃、建置與後續支持的整體關係，可查看軟體外包服務頁。
保密與資料：先分清會接觸什麼
先盤點廠商在需求、測試、移轉與維護時可能接觸的營業資料、個人資料、帳號、金鑰、測試資料與系統紀錄。契約可約定使用目的、可接觸角色、保存位置、返還或刪除方式，以及發生事件時的通知窗口。不要把正式資料直接當測試資料，也不要在一般聊天工具傳送敏感憑證。
若專案受特定法規、內控或產業要求約束，應在簽約前交由相應專業人員確認。技術團隊可以說明系統如何存取與保護資料，但不能替業主決定全部法律義務。條款越接近實際資料流與操作責任，越容易執行。
虛構教學例：把模糊的完成改成可驗收
以下是虛構教學例，不代表任何客戶或實際契約。某團隊委外製作預約系統，草稿只寫完成預約、會員和後台。雙方後來把範圍補成顧客建立與取消預約、櫃台更新狀態、主管查閱紀錄，並列出首版不包含的行銷與跨店功能。
驗收附件改以角色、前提、步驟和預期結果描述；合約另列變更單流程、版本庫與文件交付、第三方服務清單、付款里程碑、問題分類及資料接觸規則。這些文字沒有消除所有變化，但讓雙方知道變化發生時要回到哪一份文件、由誰決定、留下什麼紀錄。
可直接照做的收尾清單
- 確認正文、需求、報價、原型與附件的版本及優先順序。
- 列清做、不做、由誰提供及依賴第三方的項目。
- 讓每項交付物都有格式、位置與確認方式。
- 用前提、操作、預期結果寫驗收情境。
- 寫明驗收不通過、修正、重測與爭議判定流程。
- 建立需求變更的提出、影響分析與核准紀錄。
- 分別確認著作權、原始碼、帳號、文件與第三方授權。
- 讓付款節點對應可確認的階段成果。
- 拆開缺陷、操作、環境事件、新需求與維護邊界。
- 盤點保密資料、接觸角色、保存與返還方式。
資料來源與核對日期
- 全國法規資料庫：著作權法第 12 條，核對出資聘請完成著作時，著作人與著作財產權歸屬可依契約約定，未約定時有法定規則；2026-09-21 核對。
- 行政院公共工程委員會：資訊服務採購契約範本，核對資訊服務契約可依公開範本逐項檢查履約、驗收、權利與維護等約定；2026-09-21 核對。
- Acquisition.gov：FAR Part 46 Quality Assurance，核對契約品質要求、檢查、驗收、不符合事項與保固期間及通知應有明確依據；2026-09-21 核對。
作者與關係揭露
本文由奧微軟體開發企業社發布，內容為一般軟體外包比較方法與虛構教學例，不構成個別專案報價、採購、法律或契約意見；奧微可能提供與本文主題相關的軟體開發服務。
回文章列表