从腾讯的“灰度机制”到产品的“灰度上线”，你了解多少？

　　灰度：使用黑色调表示物体，即用黑色为基准色，不同的饱和度的黑色来显示图像。每个灰度对象都具有从0（白色）到100（黑色）的亮度值。（注意这个百分比是以纯黑为基准的百分比。与RGB正好相反，百分比越高颜色越偏黑，百分比越低颜色越偏白。科普一下：RGB即Red红色、Green绿色、Blue蓝色。RGB色彩模式是工业界的一种颜色标准，是通过红（R）、绿（G）、蓝（B）三个颜色通道的变化以及它们相互之间的叠加来得到各式各样的颜色的，这个标准几乎包括了人类视力所能感知的所有颜色。）
　　简而言之，灰度指不饱和的黑色。
　　自然界中的大部分物体平均灰度为18。我们平常所说的黑白照片、黑白电视，实际上都应该称为灰度照片、灰度电视才确切。灰度色中不包含任何色相，即不存在红色、黄色这样的颜色。
　　以上可以认为是废话，转入今天的标题。
　　2015年5月31日，马化腾在香港大学李兆基会议中心大礼堂举办了一场创业演讲，演讲中爆了一个大料：微信的诞生史。
　　微信在诞生之前，在腾讯内部有三个团队在同时做微信，主要竞争者为张小龙的email团队和手机QQ团队。做这个产品之前，腾讯内部并没有给这个产品定一个完整的基调，而是让公司内部形成一个激烈的竞争，通过观察用户对产品的喜好程度和产品的实际完成情况决定上线结果。
　　马化腾的灰度机制是这样的：很多公司在一开始做产品定义时，要么确定它是黑的，要么确定它是白的。但是马化腾发现，互联网产品的定义是有用户投票决定的。在一开始，我们不定义它是黑，还是白，有一个灰度的周期。在这个灰度周期里，让用户的口碑决定它是生是死，是白还是黑。
　　说的再直接点，这也是马化腾创新上的灰度机制：容忍失败，允许适度浪费，鼓励内部竞争内部试错。马化腾说过，在产品研发过程中，我们还会有一个困惑：自己做的这个产品万一失败了怎么办？“我的经验是，在面对创新的问题上，要允许适度的浪费。怎么理解？就是在资源许可的前提下，即使有一两个团队同时研发一款产品也是可以接受的，只要你认为这个项目是你在战略上必须做的。很多人都看到了微信的成功，但大家不知道，其实在腾讯内部，先后有几个团队都在同时研发基于手机的通讯软件，每个团队的设计理念和实现方式都不一样，最后微信受到了更多用户的青睐。你能说这是资源的浪费吗？我认为不是，没有竞争就意味着创新的死亡。即使最后有的团队在竞争中失败，但它依然是激发成功者灵感的源泉，可以把它理解为内部试错。”
　　总结一下，马化腾的“灰度机制”包括7个维度：
　　具体内容，请参考：《马化腾致信合作伙伴：灰度法则的七个维度》
　　需求度：用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度；
　　速度：快速实现单点突破，角度、锐度尤其是速度，是产品在生态中存在发展的根本；
　　灵活度：敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要；
　　冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功；
　　开放协作度：最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新；
　　进化度：构建生物型组织，让企业组织本身在无控过程中拥有自进化、自组织能力；
　　创新度：创新并非刻意为之，而是充满可能性、多样性的生物型组织的必然产物。
　　下面说说灰度上线
　　楼主在去哪儿工作时，发现自己和同事手机里的APP展示页面不同，于是就问什么情况，为什么没有自动更新。PM告诉我是ABtest，当时还不知道什么意思。
　　先来看看百度百科的定义：
　　灰度发布：是指在黑与白之间，能够平滑过渡的一种发布方式。ABtest就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
　　传统的产品研发模式大致可以分为：
　　产品调研架构评估产品启动需求分析产品设计产品开发产品发布
　　七大阶段。
　　实际情况中，你会发现，从产品调研到产品发布，总是一拖到底。这样的做法对于范围比较大，周期比较长的项目，尤其是用户体验类项目而言，存在较大的弊端：我们很可能在没有足够清楚用户需求的情况下，定制了过多的辅助功能，这样即拉长了项目周期，又无谓的投入了过多的人力。
　　灰度上线，简单点理解就是按产品需求优先级，抽出核心需求，在满足用户基本要求的情况下快速上线，并通过限制流量、白名单等机制进行产品试用，以此收集用户的意见，从而萃取出用户潜在的需求，形成后续更有针对性的设计方案。
　　和传统研发模式相比，这么做唯一的区别就在于将原先一锅粥式的需求和功能点进行了轻重缓急的排序，并以此将项目从原来的单长线作战转化为多迭代短线循环，让产品的生命周期不再昙花一现。
　　如此一来，需求分析阶段显得尤为关键，我们必须清晰的将需求按优先级归纳分类为几个序列，如：p1，p2，p3核心功能和必备的体验在p1序列，辅助功能点和辅助型体验列在p2序列，争执不定的需求点可以放在p3序列。需求排序后，我们可以将项目发布点有序的分成（2期），第一期只确保主要的核心功能和基础体验快速灰度上线，随后通过用户访谈、产品的session数据、业务数据等手段分析出用户对产品的真实反应，并以此调整二期需求，该加的加，该砍的砍，做到有的放矢。
　　下面是百度百科定义的灰度发布的步骤：
　　定义目标；
　　选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等；
　　筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等；
　　部署系统：部署新系统、部署用户行为分析系统（webanalytics）、设定分流规则、运营数据分析、分流规则微调；
　　发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表；
　　产品完善；
　　新一轮灰度发布或完整发布。
　　虽然，灰度、灰度机制、灰度发布之间的概念完全不一致，但是都包含着从黑到白的过程。所以，瞎扯了一通。