從前,有兩個賣水果的公司……
有兩個賣水果的公司,分別是 A 和 B。
前期水果不多,只有蘋果和橘子。
他們分別給使用者做了一個線上下單的系統,方便大家買水果。
隨著時間的流逝,A 公司決定改造他們的下單系統,以便和 B 公司進行競爭,於是把頁面改成了這個樣子。
系統會 根據使用者歷史購買的水果 ,來智慧分析他喜歡吃什麼,然後智慧下單購買新的水果。
但目前邏輯還很簡單,單純通過 數量 來決定,比如某使用者購買蘋果的數量要多於橘子,系統就認為使用者更喜歡吃蘋果,於是便會智慧為其下單購買蘋果。
大部分使用者都幾乎是嚴重偏好一種水果的,所以 A 公司的系統很方便地幫助了他們省去了下單時填寫的麻煩。A 公司的使用者量增長了很多,搶佔了 B 公司的市場。
------
但是,隨著時間的流逝,水果越來越多,不只有蘋果和橘子,還多了香蕉。
買水果的人也越來越多,很多人有了不同的訴求,比如有的人就是想吃一些曾經較少吃的水果,來平衡自己的飲食。
所以,智慧下單這個功能,變得越來越不智慧了,好多人開始傾向於去簡單明瞭的 B 公司買水果。
A 公司看情況不對,趕緊商量對策,於是增加了一些新功能。
使用者可以給之前買過的水果 打標籤 ,比如給蘋果點選一個 【喜歡】 按鈕,給香蕉點選一個【 不喜歡】 按鈕。
那麼之後智慧購買,就會優先選擇使用者標記為喜歡的水果。如果使用者沒有標記,則選擇使用者曾經購買數量最多的水果。不過如果這個最多的水果恰好是使用者標記了不喜歡的水果,那就找倒數第二多的進行購買。
慢慢地,A 公司的系統又變得智慧了起來,換來了使用者的增長。
------
可好景又不長,有的使用者發現,自己給蘋果標記了喜歡,但下單後發現得到的卻是香蕉。
這個 bug 反饋給 A 公司排查後發現,原來該使用者不僅給蘋果標記了喜歡,還給香蕉標記了喜歡,而香蕉的購買數量又大於蘋果,所以系統判斷使用者更喜歡香蕉。
但該使用者實際上是 忘記了自己曾經標記過香蕉 ,所以標記蘋果後,得到了不符合預期的情況。
A 公司迅速做出調整,修改了原有的打標籤邏輯,當用戶給一個新的水果點選喜歡時,自動取消原來水果的喜歡標籤。
但這樣做似乎又不太好,所以再次優化了一下,就是當用戶給一個新的水果點選喜歡時,把原來有喜歡標籤的水果,改為【 上一個喜歡的水果】 標籤。然後如果使用者取消了新水果的喜歡標籤時,上一個喜歡的水果,將會再次更改為喜歡。
但又有好多使用者反饋,我就是喜歡兩種水果,我希望每次購買的時候多種我喜歡的水果都能自動購買,而不是隻取一個。
A 公司沒辦法,但為了相容原來的邏輯,只能給使用者增加了一個 配置項 ,讓使用者決定當給一個新水果打喜歡標籤時,原水果的喜歡標籤是去掉、還是保留、還是變成上一個喜歡的標籤。
一鼓作氣,A 公司又增加了一系列使用者可以配置的選項,包括,讓使用者決定首選策略,次選策略,兜底策略等。
比如,首選打了喜歡標籤的水果,如果沒有,再次選數量相對多的水果,如果也沒有,那就在剩下的水果裡隨機選一個。
------
A 公司很滿意自己的方案,覺得自己為使用者已經無微不至、方方面面都照顧到了,還有兜底方案。
但又有使用者對隨機選一個產生了質疑,他們覺得,隨機選一個,還不如給我提示一個錯誤,讓我手動選,不希望將決策權完全交給一個未知的系統。
但還有一部分使用者說,隨機選一個方案挺好的,省去了很多麻煩,還能增加一些趣味性,不好麼?
為了照顧不同的使用者,A 公司再次增加了一個個性化配置,就是讓使用者決定,當所有條件都不滿足,需要隨機選擇一個水果時,是完全隨機選一個,還是輪詢選擇,還是報出錯誤將決策權留給使用者。
------
就這樣,A 公司的系統做得越來越複雜,越來越智慧,而且還在不斷優化、迭代。
但是,新使用者看到 A 公司的系統後,要配置好多資訊,每次買水果時還要想著是否打標籤,而且也不知道系統的選擇策略是什麼,學習成本很高。
作為 A 公司系統的開發人員,也越來越難以排查問題,也不知道當一個使用者選擇智慧購買時,到底會為其推薦哪款水果,因為邏輯已經太過複雜了。
最後,越來越多的人選擇 B 公司來購買水果。
雖然它需要手動輸入水果的名稱,但有 A 公司買水果經驗的使用者表示,這都不是事兒。
A 公司始終想不明白,為什麼他們投入了那麼多人力優化系統,而且幾乎照顧到了各種使用者的各種刁鑽的需求,可最後還是敗給了什麼都沒做的 B 公司。
- EOF -
伯樂線上
分享IT網際網路職場和精選乾貨文章(原域名已不再維護)。組織 維護10萬+star的開源技術資源庫,包括:Python, Java, C/C++, Go, JS, CSS, Node.js, PHP, .NET 等。
回覆 資源 獲取10萬+star開源資源