需求确认不是走流程，而是给项目上保险
很多企业在启动电商项目时，最着急的是“什么时候能上线”，最不在意的是“我们要做什么”。开发公司问“需求文档有吗”，回答往往是“你们看着做，参考某宝就行”。这种模糊态度，往往会在项目中期演变成反复改版、预算超支、上线延期，甚至最终交付一个“能用但不好用”的系统。
作为服务过零售、跨境、B2B等多个行业的开发团队，我们见过太多因前期需求确认不充分而“翻车”的案例。今天不谈技术选型，也不谈UI设计，只聚焦开发前最容易被忽略、但影响最大的三项需求确认工作。
第一项：确认“核心交易路径”，而不是功能清单
大多数企业给开发方的需求是“我要有购物车、优惠券、会员积分、直播入口、分销裂变……”这叫功能清单，不叫业务需求。真正的需求，是明确用户从进站到完成支付，究竟走哪几条必经路径。
为什么这条必须确认？
因为电商系统的复杂度，90%来自流程编排，而非页面数量。举例来说：“用户领取优惠券后，是下单时自动抵扣，还是需要手动选择？如果自动抵扣，是否允许用户取消优惠？如果取消，库存和优惠券状态如何回滚？”——这些问题不提前定义，开发只能靠猜，测试只能靠蒙。
建议做法
- 画出3条以内核心路径（如：普通购买、凑单满减、会员积分抵现）。
- 每条路径标注关键节点：商品详情→加入购物车→结算页→支付→订单状态变更。
- 明确每个节点的异常分支：库存不足、支付超时、优惠券失效、地址不完整。
这一步做完，开发评估的工作量误差能从±50%缩小到±15%。
第二项：确认“商品模型”的灵活度边界
电商开发中，商品模型是地基。但很多企业只告诉开发“我们有商品”，却不说清楚商品有多少种售卖形态。等到开发到一半，运营过来说“我们要卖服务，按小时计费”“我们要卖组合装，拆开也能卖”“我们要卖电子卡券，不需要物流”——这时候改模型，等于拆承重墙。
具体要确认什么？
- SKU属性维度：单规格（如一本书）还是多规格（颜色+尺码+材质）？规格数量是否固定？
- 售卖方式：普通现货、预售、拼团、秒杀、周期购（如按月订阅）。
- 库存逻辑：是按SKU扣减，还是按属性组合扣减？是否支持多仓库发货？
- 价格体系：是否有阶梯价、会员价、渠道专享价？价格优先级如何排列？
这里不需要给出最终答案，但必须确认“未来半年内不做的事”。比如明确“不做多商户入驻”，那数据库设计就可以简化很多。最怕的是“先做简单点，以后再加”——电商系统没有“以后再加”这回事，后期重构成本远高于初期多花两天讨论。
第三项：确认“订单状态机”和逆向流程
绝大多数企业只关心“用户下单成功”，却很少提前想“用户退款、拒收、换货、取消订单时，系统该怎么走”。结果上线第一周，客服就被售后流程逼疯了。
需要明确的核心状态节点
- 待付款→已取消 / 已关闭
- 待发货→用户申请退款→同意/拒绝
- 已发货→用户拒收→退货入库→退款
- 已完成→售后申请→仅退款 / 退货退款
容易被忽略的细节
- 退款是原路退回还是退到账户余额？手续费谁承担？
- 部分退款（如只退一件商品）后，优惠券是否要追回？
- 订单取消后，库存是立即释放还是延迟释放？
- 换货流程是否需要生成新订单？还是原订单上做状态变更？
这些确认不需要写长篇文档，只要开发、运营、客服三方坐在一起，把“最糟糕的5个售后场景”过一遍，就能发现80%的逻辑漏洞。
常见误区：把“需求确认”当成“开发方的事”
很多企业认为，需求确认是开发公司项目经理的工作，自己只要提要求就行。实际上，需求确认必须由企业方主导，尤其是业务负责人参与。因为开发方只能问出“技术上可能的问题”，而业务方才知道“运营上不能接受什么”。
例如，开发方会问“退款审核需要几级审批”，但只有运营负责人能回答“客服权限是否足够，还是必须主管级以上审核”。这类决策，开发方替你做不了，也不该替你做。
总结：省下的时间，都会在测试期加倍还回来
电商开发不是越快越好，而是越稳越好。三项需求确认——核心交易路径、商品模型边界、订单逆向流程——如果能在开发前花一周时间讨论清楚，就能避免至少一个月的返工周期。
最后给一个可执行建议：不要追求“一次想全”，而是用“最小可行业务闭环”来做需求确认。先定义最简单的交易流程，确认无误后再扩展营销、会员、分销等周边功能。这样即使后期有调整，也不会伤筋动骨。