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