騰訊王晶：詳解互聯網產品開發中的「快」字訣

當今互聯網的發展，已不是大魚吃小魚的時代，而是快魚吃慢魚的時代。互聯網產品的制勝原則就是一個字——「快」。在各類形態的產品研發中，咱們始終貫徹如一的價值觀之一就是「快」，咱們應該如何來理解和詮釋「快」？又會從哪些方面來執行貫徹這個原則呢？
 

1、快速迭代，快作快發

 

　　互聯網產品不一樣於傳統軟件開發，咱們面對的是上億用戶這樣一個龐大的使用羣體，他們是誰，有什麼喜愛，有何種習慣， 會怎樣使用咱們的產品，是否喜歡咱們的產品……這些狀況咱們並不能準確地知道。所以，互聯網產品的需求，並不能經過幾個月的用戶調研、市場調查、產品規劃 就能弄清楚，況且互聯網的用戶羣體自己也處於飛速的動態發展之中。

 

　　那麼，這種狀況下如何發展咱們的產品？如何對各類可能的產品特性作選擇？用戶將是最好的指南針，任何產品推出時確定 不會是完美的，完美是一種動態的過程，因此要迅速讓產品去感應用戶需求，從而一刻不停地升級進化，推陳出新，這纔是保持領先的惟一方式。在這個領域，產品 永遠是Beta版，可能每幾天一個版本，快速地去升級，不斷地傾聽論壇、用戶的反饋，不斷地調整修改，而後決定你後面的方向。

 

　　因此，「快速迭代」是咱們對產品的基本要求，可否作得足夠快已成爲衡量一款產品研發是否成熟的標準之一。以「QQ農牧場」爲例，目前每週平均會發布20個版本，之因此能作到如此高的產品發佈節奏，是因爲咱們一直堅持在作兩件事情。

 

1. 以穩定迭代，小步快跑

 

　　雖然，咱們追求快速發佈，但更須要一個穩定的研發節奏來便保證團隊的效率和產品的質量。如何能既快又穩，QQ農牧場採用了一種有特點的敏捷迭×××發模式，咱們稱之爲「極速模型」。

 

圖1  QQ農牧場的「極速模型」

 

　　QQ農牧場的研發團隊，由多個角色組成，包括：項目經理、產品、UE設計、前臺開發、後臺開發、測試、運維。以一週爲一個固定的迭×××發週期，這一週時間包括了團隊一次完整的各個角色的研發協做過程：迭代前有特性規劃、迭代後有回顧，其中迭代過程也會包括迭代規劃、開發、測試、發佈等過程。但與Scrum敏捷迭代最大的不一樣是：並不是在迭代結束時進行交付，而是可以在一次迭代中完成屢次交付和發佈過程。

 

　　此種方式看似簡單，但其實對團隊的綜合研發能力是一個巨大的挑戰。其中主要挑戰來自如下幾個方面。

 

1)       特性須要能裂解成很細小的可交付的子特性，一般不超過2天的開發工做量。

 

2)       迭代前，特性規劃、溝通確認、界面交互及視覺設計這些工做均需提早安排完成。

 

3)       迭代計劃及評估過程，還必須考慮到特性/子特性之間的耦合關係以及開發人力的耦合關係，合理地做出計劃安排，保證開發過程的順利進行，下降風險。

 

4)       要求團隊成員工做咬合能力高，自運轉能力高，須要長期默契配合。前臺開發、後臺開發、測試人員都可以高效率地溝通，順暢地協做。

 

2. 以特性爲中心，隨作隨發

 

　　特性，是用戶可以感知和使用的、對用戶真實有意義的功能單元。因此，僅僅追求發佈版本數量是沒有意義的，每次發佈至少可以給用戶帶來感知或使用的功能。

 

　　所以，咱們產品研發的全部活動，都是以特性爲中心開展的。一種比較一般的方式是規劃一批特性，而後通過一個開發階段進入測試，集中測試迴歸後完成發佈。但在「QQ農牧場」，從特性規劃、計劃、開發、測試、發佈都是以特性爲單位來驅動的。也就是說當完成了一個特性的開發後，即刻轉入測試、完成測試後即刻發佈。在一個迭代週期內，會有不少不一樣的特性獨立並行於從開發到發佈的過程。

 

　　固然了，可以作到這樣的程度，還依必須賴於產品技術架構、測試自動化、運維發佈自動化能力作支撐。但首先，「以特性爲中心、隨作隨發」的核心思想，是產品、技術、項目管理、運維的指導原則，它讓產品的整個研發配套能力建設圍繞這這個中心來持續開展。

 

2、反饋及時，響應快速

 

　　作到產品的快速發佈只是第一步，其根本目的就是讓用戶儘快能用到新功能，儘快獲得用戶反饋信息，以便及時地對產品開發作調整。因此，一個產品團隊可否可以快速獲取用戶反饋、是否真正重視反饋並及時做出響應很是重要。經歷了12年互聯網的摸爬滾打，咱們很是重視來自用戶的反饋意見，不斷改進產品，積累了豐富的交付經驗。

 

1.       建設用戶反饋渠道

 

　　首先，要解決如何蒐集用戶反饋的問題，知足不一樣用戶習慣，提供多種方式的反饋渠道，讓反饋及時獲得。用戶能夠經過不一樣的渠道對使用的產品進行問題反饋，提出意見和建議。

 

2.       重視反饋，快速響應

 

　　用戶反饋、意見和建議就像一座礦山，爲產品的發展提供了寶藏，但產品團隊是否真正認識到它們的價值，是否可以快速地挖掘這些寶藏，卻並非一件容易的事情。

 

　　以QQMail爲例，爲了確保對來自用戶反饋的快速響應，在騰訊流傳着一個1000/100/10的故事。

 

1)       每人每個月必須回覆1000條論壇用戶帖子。

 

2)       每人每個月必須查閱100篇與QQMail相關的網絡評論文章。

 

3)       每人每個月必須處理10個用戶反饋意見。

 

3. 注重數據運營，有數據纔有真相

 

　　不管事前通過多麼細緻的調研、多麼縝密的規劃，對於產品經理來講，一個新特性的發佈，仍然是一個提心吊膽的經歷：特 性被用戶的接受程度如何，用戶將如何使用，新特性給產品帶來了怎樣的拉動或抑制，哪些特性可能存在交互、易用性、穩定性等問題。要想回答這些問題都很困 難。

 

　　數據運營，就是用產品運營數聽說話，經過對運營數據的分析，爲產品發展提供客觀的決策依據。經過運營數據的分析，可以在短期內得到對某個產品特性的準確評價，進而快速地指導產品下一步的發展。

 

　　圖2是一個產品93天內用戶註冊成功率的連續運營數據的例子。

 

圖2  連續運營數據分析示例

 

　　從圖2能夠看出，7月12日前註冊成功率穩定維持在20~30%之間。7月12日對註冊頁面交互流程進行了優化並對 外發布，以後2周的數據觀察代表新的交互設計起到了預期的做用，註冊成功率提高到了40%~60%，即便在7月17日、24日兩天有定向向某省全部上線 QQ用戶發佈消息時，其註冊成功率也在40%左右浮動2個百分點。經過運營數據分析，可以快速地判斷特性目標是否達到，進而指導下一步的行動。

 

3、快須要創新、須要實力

 

　　咱們但願產品迭代得更快，但有了這個理念就必定可以快起來嗎？快不僅是一種產品理念，更是一種技術實力，遵循着這個核心價值觀，須要技術上的創新思惟，讓技術能力來支撐咱們的快。

 

　　以QQ寵物爲例，經過技術架構創新成功地提高了客戶端產品的發佈速度和更新頻率。若是採用傳統客戶端方式的話，一次版本的全量升級須要6個月的時間，新架構下一次全量升級僅需1天。架構從如下幾方面提高了快的能力。

 

1.客戶端Web化技術：像B/S系統同樣的開發方式和發佈週期

 

　　有人會問：客戶端的產品發佈能快得起來嗎？確實很困難，但必須作到，由於這就是互聯網產品的基本要求，咱們能作到讓客戶端像Web同樣敏捷嗎？ 答案是確定的，咱們的客戶端微內核懶加載架構，將客戶端Web化技術作到了像Web同樣開發客戶端產品。

 

整個架構由客戶端的微內核、插件版本控制服務器和資源下載服務器構成，如圖3所示。

 

 

圖3  QQ寵物的技術架構

     

微內核簡要介紹以下。

 

1)       整個客戶端改形成爲一個微內核插件平臺，只有一個插件加載器、插件版本控制組件、資源下載組件。

 

2)       插件加載器，負責加載插件。

 

3)       插件版本控制組件，負責詢問版本服務器獲取加載的版本。

 

4)       資源下載組件，負責下載插件資源。

 

客戶端的簡要啓動運行流程以下：

 

1)       獲取版本：內核啓動後，詢問版本控制服務器，獲取須要加載的版本。

 

2)       下載相應版本的XML配置。

 

3)       加載器解析XML配置。

 

4)       開始第一個插件加載邏輯。

 

5)       下載第一個插件的資源。

 

6)       加載第一個插件。

 

7)       繼續加載子節點插件。

 

　　微內核懶加載架構與Web架構的比較如表1所示。

 

表1  微內核懶加載架構與Web架構的比較

 

	懶加載架構	Web架構
加載器	懶加載微內核	TT、QQBrowser、IE、Chrome、FireFox等瀏覽器
描述語言	XML	HTML
加載對象	插件	圖片、視頻、Flash等

 

2. 微內核、插件化體系結構：特性即插即用，產品靈活穩定

 

　　基於微內核懶加載架構的業務開發就變得很是簡單、異常靈活。整個產品 大大小小的特性，都被拆解成一個個功能組件，組件之間被強行解耦，減小依賴獨立運行，這大大下降了依賴性在聯調、測試、系統集成方面帶來的工做難度，減小 了時間，提高了效率。更重要的是，每一個組件均可以被獨立下載，在客戶端加載運行，這也就意味着發佈風險的下降、效率的提高。

 

圖4        微內核、插件化體系結構

 

3. 面向特性的豎向架構：以特性爲開發粒度，提高開發效率

 

　　傳統的產品技術架構多爲橫向的分層結構，而每一層又習慣於分配不一樣的人來負責。這直接帶來的一個問題是，咱們以特性爲粒度進行開發、聯調、測試時會由於人員耦合、層耦合帶來複雜性、引入風險。

 

圖5  傳統的橫向分層產品技術架構

 

　　舉個例子，好比開發一個login頁面登陸功能，可能須要Web前臺工程師開發頁面、Web後臺工程師開發CGI、Server後臺工程開發用戶鑑權接口、數據庫工程師作數據庫表結構開發。那麼這樣一個簡單的login功能，在聯調、測試、發佈方面就會牽扯不少的人力協做，而又由於每一層都須要改動代碼，可能對這一層的其餘功能代碼形成影響。試問這樣的方式能快得起來嗎？

 

　　QQ寵物的新架構則以特性爲中心，採用豎向的架構來解決這個問題，每一個特性一個組件，一我的負責開發，每一個組件必須包括UI、邏輯、協議的代碼實現。

 

圖6  豎向產品技術架構

 

　　這樣的方式，使得面向特性的開發模式得以強制化，從而提高了效率，加快了節奏。

 

4、快須要手段

 

　　想快容易——作快難，除了產品、運營、技術上的能力，產品研發過程上須要有必要的手段保證整個研發快起來。

 

1. Scrum敏捷開發：發揚光大

 

　　敏捷爲快而生，快速響應變化，這正是互聯網產品的發展須要。咱們早在2005年就引入了敏捷開發，目前已經將Scrum結合咱們自身的產品、文化、團隊特色造成了本身的敏捷研發管理框架。通過自下而上的發展和騰訊人積極的探索和沉澱，逐步造成了「經典迭代」、「極速」、「大象」、「運營」這四個比較有特點的敏捷研發管理模式。

 

　　咱們在敏捷的推廣、實施方面，已經有一套以運營爲理念的推廣模式，把敏捷看成產品來運營，造成了「管理」、「工程」兩條線，在多個維度推行敏捷。

 

圖7  騰訊的Scrum敏捷開發

 

2. CI：持續集成，快速體驗

 

　　CI在產品開發、測試階段提高自動化效率方面很是有效。目前咱們CI的發展水平還良莠不齊，但從起初的自動編譯已逐步加入了靜態代碼檢測、單元測試、自動化部署等更多內容，開始爲更多的研發團隊所青睞。

 

　　做爲加快產品的發佈的能力，CI在如下幾個方面做用明顯。

 

1)       自動編譯輸出報告，維護代碼可運行，及時暴露風險，下降集成成本。

 

2)       Dailybuild日構建系統，讓產品經理、測試人員能夠儘早進行體驗和測試。

 

3)       做爲一個自動化系統，利用靜態代碼檢查、單元測試報告等手段爲團隊提供報告，促進編碼質量不斷獲得重視，下降缺陷解決成本、縮短解決時間。

 

3. 灰度發佈：提高發布的頻率，下降發佈風險

 

　　在互聯網行業，灰度發佈已經成爲最重要的發佈控制手段。有時咱們但願經過向小部分用戶開發新功能，讓他們先來體驗新功能、新特性。經過用戶反饋、數據運營的手段及早得到反饋，及時改進。以此方式，既能夠下降發佈風險，也能夠提高發布頻率，加快發佈節奏。

 

總結

 

　　快是一種追求、一種習慣，更是一種能力，這種能力須要產品、技術、運營、研發管理多方面的支撐纔可以快得起來。這樣的快，就像是中國的高鐵，在高速的行駛中還必須讓你感到安全、溫馨、服務、便利。

 

做者簡介：

 

　　王晶，騰訊R&D項目總監、敏捷教練。從事通信、互聯網開發、項目及研發管理多年，目前負責騰訊多個業務線重要產品的項目管理工做，探索並推行適合騰訊的敏捷研發及項目管理。

本文來自騰訊大講堂(DJT.QQ.COM)，轉載請註明出處。