軟體開發是結合領域知識、工程方法及成本控制等多面向的複雜任務，尤其在這個技術發展越來越快、用戶需求越來越細緻的時代，複雜度往往遠超想像。

而對一個新商業模式或數位轉型來說，驗證可行性及解決既有的痛點難度本就不低，如果還得再加上對於資訊技術的掌握度要求就更容易招致失敗。在這種情況下，尋求外包、找專業的支援就是個很理性的選擇。

但外包合作有那麼簡單嗎？且不論夥伴選擇及溝通本身就是學問(參考如何讓你的系統設計能真正解決問題)，有時候連合約怎樣落都是個問題。

本篇文章稍微分享一下過往在合約來回時常碰到的問題及調整方向。

困難之處：非標準品本就容易雞同鴨講

軟體開發易生糾紛之處主要來自於標的物不明確，這也連帶使成本計算變得困難(參考軟體開發值多少？系統開發怎樣估成本)。

可能會有朋友覺得標的物哪裡不明確了？以電子商務來說，這個我們看的還少嗎，打開 google 搜尋一找一大把。但如果仔細思考，你會發現其實這些電商類似的地方在於體驗及用法，背後的運作邏輯甚至可能換間店就大不相同。

軟體開發的歷程在於重新描述、搭建流程而非單純的看到結果就仿照模擬。

所以當甲乙方要立定契約時就容易雞同鴨講。畢竟連標的物不明確了，出現糾紛時當然難以說分明。

基於事實才是硬道理

蠻常在一些合約裡頭看到「… 雙方應秉持善良合作義務與對方協同合作 …」等條款，但比起這些文字上的概念敘述，找到共同立足點更為重要。

商務合作的底線不一定在道德約束，更常是在利益分配。

列幾個可能的原則：

1. 追求的公平要考慮雙方曝險程度：有時候在你這是 bug，在對方那可能是滅頂之災
2. 追求達成商務需求而不是百分百規格：軟體工具畢竟是拿來用的，先求能用才能再求好用
3. 保留彈性很重要：合作過程中標定方向後得隨時調整，世界上沒那麼多的想當然爾

條條款款都可以拉鋸

這裡聊幾個過往經驗中常常有來回，建議可以多注意的地方。

1. 標的物要將商務需求進行描述明確，並將基本組成列清楚
2. 最好能明訂一個局中可以決定最後規格的人，不下決定才是最不好的決定
3. 文件的撰寫如非必要在過程中不要過度注重，很多時候清晰的文件在最後階段才有辦法確定。但要小心過程不要偏離終點
4. 如同第一點，驗收的目的盡量注重在事實的功能而不要追求表象的完美。畢竟功能及架構對了，細部修整風險不大
5. 開發期數可以以階段來分(如開案、期中及期末)也可以單純用時間切，重點在於兩造對於各期要達成的商業目標及功能能清楚標示
6. 維護的重點在於維繫雙方對系統運作的成本共識。概念是為了維持甲方系統正常運作或出事時有人會處理，乙方需要維持怎樣的日常投入
7. 產出的歸屬不要過度聚焦在排除乙方，軟體系統很難做到去乙方化(換個語言改寫也不是難事)。如果真的有必要，還是回到費用上討論的好
8. 罰則的設計要分層次，以該期費用、乙方收到的費用、合作總價等逐步釐清。但也請注意甲乙方還是要盡量公平
9. 尾款可以設定在最終移交標的物時。很多時候尾款結案會有糾紛，有個明確的任務界定(如程式碼移交)雖不完滿但至少明確

合約敲不定或有糾紛也只是個新起點而不是終點

其實雙方要能好好合作本質在於互信跟理解，合約只是一個協助這個目標的手段。就好比使用手冊、UI / UX 規格書、測試報告等前期、後期文件，合作契約也只不過是整個軟體的一個觀看視角 — 封裝的是合作關係。

規範要合乎事實，提出異議也要設法思考解法。事後之明總是簡單，但卻也不聰明。

一旦甲乙方進到零和賽局，情感上開始對抗之後，兩敗俱傷就是必然的結局了。既然是這樣，合約的撰寫及執行不妨看作是合作誠意的具象表態。