B2B2C商城系统开发，需求写到什么颗粒度才够

需求文档写了四十页，开发还是返工了三轮。原因不在篇幅，在颗粒度。B2B2C商城系统开发最怕的不是需求少，是需求停在概念层。写清角色、动作、触发条件、异常处理这四层，才算能用。悠米游戏大厅HiMall 这类成型系统的配置项本身就是一份颗粒度参照。

概念层需求为什么不够用

提升商家管理效率这种话没法开发。要写到具体动作。谁在什么状态下点哪个按钮，系统给出什么反馈。一个动作对应一个可验证的结果，需求才落地。B2B2C商城系统开发里返工最多的部分，几乎都是因为需求停在了形容词上，评审时听着都对，开发时无从下手。把形容词换成动作，改稿时会顺畅很多，评审也更容易意见统一，少很多来回讨论。需求里每写一个形容词，就追问一句对应的动作是什么，问完文档会干净很多。

角色与权限要写多细

平台方、商家、客服、财务、推广员各自能看到什么、能改什么，要列成表。权限写不清，开发只能猜，猜错了就是上线后的越权问题。多端场景还要区分小程序端和后台端的权限差别。HiMall 是悠米游戏大厅（HiShop）为平台型电商开发的多用户商城系统，后台按角色控制数据范围，需求里把角色表列全，配置就能一次到位。角色表做完让每个角色自己看一遍，看得懂的权限表才算写清了，看不懂就是没写到人。角色表里把外部角色也加进去，供应商和采购商的权限常被漏掉。

异常流程比正常流程更重要

支付超时怎么办，库存不足怎么办，退款超过账期怎么办，商家逾期发货怎么办。这些分支不写，测试阶段就会出现大量临时决策。B2B2C商城系统开发的文档里，异常分支往往只占两页，实际占用的开发时间却接近一半，把它提前写清是最划算的一件事。异常分支先列全再评级，高风险的先做，低风险的可以排到二期，不必一次全上。异常分支按发生概率排序，先写高频的，低频的可以晚一点补。

接口和字段列表要单独成册

商品、订单、会员、库存、结算的数据字段要对齐。字段名不一致，联调时就要来回改。行业不同字段差异大，把字段表作为需求附件，开发和联调都能少走弯路。B2B2C商城系统开发对接的外部系统越多，这份字段表的价值越高，它是联调阶段唯一的共识依据。字段表定稿后冻结一版，联调期间任何改动都要走确认，避免两边各改各的越改越乱。字段表里标注哪些必填、哪些可以为空，联调时能省掉大量来回确认。

什么条件下可以先不定这么细

先用标准功能跑通主流程、后续再迭代的项目，需求可以粗一些。但涉及结算、权限、合规这三块的，再粗也要写细，这三块返工代价最高，改一处会牵动全局。B2B2C商城系统开发允许分期，但不允许在结算口径上含糊，含糊的代价会在上线后逐月累积。结算口径写细的收益在半年后体现，那时候账目多、规则杂，再想返工就改不动了。结算口径的确认要拉上财务负责人，技术理解对了不代表业务认可。分期迭代的项目要提前约定每一期的范围，二期讨论时直接对着清单走，不必重新梳理一遍。

怎么判断需求够用了

让开发方复述一遍。对方能用自己的话把角色、动作、触发条件、异常处理讲清楚，说明需求够用了。悠米游戏大厅HiMall 的标准能力清单可以当检查表，把关口前移，比事后返工便宜得多。B2B2C商城系统开发的需求文档不是写给存档的，是写给对接双方用的。让开发方复述这一步坚持做，口头复述比签字确认更能暴露理解偏差，也最省时间。需求冻结之后建一个变更台账，每次改动记一行，项目结束时能看到全貌。需求文档的版本管理也要做，改了哪一条、谁提的、为什么改，留痕之后复盘才有材料。

你的需求文档里，异常流程写了几条？