最近做了一件很吃力不討好的事情置逻，就是分析了一個周的需求嗦嗡，最后發(fā)現(xiàn)不用調(diào)整淡诗，可能研發(fā)自己調(diào)整下就可以了
問題是這樣產(chǎn)生的：有個預(yù)約功能，有家明星店面集中放號的時候汛闸，系統(tǒng)就會卡的不要不要的，查具體原因艺骂，是預(yù)約有A和B兩種類型诸老，但這兩種類型的可預(yù)約間隔時間不一樣，導(dǎo)致每次預(yù)約的時候钳恕，系統(tǒng)會計算該時間段能不能預(yù)約别伏，當(dāng)用戶量較大時候，對系統(tǒng)的資源消耗就非常巨大了忧额。
當(dāng)研發(fā)同學(xué)把這個問題甩過來時厘肮，我們產(chǎn)品經(jīng)理就掉坑了：我們目的是解決性能問題。
首先我們分析了下睦番，目前的業(yè)務(wù)邏輯是沒有問題的类茂，能支持業(yè)務(wù)的正常進行，如果我們?yōu)榱私鉀Q性能問題托嚣，就要使用plan B大咱，取消預(yù)約類型“A和B”這種方式，設(shè)置統(tǒng)一的預(yù)約間隔時間注益，這樣計算機就不用每次計算了碴巾，只需要初始化的時候，知道每個時間間隔是能約幾個號就行了丑搔，看起來性能問題解決了厦瓢。
當(dāng)方案確定后提揍，我們還是不放心，就拉取了設(shè)置預(yù)約類型A和B的機構(gòu)煮仇，他們是否愿意設(shè)置為統(tǒng)一時間劳跃。50%的機構(gòu)認(rèn)為無所謂，30%的機構(gòu)能接收我們的改變浙垫，但有10%的客戶刨仑，堅決反對。
于是我們就想夹姥，為什么有10%的客戶堅決反對呢杉武？原來設(shè)置預(yù)約類型B的客戶，必定有用戶來機構(gòu)線下使用過辙售，而很大情況下轻抱，預(yù)約類型B是客戶自己設(shè)置的，為客戶下次來訪進行預(yù)約旦部，用戶不會使用狀態(tài)B來預(yù)約祈搜。
弄明白這個道理，那我們再回過來看這個問題：我們要不要改這個業(yè)務(wù)邏輯士八，如果改了會有10%的用戶直接找你問題容燕，甚至?xí)辉偈褂孟到y(tǒng)。而這些客戶都是比較高端客戶婚度，代表這某一個類型的客戶群缰趋。
最終結(jié)論：邏輯不動，優(yōu)化了預(yù)約號源的計算方式陕见，不是在每次預(yù)約的時候才進行計算秘血，提前計算好量，然后預(yù)約時候判斷是否可預(yù)約即可评甜。
雖然是個小問題灰粮，但對我影響很大。
1. 沒有了解客戶的使用場景忍坷，貿(mào)然的更改業(yè)務(wù)方式粘舟，對存量客戶是有一定的影響；你不改可能只是性能問題佩研，改了就是業(yè)務(wù)問題柑肴。
2. 不要為了性能而去改業(yè)務(wù)，雖然可能會解決現(xiàn)在問題旬薯，但未來會給自己挖更大的坑
