第章快速响应阶段

第25章　快速响应阶段　Rapid Response

产品出炉后切莫虎头蛇尾

我反复强调发布产品不等于大获全胜，交付产品后依然需要保持高度警惕。本章详细介绍产品交付后的收尾工作。

产品发布后，多数公司会迅速撤走为研发产品和发布产品整合的资源，急于投入下一个项目，殊不知此时正是收集反馈信息、改进产品的最佳时机。急于“撤军”是项目管理和产品开发流程中的大忌，只要稍微延长项目周期，观察用户对产品的反应，效果就会有天壤之别。这样做投资之小、回报之高会令你瞠目结舌，绝非其他项目阶段可比。

我向来坚持产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产品发布后的用户反馈意见。

快速响应阶段最早是针对大众网络服务的，因为大众网络服务特别重视用户的反馈意见。我相信它同样适用于平台产品、基础设施类产品、企业级产品。

即便建立了可靠的测试团队，在正式开发产品前严格测试原型，你依然无法预料所有的意外情况，有些问题发布后才会显露端倪。你可以坐等问题出现，按部就班地安排在下次发布时改进缺陷，但这样做的代价太高。

关键不在于是否会出现问题，而在于能多快解决问题。

评估产品表现应该使用明确的、可量化的指标。你最关心产品哪方面的表现，是页面访问量、注册用户数、访问停留时间、会员转换率、订阅数，还是广告收益？具体使用哪些指标取决于产品的商业目标。应该给指标分出轻重缓急，并保持关注。此外，对于什么样的结果代表产品成功，什么样的结果代表失败，应该做到心中有数。

如果产品是针对大众的网络服务，追踪用户的使用情况从来都不容易。还好如今有专业工具可以协助追踪用户行为，例如谷歌分析工具（http://www.google.com/analytics）可以快速清晰地展现用户使用网络产品的状况。

如果是企业级软件，我会派遣产品团队成员（产品经理、设计师、开发人员等）亲自上门为客户安装软件。这样做总能迅速发现、解决问题，因为他们明白不安装好产品就别想离开。

一旦问题反馈回来，产品团队（产品经理、交互设计师、主程序员、客户服务人员、市场营销人员等）应该至少每天召开一次简短会议，讨论问题的轻重缓急，确定最佳解决方案，比如，通过网站发布补丁，或是发表声明公示处理办法……如果团队事先做好心理准备，认识到快速响应阶段的重要性，大幅提高产品或服务的质量便指日可待了。

除了使用网站分析工具掌握用户行为外，还可以借助问卷调查、邮件讨论、留言板、现场测试等方式。我最喜欢察看网站分析工具提供的实时数据，例如，哪些页面最受欢迎，用户来自哪里，他们在网站上停留的时间，两次访问的间隔时间，还有页面访问量。此外，在快速响应阶段，客户服务人员、销售人员和合作伙伴的意见也不容忽视。