腾讯王晶：详解互联网产品开发中的“快”字诀

当今互联网的发展，已不是大鱼吃小鱼的时代，而是快鱼吃慢鱼的时代。互联网产品的制胜原则就是一个字——“快”。在各类形态的产品研发中，咱们始终贯彻如一的价值观之一就是“快”，咱们应该如何来理解和诠释“快”？又会从哪些方面来执行贯彻这个原则呢？
 

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)，转载请注明出处。