剛開始接案的人，多半栽在同一個地方：技術做得出來，但案子做不完。原因不是能力不足，而是一開始沒把範圍、驗收與付款講清楚，做到後來變成無止盡的修改。也有另一種情況，是已經接了幾個案子的人，開始想把流程制度化，不要每次都靠人情與加班收尾。這篇站在接案方的位置，把從找案、篩案、問需求、簽約、驗收到交付的每一步該注意什麼寫出來，重點放在那些事後才發現、當初應該先講的事。
案源的三種來源，性質完全不同
- 轉介與回頭客：信任基礎最好，需求溝通成本低，但來源不穩定，也容易因為熟識而省略書面約定，反而埋下爭議。
- 公開媒合的接案平台：案量多，能快速累積經驗，缺點是競爭集中在價格，需求描述通常很簡略，篩選成本高。
- 同業轉包：由開發公司把部分工作外發，規格相對完整、對接的人懂技術，溝通效率高，但要接受在較長的鏈條裡工作，付款節奏受上游影響。
初期靠平台累積作品沒有問題，但長期要把重心移到前兩種。判斷方式很簡單：如果每一次都要從頭解釋自己會什麼，代表還沒有建立可累積的信任。
接不接之前，先做這一輪篩選
不是每個案子都值得接。有幾個訊號出現時要特別謹慎：對方說不出這個系統要解決什麼問題、無法指出誰是最後決定的人、希望先看到成品再談條件、把時程壓在明顯不合理的期限、對前一位接手的人有很多抱怨卻說不出具體原因。
另一個容易被忽略的篩選點，是對方公司內部的準備程度。資料還沒整理、流程還在爭論、要串接的系統聯絡不到窗口，這些都會讓工期延長，而延長的成本通常由接案方吸收。開工前確認這些事，比事後爭執有用得多。
報價之前，這些一定要問出來
沒問清楚就報價，等於是替自己下注。至少要問到以下幾項：
- 使用者是誰、同時會有多少人用、要不要分權限。
- 資料從哪裡來，是人工輸入、既有系統匯出，還是要即時介接。
- 要串接的外部服務有沒有測試環境與文件，由誰申請帳號。
- 誰負責驗收，除了他之外還有誰能提意見。
- 要不要負責主機、網域與上線後的環境維護。
- 有沒有既有的程式碼或設計稿要沿用，狀態如何。
其中「介接對象有沒有文件」影響最大。同樣一個功能，對方有完整文件與沒有文件，工作量可能差到好幾倍，這件事沒確認就報價，風險全部落在自己身上。
合約裡不能省的幾個條款
金額之外，真正保護雙方的是這幾條。第一是工作範圍，用可以驗證的方式描述功能，並寫明不包含哪些項目。第二是變更程序，約定超出範圍的需求要以書面提出、重新評估工期與費用後才進行。第三是付款與里程碑掛勾，依階段完成情況分次請款，避免全部押在結案。
第四是智慧財產權歸屬，寫清楚交付的程式碼何時移轉、接案方能否保留通用元件再利用。第五是保固範圍與期限，明訂保固只涵蓋原範圍內的瑕疵修正，不包含新增功能與環境變動造成的問題。第六是終止條款，約定任一方中止時，已完成部分如何計價與交付。
驗收標準要在開工前就寫下來
爭議大多不是出在功能有沒有做，而是出在「算不算做好」。避免的方法是把驗收條件寫成可以逐條打勾的清單，每一條都描述在什麼情況下輸入什麼、應該得到什麼結果。含糊的形容詞例如順暢、好用、要快一點，都應該轉成可觀察的描述。
同時要約定驗收的期限與默認機制：交付後對方在一定期間內未提出書面意見，視為通過。沒有這一條，案子會無限期停在「還在測」的狀態，尾款也跟著卡住。
最常見的踩雷情境
需求分批出現是第一名。對方在過程中陸續想到新功能，每一項單獨看都不大，累積起來卻遠超原本範圍。處理方式不是拒絕，而是每一次都回覆：可以做，這會影響工期與費用，請確認後我們安排在哪個階段。把選擇權交回去，多數需求會自己消失。
第二是窗口不只一個，兩位主管給的方向相反，改來改去。開工前要確定唯一的對接人與決策人，其他意見統一由他彙整。第三是對方的資料遲遲沒有提供，導致無法測試卻仍要求如期交付，合約裡應約定資料延遲提供時，時程順延。第四是上線後被視為長期免費支援，這要靠保固範圍與維護合約分開來處理。
交付與後續維護的界線
結案時該交出的不只有可以執行的系統。完整的交付通常包含原始碼與版本紀錄、資料庫結構與初始資料、環境建置與部署步驟說明、使用到的第三方服務清單與設定方式、以及帳號密碼的移交。這些準備好，對方才不會在半年後回頭找你處理小事。
維護則建議另立合約，明確寫出回應時間、服務範圍、超出範圍如何計費。把保固與維護分開，是讓雙方關係能長期維持的關鍵，也避免結案之後責任模糊。
常見問題
客戶只給一句話的需求，要怎麼開始？
先不要報價，改成安排一次釐清會議，由你提問、對方回答。問題順序建議從使用者與情境開始，再到資料與流程，最後才談畫面。會後把理解寫成一份簡短的需求摘要請對方確認，這份文件既是後續報價的基礎，也是變更時的比對依據。願意配合這一步的客戶，通常後面也好合作。
對方要求先做出來看看再談條件，可以答應嗎？
完整功能不建議。如果對方需要具體的東西才能決定，可以改成先做一份可點擊的畫面流程或小範圍的技術驗證，並將這段工作單獨計價。這樣雙方都能降低風險，也能篩掉只是想蒐集免費方案的詢問。無償產出完整功能，往往換不到後續合作。
需求一直增加，怎麼拒絕又不傷關係？
不要用拒絕的方式表達，改用選擇的方式。回覆時明確列出這項需求需要多少工作量、會讓哪一段時程往後、費用如何調整，並提供替代方案，例如先上線再排入下一階段。全程留下書面紀錄，讓對方看到範圍是被記錄下來的，而不是靠感覺爭論。
尾款遲遲不付，事前可以怎麼預防？
把付款拆成階段，讓每一階段的請款都對應到可驗證的交付物，而不是把大部分金額押在最後。合約中加入驗收期限與逾期未表示意見視為通過的約定，並約定逾期付款的處理方式。上線所需的帳號與正式環境部署，可安排在款項到位後進行，這是合理且事前說明清楚的做法。
原始碼一定要交給客戶嗎？
依合約而定，但建議在簽約時就講明白。多數企業客戶會要求取得所有權，這時要在報價中反映；若你希望保留可重複使用的通用元件，可以約定客戶取得專案程式碼的完整使用權，而通用元件以授權方式提供。最忌諱的是不談清楚，等到結案才發現雙方認知不同。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「程式外包接案」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
