起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識A/B Test給我的三個哲學啟發
許多互聯網公司都會以A/B Test的形式來進行產品決策——通過展現A方案和B方案，通過最終結果來判斷哪個方案更好。本文筆者將與大家分享自己對于這種決策方式的一些思考。
A/B Test，這是如今互聯網行業開發中常用的方法。它的做法很簡單，某個問題如果有A和B兩個方案，卻無法決定哪個更好。那么不要爭論，直接投入生產進行測試，把用戶分成兩群（劃分標準可以是時間、地域、消費能力等等各種因素，但要樣本足夠大，足夠有代表性），分別展現A方案和B方案，通過最終結果來判斷哪個方案更好。
這看起來簡單粗暴，但是一種相當有效的方法。據說：今日頭條就大量使用A/B Test來進行產品決策，所以迭代速度很快，效率也很高。不過，今天我想換個角度，談談A/B Test給我的哲學啟發。
我接觸A/B Test是許多年前，那時候A/B Test的概念還沒有流行，當時我甚至沒聽說過這個概念。但是，這不妨礙我用它的思想來解決問題。
當時我們開發的系統里的單據管理頁面有個“大一統”搜索框，設計初衷很好，希望用戶“一站式”搜索到想看的內容。
但是，單據的屬性太多，原有系統的設計又很糟糕，用戶在搜索框輸入信息之后，程序要對所有屬性進行逐一匹配檢索，查詢的效率特別低。如果遇上多個用戶同時查詢，系統基本就失去響應了。這個問題讓客戶非常不滿，抱怨聲此起彼伏。
我們在仔細分析了用戶的搜索行為之后發現：用戶搜索時，大量輸入的只有三個屬性——客戶代碼、日期、訂單編號。
這三個屬性的特征很明顯，匹配檢索也可以專門優化，速度會大大提升。所以，改進方案也很簡單：收到用戶提交的搜索請求時，先判斷一下是否這三個屬性，如果是就走專門優化的渠道。如果檢索不到則彈出另一個界面，引導用戶進行“完整搜索”。
據測試：這個方案很有效，響應速度提升很多，我們也非常有信心。但是，臨到要上線，卻被業務（銷售）給叫停了。他們的理由也很充分：這樣改動看起來有道理，但是客戶已經習慣了原來的邏輯，行為結果會變化（“你怎么知道我的大客戶沒有特殊習慣呢？”）。而且，這個行業的客戶大多專注于生意，文化水平不高，最怕的就是系統改了要重新適應。這種改動肯定不會受用戶歡迎。
一邊是系統的運行壓力和技術人員的責任心，一邊是銷售描述的客戶的慣性阻力。兩邊看起來都有道理，到底應該怎么抉擇？
當時我有了A/B Test的模糊想法——不進行整體硬切換，讓不同的用戶走不同的邏輯，甚至可以動態調整大客戶的搜索邏輯，如果客戶不滿意隨時復原。好說歹說，終于說服了銷售，可以上線測試。
測試結果顯示：絕大部分客戶都滿意改進之后的搜索邏輯，能感知到速度大大提升，即便有少數客戶感覺怪異。但是耐心加以解釋，對比了常用搜索的表現之后，他們都比較愿意“花一點時間學習和適應”。所以，最終，這次改進的結果相當令人滿意。
這是A/B Test給我的第一個啟發：
在解決問題之前，如果有多種方案需要抉擇，很可能每種方案都有理由，都有支持的聲音，而且理由嚴密完整，聲音鏗鏘有力。自說自話，總是能自圓其說。但是，評價決策的最終標準不應當是這些理由和聲音，而是實際的結果。
看看我們周圍，有無數熱鬧的文章在解釋世界，在把某種抉擇描繪得無比英明。但是，支持真實世界運轉的并不是這些炫目的解釋，而是現實的邏輯。所以，也才會有“不看廣告看療效”的說法。
扯遠點說，卡爾·波普爾很早就發現：許多炫目的理論之所以讓人著迷，是因為它們“從來都不可能出錯”，即便出了錯也能自圓其說。
波普爾認為：這些理論其實不是科學的理論，因為科學理論包含必須有出錯的風險，只有不斷通過“驚心動魄”的事實檢驗，理論的科學性才能得到證明。
許多人大概會記得，在前些年小米春風得意的時候，有無數專家在宣稱。小米掌握了“互聯網方法論”，當然能在手機市場上所向披靡，這是致勝的法寶。
然后，小米出貨量下滑，而oppo和vivo崛起了，于是大家的口風瞬間轉變，“線下勝過線上”、“互聯網企業做實業根基不穩”的論調開始大行其道。之后小米扭轉了下跌的趨勢，為小米歌功頌德的聲音又開始躲起來。
按照IDC最新的數據：2019年1季度，主攻線下的oppo手機出貨量出現了6%的下跌，不知道這些專家又要說什么……
不過不管他們說什么，都無法改變一個事實。那就是，如果你只看這些專家的說法，必然會有和許多人同樣的困惑——“看書看來了許多道理，自己仍然不會做決策”。
去年我看了《命運攸關的選擇：1940-1941年間改變世界的十個決策》，也很有這方面的意思。比如：對于不列顛之戰，如今許多人都在歌頌丘吉爾毫不屈服的堅定意志。但作者要分析的是：當時丘吉爾面臨的情境是怎樣的？他是如何決策的？如果他不選擇抗戰，結果大概會是什么樣？…… 必須承認，這樣的分析視角，會給人更多的啟發和收獲。
回頭來說A/B Test，還是許多年前，還是在系統開發中，我又遇到過另一件事。
那時候，客戶往往需要整批提交格式化的數據。按照日常經驗，這種數據顯然應當用Excel的格式最合適。用戶按照我們給定的模板把數據分門別類錄入好，最后在瀏覽器里上傳到作業系統即可。
但是這樣操作也會有問題。Excel文件的交互能力比較弱，如果一次提交幾百上千條記錄，某一條又出了錯，很難告知準確告知客戶錯誤的位置和類型，修改起來也很不方便。
另外，許多客戶是一天提交一次Excel的，如果在Excel制作的過程中電腦死機或者文件損壞，很可能前功盡棄，之前的工作成果要全部重新來過。
在嘗試了幾次優化上傳界面之后，我們決定徹底廢棄之前的做法，直接給客戶提供一個客戶端軟件?？蛻舻卿浿?，可以逐一錄入數據，數據錄入時軟件會直接和服務器交互進行驗證-保存，出錯了則即時提示。
這種軟件開發起來不難，但也很好玩，里面有不少設計需要花點心思，大家也樂在其中。開發完之后，我們信心滿滿地介紹給銷售同事，希望他們能推動客戶使用。在我們看來，這是三贏的局面：技術不必反復查錯，客戶不必反復提交，銷售不必反復溝通。
不出意外，銷售同事第一反應就是質疑，因為客戶已經習慣了原有的操作，讓他們改變操作習慣，成本太高。不過，因為之前的搜索欄改進的例子，質疑并沒有成為反對，大家約定這個改進也來實地測試一番。
這次的測試結果大大出乎我們的意料，絕大部分客戶在試用新軟件之后都不滿意，又回到老的Excel的操作方式上來?！霸趺礃?，說了客戶的操作習慣不是那么容易改變的吧！” 這一次，獲勝的是銷售同事了。
但是我們并不滿意，一方面，對自己開發的軟件有足夠的信心（和期望），另一方面，“用戶操作習慣不那么容易改變”并不能成為萬金油，總有那么強的說服力。
可是，A/B Test的結果又分明證明，確實我們想錯了。那么，問題到底出在哪里呢？
不甘心的技術人員走出辦公室，深入到客戶的使用場景去調查，真相才浮出水面：原來，開發時犯了想當然的錯誤。
開發人員的電腦配置比較好，開發使用的是.Net技術框架，而客戶的電腦并沒有那么新潮，許多仍然在用Windows XP，并沒有自帶.Net Framework，這就讓許多客戶望而卻步了。即便知道要下載.Net Framework，又面臨版本問題，國內各種下載站捆綁其它軟件的問題。安裝好之后，因為電腦配置低，程序運行起來響應也很緩慢，反而不如Excel干脆利落。
找到問題之后就好辦了。把軟件原有的操作邏輯都保留，.Net實現都廢掉，以原生的Visual Basic重寫。雖然這樣有點折騰，新時代的程序員大多不會寫VB了，要重新學習，但結果是非常好的。重新下發的版本在客戶的機器上跑得很快，甚至比Excel還要快，迅速贏得了客戶的信任，也在銷售同事那里找回了面子。
這是A/B Test給我的第二個啟發：
即便一個問題有了最終答案，也不能單純相信最終答案所依附的那種解釋，因為它可能是不對的。盡管這些解釋能自圓其說，但也只是牽強附會，或者流于表面。換句話說，A/B Test這樣的測試只能證明“哪種方案好”，而不能說明“為什么好”，不能替代人工的分析。要認清真相，我們不應忘記細致探尋其中的理由。
我的第三個例子不是來自自己，而是來自朋友。
近些年，A/B Test已經大為流行，會用A/B Test的人也越來越多。對應的，愿意討論的人也越來越多了。一次吃飯時，有位朋友跟我說了這么個故事。
這個朋友開發的用戶登錄界面里面臨一個問題：輸入手機號接收短信驗證碼的界面，是否需要用戶先輸入圖形驗證碼？如果不要求，則這個界面可能被濫用，別有用心的人可以利用這個界面給其他人發送垃圾騷擾信息。如果要求，正常的用戶流程又不夠順暢，憑空多了一重阻攔。
因為單純憑討論無法決定，他們采用了A/B Test。最終發現：如今大概黑產肆虐，羊毛黨猖獗，如果要求輸入圖形驗證碼，每天的無效和風險登錄次數少了很多，正常用戶的登錄次數卻沒有太大的波動。從結果來看，安排圖形驗證碼顯然是一個更好的選擇。
聽完這個故事，我現場給他展示了一下登錄流程。在輸入手機號，滿心期待可以等來短信之前，硬生生彈出一個“請輸入圖形驗證碼”的界面。
我問他：“你作為普通用戶，你的體驗好嗎？”
他老老實實回答說：“不好。”
所以，從概率上看，A/B Test的結果確實防住了很大一部分黑產、羊毛黨，但如果你不幸處于“不需要防住”的那一部分，對你來說這個結果就非常悲劇了。
你說這個問題確實存在，但是要怎么改進A/B Test呢？
實際上，所有這類決策都會有決策成本。按照80-20原則，你抓住了80%，就放棄了20%。何況現實中未必處處都是80-20，有時候你抓住的只是60%，放棄的是40%，甚至抓住的是55%，放棄的是45%。雖然從總數上看是不錯的，但實際成本太高，放棄的太多。
那么，怎么解決這種問題呢？
解決這種問題并不是靠A/B Test，而需要輸入更多的信息。
如果你的登錄界面只輸入一個手機號，讓用戶收一個短信驗證碼，就是把A/B Test做出花來，也沒有什么用。如果你輸入的不只有用戶的手機號，還有用戶的IP、瀏覽器版本等等信息，如果是在專屬App里登錄，還可以加上Wi-Fi網絡、地理位置、設備ID等等信息……
你的信息更豐富了，決策邏輯就可以更復雜，可以調整的空間也更大。如果要做A/B Test也可以做更細致，可以從多層次、多角度來做A/B Test。
這位朋友聽了之后若有所思，回頭找安全、風控等等行業的朋友聊了一圈，得到了更完整的方案。再過幾個月我去看他們的系統，已經基本做到了“對正常用戶勿打擾，對風險用戶自動驗證”的水平，用戶體驗比之前粗暴彈出圖形驗證碼好了很多。
實際上，這是我前些年思考的結果，也是A/B Test給我的第三個啟發：
A/B Test不是萬能的，不能迷信。
它只能教我們如何從給定的選項中擇優，但許多時候選項本身的層面不對，或者粒度太粗。所以，即便做了A/B Test，結果也未必盡如人意。許多時候我們需要跳出來，輸入更多的信息，或者改進A/B的粒度，往往能取得更理想的結果。
如果你有印象大概會記得：2002年8月12日，公安部在北京、天津、深圳、杭州四個城市推行了個性化車牌。個性化車牌有6位，前三位可以由用戶自行選擇數字或者字母。這種給予極大自由的政策，一經推出就引發民眾熱捧。不幸的是，政策公布之后還不到兩周，就因為“技術原因”叫停了。
據媒體報道：這項政策被叫停的真正原因在于，許多用戶自定的車牌有爭議，比如BWM-001、FBI-001、USA-911、PLA-081之類，甚至還有SEX-001等等“出格”現象，被認為“不符合精神文明建設”。后來還有不少“專家”引用這個例子，證明“社會現階段不能太過自由，否則就會出各種幺蛾子，影響穩定”之類的結論。
在我看來，這恰恰是個典型的因為粒度過粗、層次不當的例子。如果只是粗放規定“用戶可以選擇/不選擇個性化車牌”，對“個性化車牌中不容許哪些內容”又沒有任何細致的規定，結果當然五花八門，出乎意料。
拿它當例子來證明“社會不能太過自由，否則就會影響穩定”，就更是匪夷所思——自由從來都是和規定相聯系的，沒有什么正經的人主張社會需要毫無約束的自由。
系統智能與否，體現在它能動用多少信息，對多少情況進行細致的分析，給出對應的處理，而不是一兩條簡單的if-else萬事。
同樣的道理，解決問題水平的高低，也體現在問題的解決者能夠動用多少信息，事先制定多少分門別類的規則，事后依據多少細致的分析，而不是簡單粗放得到一個結論了事。
最后做個簡短總結：
- A/B Test很好，可以用來戳穿各種貌似合理的奇談怪論。
- 做A/B Test不只是技術上做點事情就完了，沒有細致認真的分析，還是可能走彎路。
- 要想給出更優的解決方案，并不能完全依賴A/B Test，輸入更多的信息，掌握更多的計算能力，才可能得到更優的解決方案。
作者：余晟，微信公眾號：余晟以為（ID：yurii-says）
來源：https://mp.weixin.qq.com/s/VVS49gO9M8gMgWQ73KdKvA
本文由@余晟以為 授權發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unspalsh, 基于CC0協議。
寫得很贊，提供了很多思路
學習學習