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

一、快速迭代，快做快发

互联网产品不同于传统软件开发，我们面对的是上亿用户这样一个庞大的使用群体，他们是谁，有什么喜好，有何种习惯，会怎样使用我们的产品，是否喜欢我们的产品……这些情况我们并不能准确地知道。因此，互联网产品的需求，并不能通过几个月的用户调研、市场调查、产品规划就能弄清楚，何况互联网的用户群体本身也处于飞速的动态发展之中。

那么，这种情况下如何发展我们的产品？如何对各种可能的产品特性做选择？用户将是最好的指南针，任何产品推出时肯定不会是完美的，完美是一种动态的过程，所以要迅速让产品去感应用户需求，从而一刻不停地升级进化，推陈出新，这才是保持领先的唯一方式。在这个领域，产品永远是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架构的比较

	懒加载架构	Web架构
加载器	懒加载微内核	TT、QQBrowser、IE、Chrome、FireFox等浏览器
描述语言	XML	HTML
加载对象	插件	图片、视频、Flash等

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项目总监、敏捷教练。从事通讯、互联网开发、项目及研发管理多年，目前负责腾讯多个业务线重要产品的项目管理工作，探索并推行适合腾讯的敏捷研发及项目管理。