灰度发布 - UCD大社区

杂谈产品灰度上线的研发模式

老鱼 — 2010-06-07 16:03:37

传统的产品研发模式大致可以分为：产品调研-架构评估-产品启动-需求分析-产品设计-产品开发-产品发布七大阶段。本人在公司经历过大大小小的项目数以百计，发觉这些阶段一直以来都是以一条直线的形式串行着：从产品调研到产品发布，总是一拖到底。这样的做法对于范围比较大，周期比较长的项目，尤其是用户体验类项目而言，存在较大的弊端：我们很可能在没有足够清楚用户需求的情况下，定制了过多的辅助功能，这样即拉长了项目周期，又无谓的投入了过多的人力，在资源如此宝贵的今天，浪费资源实在太过奢侈，我代表春哥鄙视之…

言归正传，切入今天要谈的话题 —-“产品灰度上线的研发模式”。何谓“灰度上线”，简单点理解就是按产品需求优先级，抽出核心需求，在满足用户基本要求的情况下快速上线，并通过限制流量、白名单等机制进行产品试用，以此收集用户的意见，从而萃取出用户潜在的需求，形成后续更有针对性的设计方案。

和传统研发模式相比，这么做唯一的区别就在于将原先一锅粥式的需求和功能点进行了轻重缓急的排序，并以此将项目从原来的单长线作战转化为多迭代短线循环，让产品的生命周期不再昙花一现。

如此一来，需求分析阶段显得尤为关键，我们必须清晰的将需求按优先级归纳分类为几个序列，如：p1,p2,p3…核心功能和必备的体验在p1序列，辅助功能点和辅助型体验列在p2序列，争执不定的需求点可以放在p3序列。需求排序后，我们可以将项目发布点有序的分成（>2期），第一期只确保主要的核心功能和基础体验快速灰度上线，随后通过用户访谈、产品的tracker&session数据、业务数据等手段分析出用户对产品的真实反应，并以此调整二期需求，该加的加，该砍的砍，做到有的放矢。

有画面有真相，我们就以支付宝个人版三期中提醒代扣项目的研发始末为反例，正视我们现有研发模式中存在的问题：整个项目从产品启动到产品发布历时近3个月之久，发布后却尴尬的发现用户的青睐程度并不高，甚至可以用“门可罗雀”来形容产品使用率之惨淡，当然产品的始作蛹者可以推托怪罪于运营力度不够，也可以感慨产品的身不逢时，但是作为产品的设计者，在用户需求并不明朗，且欠东风的情况下除了核心功能，你完全没必要夹杂过多的辅助功能、体验…试想，在这个项目中，我们采用灰度上线的研发思路，那么这款产品的核心功能上线周期将缩短一倍有余，我们将赢得足够的时间观察用户，并形成相应的运营策略以及产品体验的优化策略。比之将产品一捅到底后奄奄一息，合理的规划迭代研发将使你的产品呈现出更旺盛的生命力，这样才可能撑过你感叹的“身不逢时”。

当然从产品角度来看，我们必须肯定提醒代扣的战略意义，他将成为支付宝会员的理财管家，缴费、还款、充值、付款等等操作都可以在这个平台上进行定制，非常便捷，绝对堪称支付宝一款“伟大”的产品。但是再伟大的产品，在一个不适合的时间通过不恰当的方式诞生，也无怪受人唏嘘，唏嘘的绝非产品本身，而是产品的设计规划和研发模式，恩，设计师，你懂的！

作为一个非专业流程管理人员夸夸其谈了这么多，实感不易，不论说的怎么样，最后还是要总结呈词：产品灰度上线的研发思路，其好处就在于将原先一锅粥的需求按轻重缓急做了一个排序，并将原来一捅到底的研发模式合理的做了一个迭代的循环，即缩短了产品核心功能的上线的周期，又大大降低了未明需求情况下的资源浪费，可谓双赢。尤为重要的是，通过有计划的迭代开发，我们可以真正做到以用户为中心的设计理念。

纯属个人感触，有砖的尽管砸…

互联网产品的灰度发布

chuanliang — 2010-08-09 10:31:12

在传统软件产品发布过程中（例如微软的Windows 7的发布过程中），一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，涉及的用户数也是逐步放量的过程。

在互联网产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看，很符合中国人中庸的思维模式：自然界所有的事物总是以对称、互补、和谐的形式存在，例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中间色——灰色。于是出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐任正非：管理的灰度），灰色收入，灰色地带等等。因此对于灰度发布实际上就是从不发布，然后逐渐过渡到正式发布的一个过程。

1、灰度发布的作用

及早获得用户的意见反馈，完善产品功能，提升产品质量
让用户参与产品测试，加强与用户互动
降低产品升级所影响的用户范围
。。。

2、灰度发布的步骤

1）、定义目标

2）、选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等

3）、筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等

4）、部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调

5）、发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

6）、产品完善

7）、新一轮灰度发布或完整发布

3、常见问题

3.1）、以偏概全

1)、问题特征：

a、选择的样本不具有代表性；

b、样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能
2）、解决方案：

样本选择要多样化，样本的组合涵盖大部分核心功能

3.2）、知识的诅咒

”知识的诅咒“的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。

1）、问题特征：

a、结果没有量化手段；

b、只依赖于用户问卷调查；

c、没有web analytics系统；

d、运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

               e、对结果分析，只选择对发布有利的信息，对其他视而不见
          2）、解决方案：
               a、产品设计考虑产品量化指标
               b、结果分析依据量化指标而不是感觉

3.3）、发布没有回头路可走

1）、问题特征：

a、新旧系统用户使用习惯差异太大，没有兼容原有功能

b、新旧系统由于功能差异太大，无法并行运行，只能强制升级

c、新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在在新旧系统切换

d、新旧系统数据库数据结构差异太大，无法并行运行

2）、解决方案：

前期产品策划重点考虑这些问题，包括：

回滚方案、新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

3.4）、用户参与度不够

1）、问题特征：

                 a、指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能
                 b、互动渠道单一
                 c、陷入“知识的诅咒”，不尊重参与用户意见
        2）、解决方案：
                a、善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title
                b、通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
                c、提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

4、灰度发布 VS. A/B测试

灰度发布于互联网公司常用A/B测试似乎比较类似，老外似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义，A/B测试又叫：A/B/N Testing、Multivariate Testing，因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆，谈谈自己理解的两者的差异。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量

A/B测试重点是在几种方案中选择最优方案

关于A/B测试可以参考这篇文章：A/B测试终极指南

5、灰度发布引擎

对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

6、参考文档