最近做了一件很吃力不讨好的事情，就是分析了一个周的需求，最后发现不用调整，可能研发自己调整下就可以了
问题是这样产生的：有个预约功能，有家明星店面集中放号的时候，系统就会卡的不要不要的，查具体原因，是预约有A和B两种类型，但这两种类型的可预约间隔时间不一样，导致每次预约的时候，系统会计算该时间段能不能预约，当用户量较大时候，对系统的资源消耗就非常巨大了。
当研发同学把这个问题甩过来时，我们产品经理就掉坑了：我们目的是解决性能问题。
首先我们分析了下，目前的业务逻辑是没有问题的，能支持业务的正常进行，如果我们为了解决性能问题，就要使用plan B，取消预约类型“A和B”这种方式，设置统一的预约间隔时间，这样计算机就不用每次计算了，只需要初始化的时候，知道每个时间间隔是能约几个号就行了，看起来性能问题解决了。
当方案确定后，我们还是不放心，就拉取了设置预约类型A和B的机构，他们是否愿意设置为统一时间。50%的机构认为无所谓，30%的机构能接收我们的改变，但有10%的客户，坚决反对。
于是我们就想，为什么有10%的客户坚决反对呢？原来设置预约类型B的客户，必定有用户来机构线下使用过，而很大情况下，预约类型B是客户自己设置的，为客户下次来访进行预约，用户不会使用状态B来预约。
弄明白这个道理，那我们再回过来看这个问题：我们要不要改这个业务逻辑，如果改了会有10%的用户直接找你问题，甚至会不再使用系统。而这些客户都是比较高端客户，代表这某一个类型的客户群。
最终结论：逻辑不动，优化了预约号源的计算方式，不是在每次预约的时候才进行计算，提前计算好量，然后预约时候判断是否可预约即可。
虽然是个小问题，但对我影响很大。
1. 没有了解客户的使用场景，贸然的更改业务方式，对存量客户是有一定的影响；你不改可能只是性能问题，改了就是业务问题。
2. 不要为了性能而去改业务，虽然可能会解决现在问题，但未来会给自己挖更大的坑
网友评论