更新於 2024/02/04發佈於 2023/01/19閱讀時間約 3 分鐘

語焉不詳未必不好？軟體開發合約那些要注意的地方

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

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

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

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

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

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

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

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

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

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

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

列幾個可能的原則：

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

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

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

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

分享至

成為作者繼續創作的動力吧！