作者王晶，騰訊R&D項目總監(jiān)、敏捷教練。從事通信、互聯網開發(fā)、項目及研發(fā)管理多年，目前負責騰訊多個業(yè)務線重要產品的項目管理，探索并推行適合騰訊的敏捷研發(fā)及項目管理，從產品、運營、技術、管理四個方面，詮釋了騰訊互聯網產品研發(fā)中貫徹的價值觀——“快”。

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

快速迭代，快做快發(fā)

互聯網產品不同于傳統(tǒng)軟件開發(fā)，我們面對的是上億用戶這樣一個龐大的使用群體，他們是誰，有什么喜好，有何種習慣，會怎樣使用我們的產品，是否喜歡我們的產品……

圖1 QQ農牧場的“極速模型”

這些情況我們并不能準確地知道。因此，互聯網產品的需求，并不能通過幾個月的用戶調研、市場調查、產品規(guī)劃就能弄清楚，何況互聯網的用戶群體本身也處于飛速的動態(tài)發(fā)展之中。

那么，這種情況下如何發(fā)展我們的產品？如何對各種可能的產品特性做選擇？用戶將是最好的指南針，迅速讓產品去感應用戶需求，不斷地升級進化，推陳出新，才是保持領先的唯一方式。要不斷地傾聽用戶的反饋，不斷地調整修改，然后決定你后面的方向。

所以，“快速迭代”是我們對產品的基本要求，能否做得足夠快已成為衡量一款產品研發(fā)是否成熟的標準之一。以“QQ農牧場”為例，目前平均每天都會有至少一個版本發(fā)布，甚至更多，之所以能做到如此高的產品發(fā)布節(jié)奏，是由于我們一直堅持在做兩件事情。

以穩(wěn)定迭代，小步快跑

首先，QQ農牧場采用了一種有特色的敏捷迭代開發(fā)模式，我們稱之為“極速模型”。

QQ農牧場的研發(fā)團隊，由多個角色組成，包括：項目經理、產品、UE設計、前臺開發(fā)、后臺開發(fā)、測試、運維。以一周為一個固定的迭代開發(fā)周期，這一周時間包括了團隊一次完整的各個角色的研發(fā)協作過程：迭代前有特性規(guī)劃、迭代后有回顧，其中迭代過程也會包括迭代規(guī)劃、開發(fā)、測試、發(fā)布等過程。但與Scrum敏捷迭代最大的不同是：并非在迭代結束時進行交付，而是能夠在一次迭代中完成多次交付和發(fā)布過程。

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

• 特性需要能裂解成很細小的可交付的子特性，通常不超過兩天的開發(fā)工作量。
• 迭代前，特性規(guī)劃、溝通確認、界面交互及視覺設計這些工作均需提前安排完成。
• 迭代計劃及評估過程，還必須考慮到特性/子特性之間的耦合關系以及開發(fā)人力的耦合關系，合理地作出計劃安排，保證開發(fā)過程的順利進行，降低風險。
• 要求團隊成員工作咬合能力高，自運轉能力高，需要長期默契配合。前臺開發(fā)、后臺開發(fā)、測試人員都能夠高效率溝通，順暢協作。

以特性為中心，隨做隨發(fā)

其次，我們產品研發(fā)的所有活動，都是以特性為中心開展的。一種比較通常的方式是規(guī)劃一批特性，然后經過一個開發(fā)階段進入測試，集中測試回歸后完成發(fā)布。但在“QQ農牧場”，從特性規(guī)劃、計劃、開發(fā)、測試、發(fā)布都是以特性為單位來驅動的。也就是說當完成了一個特性的開發(fā)后，即刻轉入測試、完成測試后即刻發(fā)布。在一個迭代周期內，會有很多不同的特性獨立并行于從開發(fā)到發(fā)布的過程。

這還必須依賴于產品技術架構、測試自動化、運維發(fā)布自動化能力做支撐。但是“以特性為中心、隨做隨發(fā)”的核心思想，是產品、技術、項目管理、運維的指導原則，它是讓產品的整個研發(fā)配套能力建設圍繞這個中心來持續(xù)開展的基礎。

反饋及時，響應快速

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

建設用戶反饋渠道

首先，要解決如何搜集用戶反饋的問題，滿足不同用戶習慣，提供多種方式的反饋渠道，讓反饋及時得到。用戶可以通過不同的渠道對使用的產品進行問題反饋，提出意見和建議。

重視反饋，快速響應

用戶反饋、意見和建議就像一座礦山，為產品的發(fā)展提供了寶藏，但產品團隊是否真正認識到它們的價值，是否能夠快速地挖掘這些寶藏，卻并不是一件容易的事情。
以QQMail為例，為了快速響應來自用戶的反饋，在騰訊流傳著一個1000/100/10的故事。

• 每人每月必須回復1000條論壇用戶帖子。

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

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

注重數據運營，有數據才有真相

無論事前經過多么細致的調研、多么縝密的規(guī)劃，對于產品經理來說，一個新特性的發(fā)布，仍然是一個提心吊膽的經歷：特性被用戶的接受程度如何，用戶將如何使用，新特性給產品帶來了怎樣的拉動或抑制，哪些特性可能存在交互、易用性、穩(wěn)定性等問題。要想回答這些問題都很困難。

圖2 連續(xù)運營數據分析示例

通過運營數據的分析，我們能夠在短時間內獲得對某個產品特性的準確評價，進而快速地指導產品下一步的發(fā)展。圖2是一個產品93天內用戶注冊成功率的連續(xù)運營數據的例子。

從圖2可以看出，7月12日前注冊成功率穩(wěn)定維持在20%~30%之間。7月12日對注冊頁面交互流程進行了優(yōu)化并對外發(fā)布，之后兩周的數據觀察表明新的交互設計起到了預期的作用，注冊成功率提升到了40%~60%，即使在7月17日、24日兩天有定向向某省所有上線QQ用戶發(fā)布消息時，其注冊成功率也在40%左右浮動兩個百分點。通過運營數據分析，能夠快速地判斷特性目標是否達到，進而指導下一步的行動。

快需要創(chuàng)新、需要實力

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

以QQ寵物為例，通過技術架構創(chuàng)新成功地提升了客戶端產品的發(fā)布速度和更新頻率。如果采用傳統(tǒng)客戶端方式的話，一次版本的全量升級需要6個月的時間，而在新架構下一次全量升級僅需1天。架構從以下幾方面提升了快的能力。

客戶端Web化技術：像B/S系統(tǒng)一樣的開發(fā)方式和發(fā)布周期

有人會問：客戶端的產品發(fā)布能快得起來嗎？我們能做到讓客戶端像Web一樣敏捷嗎？ 答案是肯定的，我們的客戶端微內核懶加載架構，將客戶端Web化技術做到了像Web一樣開發(fā)客戶端產品。

圖3 QQ寵物的技術架構

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

微內核簡要介紹如下。

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

• 插件加載器，負責加載插件。
• 插件版本控制組件，負責詢問版本服務器獲取加載的版本。
• 資源下載組件，負責下載插件資源。

客戶端的簡要啟動運行流程如下。

• 獲取版本：內核啟動后，詢問版本控制服務器，獲取需要加載的版本。
• 下載相應版本的XML配置。
• 加載器解析XML配置。
• 開始第一個插件加載邏輯。
• 下載第一個插件的資源。
• 加載第一個插件。
• 繼續(xù)加載子節(jié)點插件。
• 微內核懶加載架構與Web架構的比較如表1所示。

同時，通過微內核懶加載架構還能做到特性即插即用，使產品靈活穩(wěn)定。組件之間被強行解耦，大大降低了依賴性在聯調、測試、系統(tǒng)集成方面帶來的工作難度。由于每個組件都可以被獨立下載，在客戶端加載運行，這也就意味著發(fā)布風險的降低、效率的提升。

面向特性的豎向架構：以特性為開發(fā)粒度，提升開發(fā)效率

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

圖4 傳統(tǒng)的橫向分層產品技術架構

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

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

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

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

圖5 豎向產品技術架構

Scrum敏捷開發(fā)：發(fā)揚光大

我們早在2005年就引入了敏捷開發(fā)，目前已經將Scrum結合我們自身的產品、文化、團隊特點形成了自己的敏捷研發(fā)管理框架。經過自下而上的發(fā)展和騰訊人積極的探索和沉淀，逐步形成了經典迭代、極速、大象、運營這四個比較有特色的敏捷研發(fā)管理模式。而在敏捷的推廣、實施方面，也已經有了一套以運營為理念的推廣模式，把敏捷當作產品來運營，形成了“管理”、“工程”兩條線，在多個維度推行敏捷。

CI：持續(xù)集成，快速體驗

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

圖6 騰訊的Scrum敏捷開發(fā)

作為加快產品發(fā)布的能力，CI在以下幾個方面作用明顯。

• 自動編譯輸出報告，維護代碼可運行，及時暴露風險，降低集成成本。
• Dailybuild日構建系統(tǒng)，讓產品經理、測試人員可以盡早進行體驗和測試。
• 作為一個自動化系統(tǒng)，利用靜態(tài)代碼檢查、單元測試報告等手段為團隊提供報告，促進編碼質量不斷得到重視，降低缺陷解決成本、縮短解決時間。

灰度發(fā)布：提升發(fā)布的頻率，降低發(fā)布風險

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

總結

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