软件 RFP，也就是需求建议书，本来的作用是让不同的供应商变得可以互相比较。可现实中大多数文件恰好起了反作用：它们把解决方案写得足够细，细到把答案的空间捆死，却偏偏漏掉了任何人报价时都需要的那些信息。结果就是五份报价，彼此相差一个数量级，形式上每一份都回应了要求，但没有任何两份在测量同一件事。

常见的解释是供应商在打太极。偶尔确实如此。但更常见的情况是，文件要了一个从它自身内容里根本推不出来的数字，于是每家供应商都用各自不同的假设去填补空白。假设不同，价格自然不同，这里并不存在诚不诚实的问题。

判断你的 RFP 是否有效的检验方法： 两家不同的供应商读完之后，能不能得出实质上相同的范围？如果文件里只写了“用户管理”，没有说明有多少种角色、权限是否按记录变化、是否需要对接已有的用户目录，那么一家会报一周，另一家会报两个月。两家都在诚实作答。而你无法把它们放在一起比较。

为什么功能清单是错误的起点

一份功能清单告诉供应商的是你做了什么决定，而不是你需要什么。这件事之所以重要，是因为那个决定本身可能就是错的，而看出错误的人，在你规定的文件结构里根本找不到地方把它说出来。

功能清单还会把真正驱动成本的信息藏起来。软件的工作量集中在那些麻烦的部分：要对接多少个外部系统，有多少存量数据需要迁移、这些数据有多干净，有多少种权限各不相同的用户类型，以及需要满足哪些合规义务。一份功能清单可以写得很长，长到好几页纸，却一条都没有提到上面这些。

替代做法不是把话说得含糊。准确描述问题，写清楚哪些约束是真正不能动的，然后把方案本身的解释交给提案方去写。你会收到不一样的答案，而这些差异是有信息量的，而不是噪音。哪里出现分歧，哪里就是你接下来真正需要讨论的议题。

一份软件 RFP 真正该写的内容

业务问题，以及成功意味着什么。 现在发生的是什么，本来应该发生什么，以及你会用什么来判断这件事做成了。供应商会拿这一段去质疑范围本身，而在这个阶段，这是他们能为你做的最有价值的事。

规模和数量，用数字写出来。 用户数、交易笔数、记录条数、预期增长。仅这一项就能消掉报价差异中很大的一块。

必须对接的系统，逐个点名，并注明每一个是否有文档齐全的 API。一个没有文档的老系统对接，花的钱就可能超过其余所有工作加起来的总和。

你已经有的数据。 有多少、存在哪里、状态如何。数据迁移几乎在每个项目里都是被低估得最厉害的一项。

真正不能动的约束。 监管义务、指定的托管地点、已经在用的身份认证系统、挪不动的截止日期。请说明哪些是硬性条件、哪些只是偏好，因为供应商会对硬性条件做防御性报价。

你不打算做的事。 把不在范围内的东西明确写出来，是压缩报价离散度最便宜的办法之一。

你的预算区间。 藏着它并不会让价格更低，只会换来一批按照谁也不知道的预算去裁剪范围的方案，然后还得重做一遍。给出区间，供应商才能告诉你在这个区间里究竟能做成什么。各个价位分别能买到什么，我们在定制软件开发成本指南里写清楚了。

能把供应商区分开的问题

问题要少而精。下面这几个问题，比一份一百行的合规对照表能揭示的东西多得多。

你们会先做哪一部分，为什么？ 先后顺序会暴露对方到底理解了问题，还是只理解了这份文件。

这里面风险最大的是什么，你们打算怎么把它降下来？ 能说出一个真实风险的供应商，比一个报告说没有风险的供应商更值得信任。

具体是谁来做？ 姓名、资历，以及他们投入多少比例的时间。写提案的人不参与实现，是一种反复出现的失望。

范围发生变化时会怎么处理？ 它一定会变。这个答案告诉你这段关系在压力之下怎么运转，而这比人天单价更重要。

你们需要我们配合什么？ 项目失败的原因里，客户方抽不出人至少和供应商能力不足一样常见，肯把这话说出口的供应商，是在描述现实而不是在卖东西。

结束之后哪些东西归我们？ 代码、基础设施、各类账号、数据。这件事要在定标之前落成书面，而不是之后。

怎么读这些回复

最便宜的报价通常反映的不是效率最高，而是对范围最窄的一种理解，而这个差额会在开工之后以变更申请的形式重新出现。

看看每家供应商把力气花在了哪里。把篇幅花在系统对接和数据迁移上的提案，说明它明白难点在哪。把篇幅花在方法论和团队合影上的提案，说明它根本没有和问题正面接触。

对方主动提出的反驳，应当当作好信号。一家供应商说你范围里的某一部分其实没必要做，或者说你提出的某个约束的代价大过它的价值，这正是你真正希望别人替你做的工作。什么都点头的供应商，看起来省事，合作起来更糟。

还要核对每一份报价回答的是不是同一个问题。两份报价如果差了三倍，那么其中一份一定假设了文件没有写的东西，找出是哪一份，比任何评分矩阵都有用。

什么时候不该走 RFP

如果工作量很小，或者带有探索性质，或者你还不知道自己需要什么，那么 RFP 就是用错了工具。它会让双方各花掉几个星期，最后只留下一种精确的假象。

这些情况下，通常更好的做法是先做一次付费的需求调研：用一小段工作产出一份规格说明，之后再拿它去找供应商；或者得出结论说这件事根本不值得做。这两种结果，都好过让大家围着一个谁也定义不清的范围去竞标。关于怎么收窄范围，我们那篇MVP 软件开发指南里的做法可以直接照搬。

Mecanik 既会作为供应商回应 RFP，也会帮助采购方把 RFP 写出来，这是我们软件开发工作的一部分。真正能换来好报价的文件，无一例外都是更短的那一份，而且里面有真实的数字。

常见问题

一份软件 RFP 应该包含什么？ 业务问题和成功的定义，带真实数字的规模与数量，需要对接的系统逐个点名并说明每个是否有文档齐全的 API，待迁移数据的状态，哪些约束是真正不能动的，哪些内容明确不在范围内，以及一个预算区间。

要不要在 RFP 里写预算？ 要写。藏着预算并不会让价格更低，只会换来一批按谁也不知道的预算裁剪过的方案，之后还得重做。给出区间，供应商才能告诉你在这个范围内现实上能做成什么，各家的回复也才具备可比性。

同样一套软件，报价为什么能差这么多？ 通常是因为文件留了空白，而每家供应商用了不同的假设去填。像“用户管理”这样一行字，没有说明角色数量、是否按记录设置权限、是否需要对接用户目录，报一周和报两个月都可以是诚实的。这种离散度是 RFP 的属性，不是供应商的属性。

哪些问题能看出一家好的软件供应商？ 他们会先做什么、为什么这么做，他们认为风险最大的是什么、打算怎么降低，具体由谁来做、投入多少比例的时间，范围变更怎么处理，需要你配合什么，以及结束之后哪些东西归你所有。

什么情况下不该用 RFP？ 工作量小、带探索性质，或者你还无法定义自己需要什么的时候。围着一个没定义清楚的范围竞标，会让双方各花掉几个星期，只换来精确的假象。更合适的工具是一次付费的需求调研，它要么产出一份规格说明，要么直接得出这个项目不值得做的结论。