Re: [討論] 搭配 agile development 的合約?

看板CodeJob (BBS架站)作者reader (讀者)時間18年前 (2006/03/16 22:07)推噓3(3推 0噓 0→)

留言3則, 3人參與討論串2/2 (看更多)

※ 引述《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