业务变化快，系统边界却常常没有同步变化

电商业务的订单、商品、库存、营销、会员、结算、履约和售后彼此牵连。企业在早期可能只需要一个可验证的交易闭环，但随着渠道增加，系统会被要求接入直播、分销、门店、供应链、跨境、企业采购和多组织核算。每一个新增渠道都可能带来新的价格规则、库存口径、订单状态和结算方式。

我在复盘时会把“新增功能”分成三种：改变核心交易模型的结构性变化；增加外围流程的扩展性变化；只改变页面呈现的局部变化。三者不能用同一种工期估算。结构性变化往往会影响数据模型、接口契约、测试场景和历史数据迁移，表面上是一个页面需求，实际可能是一次架构变更。

如果项目立项时只写“建设一套可扩展的电商中台”，而没有定义可扩展的对象、边界和验证方式，后续所有争议都会变成主观判断：技术说必须做，业务说只是顺手加，财务则只能看到付款进度。这正是预算失控的温床。

第一本：基线账——一开始究竟承诺了什么

我会把原始预算拆成产品范围、架构与基础设施、数据迁移、质量保障、项目管理和上线后的过渡支持。每项都要同时记录数量、质量和时间。例如“支持一万并发”必须说明是读请求还是交易请求、持续多久、允许的响应时间和失败率是多少。

如果基线只有一个总金额，没有范围字典和验收口径，那么它不能称为预算基线，只能称为预算愿望。管理层应允许在立项初期存在区间，但必须设置区间收敛节点。

第二本：变化账——哪些钱是后来增加的

每一条变更至少保留六个字段：提出人、业务原因、影响模块、预计工作量、延迟或风险、批准人。我的经验是，项目一旦把变更和原预算分开呈现，争论会从“谁的错”变成“是否值得”。

尤其要防止“隐性变更”：为了兼容旧接口而增加适配层，为了赶进度而临时绕过自动化测试，为了满足单个大客户而写入特殊规则。它们可能没有新的采购单，却会形成长期技术债。

第三本：复杂度账

我会统计服务数量、数据库种类、外部接口数量、消息主题、权限角色、部署环境和需要回归的关键场景。复杂度不是越低越好，但必须和业务收益匹配。

第四本：价值账

价值可以表现为增量订单、转化率改善、人工减少、客诉下降、结算加速、库存准确率提高或风险损失降低。不能量化的价值，也要写出验证方式与观察周期。

一个实用公式

总拥有成本 = 开发成本 + 迁移成本 + 运行成本 + 变更成本 + 风险成本。其中风险成本可用发生概率乘以影响金额估算，重点不是得到绝对精确数字，而是比较不同方案。

我会坚持的三个财务口径

• 按总拥有成本比较，而不是只比较初始开发报价。
• 把已经发生的沉没成本与未来可避免成本分开。
• 把风险、延迟和机会成本放入方案评审，而不是事后解释。

我会坚持的三个技术口径

• 所有架构选择都要关联明确的业务约束或质量目标。
• 复杂度要有可观察指标，不能只靠资深工程师的感觉。
• 系统边界先服务当前价值，再为经过验证的未来留出扩展点。