今天继续为大家更新《启示录-如何打造用户喜爱的产品》
第24章 平滑部署
Gentle Deployment
避免更新产品导致用户反感
毫无征兆地更新不必要的版本会令用户产生反感。有件事你可能觉得难以置信，但的确是事实：不是所有用户都喜欢新版本的产品。用户产生反感主要有以下几个原因。
1. 事前没有收到更新通知，用户觉得措手不及。
2.用户没时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用。
3.新版本无法正常运行。
4.新旧版本不兼容(比如新版本无法访问旧版本的数据)。
5.虽然新版本可以正常运行，但用户认为添加的功能和特性毫无必要。
6.应付接二连三的版本更新，用户感到疲惫不堪。
7.新版本修改了用户已经习惯的使用方式和操作流程，用户不得不重新调整适应。
通常情况下，用户不喜欢变化。虽然他们也希望产品更完善，功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。
然而我们的工作要不断地推陈出新，这就是矛盾所在。需求在更迭，技术在进步，市场在变化——软件也要与时俱进。产品团队不得不挖空心思、不遗余力地为用户完善产品功能、创造新的价值。
我们不能因噎废食，不能因为用户可能反感就放弃更新产品，但是更新产品时必须谨慎、理智。
发布1.0版本的产品是最轻松的，因为用户对产品没有成见。虽然他们多少受到同类产品和服务的影响，但是总体而言你无须担心产品的历史兼容性，也不用考虑维护老用户的问题。
可惜我们不可能一直使用1.0 版本，更多时间里，我们不得不设法更新产品和服务。
过去信息不对称，就算软件公司发布了不兼容、“副作用”极大的新版本，也能轻易化解麻烦， 即便用户分别来投诉，这种抱怨也无法形成规模，不会给竞争对手可乘之机。然而，随着互联网的普及，产品的口碑无论好坏都会迅速传播。如果发布了糟糕的版本，没能及时补救， 那你就有麻烦了。
对大众互联网服务而言，这种威胁显得尤为突出。公司必须慎重考虑一举一动(尤其是版本更新)对用户的影响。我把合理地、审慎地更新产品版本的行为称为“平滑部署”。
为了将版本更新带来的负面影响降到最低，可以采取以下几种措施。
1. 通过公告、群发邮件、在线教程等方式提前通知用户，但是很多人既没时间也没兴趣阅读这些内容，所以这个方法效果有限。
2. 加倍做好测试.工作，避免新版本存在影响正常使用的隐患，比如可靠性问题、扩展性问题、性能问题。确保将来不会陷入被迫返问旧版本的窘境，为用户增加不必要的麻烦。
3.如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险。
平滑部署的方式很多，比如发布两个并行的版本，邀请有兴趣、有时间的用户试用新版本。如果新版本运行正常，大部分用户习惯新版本后，再将新版本设为默认版本。同时将旧版本保留一段时间，公示为旧版本提供支持的最后期限， 以便没来得及习惯新版本的用户在这段时间内能照常使用产品。对于用户数量庞大的服务和产品，这个过渡可能需要几个月的时间。产品经理还要准备好承担来自开发团队和运维团队的压力，毕竟支持并行版本不是件容易的事。
另一种平滑部署的方式是区域性逐步部署，首先在某个区域内部署新版本，然后逐步扩大范围。还有一种方式是增量部
署，将更新项分割成几个较小的部分逐步发布。无论采用哪种处理方式，关键要全面考虑更新可能带来的“副作用”，为用户提供便利，方便他们在空闲时适应变化，同时尽可能降低新版本带来的负面影响。
优秀的产品和服务可以赢得用户的好感，这是宝贵的信任，应该小心保护。不要轻易试探用户的耐心，让好感变成反感。
第25章 快速响应阶段
Rapid Response
产品出炉后切莫虎头蛇尾
我反复强调发布产品不等于大获全胜，交付产品后依然需要保持高度警惕。本章详细介绍产品交付后的收尾工作。
产品发布后，多数公司会迅速撤走为研发产品和发布产品整合的资源，急于投入下一个项目，殊不知此时正是收集反馈信息、改进产品的最佳时机。急于“撤军”是项目管理和产品开发流程中的大忌，只要稍微延长项目周期，观察用户对产品的反应， 效果就会有天壤之别。这样做投资之小、回报之高会令你瞠目结舌，绝非其他项目阶段可比。
我向来坚持产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产品发布后的用户反馈意见。快速响应阶段最早是针对大众网络服务的，因为大众网络服务特别重视用户的反馈意见。我相信它同样适用于平台产品、基础设施类产品、企业级产品。
即便建立了可靠的测试团队，在正式开发产品前严格测试原型，你依然无法预料所有的意外情况，有些问题发布后才会显露端倪。你可以坐等问题出现，按部就班地安排在下次发布时改进缺陷，但这样做的代价太高。
关键不在于是否会出现问题， 而在于能多快解决问题。
评估产品表现应该使用明确的、可量化的指标。你最关心产品哪方面的表现，是页面访问量、注册用户数、访问停留时间、会员转换率、订阅数，还是广告收益?具体使用哪些指标取决于产品的商业目标。应该给指标分出轻重缓急，并保持关注。此外，对于什么样的结果代表产品成功，什么样的结果代表失败，应该做到心中有数。
如果产品是针对大众的网络服务，追踪用户的使用情况从来都不容易。还好如今有专业工具可以协助追踪用户行为，例如谷歌分析工具(http://www.google.com/analytics)可以快速清晰地展现用户使用网络产品的状况。
如果是企业级软件， 我会派遣产品团队成员(产品经理、设计师、开发人员等)亲自上门为客户安装软件。这样做总能迅速发现、解决问题，因为他们明白不安装好产品就别想离开。
一旦问题反馈回来，产品团队(产品经理、 交互设计师、主程序员、客户服务人员、市场营销人员等)应该至少每天召开一次简短会议，讨论问题的轻重缓急，确定最佳解决方案，比如，通过网站发布补丁，或是发表声明公示处理办法...如果团队事先做好心理准备，认识到快速响应阶段的重要性，大幅提高产品或服务的质量便指日可待了。
除了使用网站分析工具掌握用户行为外，还可以借助问卷调查、邮件讨论、留言板、现场测试等方式。我最喜欢察看网站分析工具提供的实时数据，例如、哪些页面最受欢迎，用户来自哪里，他们在网站上停留的时间，两次访问的间隔时间，还有页面访问量。此外、在快速响应阶段，客户服务人员、销售人员和合作伙伴的意见也不容忽视。
本次更新，在产品最终上线后，对于产品每次的迭代平滑部署以及发布后的快速相应都给与了具有实际性的建议，作为产品经理，要维护好和用户之间的关系，并珍惜用户对自己产品的信任。产品经理犹如一位全能的守护者，要全方面保护好自己的产品。
网友评论