一、快速迭代,快做快发
互联网产品不同于传统软件开发,我们面对的是上亿用户这样一个庞大的使用群体,他们是谁,有什么喜好,有何种习惯,会怎样使用我们的产品,是否喜欢我们的产品……这些情况我们并不能准确地知道。因此,互联网产品的需求,并不能通过几个月的用户调研、市场调查、产品规划就能弄清楚,何况互联网的用户群体本身也处于飞速的动态发展之中。
那么,这种情况下如何发展我们的产品?如何对各种可能的产品特性做选择?用户将是最好的指南针,任何产品推出时肯定不会是完美的,完美是一种动态的过程,所以要迅速让产品去感应用户需求,从而一刻不停地升级进化,推陈出新,这才是保持领先的唯一方式。在这个领域,产品永远是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项目总监、敏捷教练。从事通讯、互联网开发、项目及研发管理多年,目前负责腾讯多个业务线重要产品的项目管理工作,探索并推行适合腾讯的敏捷研发及项目管理。
本文来自腾讯大讲堂(DJT.QQ.COM),转载请注明出处。