SoW
Statement of Work
一份签署过的合同，明确指出交付物、价格与截止日期，并在法律上把供应商绑定到这三项之上。
SoW 是把口头约定变成合同的那份文件。它以具体语言列出交付物（例如「功能 X 上线到生产，通过验收标准 A、B、C」）、价格、截止日期与签收条件。
在奥地利与德国法律下，对应的工具是 Werkvertrag，它比英语世界的 SoW 更强：供应商在法律上必须交付这项工作，而不仅仅是提供劳动，客户可以在工作被验收之前扣留付款。同一法律框架下的 Time & Material 合同是 Dienstvertrag，只承担劳动义务。Wavect 的固定价格合作都是 Werkvertrag 合同。
为什么验收标准撑起了整份合同，举个实际例子：一份写着「构建报表功能，功能应当运作良好」的 SoW 无法执行，因为「运作良好」是个意见。一份写着「端点 /reports 在负载 L 下、对输入区间 R 在 200ms 内返回月度数字，且数值匹配规格 S」的 SoW 可被测试，「做完了」不再是一场谈判。创始人最常犯的错误是为了在开头省时间而签一份措辞含糊的 SoW，然后花六个月争论一个半成品功能算不算交付了。一个抗拒写下精确验收标准的供应商，是在保护他将来去吵这场架的权利。
SoW 同时也是防止范围蔓延的文件：任何不在其中的内容，按定义就在范围之外，要用 Change Request 处理。注意分层，一份 MSA（主服务协议）一次性覆盖法律框架（知识产权、责任、管辖），而多份 SoW 可以随时间挂在它之下。诚实的取舍是，一份严密的 SoW 要花真功夫去写，前期感觉很慢，而这恰恰是一段付费的发现阶段存在的意义。相关：Fractional CTO 奥地利 解释了 Werkvertrag 模式的实操。
在软件项目中何时最关键。 在钱易手的那一刻。SoW 是「你买的是什么」从一场对话变成可强制执行条款的地方，所以它是唯一一份决定日后争议是按合同解决、还是按谁嗓门大解决的文件。
创始人通常会搞错什么。 他们为了更快开工而签下一份措辞含糊的 SoW，然后花几个月争论一个半成品功能算不算交付。验收标准承载了整份合同；「应该好用」是一种意见，不是交付物。
Wavect 如何处理。 我们在任何人签字之前就把验收标准写得足够精确、可测试，并先跑一段付费 Discovery，让范围是真实的。我们的如何挑选软件机构指南和固定价格对比 Time and Materials 指南用大白话讲透了合同决策。