可比较的方案始于清晰的项目需求：值得提供的12项信息

英国现行Sourcing Playbook指出，清晰的需求说明应向潜在投标方提供足够信息，使其能够在充分了解情况的基础上决定是否参与。文件还指出，如果各方对要求没有共同理解，就很难把所报价格与采购方对成本和预期结果的理解联系起来。 [1]

Government Commercial Function的表述更加直接：好的需求说明应包含足够信息，让供应方能够准确计算商品或服务的成本，从而让采购方在相近基础上比较不同方案。 [2]

与此同时，英国Digital, Data and Technology Playbook提醒不要把解决方案规定得过细。它建议关注用户、问题和预期结果，同时给供应方留出提出有效实施方式的空间。 [3]

因此，结论并不是 “把所有事情写得越细越好”。更好的原则是：

准确写明所有方案必须共同遵循的内容，而不要替有能力的专业人士预先决定那些本可以合理自行设计的部分。

两份专业方案不会完全一样，也不应该追求完全一样。

可比较意味着专业人士是在 大体相同的假设下回答同一个问题。

因此，他们对以下内容应有大致一致的理解：

• 目标,
• 范围,
• 起点,
• 预期结果,
• 重要限制,
• 时间安排,
• 客户责任,
• 价格如何呈现,
• 方案将依据什么标准评估.

而以下内容可以不同：

• 建议的思路,
• 工作顺序,
• 方法,
• 团队构成,
• 工具,
• 阶段划分,
• 降低风险的方式.

这些差异往往正是有价值的部分，因此应该保持可见。

从问题开始，而不是从功能清单开始。

与其写：

“我需要一个带总览页面、通知和报告的应用。”

不如写：

“目前有五个人通过电子表格和电子邮件管理流程。很难查看每个事项的当前状态、负责人以及下一步任务。我们希望减少人工跟踪，并在一个地方看到最新状态。”

第二种描述仍没有决定应该做什么样的应用。

但它能帮助专业人士理解 这个项目为什么存在。

针对成果导向服务，Federal Acquisition Regulation建议主要通过所需结果描述工作，而不是只规定工作方式或投入小时数。目标说明的最低内容包括目的、范围、背景、所需结果和运行限制等。 [4]

因此，应写清工作结束后什么事情应该能够实现。

例如：

• 用户能够独立完成指定流程,
• 团队能够查看所有事项的当前状态,
• 客户获得带优先级的分析,
• 系统迁移到新环境并按商定标准运行,
• 准备好的材料可在指定渠道发布.

结果应足够具体，让双方都能理解工作的方向。

但这不意味着必须保证由市场、用户行为或供应方无法控制的其他因素决定的商业结果。

同一个最终目标，根据起点不同，所需工作量可能差别很大。

建议说明：

• 已经有哪些东西,
• 哪些可以正常工作并应保留,
• 哪些不能正常工作,
• 是否有源文件,
• 是否有现有文档,
• 是否需要迁移数据,
• 是否必须在现有系统上继续工作,
• 哪些材料已经准备好.

“新网站” 可能意味着从零开始建设，也可能意味着在保留内容、网址、分析设置、系统集成和数据的情况下重建现有网站。

即使最终外观可能相似，这也是两种不同的工作。

项目范围不应让专业人士自己猜测问题的哪些部分需要计价。

例如：

范围内：

• 分析当前方案,
• 设计新页面,
• 实施,
• 迁移已经明确的一部分数据.

范围外：

• 创建新内容,
• 购买许可,
• 第一个月之后的维护,
• 重建支付系统.

世界银行的Terms of Reference示例强调，应清楚说明咨询服务的要求和期望，并根据具体项目进行调整。 [5]

当两项工作天然相关，很容易让人误以为一项包含另一项时，明确边界尤其重要。

如果你期待特定材料或结果，就直接写明。

例如：

• 可运行的解决方案,
• 源文件,
• 报告,
• 文档,
• 视觉设计,
• 一组材料,
• 环境配置,
• 培训,
• 录制文件,
• 代码和访问权限的交接.

“设计”、“分析”、“实施” 等词可能被不同的人理解成不同内容。

统一列出主要交付内容，可以避免某份方案实际上包含远多于另一份方案，却因为服务名称相似而看不出差异。

并不是每个限制都属于技术细节。

重要限制可能包括：

• 必须使用的系统或环境,
• 必须与指定服务集成,
• 无障碍要求,
• 行业法规,
• 数据存储限制,
• 必须保留现有基础设施,
• 指定设备或浏览器,
• 必须在特定时间工作,
• 数据访问限制.

FAR在目标说明中明确包括运行限制，而英国Digital, Data and Technology Playbook也说明，如果并不存在真正的限制，就不应提前规定解决方案。 [4] [3]

一个实用原则是：

明确专业人士不能改变的内容，但不要仅仅因为你习惯某一种方案，就人为创造一个限制。

专业人士需要知道，自己的方案可以建立在怎样的客户配合基础上。

请说明你是否会提供：

• 决策人,
• 系统访问权限,
• 现有材料,
• 数据,
• 测试账号,
• 团队信息,
• 与用户接触的条件,
• 内容,
• 定期会议,
• 在指定时间内回复.

如果你现在还不知道能够提供什么，也应该直接说明。

缺少对数据、材料或人员的访问，可能改变方法、成本和时间。这不是小的行政细节，而是方案成立所依赖的条件之一。

不是每一个日期都有同样的含义。

应区分：

• 希望开始的日期,
• 不能移动的截止日期,
• 与外部事件相关的日期,
• 参考日期,
• 必须按特定顺序发生的阶段.

如果截止日期确实不能移动，请解释原因。

如果可以调整，也应说明。

这样专业人士可以提出不同的范围、顺序或分阶段交付，而不是把所有日期都当成绝对要求。

没有一条统一规则要求客户必须始终公开全部预算。

根据情况，你可以提供：

• 最高预算,
• 预算区间,
• 第一阶段预算,
• 先希望收到范围建议，再讨论价格,
• 希望价格按什么结构拆分.

为了比较，最重要的是让专业人士用类似结构呈现成本。

例如：

“请分别列出分析、设计、实施和每月维护的价格，同时注明未包含在报价中的第三方服务费用。”

这种格式比四个总价更容易比较，因为不同总价可能各自包含完全不同的内容。

不确定性不会因为没有写下来就消失。

如果你不知道：

• 需要迁移多少数据,
• 外部接口是否支持所需操作,
• 所有内容是否能够按时准备,
• 当前代码是否适合继续扩展,
• 必需的批准是否会按时获得,

就直接说明。

GAO关于可靠成本估算的指南强调，明确假设以及分析风险和不确定性非常重要。 [6]

这样，好的专业人士可以：

• 设置合理预留,
• 建议先做调查阶段,
• 分别给不同方案报价,
• 指明什么条件会导致价格变化,
• 拒绝假装给出目前还无法诚实达到的精确程度.

公开的未知事项，比隐藏的假设更好。

如果你已经知道决策时哪些因素重要，应在专业人士准备方案之前说明。

可以评估：

• 所提方法是否合适,
• 是否有类似问题的经验,
• 过去工作证据的质量,
• 时间计划是否现实,
• 可投入程度,
• 风险管理方式,
• 实际执行项目人员的能力,
• 价格,
• 维护成本,
• 沟通质量.

世界银行目前关于Rated Criteria的资料指出，非价格标准可以包括方法和工作计划质量、风险管理、履约和能力以及关键人员。标准根据具体采购进行调整，并按相对重要性设置权重。 [7]

这并不意味着小项目需要正式打分。

在发送需求前，能够回答这个问题就很有帮助：

“除了价格之外，什么会让一份方案对我而言比另一份更好？”

如果你确实希望比较方案，就让所有人回答同一组基本问题。

例如：

1. 你如何理解这个问题和预期结果？
2. 你建议什么方法？
3. 你的方案具体包括什么？
4. 哪些内容不包括？
5. 你基于哪些假设？
6. 时间安排是什么？
7. 你需要客户提供什么？
8. 主要风险是什么？
9. 价格是多少，具体包含什么？
10. 哪些类似经验或工作证据与本项目有关？

在公共采购中，统一回复、评价标准和价格呈现格式，就是为了能够在共同基础上评价方案。Government Commercial Function强调，应提供足够信息，以支持准确成本计算和同等基础上的比较。 [2]

统一格式不应抹去不同专业人士之间的差异，而应让这些差异出现在相同的位置，便于看清。

这取决于需求的目的。

公开预算可能有帮助，例如：

• 可以根据可用资金调整范围,
• 希望在明确上限内获得最佳方案建议,
• 希望迅速排除不符合项目财务现实的方案.

不公开完整预算也可能合理，例如：

• 希望先获得对合理范围的独立意见,
• 还不知道现实成本,
• 正在比较不同解决模式,
• 流程要求用其他方式收集价格.

最糟糕的情况不一定是没有预算，而是没有说明 你希望对方以什么形式回答价格问题。

专业人士应知道，是给一个总价、一个区间、几个方案、分阶段价格，还是给出获得更精确估算所需的前提条件。

好的项目需求说明不需要回答所有问题。

可以坦率地写：

• “我们还不知道当前系统能否安全扩展。”
• “我们不知道需要迁移的准确记录数量。”
• “我们还没有决定第二种语言是否进入第一阶段。”
• “我们需要帮助选择最合适的方案。”

这些都是有价值的信息。

不确定性应该影响方案如何准备，而不是从文档里消失。

在某些情况下，第一项最合适的服务并不是全面实施，而是一个短期调查阶段，最终得到决策、更准确的范围或更可靠的估算。

1. 给每位专业人士不同的信息。

2. 只列功能，不解释问题和目标。

3. 不说明已经有哪些东西。

4. 隐藏会在后面改变实施方式的限制。

5. 要求一个最终总价，却不说明这个价格应包含什么。

6. 用自己事前都没有明确的标准评价方案。

7. 把详细描述问题和详细规定解决方案混为一谈。

1. 我是否清楚描述了问题，而不仅仅是自己想象的解决方案？
2. 我希望达到的结果是否清楚？
3. 专业人士是否能理解当前状态？
4. 必须保留的内容是否清楚？
5. 第一阶段范围边界是否清楚？
6. 我是否列出最重要的交付内容？
7. 我是否说明真实限制？
8. 我这一方会提供什么是否清楚？
9. 时间安排是否连同灵活程度一起说明？
10. 价格呈现格式是否方便比较方案？
11. 我是否公开说明最重要的未知事项？
12. 我是否知道除了价格还要评估什么？
13. 所有专业人士是否会回答类似的一组问题？
14. 我是否为比自己设想更好的解决方案留下空间？

好的项目需求说明有两个看似相反的目标。

它应当 足够具体，让几位专业人士针对同一个问题报价。

同时也应当 足够开放，让每个人提出自己的、可能更好的解决思路。

一个实用顺序是：

问题 -> 结果 -> 当前状态 -> 范围 -> 交付内容 -> 限制 -> 客户责任 -> 时间安排 -> 价格格式 -> 未知事项与风险 -> 选择标准 -> 统一回复格式。

如果收到方案后才发现，一个人报价整个项目，一个人只报价分析，第三个人又假设存在额外集成，那么问题不一定出在价格本身。

即使所有人收到的是同一段文字，他们实际理解到的也可能是不同的项目。

[1] UK Government - The Sourcing Playbook
打开来源

[2] Government Commercial Function - How to write a procurement specification
打开来源

[3] UK Government - The Digital, Data and Technology Playbook
打开来源

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
打开来源

[5] World Bank - Sample Consultants Terms of Reference
打开来源

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
打开来源

[7] World Bank - Rated Criteria
打开来源

方法说明： 这些来源主要来自公共采购和成本管理环境，并不作为私人专业人士市场的直接规则。本文只采用它们实际支持的原则：要求清晰、聚焦结果、明确假设和风险、可比较的价格信息，以及使用价格之外的质量标准进行评价。