固定价格、按实际投入计费还是包月服务？软件项目定价模式选择

当企业索取软件开发报价时，收到的答复往往看起来无法相互比较。一家供应商报整个项目的固定价格，另一家按工时计费，第三家建议为一个团队收取固定月费。差别不只是数字，而是当需求变化、工作比预期更难或进度延误时，由谁来承担风险。

了解定价模式，有助于您选择与项目相匹配的模式，而不是只看哪家在报价单上显得最便宜。本文比较三种最常见的模式，即固定价格、工时与材料（按实际投入计费）和包月服务（Retainer），以及混合模式、各模式的风险，并列出签约前应提出的问题。

摘要

• 固定价格适合范围清晰且稳定的项目；风险转移给供应商，变更通常需另行收费
• 按实际投入计费适合需求仍在演变的项目；灵活，但缺乏监督时最终预算不够确定
• 包月服务适合维护和渐进式开发等持续性需求
• 混合模式，例如先按工时进行付费的探索阶段，再以固定价格开发，往往最合理
• 无论哪种模式，都仍需要书面的范围、交付时间表、验收标准和清晰的变更机制

为什么定价模式比数字更重要

数字相同的两份报价，可能带来截然不同的结果。范围含糊的低价固定价格，常常以关于“包含什么”的争执、被牺牲的质量或膨胀的变更费用收场。看起来合理的小时费率，如果缺乏范围控制和进度汇报，也可能变得昂贵。因此，第一个问题不是“多少钱”，而是“谁承担什么风险”。

软件项目为何失败一文中讨论的许多失败，根源在于项目性质与商业模式不匹配，例如对尚不明确的需求要求固定价格。

模式一：固定价格

供应商与客户在一开始就约定范围、进度和总价。客户按约定节点付款，通常与定金、设计完成和交付等里程碑挂钩。

优点

• 预算易于预测，也便于在内部获批
• 因工作比预期更难而造成超支的风险由供应商承担
• 范围相同时，容易在不同报价之间比较

缺点与风险

• 范围必须从一开始就非常清晰，而业务需求往往要看到原型之后才能真正理解
• 每次变更都成为一场谈判，通常需要收费，因此客户即便需要也不愿改变方向
• 供应商有动力削减质量、测试或文档以保住利润
• 固定价格报价往往已包含风险储备，所以并不总是更便宜

固定价格最适合范围界定良好的项目，如企业官网、特定集成或规格明确的迁移。需求文档的质量起决定作用，另请阅读如何编写软件需求文档。

模式二：按实际投入计费（Time and Material）

客户按实际使用的时间付费，通常是各角色的小时或日费率，如有其他费用另计。供应商会给出估算，但除非另有约定，估算并不是有约束力的上限。

优点

• 对变更灵活，因此契合[敏捷还是瀑布](/blog/agile-atau-waterfall-metode-proyek-software-untuk-bisnis)一文中讨论的迭代方法
• 客户为已完成的工作付费，而不是为风险储备付费
• 无需等待完整规格即可更早启动项目
• 可根据从用户那里学到的内容在中途调整优先级

缺点与风险

• 最终总成本不确定，范围失控时可能膨胀
• 客户承担工作耗时超出估算的风险
• 需要透明度：工时表、进度和可验证的成果
• 客户一方需要有人积极管理优先级并验收交付物

为控制风险，应设定每期预算上限，在例行演示中定期评审成果，并要求提供把工时与已完成功能对应起来的报告。企业应用 MVP一文中“从小处着手”的方法与此模式非常契合。

模式三：包月服务（Retainer）

客户定期（例如每月）支付固定费用，以获得供应商一定的服务能力：若干工时、专属团队或承诺响应时间的服务套餐。包月服务适合维护、缺陷修复、安全更新和小功能的渐进式开发等持续性需求。

优点

• 月度成本便于预算，长期合作让供应商更了解您的系统
• 由于已预留能力，对紧急问题响应更快
• 适合维护，详见[上线后的应用维护](/blog/pemeliharaan-aplikasi-setelah-peluncuran)一文

缺点与风险

• 未使用的工时或能力可能作废，导致为不用的东西付费
• 没有优先级清单时，能力常被影响较小的零碎工作占用
• 需要明确哪些包含在包月服务内，哪些另行计费

往往最合理的混合模式

许多成功的项目会组合多种模式。常见做法是：先用较短的探索与设计阶段，按实际投入计费，产出范围、原型和更准确的估算；之后，明确的部分按阶段固定价格开发，仍在演变的部分继续按实际投入计费并设预算上限；上线后，维护以包月服务延续。

1. 01较短的探索与原型阶段，产出书面的范围、优先级和估算
2. 02核心模块按阶段以固定价格开发，按里程碑付款
3. 03附加功能按实际投入计费，并设每月预算上限
4. 04持续的维护和改进采用包月服务

这种分阶段的方式降低了前期赌注，让双方在作出重大承诺之前有机会评估是否合适。跨地区项目的其他考虑，见将软件开发外包到印度尼西亚一文。

如何选择合适的模式

• 范围有多清晰？清晰且稳定则固定价格合理；仍在演变则选择按实际投入计费或分阶段方式
• 对预算波动的容忍度有多大？刚性预算倾向于固定价格或设上限的按实际投入计费
• 您的团队能多积极地参与？按实际投入计费要求客户持续参与
• 需求是一次性的还是持续的？持续性需求适合包月服务
• 对供应商有多大信任？新的合作关系适合先用一个小阶段试水

无论哪种模式，合同中都必须写明的内容

定价模式只是合同的一部分。同样重要的要点见软件开发合同的关键要点一文。请确保至少写明以下内容：

• 工作范围以及不包含的内容
• 可测试的验收标准，以及[用户验收测试](/blog/uat-pengujian-sebelum-aplikasi-diluncurkan)流程
• 进度、里程碑，以及双方延误的后果
• 范围变更机制：由谁提出、如何估算、由谁批准
• 代码、设计和数据的所有权，以及对代码库和环境的访问权限
• 交付后的缺陷修复保修期及之后的维护费用
• 保密、数据安全和合同终止条款

报价中的危险信号

• 价格远低于其他报价，却没有对范围的任何说明
• 范围只用“完整系统”之类的笼统说法，没有功能清单
• 没有说明测试、安全和文档
• 只有小时费率，没有估算、上限或汇报
• 在全额付款前扣留代码或访问权限，且没有清晰的托管安排
• 供应商拒绝在签约前讨论范围变更

如果项目已经启动但感觉停滞，挽救停滞的软件项目一文讨论了如何重新评估合同和可行的选择。若想更全面了解成本，包括开发之外的费用，请阅读计算软件项目的真实成本和选择软件公司的检查清单。

常见问题

三种模式中哪种最便宜？没有哪一种天然最便宜。固定价格可能含有风险储备，按实际投入计费在缺乏控制时可能膨胀，包月服务在能力未被使用时则显得昂贵。应比较总拥有成本，而不仅仅是报价数字。

可以在项目中途更换模式吗？可以，只要有书面约定。例如，先用按实际投入计费完成探索阶段，范围清晰后再转为固定价格。

如何避免按实际投入计费时的成本超支？设定每期预算上限，要求定期演示，对功能清单排定优先级，并与供应商一起复核工时表。

保修应该写进合同吗？应该。要明确保修期限、涵盖的问题类型和响应时间，以免交付后发生争议。

包月合同的合理期限是多长？先从较短的周期开始并定期评审，如果结果令人满意再延长。

结语

没有哪种定价模式永远最好。固定价格在范围清晰时提供确定性，按实际投入计费在需求演变时提供灵活性，包月服务则在上线后保持系统健康。许多项目以三者分阶段组合的方式运行得最好。请根据范围的清晰度、预算容忍度和团队的参与程度选择模式，并确保合同清楚写明范围、验收标准和变更机制。