互联网产品开发快字诀 编辑本段回目录
当今互联网的发展，已不是大鱼吃小鱼的时代，而是快鱼吃慢鱼的时代。互联网产品的制胜原则就是一个字——“快”。在各种形态的产品研发中，我们始终贯彻如一的价值观之一就是“快”，我们应该如何来理解和诠释“快”？又会从哪些方面来执行贯彻这个原则呢？
一、快速迭代，快做快发
互联网产品不同于传统软件开发，我们面对的是上亿用户这样一个庞大的使用群体，他们是谁，有什么喜好，有何种习惯，会怎样使用我们的产品，是否喜欢我们的产品……这些情况我们并不能准确地知道。因此，互联网产品的需求，并不能通过几个月的用户调研、市场调查、产品规划就能弄清楚，何况互联网的用户群体本身也处于飞速的动态发展之中。
那么，这种情况下如何发展我们的产品？如何对各种可能的产品特性做选择？用户将是最好的指南针，任何产品推出时肯定不会是完美的，完美是一种动态的过程，所以要迅速让产品去感应用户需求，从而一刻不停地升级进化，推陈出新，这才是保持领先的唯一方式。在这个领域，产品永远是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项目总监、敏捷教练。从事通讯、互联网开发、项目及研发管理多年，目前负责腾讯多个业务线重要产品的项目管理工作，探索并推行适合腾讯的敏捷研发及项目管理。
源地址：http://djt.open.qq.com/po……=view&aid=206
