一、先别比较价格，先确认报价到底包含什么
“做一套客户管理系统”不是可以直接计价的采购单位。真正影响报价的是范围、质量标准、交付责任和风险承担。
拿到报价前，至少要把以下内容放在同一张表里比较：
- 覆盖哪些用户、角色、流程和终端；
- 是否包含原型、视觉设计、开发、测试和上线；
- 是否包含旧数据清洗、迁移和校验；
- 要对接哪些已有系统与第三方平台；
- 性能、安全、兼容性和可用性要求是什么；
- 源代码、设计稿、数据库脚本和部署文档是否交付；
- 服务器、短信、地图、支付和模型 API 是否另计；
- 免费缺陷修复期多长，新增需求如何计费；
- 由谁准备账号、测试数据和业务确认人员；
- 以什么证据验收，付款对应什么结果。
如果两份报价的这些边界不同，只比较总金额没有意义。可以先参考《开发公司报价差很多，老板到底该看哪一项？》，把功能数量、交付深度和风险责任拆开再看。
二、总价合同：买的是明确范围内的结果
总价方式通常是：双方先确认需求、交付物、周期和验收标准，供应商承诺以约定金额完成。只要客户没有改变范围，估算偏差主要由供应商承担。
总价最适合哪些项目
- 业务流程已经稳定，短期不会大改；
- 功能、角色、数据和接口边界能够写清；
- 有明确的验收样例或现有系统可参照；
- 决策人和业务负责人能及时确认；
- 第三方接口、历史数据和部署环境已经核实；
- 交付时间和预算上限比持续探索更重要。
例如，按照已确认模板建设一个内部报修系统，用户角色、表单字段、审批节点、统计口径和消息渠道都清楚，就有条件做总价。供应商可以据此估算工作量并为交付结果负责。
总价并不等于“所有想法都包含”
总价只对基线范围有效。签约后增加一个角色、改变审批逻辑、接入新的财务系统，都会改变设计、开发和测试工作。若合同没有变更机制，双方很容易陷入争论：客户认为只是小改，供应商认为已经超出报价。
因此，总价合同必须同时写清“包含什么”和“不包含什么”，并约定变更由谁提出、怎样评估、谁批准、对费用和周期有什么影响。没有范围基线的总价，往往只是把争议推迟到项目中后期。
总价项目最常见的风险
一是为了抢单而低价承诺，后期通过频繁追加费用或减少测试、文档和售后弥补；二是需求写得很粗，供应商只能按最简单的理解交付；三是验收标准写成“系统正常使用”，出现分歧时无法判断是否完成。
所以，总价真正需要锁住的不是一张功能名称清单，而是关键流程、业务规则、异常场景、交付资料和可验证的验收条件。
三、按人天计费：买的是可调整的团队产能
按人天，也常被称为工时计费或 Time & Materials。企业按不同角色实际投入的时间结算，例如产品、设计、前端、后端、测试和运维分别记录投入。
这种方式不是供应商“随便花时间”，而是把方向调整权更多留给客户：每个迭代先排优先级，团队按约定节奏交付，企业根据结果继续、调整或停止。
按人天适合哪些项目
- 产品仍在探索，用户反馈会持续改变优先级；
- 无法在开工前写清所有细节；
- 旧系统情况复杂，需要边分析边改；
- 第三方接口和数据质量存在不确定性；
- 企业内部有懂业务、能持续参与的产品负责人；
- 希望先交付高价值功能，再根据预算决定后续范围。
例如，一套面向客户的新业务平台，企业知道要解决什么问题，但套餐、运营规则和用户路径仍在试验。若一开始用总价锁死全部页面，之后每次根据市场反馈调整都会触发变更。按人天更适合持续排序和验证。
按人天不等于只看考勤表
企业真正要管理的是产出、质量和剩余预算。一个健康的按人天项目至少应该有：
- 透明的需求池和优先级；
- 每个迭代的目标与演示；
- 角色单价和投入上限；
- 可核对的工时记录；
- 已完成、未完成和阻塞事项；
- 缺陷是否重复计费的规则；
- 每周或每月的预算消耗预测；
- 代码、文档和环境持续归企业掌控。
如果客户没有人做决策，需求长期堆积；供应商只报投入，不展示可运行结果，按人天确实很容易失控。它需要的不是更少管理，而是更短反馈周期和更透明的交付。
四、分阶段计费：买的是逐步降低风险
分阶段不是简单把总价拆成三次付款，而是让每一段解决一种不同的不确定性，并在下一段开始前重新确认范围和预算。
常见做法可以分为：
- 现状审计与需求梳理；
- 原型或技术验证；
- 最小可用版本；
- 分模块扩展；
- 数据迁移、上线与稳定运行；
- 持续运维和迭代。
第一阶段可以采用小额总价，明确交付现状清单、流程图、原型、接口盘点、风险清单和下一阶段估算。高风险技术点则单独做验证。事实更清楚之后，成熟模块可转为总价，探索模块继续按人天。
分阶段最适合哪些项目
- 老系统接手、升级或重构；
- 跨多个部门、规则尚未统一；
- 历史数据量大且质量未知；
- 需要连接 ERP、CRM、财务或硬件；
- AI、算法或自动化效果需要用真实样本验证；
- 企业希望控制现金流，并保留中途停止权。
分阶段最大的价值，不是拖延报价，而是避免企业在未知问题最多的时候一次承诺全部预算。
五、三种方式放在一起怎么比较
| 比较项 | 总价 | 按人天 | 分阶段 |
|---|---|---|---|
| 采购对象 | 明确范围内的结果 | 可调整的团队产能 | 每阶段的验证与结果 |
| 需求稳定度 | 高 | 中低 | 低或未知 |
| 预算确定性 | 基线范围内较高 | 取决于投入上限 | 近期明确、远期逐步确认 |
| 客户参与度 | 仍需及时确认 | 很高 | 每阶段必须决策 |
| 变更灵活性 | 较低，通常另计 | 高 | 中高 |
| 估算风险 | 供应商承担较多 | 客户承担较多 | 双方逐步消化 |
| 适合场景 | 标准化、边界清楚 | 产品探索、持续迭代 | 复杂集成、旧系统、AI 验证 |
| 停止成本 | 中途停止容易争议 | 可按周期停止 | 阶段验收后可停止 |
没有一种方式天然更诚信。真正的差异是：项目中的未知风险由谁承担、方向由谁决定、费用怎样被看见。
六、为什么“人天单价高”不代表总成本高
人天单价不是工程师工资除以工作日。报价通常还覆盖产品与项目管理、测试、代码评审、办公与管理成本、招聘空档、设备、工具和企业经营风险。更重要的是，同样一人天，不同团队解决问题的效率和返工率不同。
老板应关注的公式是：
项目总成本 = 已付开发费用 + 内部配合成本 + 第三方费用 + 延期损失 + 返工与切换成本 + 上线后持续成本
低单价团队如果需要反复解释、返工和救火，最终总成本可能更高。高单价也不自动代表高质量，仍要通过相似项目、技术方案、样例交付、团队稳定性和验收机制验证。
七、最实用的方案通常是混合计费
复杂项目很少适合从头到尾只用一种方式。更现实的组合是：
- 需求梳理和技术审计按小阶段总价；
- 目标明确的基础模块按总价；
- 需求会变化的运营功能按人天迭代；
- 不确定接口先做限时技术验证；
- 数据迁移按样本盘点后分批报价；
- 上线支持按明确时段或服务等级计费；
- 长期运维按基础服务包加新增需求人天结算。
这样既能控制核心预算，又不会为了守住一个虚假的总价，把所有变化都变成合同争议。
八、用六个问题选计费方式
老板可以和业务负责人一起回答：
- 关键流程和异常规则是否已经写清？
- 验收能否用样例、数据和操作结果判断？
- 第三方接口、历史数据和环境是否已经验证？
- 三个月后需求优先级发生变化的可能性有多大？
- 企业内部是否有人持续做产品决策和验收？
- 如果第一阶段结果不理想，是否需要低成本停止？
前两项答案越肯定，总价条件越成熟；第三项未知越多，越应该先分阶段；第四项越可能变化、第五项又有负责人，越适合按人天；第六项越重要，越不能一次性押完整个项目。
九、无论怎么计费，合同都要锁住这九件事
1. 范围基线
需求文档、原型、流程图和接口清单以哪个版本为准，附件与正文冲突时怎样处理。
2. 角色和责任
客户提供哪些资料、账号和确认人，供应商投入哪些角色，双方延迟如何记录。
3. 验收标准
每项结果用什么测试数据、操作步骤和交付资料证明，缺陷等级怎样划分。
4. 变更机制
谁能提变更，怎样评估影响，谁批准后才执行，未批准事项不能靠口头插单。
5. 付款节点
付款应对应可检查的成果，而不是只对应日历日期。预付款、阶段款、验收款和质保款的条件要明确。
6. 源码和知识产权
代码仓库、设计源文件、数据库脚本、第三方组件及授权边界要写清。相关细节可阅读《软件外包合同里最容易埋坑的 4 件事》。
7. 第三方费用
云资源、短信、地图、支付、电子签章和模型 API 谁采购、谁续费、超量怎样处理。
8. 缺陷与新增需求
已确认功能不符合标准属于缺陷；新增流程或改变规则属于变更。两者不能混为一谈。
9. 退出与交接
项目暂停或更换团队时，企业能拿到什么版本的代码、数据、账号、文档和部署环境。
最终验收资料可对照《软件项目验收需要哪些资料？》提前写入合同，别等尾款阶段才补。
十、三类看似便宜、实际危险的报价
第一类是“什么都含”的极低总价，却没有详细范围、接口和验收附件。后续要么不断追加，要么按最低标准交付。
第二类是按人天收费但不提供需求池、演示、仓库和预算预测。企业只看见工时，看不见资产增长。
第三类是所谓分阶段，实际上第一阶段就收取大部分费用，后续阶段没有独立交付物，也没有停止和移交机制。
遇到这些情况，不要只要求对方降价，而要要求把责任、证据和退出机制写清。报价越模糊，企业承担的隐藏风险越大。
十一、一个可直接执行的采购顺序
先用一页纸说明业务目标、用户、核心流程、现有系统、数据、接口和必须上线时间；再邀请供应商做澄清，让各家基于同一版本报价；对于未知较多的项目，先采购审计、原型或验证阶段；收到方案后统一比较范围、团队、交付、风险和持续成本；最后再选择总价、按人天或混合方式。
谈判时还可以设置预算护栏：按人天项目设月度上限和提前预警；分阶段项目设进入下一阶段的批准条件；总价项目为正式变更预留独立预算，但不把所有模糊需求都塞进“备用金”。
常见问题
总价合同一定不会超预算吗？
不会。只有基线范围内相对确定。新增需求、第三方变化、客户延迟和未披露的数据问题，都可能影响费用与周期。关键是事先约定如何认定和批准变化。
按人天怎样防止供应商故意拖延？
要求短周期演示、透明需求池、角色投入、仓库提交、缺陷记录和预算预测，并设置周期上限。不要只验工时，要验每个周期增加的可运行结果和项目资产。
需求还没写清，能不能先要一个总价？
可以要预算级区间，用于判断是否值得继续，但不宜把它当成交付承诺。先完成需求和技术验证，再形成可签约报价更可靠。
小项目是不是都适合总价？
不一定。项目金额小，但如果目标是试验新业务、外部接口未知或决策人频繁改变，总价仍可能制造大量变更。规模和确定性是两回事。
合同条款谁来最终审核？
技术团队可以核对范围、交付和验收，但权属、违约、数据合规等法律条款应由企业结合实际情况请专业法律人员审核。本文不构成法律意见。
参考来源与口径说明
本文对三种计费方式的比较用于软件采购和项目治理，不是统一行业报价，也不替代针对具体合同的法律审查。不同供应商对“人天”“阶段完成”和“质保”的定义可能不同，签约时应以需求基线、责任矩阵、验收附件和付款条件为准。
结语：先匹配不确定性，再谈哪种价格最低
定制软件不是买一件规格完全固定的商品。总价、按人天和分阶段的本质，是用不同方法分配未知风险、决策权和预算责任。
需求明确就用可验收的总价；方向会变且企业有人持续决策，就用透明的人天迭代；业务、数据和技术还不清楚，就先分阶段买清楚。不要为了得到一个看似确定的数字，把尚未解决的不确定性藏进合同。
如果你正在比较软件开发报价，可以先查看华茂思捷的软件定制、系统集成与技术顾问服务，也可以通过联系页面提交现有需求、系统和报价单，我们会先帮助核对范围与风险，再判断适合总价、人天还是分阶段交付。
