需求确认不到位，电商项目容易“返工又返钱”
很多电商网站开发项目，表面上看是技术问题——页面卡不卡、支付通不通、后台好不好用。但实际推进中，80%的延期和预算超支，都出在启动阶段的需求确认环节。需求没对齐，开发团队按自己的理解做，业务方按自己的想象验收，最后两边都觉得对方有问题。
本文不聊泛泛的“沟通很重要”，直接列出5个具体、可执行的需求确认细节。每个细节都对应实际项目中常见的坑，建议在项目启动会或需求评审会上逐条过一遍。
1. 商品SKU的“规格组合”到底有多复杂
电商网站核心是商品，而商品的核心是SKU（库存量单位）。很多项目在需求文档里只写“支持多规格”，但“多规格”三个字背后差异巨大。
需要确认的具体问题：
- 规格维度有几个？比如颜色、尺码、套餐，最多支持几层组合？
- 每个SKU是否独立价格、独立库存、独立图片？还是说只有部分规格需要单独管理？
- 是否存在“销售单位”和“库存单位”不一致的情况？比如按箱卖但按件管库存。
- 商品是否有多计量单位（件/箱/吨），切换时价格和库存如何联动？
建议动作：让业务方提供2-3个最复杂的真实商品，完整描述其规格、价格、库存逻辑。开发团队据此评估数据库设计和后台录入界面的复杂度，而不是凭想象设计。
2. 订单状态流转的“边界情况”
标准流程谁都会写：待付款→待发货→待收货→已完成。但真正让开发头疼的是边界情况，比如：
- 用户付款后，支付回调失败，但钱已扣，怎么处理？
- 订单发货后，用户申请退款，仓库已经出库了，流程怎么走？
- 未付款订单，系统自动取消时间是15分钟还是30分钟？期间用户又付款了怎么办？
- 拼团、秒杀、预售订单，和普通订单的状态机是否分开？
这些细节如果不在启动前确认，开发只能按“常规逻辑”写，等测试阶段业务方发现“这个场景我们不是这样操作的”，再改代码，成本就高了。
建议动作：让业务方画出从下单到售后的全流程分支图，重点标注异常分支。哪怕画得粗糙，也比口头描述强。
3. 会员等级与营销规则的计算口径
电商基本都有会员体系，但“会员等级怎么算”“优惠券能不能叠加”这类规则，经常在开发中反复修改。
必须确认的规则点：
- 会员等级是根据累计消费金额、消费次数，还是积分？统计周期是年还是历史累计？
- 等级升级是实时生效，还是次日生效？降级呢？
- 优惠券、满减、秒杀、会员折扣，同时满足时，优先级怎么定？
- 运费模板是否区分地区、重量、件数？偏远地区是否单独设置？
很多项目把营销规则写得过于灵活，比如“支持多种促销组合”，但没定义清楚优先级和互斥关系。开发实现后，运营配置活动时发现规则冲突，又要改逻辑。建议在启动阶段就限定首期支持的促销类型和叠加规则，把“灵活”放在二期。
4. 前后台“数据字典”是否统一
这个细节最容易被忽略，但影响极大。比如“订单状态”在后台叫“已发货”，在用户端叫“运输中”，在客服系统叫“已出库”。三个系统三个叫法，数据同步和报表统计就会混乱。
需要确认：
- 商品状态（上架/下架/售罄）、订单状态、支付状态、售后状态，是否有一套统一的编码和名称定义？
- 后台管理系统和前台展示页面，是否使用同一套状态映射？
- 导出报表时，字段命名和口径由谁确认？
如果项目已有历史数据（比如从旧平台迁移），还需要确认旧数据的状态如何映射到新系统。这个工作不复杂，但需要业务方和开发一起逐项核对，建议在启动会上明确负责人。
5. 非功能性需求的底线
业务方通常只关注功能“有没有”，但开发需要知道“能用成什么样”。以下问题必须量化：
- 预期同时在线人数峰值是多少？首页加载时间是否接受3秒以内？
- 商品图片上传大小限制？是否需要自动压缩？
- 后台订单导出，最大支持多少条数据？超过后是分批还是直接失败？
- 第三方接口（支付、物流、短信）的响应时间要求？超时后重试几次？
如果这些不确认，开发会按“合理默认值”设计，但上线大促时服务器扛不住，或者后台导出卡死，责任划分就说不清了。建议将这些量化指标写入需求文档，作为验收标准的一部分。
总结：需求确认不是“开会聊天”
以上5个细节，每个都可以在半天内完成确认，但能避免后期大量返工。实际操作中，最好由业务方、产品经理、技术负责人、测试负责人共同参与，逐条确认并签字。如果项目外包，更要把这些内容写进合同附件，作为验收依据。
电商开发不是“做完就行”，而是“做对才行”。启动前多花两天确认细节，远比上线后花两周修bug划算。