在固定价格合同和按工时计费之间做选择，通常被描述成一次关于风险的选择。这个说法本身没错，但紧接着就被处理错了，因为双方都默认风险会消失，而不是只从一方转到另一方身上。

风险不会消失。在固定价格的安排里，供应商承担估算出错的风险，并把这份风险提前算进报出的数字里。在按工时计费的安排里，承担风险的是客户。真正的问题从来不是哪一种方式能消除不确定性，而是哪一方更有条件去管理它，以及为转移风险付出的代价值不值得。

能预判哪种方式管用的检验： 你能不能把“完成”写下来，写到两个人对是否已经达到这个状态能给出一致判断的细致程度？如果能，固定价格是你可以用的选项，而且多半是合理的。如果写不出来，固定价格合同并不会消除模糊，它只是把将来每一次分歧从技术讨论变成商务谈判。

固定价格合同究竟买到了什么

买到的是账单金额上的确定性，除此之外没有别的。具体来说，它并没有买到结果、日期或质量上的确定性，而买家往往以为这三样是打包附送的。

它也有价格。按固定价格报价的供应商一定会加上风险准备金，因为超支要由他自己吞下，而这笔准备金的大小随着需求说明的模糊程度一起变大。对于边界清楚的工作，它可以很有限。对于描述松散的工作，它可能逼近工作本身的成本，而且无论风险是否真的发生，你都要付这笔钱。

第二种代价体现在行为上。价格一旦锁定，所有含糊之处都会朝着少做一点的方向被解释，因为供应商的利益现在落在那一边。这不是恶意，这是合同本身制造出来的激励。在实施中途发现更好做法的供应商，没有理由把它提出来；意识到某条需求写错了的客户，面对的是一份变更请求，而不是一次交谈。

固定价格在真正有边界的工作上表现很好：源和目标都清楚的迁移、对接一个有文档的 API、按已确认设计做一组确定的页面。只要工作带有探索性质，它就表现得很差。

按工时计费何时更便宜

与直觉相反，这种情况经常出现，因为你不用付风险准备金，也不用付处理变更请求的开销。

它适合范围会出于正当理由发生变化的工作：方向取决于用户实际行为的第一个版本、与一套没人写过文档的系统对接、在有人打开之前根本不知道状况的代码库抢救。在所有这些情形里，固定价格实质上是给一个猜测标了一个死价。

它对客户的要求是投入注意力。没有参与的按工时计费会变成一张没有尽头的账单，典型的失败形态是一个项目跑了好几个月，却没有人问上周到底交付了什么。控制力不在合同条款里，而在运作方式里：一份看得见的待办清单、按固定节奏进行的演示，以及客户一方有权调整优先级的具体负责人。

如果你这边没有人能拿出这份注意力，就把话说明白，因为按工时计费不会运转得好，而且没有任何条款能修好这一点。

大多数项目真正该用的第三种方式

一种带上限的、或者按阶段切分的安排。它既不是前面两种中的任何一种，实际适用的软件工作却比两者都多。

带上限的按工时计费。 工作按时间计费，同时设一个约定的封顶金额。客户保留调整方向的灵活性，供应商承担超出上限之后的尾部风险。双方都还留着提高效率的动机，这是两种纯粹模式都做不到的。

分阶段的固定价格。 一段简短且付费的需求梳理产出一份说明书，之后才针对真实存在的东西为开发阶段报固定价格。这是固定价格诚实的版本，因为估算是在未知被压缩之后做出的，而不是之前。这份说明书需要包含什么，我们的软件招标文件指南里有具体说明。

按增量的固定价格。 每个阶段单独报价、单独确认。你以分块的方式获得预算可预测性，同时保留随时停下来的权利。这是客户手里最有价值的权利，也正是长周期固定价格合同拿走的那一项。

共同的线索只有一条：只要有一部分工作已经做完，估算的准确度就会提高一大截。把商务结构搭成能利用这一点的样子，比任何条款都值钱。

固定价格项目真正失败的地方

不在价格上。在范围与变更的交界处。

每一个固定价格项目都会产生变更请求，因为说明书是在任何人真正用过这个东西之前写下的。这份安排是否健康，完全取决于这些请求怎么处理，而这又取决于一开始把范围定义得有多精确，而不是取决于谁的善意。

有两件事能减少摩擦。用书面方式约定一项变更会经历什么：谁来评估、按什么依据定价、多久给出结论。同时在客户一侧也留一笔准备金，因为客户没有变更预算的固定价格，会把每一次新发现都变成一场争吵。

另一种常见的失败是验收。如果合同没有定义如何证明已经完成，尾款就会变成一场关于观点的谈判。把验收标准写在范围旁边，并且优先选择有人能测的标准，而不是有人得去判断的标准。

实际怎么选

先问真正未知的是什么。如果答案是很少，固定价格是合理的，你应当预期为这份确定性支付一笔准备金。如果未知的东西很多，固定价格只是把技术上的不确定变成商务上的摩擦。

再问你能盯住什么。按工时计费奖励注意力，也惩罚注意力的缺席。固定价格每周向你要的更少，却在最前面的说明书阶段向你要得更多，那里的错误更便宜，但也更难被发现。

最后问确定性值多少钱。有时候董事会就是需要一个数字，这时准备金是一个公道的价钱。这是选择固定价格的正当理由，而且比相信固定价格能消除风险要好得多。

Mecanik 在软件开发服务中三种安排都做，最常推荐的是分阶段的那一种。经过两周需求梳理之后给出的估算，对双方来说都比在那之前给出的更有价值。

常见问题

固定价格合同比按工时计费更安全吗？ 它更可预测，这和安全不是一回事。固定价格把估算风险转给供应商，供应商会把这份风险作为准备金算进价格里，所以无论风险是否发生，你都要付这笔钱。它买到的是账单金额上的确定性，而不是结果、日期或质量上的确定性。

按工时计费什么时候更便宜？ 当范围会出于正当理由发生变化时：方向取决于用户行为的第一个版本、与一套没有文档的系统对接，或者在有人打开之前不知道状况的代码库上开工。这些情形下你同时省掉了风险准备金和变更请求的处理开销，因为这里的固定价格只是给一个猜测标了死价。

什么是带上限的按工时计费？ 按时间计费，但设一个约定的封顶金额。客户保留调整方向的灵活性，供应商承担超出上限的风险。它让双方都还留着提高效率的动机，而纯粹的固定价格和纯粹的按工时计费都做不到这一点。

固定价格的软件项目为什么会出问题？ 几乎总是出在范围与变更的交界处，而不是价格上。说明书是在任何人用过这套软件之前写的，所以变更请求不可避免。项目是否健康，取决于事先约定好由谁评估变更、如何定价，也取决于客户自己是否留了一笔准备金。

验收标准应该写进合同吗？ 应该，写在范围旁边。如果没有约定好如何证明已经完成，尾款就会变成一场关于观点的谈判。优先选择有人能测的标准，而不是有人得去判断的标准，因为可测的标准能了结分歧，靠判断的标准只会把分歧拖长。