<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    統計

    留言簿(1)

    DB

    Others

    QA

    Tech Website

    閱讀排行榜

    評論排行榜

    【轉】互聯網產品開發中的“快”字訣

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

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

    快速迭代,快做快發

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

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

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

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

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

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

    以穩定迭代,小步快跑

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

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

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

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

    以特性為中心,隨做隨發

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

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

    反饋及時,響應快速

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

    建設用戶反饋渠道

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

    重視反饋,快速響應

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

    • 每人每月必須回復1000條論壇用戶帖子。
    • 每人每月必須查閱100篇與QQMail相關的網絡評論文章。
    • 每人每月必須處理10個用戶反饋意見。

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

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

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

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

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

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

    快需要創新、需要實力

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

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

    客戶端Web化技術:像B/S系統一樣的開發方式和發布周期

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

    圖3 QQ寵物的技術架構

    圖3 QQ寵物的技術架構

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

    微內核簡要介紹如下。

    • 整個客戶端改造成為一個微內核插件平臺,只有一個插件加載器、插件版本控制組件、資源下載組件。
    • 插件加載器,負責加載插件。
    • 插件版本控制組件,負責詢問版本服務器獲取加載的版本。
    • 資源下載組件,負責下載插件資源。

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

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

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

    面向特性的豎向架構:以特性為開發粒度,提升開發效率

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

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

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

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

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

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

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

    圖5 豎向產品技術架構

    圖5 豎向產品技術架構

    Scrum敏捷開發:發揚光大

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

    CI:持續集成,快速體驗

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

    圖6 騰訊的Scrum敏捷開發

    圖6 騰訊的Scrum敏捷開發

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

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

    灰度發布:提升發布的頻率,降低發布風險

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

    總結

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


    轉自csdn.net

    posted on 2011-08-28 23:47 XXXXXX 閱讀(329) 評論(0)  編輯  收藏 所屬分類: PM


    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 亚洲精品乱码久久久久66| 免费人成在线观看网站品爱网日本| 亚洲欧美在线x视频| 最近免费中文字幕mv在线电影| 91精品国产免费| 久久亚洲AV成人出白浆无码国产| 亚洲欧洲国产成人精品| **真实毛片免费观看| 亚洲国产精品久久久久婷婷软件| 亚洲中字慕日产2021| 国产h视频在线观看免费| 亚洲一区二区无码偷拍| 最近2019中文字幕免费看最新 | 最近中文字幕完整版免费高清| 毛片A级毛片免费播放| 亚洲人成电影网站色| 免费一区二区视频| 中文在线免费不卡视频| 亚洲va无码专区国产乱码| 18pao国产成视频永久免费| 亚洲精品在线网站| 99久久免费精品国产72精品九九| 亚洲AV中文无码字幕色三| 99精品一区二区免费视频| 亚洲中文字幕人成乱码| 亚洲AV网站在线观看| 午夜a级成人免费毛片| 精品国产亚洲一区二区三区在线观看| 日韩免费视频一区二区| 亚洲人成黄网在线观看| 国产精品视频免费一区二区三区| 亚洲人成亚洲精品| 成人毛片视频免费网站观看| 午夜成人无码福利免费视频| 亚洲第一成年男人的天堂| 特级毛片爽www免费版| 久久久久亚洲AV片无码| 97在线线免费观看视频在线观看| 亚洲国产成人久久精品影视| 欧美a级在线现免费观看| 一级午夜免费视频|