电商开发项目启动前，这5个需求确认细节别忽略

需求确认不到位，电商项目容易“返工又返钱”

很多电商网站开发项目，表面上看是技术问题——页面卡不卡、支付通不通、后台好不好用。但实际推进中，80%的延期和预算超支，都出在启动阶段的需求确认环节。需求没对齐，开发团队按自己的理解做，业务方按自己的想象验收，最后两边都觉得对方有问题。

本文不聊泛泛的“沟通很重要”，直接列出5个具体、可执行的需求确认细节。每个细节都对应实际项目中常见的坑，建议在项目启动会或需求评审会上逐条过一遍。

1. 商品SKU的“规格组合”到底有多复杂

电商网站核心是商品，而商品的核心是SKU（库存量单位）。很多项目在需求文档里只写“支持多规格”，但“多规格”三个字背后差异巨大。

需要确认的具体问题：

• 规格维度有几个？比如颜色、尺码、套餐，最多支持几层组合？
• 每个SKU是否独立价格、独立库存、独立图片？还是说只有部分规格需要单独管理？
• 是否存在“销售单位”和“库存单位”不一致的情况？比如按箱卖但按件管库存。
• 商品是否有多计量单位（件/箱/吨），切换时价格和库存如何联动？

建议动作：让业务方提供2-3个最复杂的真实商品，完整描述其规格、价格、库存逻辑。开发团队据此评估数据库设计和后台录入界面的复杂度，而不是凭想象设计。

2. 订单状态流转的“边界情况”

标准流程谁都会写：待付款→待发货→待收货→已完成。但真正让开发头疼的是边界情况，比如：

• 用户付款后，支付回调失败，但钱已扣，怎么处理？
• 订单发货后，用户申请退款，仓库已经出库了，流程怎么走？
• 未付款订单，系统自动取消时间是15分钟还是30分钟？期间用户又付款了怎么办？
• 拼团、秒杀、预售订单，和普通订单的状态机是否分开？

这些细节如果不在启动前确认，开发只能按“常规逻辑”写，等测试阶段业务方发现“这个场景我们不是这样操作的”，再改代码，成本就高了。

建议动作：让业务方画出从下单到售后的全流程分支图，重点标注异常分支。哪怕画得粗糙，也比口头描述强。

3. 会员等级与营销规则的计算口径

电商基本都有会员体系，但“会员等级怎么算”“优惠券能不能叠加”这类规则，经常在开发中反复修改。

必须确认的规则点：

• 会员等级是根据累计消费金额、消费次数，还是积分？统计周期是年还是历史累计？
• 等级升级是实时生效，还是次日生效？降级呢？
• 优惠券、满减、秒杀、会员折扣，同时满足时，优先级怎么定？
• 运费模板是否区分地区、重量、件数？偏远地区是否单独设置？

很多项目把营销规则写得过于灵活，比如“支持多种促销组合”，但没定义清楚优先级和互斥关系。开发实现后，运营配置活动时发现规则冲突，又要改逻辑。建议在启动阶段就限定首期支持的促销类型和叠加规则，把“灵活”放在二期。

4. 前后台“数据字典”是否统一

这个细节最容易被忽略，但影响极大。比如“订单状态”在后台叫“已发货”，在用户端叫“运输中”，在客服系统叫“已出库”。三个系统三个叫法，数据同步和报表统计就会混乱。

需要确认：

• 商品状态（上架/下架/售罄）、订单状态、支付状态、售后状态，是否有一套统一的编码和名称定义？
• 后台管理系统和前台展示页面，是否使用同一套状态映射？
• 导出报表时，字段命名和口径由谁确认？

如果项目已有历史数据（比如从旧平台迁移），还需要确认旧数据的状态如何映射到新系统。这个工作不复杂，但需要业务方和开发一起逐项核对，建议在启动会上明确负责人。

5. 非功能性需求的底线

业务方通常只关注功能“有没有”，但开发需要知道“能用成什么样”。以下问题必须量化：

• 预期同时在线人数峰值是多少？首页加载时间是否接受3秒以内？
• 商品图片上传大小限制？是否需要自动压缩？
• 后台订单导出，最大支持多少条数据？超过后是分批还是直接失败？
• 第三方接口（支付、物流、短信）的响应时间要求？超时后重试几次？

如果这些不确认，开发会按“合理默认值”设计，但上线大促时服务器扛不住，或者后台导出卡死，责任划分就说不清了。建议将这些量化指标写入需求文档，作为验收标准的一部分。

总结：需求确认不是“开会聊天”

以上5个细节，每个都可以在半天内完成确认，但能避免后期大量返工。实际操作中，最好由业务方、产品经理、技术负责人、测试负责人共同参与，逐条确认并签字。如果项目外包，更要把这些内容写进合同附件，作为验收依据。

电商开发不是“做完就行”，而是“做对才行”。启动前多花两天确认细节，远比上线后花两周修bug划算。