产品管理：互联网产品发布方式

2016-12-30 09:36:00

产品上线与产品经理有关系吗？给人的第一感觉就是上线不是技术负责的吗？产品经理也不懂服务器软件部署，也不懂如何更新打包代码。难道说产品经理真地能够逃过上线发布的环节吗？互联网/软件行业的产品上线发布本质上就是产品的迭代升级，而产品迭代更新构成了产品经理的核心工作范畴。

互联网/软件产品提倡敏捷开发、快速迭代，随之而来的是用户高频率的产品更新。产品尝鲜者总是先于普通用户并且乐意去升级更新手头的应用软件，而大多数用户并不喜欢新版本的应用，甚至满腹抵触的情绪。当然，我本人是很喜欢第一时间去体验最新版本的更新服务的，都是第一时间更新各类APP新版及最新系统。大家都不太愿意相信：毫无意义的应用版本升级只能损耗用户的耐心、让用户心生厌倦。

面对升级新版，用户很难始终保持开放/接受的态度，以下所述问题应该被重视：

不痛不痒的功能更新，难以激起用户的兴趣和激情。
升级新版意味着变化，破坏固有习惯，强迫用户付出额外的时间学习适应。
强制升级，不升级将无法使用，强迫感太明显、太暴力，直接伤害用户情感。
变化诱发了潜在的不稳定——新版本无法正常运行，存在兼容性问题。

用户内心希望产品越发丰富实用，而人性的本质却是懒惰、安逸，需求与人性之间形成了第一组矛盾。产品经理的核心工作是不断的推陈出新、更新迭代产品，产品职责与用户需求形成矛盾另一组矛盾。

一句话概括：两个对象，两组矛盾。

（PS：两个对象——目标用户和产品经理；两组矛盾——以上已经做了说明。）

需求变更、技术进步、市场演变，一切都在不断变化。产品应该与时俱进，配合时代的需要，置于更为宽泛的场景，满足用户的诉求，创造衍生价值。鲁迅先生曾说过：倒洗脚水不要连孩子一起倒掉，因为部分用户的反感就放弃对产品的更新，显然有些激进，而应该以更加谨慎、理智对待产品的迭代更新。

互联网初期，网络媒体远不如今日。由于信息不对称，出现问题的影响程度可以得到有效的控制，大可不必给竞争对手钻了空子。社交新闻媒体高度发达的互联网时代，再怎么微不足道的消息也能瞬间弥漫全球。如果新产品存在问题，没能及时补救，积攒多年的口碑可能毁于一旦！

大众互联网产品/服务以广泛的目标人群为生存根基，因而对用户有极为广泛的影响，无论好坏。能力越大，责任越大。互联网产品/服务公司愿意采用【平滑部署】的产品发布模式，得益于该模式一定程度上能减少版本更新的衍生风险。

产品过程中，我大多采用一些非技术手段规避主观因素。

以公告、APP推送、短信等方式预先通知用户，而更新内容说明基本被用户忽略，效果有限；
严格控制产品测试质量，加大测试强度，确保更新可靠性，避免上线后再返回旧版本的尴尬；

产品部署中，除了产品经理力所能及的非技术性过渡手段外，技术层面也可以引入灰度发布的方式。

名称解释：灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。——来源《百度百科》

灰度发布的产品部署方式按照不同目的可以分为： AB测试、平滑部署、区域性部署、增量发布，以上均为我常采用的产品发布技术方案。其实，有关灰度发布的知识相当丰富，下面只是做一个简要的概述，并没有深入研究。如果大家感兴趣，可以进一步探讨学习。

页面/流程设计两个或多个版本（A/B/n），同时随机让一定比例用户体验，比较各个版本的使用效果量化数据，选择效果最好的版本作为正式应用发布给所有用户。
平滑部署被称为并行发布，本质也是A/B测试的一种变式。保留新、旧版本同时在线运营，给用户预留学习、适应新版本的时间，等用户适应了新版本，再将旧版本下线。
区域性部署强调的是由小范围部署逐步部署到更广范围，分割扩大发布区域，尊崇一种循序渐进的理念，与精益创业中提倡的Small Release的要义是完全一致的。
增量发布将所要发布的功能本身进行分割发布逐步发布，延续了SCRUM的增量迭代的概念，注重更新的节奏，确保产品的稳定性。稳定性先于新功能，一种保守的产品发布态度。

产品经理、技术开发两方以各自的方式减小了产品发布的风险，这一点让人很愉悦。凡是都是有代价的，凌驾于用户之上的风险全部转化为产品、技术、测试等相干人员背负的压力。运营内容的投入、测试的高强度调试、技术开发的多版维护都是无形的成本，那么为什么要采用不同发布方式呢？