詳解互聯網產品開發中的「快」字訣

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

一、快速反覆運算，快做快發

互聯網產品不同于傳統軟體發展，我們面對的是上億使用者這樣一個龐大的使用群體，他們是誰，有什麼喜好，有何種習慣，會怎樣使用我們的產品，是否喜歡我們的產品...... 這些情況我們並不能準確地知道。 因此，互聯網產品的需求，並不能通過幾個月的使用者調研、市場調查、產品規劃就能弄清楚，何況互聯網的使用者群體本身也處於飛速的動態發展之中。

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

所以，「快速反覆運算」是我們對產品的基本要求，能否做得足夠快已成為衡量一款產品研發是否成熟的標準之一。 以「QQ農牧場」為例，目前每週平均會發佈20個版本，之所以能做到如此高的產品發佈節奏，是由於我們一直堅持在做兩件事情。

1. 以穩定反覆運算，小步快跑

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

圖1  QQ農牧場的「極速模型」
QQ農牧場的研發團隊，由多個角色組成，包括：專案經理、產品、UE設計、前臺開發、後臺開發、測試、運維。 以一周為一個固定的反覆開發週期，這一周時間包括了團隊一次完整的各個角色的研發協作過程：反覆運算前有特性規劃、反覆運算後有回顧，其中反覆運算過程也會包括反覆運算規劃、開發、測試、發佈等過程。 但與Scrum敏捷反覆運算最大的不同是：並非在反覆運算結束時進行交付，而是能夠在一次反覆運算中完成多次交付和發佈過程。

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

1) 特性需要能裂解成很細小的可交付的子特性，通常不超過2天的開發工作量。

2)       反覆運算前，特性規劃、溝通確認、介面交互及視覺設計這些工作均需提前安排完成。

3)       反覆運算計畫及評估過程，還必須考慮到特性/子特性之間的耦合關係以及開發人力的耦合關係，合理地作出計畫安排，保證開發過程的順利進行，降低風險。

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

2. 以特性為中心，隨做隨發

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

因此，我們產品研發的所有活動，都是以特性為中心開展的。 一種比較通常的方式是規劃一批特性，然後經過一個開發階段進入測試，集中測試回歸後完成發佈。 但在「QQ農牧場」，從特性規劃、計畫、開發、測試、發佈都是以特性為單位來驅動的。 也就是說當完成了一個特性的開發後，即刻轉入測試、完成測試後即刻發佈。 在一個反覆運算週期內，會有很多不同的特性獨立並行于從開發到發佈的過程。

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

二、回饋及時，回應快速

做到產品的快速發佈只是第一步，其根本目的就是讓使用者儘快能用到新功能，儘快得到使用者回饋資訊，以便及時地對產品開發做調整。 所以，一個產品團隊能否能夠快速獲取使用者回饋、是否真正重視回饋並及時作出回應非常重要。 經歷了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個百分點。 通過運營資料分析，能夠快速地判斷特性目標是否達到，進而指導下一步的行動。

三、快需要創新、需要實力

我們希望產品反覆運算得更快，但有了這個理念就一定能夠快起來嗎？ 快不只是一種產品理念，更是一種技術實力，遵循著這個核心價值觀，需要技術上的創新思維，讓技術能力來支撐我們的快。

以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架構的比較

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

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

圖4 微內核、外掛程式化體系結構

3. 面向特性的豎向架構：以特性為開發細微性，提升開發效率

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

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

舉個例子，比如開發一個login頁面登錄功能，可能需要Web前臺工程師開發頁面、Web後臺工程師開發CGI、Server後臺工程開發使用者鑒權介面、資料庫工程師做資料庫表結構開發。 那麼這樣一個簡單的login功能，在聯調、測試、發佈方面就會牽扯很多的人力協作，而又因為每一層都需要改動代碼，可能對這一層的其他功能代碼造成影響。 試問這樣的方式能快得起來嗎？

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

圖6 豎向產品技術架構

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

四、快需要手段

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

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

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

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

圖7 騰訊的Scrum敏捷開發

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

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

作為加快產品的發佈的能力，CI在以下幾個方面作用明顯。

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

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

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

3. 灰度發佈：提升發佈的頻率，降低發佈風險

在互聯網行業，灰度發佈已經成為最重要的發佈控制手段。 有時我們希望通過向小部分使用者開發新功能，讓他們先來體驗新功能、新特性。 通過使用者回饋、資料運營的手段及早獲得回饋，及時改進。 以此方式，既可以降低發佈風險，也可以提升發佈頻率，加快發佈節奏。

總結

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

作者簡介：

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

源位址：HTTP://djt.open.qq.com/po......=view&aid=206