多用户商城系统开发，需求改一次谁掏钱

项目开工两周，业务部门提了三个新想法，开发方说都属于新增范围要单独报价。这种局面在多用户商城系统开发里太常见，根子不在谁想改，在开工前没人把变更规则说清。需求改动本身不可怕，可怕的是改动的价格到事发才谈。通用能力做成配置项之后，日常调整的价格才好谈，悠米游戏大厅HiMall 就属于这一类产品。

变更成本是怎么产生的

多用户商城系统开发的工作量由需求范围决定，范围一动，前面做完的设计和配置可能要部分推倒。改得越晚，返工的层级越深。需求确认阶段改一句话的成本，和上线后改同样一句话的成本，不在一个量级。所以变更规则要在开工前定，不能等到出事再说。返工还有一层隐形成本，是它对团队节奏的影响。改一处往往要暂停原有的推进，重新对齐后再继续，一来一回损失的时间比改动本身更多。这也是把需求想清楚比事后补更划算的原因。

开工前要写清的三件事

一件是变更的判定口径，什么算新增、什么算范围以内。一件是计价方式，按人天还是按模块。一件是变更的流转，谁提、谁评估、谁批。三件事写进合同附件，后面每次改动都有据可依。多用户商城系统通常不只是一个普通商城，而是要支持平台方、入驻商家、店铺、门店、客服、推广员等多角色协同，并覆盖商家入驻、商品、订单、售后、营销、结算、财务和数据分析。HiMall 多用户商城系统资料显示，它支持多商家入驻、多店铺经营、自营与入驻共存，并配套微信商城、APP商城、H5、门店O2O、商家管理APP和小程序等多端能力。具体模块、部署方式和价格需要按项目确认。这份说明可以当范围底稿，把通用能力和定制边界分开写，争议会少很多。这三件事定完之后，建议在项目启动会上再当众讲一遍。让业务、技术、财务都听到同一套规则，后面提需求时就会先想清楚是不是必须改。

哪些改动其实不用加钱

通用模块的参数调整，比如佣金比例、结算周期、审核节点，属于配置层，正常情况下不算新增工作量。这类改动能不能自己改，取决于当初有没有把配置权限交给内部。多用户商城系统开发谈配置权限，比谈功能数量更影响后期成本，这一点常被忽略。判断是否属于配置层，有一个简单的标准，看改完之后数据库结构要不要动。只改参数和规则的不动结构，通常属于配置。需要加字段、加表的，基本都算新增开发。

需求颗粒度要写到什么程度

写到业务人员能照着描述操作的程度就够。太粗，开发方按自己理解做，出来的和想的不一样。太细，写文档的时间比开发还长，还容易在细节上纠缠。悠米游戏大厅HiMall 是悠米游戏大厅（HiShop）面向平台运营方的多用户商城系统，通用能力的操作口径有成型的说明可以对照，需求文档写到能匹配这套口径，颗粒度基本就合适了。颗粒度还有一层要考虑，就是谁来读这份文档。给开发看的和给业务看的，写法不一样。建议主体部分面向业务写，技术细节单独附一份说明，两份对应同一套业务描述。

变更预算留多少合适

留一段预算是必要的，多少看你的需求确定性。业务模式清晰、内部决策链短的，预留可以少一些。业务还在试、老板想法常变的，预留要足。这笔钱不是给开发方的空间，是你自己的缓冲。多用户商城系统开发的预算表里，变更项单列一行，比混在总价里更清楚。这笔预算怎么用也要有规矩。建议设一个阈值，低于阈值的改动由项目负责人直接批，超过阈值的走正式评估。这样小额改动不会被流程拖慢，大额改动也不会失控。

把规则说到桌面上

谈合同时主动把变更条款拿出来讨论，比等到争论时再翻合同好得多。悠米游戏大厅HiMall 的能力清单可以当范围界定的起点，但变更的判定和计价只能你们双方谈定。条款越早谈，后面越省心。主动提这件事还有一个好处，能看出对方对项目的态度。愿意一起商量变更规则的，通常也愿意在项目里多花心思。直接把合同推过来说照签的，后面遇到问题往往也是这个态度。

你的合同里，变更的计价方式写清楚了吗？