此为历史版本和 IPFS 入口查阅区,回到作品页
Sam Huang
IPFS 指纹 这是什么

作品指纹

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

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

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

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

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

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

https://pixabay.com/illustrations/meet-relationship-business-1019875/

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

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

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

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

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

基於事實才是硬道理

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

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

列幾個可能的原則:

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

條條款款都可以拉鋸

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

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

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

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

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

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






CC BY-NC-ND 2.0 授权