互联网产品开发中制胜原则的“快”字诀

一些事 • 8年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

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

快速迭代，快做快发

互联网产品不同于传统软件开发，我们面对的是上亿用户这样一个庞大的使用群体，他们是谁，有什么喜好，有何种习惯，会怎样使用我们的产品，是否喜欢我们的产品……

图1 QQ农牧场的“极速模型”

这些情况我们并不能准确地知道。因此，互联网产品的需求，并不能通过几个月的用户调研、市场调查、产品规划就能弄清楚，何况互联网的用户群体本身也处于飞速的动态发展之中。

那么，这种情况下如何发展我们的产品?如何对各种可能的产品特性做选择?用户将是最好的指南针，迅速让产品去感应用户需求，不断地升级进化，推陈出新，才是保持领先的唯一方式。要不断地倾听用户的反馈，不断地调整修改，然后决定你后面的方向。

所以，“快速迭代”是我们对产品的基本要求，能否做得足够快已成为衡量一款产品研发是否成熟的标准之一。以“QQ农牧场”为例，目前平均每天都会有至少一个版本发布，甚至更多，之所以能做到如此高的产品发布节奏，是由于我们一直坚持在做两件事情。

以稳定迭代，小步快跑

首先，QQ农牧场采用了一种有特色的敏捷迭代开发模式，我们称之为“极速模型”。

QQ农牧场的研发团队，由多个角色组成，包括：项目经理、产品、UE设计、前台开发、后台开发、测试、运维。以一周为一个固定的迭代开发周期，这一周时间包括了团队一次完整的各个角色的研发协作过程：迭代前有特性规划、迭代后有回顾，其中迭代过程也会包括迭代规划、开发、测试、发布等过程。但与Scrum敏捷迭代最大的不同是：并非在迭代结束时进行交付，而是能够在一次迭代中完成多次交付和发布过程。

此种方式看似简单，但其实对团队的综合研发能力是一个巨大的挑战。其中主要挑战来自以下几个方面。

• 特性需要能裂解成很细小的可交付的子特性，通常不超过两天的开发工作量。

• 迭代前，特性规划、沟通确认、界面交互及视觉设计这些工作均需提前安排完成。

• 迭代计划及评估过程，还必须考虑到特性/子特性之间的耦合关系以及开发人力的耦合关系，合理地作出计划安排，保证开发过程的顺利进行，降低风险。

• 要求团队成员工作咬合能力高，自运转能力高，需要长期默契配合。前台开发、后台开发、测试人员都能够高效率沟通，顺畅协作。

以特性为中心，随做随发

其次，我们产品研发的所有活动，都是以特性为中心开展的。一种比较通常的方式是规划一批特性，然后经过一个开发阶段进入测试，集中测试回归后完成发布。但在“QQ农牧场”，从特性规划、计划、开发、测试、发布都是以特性为单位来驱动的。也就是说当完成了一个特性的开发后，即刻转入测试、完成测试后即刻发布。在一个迭代周期内，会有很多不同的特性独立并行于从开发到发布的过程。

这还必须依赖于产品技术架构、测试自动化、运维发布自动化能力做支撑。但是“以特性为中心、随做随发”的核心思想，是产品、技术、项目管理、运维的指导原则，它是让产品的整个研发配套能力建设围绕这个中心来持续开展的基础。

反馈及时，响应快速

做到产品的快速发布只是第一步，其根本目的就是让用户尽快用到新功能，尽快得到用户反馈信息，以便及时地对产品开发做调整。所以，一个产品团队能否快速获取用户反馈、是否真正重视反馈并及时作出响应非常重要。经历了12年互联网的摸爬滚打，我们非常重视来自用户的反馈意见，并不断改进产品，积累了丰富的交付经验。

建设用户反馈渠道

首先，要解决如何搜集用户反馈的问题，满足不同用户习惯，提供多种方式的反馈渠道，让反馈及时得到。用户可以通过不同的渠道对使用的产品进行问题反馈，提出意见和建议。

重视反馈，快速响应

用户反馈、意见和建议就像一座矿山，为产品的发展提供了宝藏，但产品团队是否真正认识到它们的价值，是否能够快速地挖掘这些宝藏，却并不是一件容易的事情。

以QQMail为例，为了快速响应来自用户的反馈，在腾讯流传着一个1000/100/10的故事。

• 每人每月必须回复1000条论坛用户帖子。

• 每人每月必须查阅100篇与QQMail相关的网络评论文章。

• 每人每月必须处理10个用户反馈意见。

注重数据运营，有数据才有真相

无论事前经过多么细致的调研、多么缜密的规划，对于产品经理来说，一个新特性的发布，仍然是一个提心吊胆的经历：特性被用户的接受程度如何，用户将如何使用，新特性给产品带来了怎样的拉动或抑制，哪些特性可能存在交互、易用性、稳定性等问题。要想回答这些问题都很困难。

图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所示。

微内核简要介绍如下。

• 整个客户端改造成为一个微内核插件平台，只有一个插件加载器、插件版本控制组件、资源下载组件。

• 插件加载器，负责加载插件。

• 插件版本控制组件，负责询问版本服务器获取加载的版本。

• 资源下载组件，负责下载插件资源。

• 客户端的简要启动运行流程如下。

• 获取版本：内核启动后，询问版本控制服务器，获取需要加载的版本。

• 下载相应版本的XML配置。

• 加载器解析XML配置。

• 开始第一个插件加载逻辑。

• 下载第一个插件的资源。

• 加载第一个插件。

• 继续加载子节点插件。

• 微内核懒加载架构与Web架构的比较如表1所示。

同时，通过微内核懒加载架构还能做到特性即插即用，使产品灵活稳定。组件之间被强行解耦，大大降低了依赖性在联调、测试、系统集成方面带来的工作难度。由于每个组件都可以被独立下载，在客户端加载运行，这也就意味着发布风险的降低、效率的提升。

面向特性的竖向架构：以特性为开发粒度，提升开发效率

传统的产品技术架构多为横向的分层结构，而每一层又习惯于分配给不同的人来负责。这直接带来的一个问题是，我们以特性为粒度进行开发、联调、测试时会因为人员耦合、层耦合带来复杂性、引入风险。

图4 传统的横向分层产品技术架构

举个例子，比如开发一个login页面登录功能，可能需要Web前台工程师开发页面、Web后台工程师开发CGI、Server后台工程开发用户鉴权接口、数据库工程师做数据库表结构开发。那么这样一个简单的login功能，在联调、测试、发布方面就会牵扯很多的人力协作，而又因为每一层都需要改动代码，可能对这一层的其他功能代码造成影响。试问这样的方式能快得起来吗?

QQ宠物的新架构则以特性为中心，采用竖向的架构来解决这个问题，每个特性一个组件，一个人负责开发，每个组件必须包括UI、逻辑、协议的代码实现。

这样的方式，使得面向特性的开发模式得以强制化，从而提升了效率，加快了节奏。

快需要手段

想快容易——做快难。在产品研发过程上，除了产品、运营、技术上的能力，我们还需要有必要的手段保证整个研发快起来。

图5 竖向产品技术架构

Scrum敏捷开发：发扬光大

我们早在2005年就引入了敏捷开发，目前已经将Scrum结合我们自身的产品、文化、团队特点形成了自己的敏捷研发管理框架。经过自下而上的发展和腾讯人积极的探索和沉淀，逐步形成了经典迭代、极速、大象、运营这四个比较有特色的敏捷研发管理模式。而在敏捷的推广、实施方面，也已经有了一套以运营为理念的推广模式，把敏捷当作产品来运营，形成了“管理”、“工程”两条线，在多个维度推行敏捷。

CI：持续集成，快速体验

CI在产品开发、测试阶段提升自动化效率方面非常有效。目前我们CI的发展水平还参差不齐，但从起初的自动编译已逐步加入了静态代码检测、单元测试、自动化部署等更多内容，开始为更多的研发团队所青睐。