软件开发报价差 3 倍，真正的工程冲突不在价格
同一份需求发给三支开发团队，报价可能相差数倍。最容易犯的错，是立刻判断低价漏项、高价溢价。
工程上更该先问：三支团队承诺的是不是同一个交付物？
"登录、订单、后台、报表"只是模块名。单角色登录和组织级数据权限不是同一项工作；能演示的订单主流程和包含取消、退款、幂等、审计的运营流程也不是同一项工作。价格差异往往来自隐藏在模块名下面的责任边界。
冲突一：需求想保持灵活，报价却想一次锁死
固定总价需要稳定范围。如果需求仍然只有几句话，供应商只能增加风险余量，或者先报低价再通过变更补回成本。
更稳妥的做法是把探索与实现拆开：先用短周期澄清目标、角色、主流程、异常和外部依赖，再为可验收范围报价。这样不是拒绝变化，而是给变化建立基线。
冲突二：双方都写了功能，却没有写完成条件
我会把报价拆成七类边界：
- 用户与权限：菜单权限、数据范围、字段和操作是否分别控制；
- 业务流程：正常路径之外，取消、超时、失败和回退怎样处理；
- 界面与终端：Web、小程序、App 和真实设备覆盖到哪里；
- 数据与集成：历史数据、支付、短信和第三方接口由谁负责；
- 质量与安全：测试、性能、越权检查、备份与恢复怎样验收；
- 交付与归属：源码、仓库、文档、账号和部署脚本交付哪些；
- 运维与售后：缺陷、新需求和第三方故障怎样划分。
如果报价单只列模块，不列这些边界，总价就没有可比性。
冲突三：变更被当成免费，或者被当成黑箱
一次"小改动"可能同时影响权限、状态机、通知、报表和回归测试。合理的变更机制至少需要记录：为什么变、影响什么、增加多少实现与验证成本、由谁批准、进入哪个版本。
缺陷与变更也要分开。没有满足已确认验收标准，是缺陷；验收标准本身改变，才进入变更评估。
把三份报价转换成同一张工程表
比较报价时，可以要求每个供应商对同一组项目回答"包含、不包含、待确认"，并为每项给出验收证据：
| 项目 | 必须回答的问题 | 证据 |
|---|---|---|
| 核心流程 | 正常与主要异常是否都包含 | 流程图、状态表 |
| 权限 | 控制菜单还是控制数据与操作 | 角色矩阵、越权测试 |
| 集成 | 账号、费用、联调与失败责任归谁 | 接口清单、回读记录 |
| 质量 | 性能、安全、备份恢复做到哪一层 | 测试与恢复报告 |
| 交付 | 源码、环境、文档和账号归谁 | 交付清单 |
| 变更 | 谁提出、谁评估、谁批准 | 变更单与版本基线 |
待确认项没有清零前，总价只能是暂定数字。
一份可以直接复用的询价包
询价前不必写几十页需求文档，先准备四份短材料：
- 目标与成功信号：系统服务谁，要改善哪条流程；
- 角色与流程：谁在什么条件下做什么，失败怎么办；
- 验收清单：功能、权限、终端、日志、备份和恢复怎样证明；
- 责任边界：源码、云资源、第三方账号、数据、上架和运维归谁。
国家标准公开系统中的 GB/T 36964-2018说明软件开发成本可以建立度量口径；OWASP ASVS也可以帮助采购双方把"做安全"落到验证范围，而不是一句模糊承诺。
结论很简单：软件开发报价的核心不是把总价压到最低，而是让每一笔成本都对应明确范围、责任与证据。只有交付物相同，价格比较才有意义。