产品手札：多种业务场景调用多端数据来源的坑

在做产品的经历中难免会遭遇到多边的用户场景，用户的边越多产品的逻辑结构就越复杂，特别是在产品不断迭代中某个版本改动了一个小东西发布上线后导致整个业务线的阻塞，最要命的还是不知道是由什么原因导致的。今天通过一个自己真实的案例还原自己踩过的坑。

【背景信息】

1.汽车后市场业务产品，用户可以分为门店、车主

2.业务场景：洗车 & 非洗车（保养、维修等）

【遇到的问题】

由于车辆信息中“生产年月”的不完整，导致车主用户在App进行非洗车业务操作时，一直停留在车辆信息完善的分支流程而无法往下走通

【问题还原】

1.车辆信息包含：品牌、车系、车型、排量、生产年月

2.门店与车主共用一份车辆信息数据

3.车辆信息来源：

*  门店通过系统开单新增，通过手机号+车牌号判断是否唯一，被动在车主App内进行新增或修改

*  车主主动通过App进行新增

4.门店发生新增车辆信息的业务场景也分为洗车和非洗车（保养、机修类），洗车类只需要对手机号、车牌号进行必填，非洗车类需要外加品牌、车系、车型必填信息。

车辆信息中的“生产年月”在数据库里存储的是一个字段，而在操作的交互层面生产年和月是分两步进行选择。产品设计时为了方便门店操作便捷，造成了与门店发生业务新增的车辆信息存在生产年月中的月份为空。

而在车主App端发起非洗车业务帮助用户进行配件适配时，却需要用到完整的生产年月信息。例如用户发起小保养业务，可以根据用户的车辆已有信息进行适配出所需要用的机油、机滤品牌及用量。

根据车辆信息适配配件及用量的精准度关键点就是信息的完整度，不同的品牌、车系、车型、排量都将影响适配配件及用量的不同，而部分车辆厂商还存在同一个年份里上半年和下半年所生产的汽车所用零配件不一样情况。例如：上半年生产是2缸发动机，下半年生产是4缸发动机。

至此，问题就来了。因为门店新增的车辆信息存在生产月份为空的情况，车主在App使用这辆车进行非洗车业务时，受制于信息不完整而进入完善车辆信息的分支流程。而在完善车辆信息的分支流程页面中，因为生产年月为一个字段合并展示，用户看到的生产年月这一行并不为空。用户就始终卡在了完善车辆信息的分支流程无法进行下一步的茫然不知所措的状态

【分析总结】

1.简单的分析了一下这个坑的原因，首先由多端产生数据源，又被多种业务共同调；其次是为了从单一维度用户进行产品设计时想着尽可能的简化用户的操作成本而导致

2.在项目开发进行过程中，前、后端对于数据存储的标准没有达成统一的认识

3.服务端在遭遇业务逻辑异常时，处理的返回结果不友好