谈谈验证能力
這其實是?談談調研能力?的姊妹篇，當時想寫成一篇的，覺得太長了，算了，分成兩篇寫。
調研是了解訴求，以及尋找可能的方案，而驗證就是檢驗訴求及方案的可行性。
那么也是分幾種場景。
包括前置驗證和回溯驗證。
前置驗證，就是在進行項目的研發和運營之前，進行小范圍驗證。回溯驗證時在運營過程中對一些想法，一些判斷進行驗證。
先說前置驗證
1、核心訴求驗證。
2、商業轉化模型驗證。
3、技術驗證。
4、團隊磨合驗證。
1、核心訴求驗證
典型如游戲的核心玩法，很多時候游戲只是做一個核心的打斗玩法場景，然后找核心玩家測試，看看接受度和期待程度，然后決定是否用這樣的方式繼續游戲，如果核心玩法未被接受，后面就不用做了。
那么其實遠不止游戲，我勸退過不少創業者，想法很多，覺得自己需要一筆投資，做個大事情，那好，做過核心訴求驗證么，怎么做，選擇最基本最核心的一個點，你的核心目標用戶群最關注的一個點，你去做一點嘗試，然后拉群，拉微信群，小范圍提供某個服務，手工也好，簡單腳本也好，哪怕貼點錢外包也好，你看看用戶如何接受這個訴求，如何回饋這個服務。
那很多創業者說，不行，用戶不接受是因為我提供的服務不完整，我必須把前前后后左左右右都做到位才能測試，這就屬于入魔了。
很多創業團隊沒做過核心訴求驗證，腦袋一熱就起高樓，最后發現除了一群評論家和自媒體跑來找了點素材，沒什么真實用戶在用。
這里要說一下，驗證和調研的區別是，調研是你去了解用戶需要什么，愿意付出什么，驗證是你提供了最基本的需要，看看用戶是否接受，以及如何反饋。
2、商業轉化模型驗證
其實游戲測試就是一個典型的商業轉化模型驗證，投一點點廣告，跑個測試服，然后統計玩家的留存率，付費率，平均付費金額，玩家生命周期，算下來跑不正，繼續優化調整；算下來跑正了，心理就有數了，再稍微做好一些后續的準備，就可以大規模推廣和運營了。
那么上市公司跟誰學的一些報道里也提到了，他們也遇到過艱難時期，估值太高，資金消耗太快，當時公司很危險，那么就醞釀轉型，但最開始也不知道做什么，開始小范圍測試一些直銷課程，結果幾個月算下來，投入產出比好的驚人，模式跑通，開始鋪量，最后鋪出一個上市公司。
小范圍模式跑通，和大規模成立之間，并不是必然的因果，但相關性還是很高的，很多人說不對啊，規模效應啊，小范圍是負的，大規模也可能是正的。是的，有些商業模型，小范圍驗證是虧的，也是可以鋪規模的，因為他們相信規模可以降低成本；但這個也是要測算的，前幾年o2o火的時候，很多人對規模的成本效應過度樂觀，最后團滅。
小規模驗證也需要精益求精，比如營銷素材的設計，比如目標人群的選擇，否則你可能產品本來沒問題，結果數據總跑不正。
驗證一定要有數據目標，一定要堅持數據原則。有些時候覺得沉沒成本太高，驗證數據并不好，但總以為規模化后可以解決所有問題，一意孤行，那驗證也就失去了意義。
3、技術驗證
我以前說過，壓力測試在什么時候進行，產品上線前？核心功能完成時？錯，是在數據結構設計的時候，壓力測試就開始了。
對，代碼一行沒有寫，就開始壓力測試了，數據結構確立后，寫個腳本建立幾百萬條測試數據，然后完成核心SQL和核心邏輯的代碼，進行壓測。
當時我做統計，做社群，都是數據結構和系統設計剛開始，就做壓測，壓測結果滿意才開始動手寫代碼，其實這就是技術驗證，驗證這里的技術邏輯能不能支持業務訴求的考驗。
那么不止壓力測試，還包括其他。
以前在百度做日志分析，日志很大，代碼邏輯不復雜，但一次跑通的概率并不高，可是跑一次要很久，很長時間，如果寫完代碼跑起來，等結果，多半是錯誤信息，那么需要幾十分鐘，甚至幾個小時。
先做片段分析，核對結果，先保證代碼業務邏輯是對的。
然后做斷點輸出，比如每執行1萬條日志輸出當前的狀態和執行時間，然后觀測執行的負載，通常會遭遇內存溢出的情況，大概就知道是執行了多少條會溢出，每1萬條的執行時間是多少，然后想辦法優化，優化的目標不是追求極致效率或極致資源節省，而是在已有資源可支持的情況下，能夠實現效率和資源的平衡。
其實也是 不斷對核心負載做技術驗證，然后不斷調整，最后確認沒有問題后才進入正式部署，以及額外增加新的邏輯和能力。
先證明技術方案可行，然后才開始進入項目的研發，如果項目研發進度到相當程度了，才發現一些核心指標滿足不了，再去重構，就頭大了。
4、團隊磨合驗證
新的團隊，新的管理者，能否具有足夠的戰斗力，挑戰足夠復雜的任務，可能也需要做個驗證。比如先做一個獨立小型的項目，考驗團隊的執行能力，項目管理方式，每個成員的特長和缺點。
有不少游戲創業團隊都是先做一個輕游戲，磨合團隊，驗證團隊執行成本，然后才會啟動重量級產品。
前置驗證，很重要的一點是提煉能力，你必須抓住核心點。抓住最關鍵的問題點，用最低的成本，去驗證整體項目的可行性。
如果你提煉的不是核心，那么驗證了也沒意義，最后實踐的時候還是會掉進坑里。
如果你提煉太多，面面俱到，覺得都是核心，那么驗證成本過高，驗證也就失去了意義。
小創業團隊，務必早期做好必要的驗證，再開始進行比較大的項目研發。而一些個體創業者，我也是不斷強調過，從最小的范圍開始驗證模式，驗證通過再開始大刀闊斧的進行投入。從微信群開始，從朋友圈開始，驗證你的產品，驗證你的服務。如果你身邊的人都不愿意接受你的產品和服務，你憑什么認為可以做出規模化的產品和服務？
下面說一下回溯驗證。
1、驗證預判。
2、驗證反饋及問題猜測。
1、驗證預判
產品上線前，你應該對一些上線后的數據特征有一定的預判。
產品人員，大概應該能預判用戶的行為特征。
技術人員，應該能預判負載壓力的構成和請求頻次的構成。
運營人員，大概可以預判用戶的反饋和交互的可能性。
那么上線后，要有針對性地做數據回溯，分析是否與預判一致，驗證自己的判斷是否準確。
這需要上線前就做好明確的數據準備，上線后可以根據具體的數據和日志信息進行追溯分析。
2、驗證反饋及問題猜測。
產品上線后，往往會有人反饋比如卡了，慢了，各種問題，也有人會反饋產品使用中的一些特性被用于預料之外的場景，那么這時候，需要對這類反饋和問題做一個驗證。是小范圍的問題，還是大范圍的問題；是一個極個別的訴求，還是一個相對普遍的訴求；
這往往需要額外增加一些監控手段，分析能力，進行驗證。
那么技術上有時候會出現一些偶發性的問題，比如1%的用戶出現打不開，加載慢，但當你面對幾百萬用戶提供服務，這1%并不是一個可以忽略的問題。怎么辦？可能確實一開始的設計沒有做好足夠的監控和分析，無法第一時間精確定位，但這時候就要開始做一些監控，一些日志的額外處理，代碼中增加一些斷點輸出，把所有懷疑的可能性，都盡量做到有跡可循，那么經常性的回溯這些監控數據和監控日志，并不斷強化這方面的能力，最終定位問題，解決問題。
?
大概就這樣吧
最近文章懶得寫，廣告懶得接，賣貨懶得賣，贊商也懶得開。
只有知識星球還是堅持維護的。歷史累計付費用戶超過2萬人，目前依然處于付費狀態的用戶超過1萬人。幾年來讀者的實際支持就是最好的證明。多少曾經火爆一時的大V已經煙消云散，多少曾經日進斗金的大師已經銷聲匿跡，時間是對信用最好的證明。
總結
- 上一篇： Redis 开发陷阱及避坑指南！
- 下一篇： 开源如此火热，但研究表明该领域已不再增长