TL;DR — 根據 Standish Group CHAOS Report，約三分之一的 IT 專案能在時程與預算內達成目標，其餘三分之二，很多問題可以追溯到一開始的合約沒寫清楚。本文拆解 8 個關鍵議題：委任 vs 承攬、SOW、IP 邊界、驗收標準、CR 流程、原始碼保管、爭議解決，以及合約真正能保護你什麼。
引言
軟體開發合約，是台灣外包市場爭議最多、範本最多，但真正被讀懂的最少的一種合約。
問題不在於懶得讀。而是，軟體開發的標的物本來就難以在簽約前完整定義，你要把「一套系統」寫進合約，卻連系統長什麼樣都還不確定。語言的模糊不一定是失誤，有時是結構性的困難。但這讓甲乙雙方都暴露在高度不確定性下。
如何選擇合適的合作夥伴是第一步，但再好的合作夥伴，沒有一份設計得當的合約，雙方都走在風險上。這 8 件事搞清楚了再簽。
一、委任還是承攬？選錯法律定性，後果差很大
根據 Standish Group 多年 CHAOS Report，約 31–37% 的 IT 專案能按時按預算交付。多數失敗案件中，法律框架選錯是一個被嚴重低估的風險來源，它決定了當事情出錯時，你能用什麼規則處理。
台灣《民法》下，軟體開發合約可能落入「委任」或「承攬」兩種截然不同的框架。選哪個，影響的不只是條文措辭，而是任意終止權、報酬請求時機、違約責任的整套邏輯。
多數人簽合約時沒意識到這個選擇。等到案子中途出問題，才發現雙方對「能不能喊停」的預期完全不同。
| 面向 | 委任（民法 §528） | 承攬（民法 §490） |
|---|---|---|
| 雙方能否任意終止？ | 均可（§549），可約定通知期 | 業主可（§511）；廠商原則上不行 |
| 報酬請求時機 | 依約定 | 完成後（§505） |
| 著作歸屬預設 | 受任人（廠商）持有 | 承攬人（廠商）持有 |
| 適合情境 | 敏捷開發、顧問合作、長期維護 | 固定需求、一次性交付 |
敏捷開發專案建議明示採「委任」關係，但必須在合約中限制任意終止的條件，例如「需提前 30 個工作日書面通知，且應支付終止前已完成工作的報酬」。
二、工作範圍（SOW）：模糊定義是所有爭議的源頭
PMI 的研究指出，35% 的專案失敗直接源自需求蒐集不準確（PMI, Workamajig 引用）。這個數字在軟體外包場景下更高，因為需求在一開始本來就沒辦法完整定義。
不是廠商想偷懶，是因為自然語言描述功能本來就是誤會的起點。「系統需要快速回應」這句話，業主想的是「像 Google 一樣快」，廠商理解的是「不會 timeout 就好」。
SOW 三要素：
- 功能清單：以用戶故事（User Story）格式定義，例如「身為會員，我可以在 30 秒內完成購物車結帳流程」
- 技術規格：量化非功能需求，「首頁載入時間 ≤ 2 秒（Lighthouse Performance ≥ 80）」
- 排除事項：明列「不包含什麼」，這是最常被遺漏、也最容易引發爭議的部分
SOW 建議作為合約附件，版本控制（v1.0, v1.1…），每次變更需雙方簽署新版本。
建議條款方向：「任何本合約附件一未列明之功能需求，均視為本合約範圍外之額外工作，須另行簽署補充協議並附加報酬。」
三、付款條款：保護雙方的結構，以及廠商不說的現實
Dun & Bradstreet 的調查顯示，25% 的外包合作關係在兩年內失效，50% 在五年內失效。付款條款設計不良，是加速這個失效的關鍵因素之一，廠商墊款墊到撐不下去，或業主付了錢卻拿不到預期的東西。
付款結構的選擇，決定的是風險由誰承擔：
| 模式 | 適合情境 | 業主風險 | 廠商風險 |
|---|---|---|---|
| 固定報價 | 需求明確、範圍不變 | 低 | 高（超工時自吸收） |
| 時間與材料（T&M） | 敏捷迭代、需求仍在演化 | 高（可能超預算） | 低 |
| 里程碑付款 | 多數外包案件 | 中 | 中 |
里程碑付款是台灣外包市場最常見的結構。業界慣例：預付款 20–30%，每期款項與驗收掛鉤，尾款 5–10% 在保固期結束後付清。
廠商不說、但你需要知道的現實：
台灣外包市場有一個結構性問題。廠商為了接案，往往接受低預付款甚至無預付款的條件。等案子開始，人力成本全部墊在前面。客戶若在開發過程中消失，電話不接、訊息已讀不回，廠商面對的局面是：合約有里程碑設計，但客戶不回應驗收；走法律途徑，訴訟成本往往超過欠款金額。
比合約條款更重要的商業結構設計：
- 預付款比例越高越好，30% 是最低防線
- 每個里程碑的付款金額應覆蓋該階段的人力成本
- 加入停工條款：「乙方收款逾期超過 X 個工作日，有權暫停工作直至付款完成，且不承擔因此導致的延誤責任」
四、IP 與 Know-how 邊界：業主能要求什麼，廠商應保護什麼
這個議題在台灣中文文章中幾乎沒人完整討論，但它是外包關係中最常引發不滿的灰色地帶，業主擔心商業模式外洩，廠商擔心技術資產被沒收，雙方在合約桌上陷入拉鋸。
業主的擔憂是合理的：廠商了解了我的業務邏輯，如果拿去服務競業怎麼辦？但有些要求超出了合理範圍。
| 項目 | 合理歸業主 | 合理歸廠商 |
|---|---|---|
| 業務流程、商業邏輯設計 | ✅ 業主帶來的需求 | |
| 客製化程式碼（依此專案開發） | ✅ 付費買斷 | |
| 廠商底層框架、通用模組 | ✅ 廠商資產，僅授權使用 | |
| 系統架構設計、技術選型方法 | ✅ 廠商技術能力 | |
| 行業 know-how 的技術實現方式 | ✅ 廠商可複用 |
業主說「我的業務流程獨特，廠商不能拿去服務競業」是合理訴求，但這應該透過 NDA 加上競業條款來保護，而不是著作權全包。要求「所有程式碼、框架、工具著作權全部歸我」，等於要求廠商把工具箱沒收，廠商就無法繼續做這個行業了。
正確的保護機制組合：
- NDA：廠商不得揭露業主的業務邏輯、客戶資料、系統架構細節
- 競業條款：合約期間及結束後 X 個月內，不得直接服務業主的直接競業
- 著作財產權：客製程式碼歸業主，通用框架採授權（非移轉）方式使用
2026 年 AI 程式碼新風險：
目前大量開發者使用 AI 工具輔助撰碼（GitHub Copilot、Cursor 等）。台灣著作權法目前不承認非人類著作人，AI 生成程式碼的著作權歸屬尚無明確法院判決。
建議在合約中加入：「乙方保證交付之程式碼若含 AI 工具生成內容，均已確認不侵害任何第三方著作權，相關合規責任由乙方承擔，並應在業主要求時揭露使用的 AI 工具清單。」
五、驗收標準：「完成」的定義決定最後一筆款能不能收
驗收條款缺失的後果很具體：廠商說交付了，業主說不對，雙方各說各話，最後一筆款就卡在那裡，沒有人拿得走。在我們觀察過的外包案件中，這是最常見的卡關點，也是最容易在一開始就處理好的問題。
驗收分兩個維度，兩個都要寫清楚：
功能性驗收：
- 以 User Story 逐項核對，每個功能點標記「通過 / 不通過 / 待修正」
- 附上截圖或測試記錄作為書面依據
非功能性驗收：
- 效能：首頁載入 ≤ 2 秒、API 回應 ≤ 500ms
- 安全性：OWASP Top 10 漏洞掃描報告
- 相容性：指定瀏覽器版本、行動裝置規格
驗收期限設計：
建議條款方向：「甲方於收到乙方書面通知後 10 個工作日內完成驗收。期限內未以書面提出具體異議者，視為驗收通過。」這個條款對雙方都公平，廠商不會被業主拖著無限期不驗收，業主也有足夠時間測試。
六、變更請求（CR）流程：需求擴張的正式處理
根據 PMI 的研究，52% 的專案受到 scope creep（需求範圍蔓延）影響，這幾乎是每兩個專案就有一個（PMI Pulse of the Profession, 2018）。問題不在變更本身，而在於沒有正式流程處理變更，廠商被拖著加功能，加到一半原始預算全部燒完。
標準 CR 流程（四步）：
- 提出：業主以書面提出，含功能描述與背景
- 評估：廠商於 5 個工作日內回覆工時、費用、對現有進度的影響
- 確認：雙方書面簽署 CR 單
- 執行：納入下一個開發週期
「不簽 CR 單就不執行」是廠商最重要的自保原則。業主說「先做，之後再說」，廠商答應了，之後再說就變成「不是說好免費的嗎？」
建議條款：「所有變更請求須以書面提出，乙方於收到後 5 個工作日內提供工時與費用評估。未經雙方書面確認之變更請求，乙方不承擔執行義務。」
這個紀律在系統現代化或數位轉型專案中尤為重要，需求演變速度快，沒有 CR 流程的合約幾乎必然失控。
七、原始碼保管與終止條款：客戶跑了，你能取回什麼？
這一段，從業主和廠商兩個視角都很重要。
對業主：廠商倒閉或終止合作時的保護
台灣中小型外包廠商有一定的財務風險。若開發期間廠商倒閉，業主能否取得原始碼，完全取決於合約有沒有寫清楚。
建議做法：
- 要求廠商使用 GitHub/GitLab 等版本控制平台，業主帳號需有 co-owner 或 fork 權限
- 合約明定：「乙方應於每個里程碑結束後，將當前版本原始碼及部署文件上傳至甲方指定之程式庫」
對廠商：客戶消失時的停損
客戶不付款、不回應驗收、電話不接，這是台灣接案市場的真實情境。廠商在這種情況下的唯一籌碼，是原始碼。
建議條款方向：「甲方付款逾期超過 15 個工作日，乙方有權暫停交付原始碼及部署作業，直至付款完成，且不因此承擔任何違約責任。」
這個條款的目的不是報復，而是創造談判空間。
知識轉移（Knowledge Transfer）
合約終止時，不論原因，建議明訂以下移交項目（參考 ncube.com 業界實務）：
- 技術文件（系統架構圖、API 文件、資料庫 schema）
- 部署說明與環境設定
- 帳號密鑰清單
移交期限建議 20 個工作日，費用獨立計算。
八、合約的邊界：它能保護你什麼，不能保護你什麼
這是所有文章都不說、但最重要的一件事。
合約能告訴你「你有理」。但無法告訴你「你能拿回錢」。
台灣小額民事訴訟上限是 10 萬元。超過 10 萬的案件走一般民事，從起訴到拿到判決，一審通常需要 1–2 年。如果對方在判決前就把資產轉移或公司清算，勝訴也是空判。
爭議解決方式比較：
| 方式 | 費用 | 時間 | 拘束力 | 適合情境 |
|---|---|---|---|---|
| 協商 | 幾乎免費 | 1–4 週 | 無（達成合意才有） | 雙方仍有合作意願 |
| 調解 | 低 | 1–3 個月 | 調解成立後有 | 金額中等、求快速結案 |
| 仲裁 | 中 | 6–12 個月 | 有（終局） | 不想公開訴訟、求確定性 |
| 訴訟 | 高 | 1–3 年 | 有 | 金額大、需要判例 |
台灣可用的仲裁機構：中華民國商務仲裁協會（CAAI）。建議合約中指定「先行調解，調解不成提付仲裁」，跳過漫長的法院程序。
比合約更有效的前期保護：
合約是最後防線，不是第一道防線。真正的保護在於：
- 業主信用評估：接案前了解對方背景，查詢公司設立狀況
- 預付款結構：收到款項才開始工作，不接受「做完再給」
- 里程碑顆粒度：拆得越細，每次曝險越小
- 原始碼作為籌碼：未付款前不交付完整原始碼
合約如果設計得當，最大的價值不是在打官司時搬出來，而是在簽約前的談判過程中，讓雙方把模糊的期待說清楚。很多糾紛在起草 SOW 的過程中就暴露出雙方認知差距，然後在簽約前就拆夥了。這比拿著合約打官司要好得多。
如果你正在評估雲端架構的合作夥伴選擇，合約設計同樣是評估廠商誠意的重要指標。
FAQ
軟體開發合約一定要找律師審閱嗎？
金額超過 50 萬元或合作期間超過 6 個月的專案，建議至少諮詢一次法律意見。費用通常在數千元以內。更重要的是，合約條款要雙方都讀懂，看不懂的條款比沒有條款更危險，因為雙方對它的解讀可能完全不同。
沒有書面合約、只有 LINE 截圖，法院會認嗎？
LINE 訊息在台灣法院實務中可以作為證據，但舉證複雜度高，你必須能完整呈現對話脈絡且截圖未遭竄改。書面合約的優勢不在於法院認不認，而在於它讓雙方在當下就必須把條件說清楚，減少事後各說各話的空間。
業主要求所有技術 know-how 歸屬自己，這合理嗎？
部分合理、部分不合理。業主的業務邏輯和商業流程應透過 NDA 和競業條款保護。但廠商的底層框架和通用模組屬於廠商的技術資產，要求著作權移轉不合理也難以執行。正確做法：客製程式碼買斷 + 通用框架授權使用 + NDA 保護業務機密。
AI 工具寫的程式碼，著作權屬於誰？
台灣著作權法目前不承認非人類著作人，AI 生成程式碼的著作權歸屬尚無明確判決。實務上，廠商應在合約中聲明 AI 生成程式碼不侵害第三方著作權，相關合規責任由廠商承擔。業主則應要求廠商揭露使用的 AI 工具清單。
客戶不付款、失去聯繫，廠商能怎麼辦？
首先確認合約是否有停工條款，暫停原始碼交付並發出書面催告（存證信函）。若催告無效，評估金額決定下一步：10 萬以下走小額民事，更大金額考慮仲裁。務實面說，前期的預付款比例和里程碑結構設計，比事後追訴重要得多。
結論
一份好的軟體開發合約，不是為了在打官司時搬出來，而是為了在簽約前讓雙方把模糊的期待說清楚。
8 個關鍵議題整理：
- 委任 vs 承攬：選對法律定性，任意終止權才不會成為地雷
- SOW 工作範圍：用量化語言定義，「排除事項」一定要寫
- 付款結構：里程碑付款 + 停工條款，廠商不要全部墊前
- IP 與 Know-how：NDA 保護業務機密，著作財產權保護程式碼，競業條款防止技術外流
- 驗收標準：量化驗收條件，設定逾期視同通過的期限
- CR 流程：不簽 CR 單不執行，是廠商最重要的自保原則
- 原始碼保管：業主要有 co-owner 權限，廠商要有停交籌碼
- 合約的邊界：合約不是護身符，真正的保護在於前期商業結構設計
合約談判本身就是一個過濾機制，願意認真討論每一條細節的對方，通常是認真想合作的夥伴。想進一步了解如何挑選合適的開發夥伴，可參考如何選擇軟體開發公司完整指南。有任何合約設計或外包規劃的問題，也歡迎直接聯繫我們。