互联网产品的灰度发布简介

作者:课课家更新于： 2015-11-09 10:38:48

在众多学习中，文章也许不起眼，但是重要的下面我们就来讲解一下！！今天的产品运营的知识数不胜数，大家感兴趣的话，可以过来看看，具体内容如下：产品包装

在传统软件产品发布过程中（例如微软的Windows7的发布过程中），一般都会经历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）、以偏概全

用户运营是指，以网站或者产品的用户的活跃、留存、付费为目标，依据用户的需求，制定运营方案甚至是运营机制。用户运营已经扩展到针对不同类型的用户进行有针对性的运营策略的阶段。
简单来说就是引入新用户、留存老用户、保持用户活跃、促进用户付费、挽回流失或者沉默的用户。用张亮的一张图总结：
一篇文章让你知道什么是运营！
首先要掌握自身用户的用户结构，比如男女比例、年龄层次、身处省市、受教育程度、兴趣点；
其次要了解用户规模以及增长或衰退情况并进行适当的用户分级，比如新用户多少、老用户多少、每日增长规模、用户处于怎样的生命周期；
最后要熟练掌握用户行为数据，并通过数据分析，懂得用户为什么来、为什么走、为什么活跃、为什么留存；对新用户增长，已有用户的活跃和留存，活跃用户促付费，流失用户的挽回都有对应的措施。
开源
注册渠道和注册方式的影响：
产品本身的注册方式：手机、邮箱；
联合登陆再绑定资料，注册转化需要做好；网络运营
注册以及注册后的引导流程：图文并茂地引导用户从哪里开始、怎么玩；
节流
流失的标准：多久没登陆意味着流失；建立用户行为模型，管理用户的生命周期；
流失预警：流失前用户进行了哪些类似行为，这些用户有哪些共同特征，产品是否更改了核心功能；
用户挽回：通知用户（通知渠道、效果评估）、告诉用户新功能新改进等、挽回的用户更需要关怀；
促活跃
留下来不代表是活跃的，哪些行为标识出用户是否活跃，如何促进这些行为
转付费
通过机制让已付费的持续付费
通过一系列行为让活跃用户付费
提需求的成本主要分为2大部分：需求沟通成本，需求开发成本
沟通成本就是运营提出需求后，跟技术（策划）一起沟通，哪些要做，哪些不做，哪些需要调整的过程。
常规的需求，开发成本就2条：人力成本（谁做），时间成本（做多久）。操作的复杂程度不在成本的考虑范围内，可以归结为时间成本。
如果开发成本比较高，花一些时间在沟通上是有价值的。如果开发成本很低且无风险，却花了很多时间用来确定沟通要不要做，那就是浪费时间。
替代品
所有需求的出发点都是目的，为了实现目的，我们想到了一种手段，这个手段在实现上需要一些道具或者逻辑来支持，才有了需求。
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 。
   大家学到了多少？如果意犹未尽，可前往课课家官网直接查看，希望大家获益匪浅哦！！！