推 QCANCER:^^ 推！！這才是正道！ 不要讓自己的技術廉價化了 03/16 23:42
推 haryewkun:這篇是一定要 m 的哦。 03/17 03:47
推 nosrep:m 了 m 了..@@ 03/18 09:49
※ 引述《NandoLee (??)》之銘言：
: 以目前網路上可以找到的一些合約範本來看，仍然不脫傳統的考量：
: 1. 客戶必需在看到實際軟體前搞清楚自己的需求
: 2. 在還沒開始執行前就要確定 schedule deadline
: 3. 無法提供中途更改 spec 的彈性
: 4. etc, etc...
: 如果遵循 agile software development 的原則，合約應該有以下精神：
: 1. iterative 式開發，訂立幾個 major release，依照驗收完成的
: functional block 付款。
: 2. 每月有一小額付款，以維持基本所需。
: 3. 各 block 不訂立詳細規格，而以通過客戶的測試為準。
: 4. 與客戶密切聯繫，每個 iteration 的結果都要 demo 並取得 feedback.
: 5. etc, etc...
: 仔細思考的話會發現中間有些問題需要解決。譬如若允許更改 spec，deadline
: 如何決定？若沒有 deadline 客戶要如何保障自己？或客戶遲遲不願接受軟體
: 而延遲付款？
: 我的初步想法是：若客戶表示不接受，則不授權客戶在測試範圍之外的場合使用軟體。
: 首先協商決定第一個 release 的時間與功能，再視結果來決定下一個 release，以及
: 估計完成時間。
: 請問大家：有類似的合約範本嗎？覺得有哪些該注意的地方呢？
規格不明確的案子，我接過許多，大致上有兩種情形，一種是自己本身比較強勢，
那就還是訂定一般的合約，只描述軟體目標。然後就是邊討論邊實作，客戶的意見
我會回應說可不可行，或是要加錢或是不適合在早期的版本中實作等等。雙方同意
也就自動延伸成合約的一部分了。
另一種情形就是拿相當低的開發費用，往後收取權利金，有按收入拆帳的，也有按
使用者數量算錢的。不過就實際操作的經驗，往往客戶會因此不想花心思在開發的
細節上，覺得交給你做就好，反而成功率偏低。不過我還是很偏好這麼做就是了。
我覺得要操作具有規格彈性的專案，自己與客戶之間的信任才是最關鍵的一環，若
雙方沒有一些信任和默契，實在不太可能靠合約規範就能運作良好。
現在我已經很少簽合約了，在著作權法保護著作人的法律優勢，加上個人商業能力
之下，不太會有客戶跟自己玩花樣，重點是不可以和有足夠勢力欺負你到死的客戶
搞這一套，在那種情況下，合約根本就是狗屁，對方可以請律師團來跟你打官司，
外加在業界圍堵你，而你真有力氣跟他們玩嗎，就算是打贏官司，損失的東西只怕
遠比獲得的東西更多。
其實這樣的開發模式，已經接近商業合作的範疇了，你有技術和工程能力，客戶有
資金和構想，大家合作一個專案，合約主要是劃清雙方權責的一個正式文件，所以
也不容易有固定的範本可以套用，通常需要合約的話，我都是自己寫。
其中內容的關鍵之處，大約就是確認合作關係、標的描述、準備事項、執行要點、
責任及排除事項、利益分配、權利授讓關係、確立合約的正式性、正式聯絡方式、
爭議的解決方式等等。
結果就是每個跟我簽過約的客戶，都拿我寫的合約當成他們的合約範本 Orz..
(世界上最機車的微軟律師都稱讚過我的合約寫得好喔 XD)
寫合約也是一種能力，如果打算靠此吃飯，這是滿有用的技能，說起來和寫程式並
沒有太大不同，大約就像是學習一種叫做合約的程式語言。
原po所提的問題，像是小額付款沒什麼意義，只是讓自己更弱勢而已，不如付頭款
就好，合約只須訂一次的發佈版本，有相關開發、維護及合作的議約優先權就好，
但這種優先權往往是寫爽的而已，對方不爽的話有很多搞法的。
這東西還有最複雜的形式，就是針對專案設立一家虛擬企業，那合約可就是以百頁
做單位的了，由於往往會設在國外，則還要準備英文合約，這才是真的保障到底，
因為客戶必須先注資，不能抽腿，做一個部分就有第三方認證方式付一部分的錢，
最後的利益分配就是以持股比例或員工紅利方式，由會計師處理，由於產品是歸屬
該公司，而雙方都會有董事席次，所以誰也不能亂動。真的是要怎麼搞都有，除非
真是大案子，還不如化繁為簡，以信任關係做基礎來談，不能信任也就不用談了。
(上面那一段很嚇人吧，但這才是正式做法，在美國很常見的)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.173.29