预算有限时，需求文档里最该写清的三件事
很多中小电商团队在找外包开发或自建技术团队时，习惯把精力放在“要什么功能”上——购物车、优惠券、会员积分。但真正导致项目延期、预算超支、上线后没人用的，往往是那些没人愿意提前写进文档的“隐形需求”。以下三个细节，建议在开发前就明确下来。
一、库存与订单的“负向操作”逻辑
绝大多数需求文档都会写“用户下单后扣减库存”，但很少有人写清楚：用户取消订单、申请退款、超时未支付时，库存什么时候加回来？ 这个看似简单的细节，在促销场景下会直接引发超卖或积压。
- 超时未支付：系统是15分钟后自动释放库存，还是30分钟？如果用户同时用两个账号分别锁定了同一件商品，谁优先？
- 部分退款：用户买了两件，退一件，库存是立即恢复，还是等售后流程走完？
- 异常订单：风控拦截的订单，库存是否已经扣减？需要人工释放还是自动回滚？
建议在开发前，用一张简单的表格列出所有库存变动场景，并注明“触发条件”和“恢复时机”。如果外包团队没有主动问这些，你更要自己写清楚，否则上线后遇到第一个“双11”就会出乱子。
二、后台管理的“操作留痕”与权限边界
中小团队往往只有两三个运营人员，觉得权限管理没必要做太细。但实际运营中，最常见的矛盾是：客服需要改订单地址，但又不能让他看到成本价；运营要改商品价格，但不能让他改结算比例。
开发前请明确以下三点：
- 角色划分：至少分“超级管理员”“运营”“客服”“财务”四类角色，每类角色能看哪些菜单、能点哪些按钮，写清楚。
- 操作日志：谁在什么时间改了商品价格、删了订单、导出了客户数据，这些动作必须记录。不要等出了纠纷才想起来查日志。
- 敏感数据脱敏：手机号、身份证号在后台列表页是否默认打码？导出订单时是否允许包含客户完整地址？这些涉及隐私合规，不能靠开发人员“顺手做”。
很多团队觉得“先上线，权限后面再加”，但后期改权限结构往往要动数据库表结构，比想象中麻烦得多。
三、商品规格与“历史订单”的兼容性
中小电商最常踩的坑是：开发时只考虑了当前商品规格（比如颜色+尺码），但没想过三个月后要加“款式”或“包装”维度。 如果数据库设计时没有预留扩展位，改起来就是伤筋动骨。
更隐蔽的问题是历史订单。比如你之前卖的是“单件装”，现在改成“两件套”，那用户查看历史订单时，商品详情页应该显示旧规格还是新规格？如果旧商品下架了，订单里的商品链接点开变成“商品不存在”，体验会非常差。
建议在需求文档里写明：
- 商品规格是固定属性还是可扩展属性？
- 历史订单中的商品快照（名称、图片、规格、价格）是否需要永久保留？
- 商品下架后，用户中心里的历史订单如何展示？
这些不是技术难题，而是产品决策。你不提前定，开发就会按最简单的方案做——直接引用商品表，结果商品一改，历史订单全乱。
开发前的一个自查清单
与其问“需要哪些功能”，不如问自己下面几个问题，把答案写进需求文档里：
- 用户拍下商品后，库存锁定多久？超时未支付怎么处理？
- 客服修改订单价格，是否需要审批？审批人是谁？
- 导出客户数据时，是否要隐藏手机号中间四位？
- 商品规格以后可能增加哪些维度？是否要预留字段？
- 如果供应商发错货，用户申请退货，运费谁承担？系统如何记录？
以上问题如果能在开发前花半天时间讨论清楚，后期至少能省下两轮改版的时间。中小团队的优势是灵活，但灵活不能建立在“后续再补”的基础上——因为补丁打多了，系统会越来越难维护，最终拖累业务。
记住，开发最怕的不是需求多，而是需求模糊。把这三个细节写清楚，你的项目就成功了一半。