以目前网路上可以找到的一些合约范本来看，仍然不脱传统的考量： 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，以及 估计完成时间。 请问大家：有类似的合约范本吗？觉得有哪些该注意的地方呢？ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.160.50.98