3-5個人做不好的事，30-50人做更爛 演講時間：2014年8月7日 ——騰訊雲CEO陳磊在2014 IT價值峰會上勵志演講稿 我在穀歌互聯網公司工作的時候，
第一次聽說了雲計算。按照現在的概念，那時候我就在做雲。今天我們談互聯網思維，大家想的更多的是思維轉變，商業模式如何轉變，產品如何轉變。通過這些轉變真正去改造一個企業，改造一個公司的運作模式，都是從技術開始的。技術是它的原動力。騰訊的產品體驗就是永不掉線。騰訊的海量產品之道是：動態運營、雲中成長和有損服務。
以微信為例，看如何實現動態運營 好的團隊，是動態反覆運算成長來的，3-5個人做不好的事情，30-50人做的更爛。高舉高打的失敗概率非常高。動態運營關鍵要素：1.小步快跑——快速求證對用戶猜想；2.灰度發佈——在黑與白之間，能夠平滑過渡的一種發佈方式；3.大系統小做——分進程，儘量保證進程的功能單一；4.邊運營邊重構邊生活——細分的實施步驟，持續的服務能力；5.乾乾淨淨——建立信心、勇於承擔、邊打掃邊生活；6.工具齊備：自動化部署、監控、大資料分析。
騰訊微信的推出完全不是一個偶然的事情。騰訊之前做QQ的技術積累發揮了巨大的作用。微信為什麼在很多的關鍵體驗上做的很好呢？因為在做QQ的時候，這些關鍵技術難題就已經攻破了。2011年1月到4月微信產品上線，當時基本沒有用戶，我們的團隊也沒有硬性在用戶體驗上灌注用戶。
5月份開始了一個生死時速時期。8月份，用戶就開始每天翻一番。在這樣情況下如何能夠保證微信的體驗不變差，是騰訊當時面臨的一個很大難題。 微信的動態運營以及騰訊的動態運營的產品思想在這過程中起到非常關鍵的作用。微信是騰訊CTO，Tony最早關注支援的產品。“產品的節奏”的把握，是最重要的，這背後是非常值得關注的一個點：不給用戶他不想要的東西，
一定是給用戶他想要的東西。 騰訊有一套動態運營的思想跟方法論和流程，這就是動態運營、雲中成長、有損服務。 其次是追求小規模團隊。我來騰訊之前在穀歌，當時穀歌CEO講，谷歌成功的產品都是兩個人做出來的，比如搜索、廣告、郵箱。成功之後，這個團隊越來越大。所以我們在有基礎的假設之後，就開始不斷地嘗試。先做一個很簡單的產品，然後不斷創新嘗試。微信1.0和現在的版本差距很大，
每個功能都是在不斷的運營、猜想和實驗的過程中做出來的。 微信團隊現在每天可以發20個版本。用戶端產品發佈新版本其實是一件很困難的事，必須讓用戶下載才能完成更新。 微信團隊做了很多的後臺開關，“很多的功能能不能被用戶用到”，或者“表現形式是什麼”都有後臺控制的。產品在研發過程當中根據使用者的使用習慣不停的調節。 前幾個版本，功能上線都是一部分用戶先使用，另外一部分用戶是看不見的。應用的用戶效果好就放大，效果不好刪除，或者將這個功能改成原來的方式。把新的功能藏起來，讓用戶一步一步找到，設置一個外掛程式，一步一步深入。找到新功能的用戶都是比較高端的用戶，對微信有很深感情，其餘絕大多數用戶看不到。觀察他們對新功能的反應。用的多，就往前挪，用的少，刪掉。這就是動態運營。 任何一個技術產品如果不上線，它的水準一定是差的。我們要做的就是大力的縮短上線的時間。如果一個項目兩個月沒有上線，就會把一定功能刪減，刪減兩個月可以上線。兩個月就上線的產品，可能功能會非常的簡單，但是會在上線之後不斷地反覆運算。 騰訊搞敗搜索的教訓 騰訊有一個產品做的很失敗——搜索。從2010年開始搜索的團隊一直在做新架構。這個新架構是從頭寫起的，每個行代碼都是新的。到2013年8月份的時候才上線，但是上線八天之後新架構徹底崩潰了。 出了問題沒有辦法定位，不知道怎麼樣把新架構修復，所以又把老架構拿出來。在此過程當中有很多不可思議的事情發生。 財付通是騰訊一個非常重要的產品，然而通過騰訊的搜索產品，大量的財富通網頁無法顯示。因為老架構一些技術問題，需要把一些APDS的網頁放到白名單裡面才能掃到。這不是缺少人員運營的問題，所以搜索應用非常失敗。 騰訊的廣告產品演算法在行業裡面是相當有口碑的，主要原因是我們每天做很多大量的實驗。每個演算法想出來之後，不能肯定在上線之後一定效果好，面臨問題的複雜性跟用戶的差異性非常大。所以我們把所有的演算法都拿出來試。最後成功的留下，不成功的刪掉。產品不斷演進產品。 “小步快跑”為什麼要這麼做，這樣做需要什麼技術。實際上每件技術做好都需要大量的積累跟沉澱。用會務發佈來講，我們有一個比較標準的發佈流程。每個功能發佈的時候首先給公司員工用。公司員工用了之後提出很多的意見，哪個地方做的不好，就不斷的改進。 當員工用戶滿意了或者問題不大的時候，會給一個核心用戶群體進行用，他們覺得可以嘗鮮用騰訊的產品是件很驕傲的事情。當然他們也會提很多的意見，這個群體用完了之後我們才會逐步的試。互聯網差別做法就是我不懂所以我要試，這個準確率可以達到多少，如何能夠讓用戶更滿意，成功率有多少。真正的內部的測試也好，真正產品的上線可能不到30%。所以有70%的好的想法並沒有被利用。 技術團隊有局限，要把專業的事交給專業的人 我們認為每個團隊雖然有很多的技術牛人，但是卻存在一定的局限性。儘量把更多的事情交給更專業的人做，這是騰訊公司一直以來的重要理念。雲計算公司有一個產品叫做微雲，微雲這個產品可以上傳圖片照片，每天上傳量1700多萬張，視頻量也很大。我們不斷的想辦法壓縮每天的數量增量，但是現在每天資料增量還在80多P到100P之間。 而且用戶端的種類不同，微軟兩個版本還有安卓、蘋果等等很多的版本。微雲團隊20個人，日活躍使用者過億的產品，怎麼樣能夠做到這一點呢？微雲使用了騰訊現有的架構，在自己的營造的雲裡面成長起來。 滴滴打車是騰訊跟阿裡分別支援的打車軟體，爆發式增長的最後關口就是技術戰。2月18號的時候騰訊雲團隊入駐滴滴打車，2月22號的時候就把所有系統搬遷團隊。嘀嘀打車用了很多開源軟體，在開源軟體周邊做了很多的工作。我們做的事情就是遷移到現成的雲服務中，這個雲存儲是騰訊產品裡面驗證的，可以撐得海量。這個事情讓嘀嘀打車脫胎換骨。 雲中成長還有另外的案例就是互娛DNF，這個非常成功的產品，日收入過億。DNF原來是從韓國的遊戲公司買來的產品。我們把它搬到雲端，擴容能量一千台一個月，提升到一千個虛擬機器一小時。DNF在騰訊的過程當中有一個非常大的高速增長的過程，雲給它很大的支持。所以這是雲中成長的關鍵要素。首先就是核心的點，我們團隊關注的是最拿手的事情，讓更重的事情快速的沉澱到專業的團隊中。 “有損服務”是互聯網的一個核心理念 有損服務，在傳統行業跟互聯網結合過程中，是最難讓大家接受的，也是互聯網最核心的一個理念。我們做的服務在正常的情況下給使用者百分之百的體驗，但是當我們遇到困難的時候，比如說發大水把機房淹了，導致很多設備不能用。或者用戶突發的高峰的時候，該如何很好的服務使用者。 用滴滴打車舉例，很多產品邏輯很明顯，不用做這麼重，但是可以保證用戶體驗。比如說要不要非常準確的顯示當前的位置，要不要把每個附近的計程車當前位置顯示很清楚，並且可以跟蹤他們的情況，然後在手機上面進行顯示。這些事情的答案如果條件允許的話，用戶都想知道。但是條件不允許的時候就要降級處理。兩天的時間，幫助滴滴打車完成了“有損手術”，在壓力過高的時候去做邏輯性處理。後端伺服器壓力銳減。 微信原來要做的就是把所有的消息都必須是送達，而且一定要在每個用戶的手機上保持順序的一致。後來我們說服了微信團隊，其實順序並沒有那麼重要。 紅米案例在行業裡面比較出名，我們做了兩次紅米的手機發佈。第一次紅米手機，第二次是紅米NOTE。第二次做紅米NOTE的時候，把小米的伺服器拖垮。 我們複盤之後，發現小米的設計是一個無損的完美設計。但是這個完美設計是不是有必要？比如每個人都能看到還剩下幾部手機。當你有十萬部手機還要賣時，就不需要了。當你有一百部的時候，才是需要的。當你只剩下一百部的時候，訪問量集聚下降，可以做到這一點，十萬部的時候不需要做到這一點。 12306曾經找過我們，讓我們解決現在每到春節系統被壓垮的問題。他們認為騰訊在這方面做的非常的好。 第一點，可以試試我們的雲，當然這個不太可能。 第二點，其實很簡單你每一趟車次分開賣，車次分開賣，就可以解決很大的問題。另外早一點賣，不要非等到那個時間段。另外可以一開始悄悄賣，不同地域的票分開賣，這個想法雖然很土，但是互聯網公司用很土的辦法解決複雜的問題。 其實大資料和雲計算，就是我們用原先的資料庫解決不了現在的問題，用柔性有損的辦法解決類似的問題，到最後形成了今天的互聯網行業的產品。 本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/yanjiang/qiyejia/4310.html功能上線都是一部分用戶先使用，另外一部分用戶是看不見的。應用的用戶效果好就放大，效果不好刪除，或者將這個功能改成原來的方式。把新的功能藏起來，讓用戶一步一步找到，設置一個外掛程式，一步一步深入。找到新功能的用戶都是比較高端的用戶，對微信有很深感情，其餘絕大多數用戶看不到。觀察他們對新功能的反應。用的多，就往前挪，用的少，刪掉。這就是動態運營。 任何一個技術產品如果不上線，它的水準一定是差的。我們要做的就是大力的縮短上線的時間。如果一個項目兩個月沒有上線，就會把一定功能刪減，刪減兩個月可以上線。兩個月就上線的產品，可能功能會非常的簡單，但是會在上線之後不斷地反覆運算。 騰訊搞敗搜索的教訓 騰訊有一個產品做的很失敗——搜索。從2010年開始搜索的團隊一直在做新架構。這個新架構是從頭寫起的，每個行代碼都是新的。到2013年8月份的時候才上線，但是上線八天之後新架構徹底崩潰了。 出了問題沒有辦法定位，不知道怎麼樣把新架構修復，所以又把老架構拿出來。在此過程當中有很多不可思議的事情發生。 財付通是騰訊一個非常重要的產品，然而通過騰訊的搜索產品，大量的財富通網頁無法顯示。因為老架構一些技術問題，需要把一些APDS的網頁放到白名單裡面才能掃到。這不是缺少人員運營的問題，所以搜索應用非常失敗。 騰訊的廣告產品演算法在行業裡面是相當有口碑的，主要原因是我們每天做很多大量的實驗。每個演算法想出來之後，不能肯定在上線之後一定效果好，面臨問題的複雜性跟用戶的差異性非常大。所以我們把所有的演算法都拿出來試。最後成功的留下，不成功的刪掉。產品不斷演進產品。 “小步快跑”為什麼要這麼做，這樣做需要什麼技術。實際上每件技術做好都需要大量的積累跟沉澱。用會務發佈來講，我們有一個比較標準的發佈流程。每個功能發佈的時候首先給公司員工用。公司員工用了之後提出很多的意見，哪個地方做的不好，就不斷的改進。 當員工用戶滿意了或者問題不大的時候，會給一個核心用戶群體進行用，他們覺得可以嘗鮮用騰訊的產品是件很驕傲的事情。當然他們也會提很多的意見，這個群體用完了之後我們才會逐步的試。互聯網差別做法就是我不懂所以我要試，這個準確率可以達到多少，如何能夠讓用戶更滿意，成功率有多少。真正的內部的測試也好，真正產品的上線可能不到30%。所以有70%的好的想法並沒有被利用。 技術團隊有局限，要把專業的事交給專業的人 我們認為每個團隊雖然有很多的技術牛人，但是卻存在一定的局限性。儘量把更多的事情交給更專業的人做，這是騰訊公司一直以來的重要理念。雲計算公司有一個產品叫做微雲，微雲這個產品可以上傳圖片照片，每天上傳量1700多萬張，視頻量也很大。我們不斷的想辦法壓縮每天的數量增量，但是現在每天資料增量還在80多P到100P之間。 而且用戶端的種類不同，微軟兩個版本還有安卓、蘋果等等很多的版本。微雲團隊20個人，日活躍使用者過億的產品，怎麼樣能夠做到這一點呢？微雲使用了騰訊現有的架構，在自己的營造的雲裡面成長起來。 滴滴打車是騰訊跟阿裡分別支援的打車軟體，爆發式增長的最後關口就是技術戰。2月18號的時候騰訊雲團隊入駐滴滴打車，2月22號的時候就把所有系統搬遷團隊。嘀嘀打車用了很多開源軟體，在開源軟體周邊做了很多的工作。我們做的事情就是遷移到現成的雲服務中，這個雲存儲是騰訊產品裡面驗證的，可以撐得海量。這個事情讓嘀嘀打車脫胎換骨。 雲中成長還有另外的案例就是互娛DNF，這個非常成功的產品，日收入過億。DNF原來是從韓國的遊戲公司買來的產品。我們把它搬到雲端，擴容能量一千台一個月，提升到一千個虛擬機器一小時。DNF在騰訊的過程當中有一個非常大的高速增長的過程，雲給它很大的支持。所以這是雲中成長的關鍵要素。首先就是核心的點，我們團隊關注的是最拿手的事情，讓更重的事情快速的沉澱到專業的團隊中。 “有損服務”是互聯網的一個核心理念 有損服務，在傳統行業跟互聯網結合過程中，是最難讓大家接受的，也是互聯網最核心的一個理念。我們做的服務在正常的情況下給使用者百分之百的體驗，但是當我們遇到困難的時候，比如說發大水把機房淹了，導致很多設備不能用。或者用戶突發的高峰的時候，該如何很好的服務使用者。 用滴滴打車舉例，很多產品邏輯很明顯，不用做這麼重，但是可以保證用戶體驗。比如說要不要非常準確的顯示當前的位置，要不要把每個附近的計程車當前位置顯示很清楚，並且可以跟蹤他們的情況，然後在手機上面進行顯示。這些事情的答案如果條件允許的話，用戶都想知道。但是條件不允許的時候就要降級處理。兩天的時間，幫助滴滴打車完成了“有損手術”，在壓力過高的時候去做邏輯性處理。後端伺服器壓力銳減。 微信原來要做的就是把所有的消息都必須是送達，而且一定要在每個用戶的手機上保持順序的一致。後來我們說服了微信團隊，其實順序並沒有那麼重要。 紅米案例在行業裡面比較出名，我們做了兩次紅米的手機發佈。第一次紅米手機，第二次是紅米NOTE。第二次做紅米NOTE的時候，把小米的伺服器拖垮。 我們複盤之後，發現小米的設計是一個無損的完美設計。但是這個完美設計是不是有必要？比如每個人都能看到還剩下幾部手機。當你有十萬部手機還要賣時，就不需要了。當你有一百部的時候，才是需要的。當你只剩下一百部的時候，訪問量集聚下降，可以做到這一點，十萬部的時候不需要做到這一點。 12306曾經找過我們，讓我們解決現在每到春節系統被壓垮的問題。他們認為騰訊在這方面做的非常的好。 第一點，可以試試我們的雲，當然這個不太可能。 第二點，其實很簡單你每一趟車次分開賣，車次分開賣，就可以解決很大的問題。另外早一點賣，不要非等到那個時間段。另外可以一開始悄悄賣，不同地域的票分開賣，這個想法雖然很土，但是互聯網公司用很土的辦法解決複雜的問題。 其實大資料和雲計算，就是我們用原先的資料庫解決不了現在的問題，用柔性有損的辦法解決類似的問題，到最後形成了今天的互聯網行業的產品。 本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/yanjiang/qiyejia/4310.html