Getting Real 学习笔记：产品上线之后的工作

一个月的调整期：在你推出产品之后，每隔30天给你的产品来个主要的 升级。这样快速的升级将会带给你动力，也意味着你在倾听用户的意见。你可以在这样后续的升级之中来完善推出之前没有做好的关键模块，持续修补并增强产品的 核心功能。这样可以让你的产品保持新鲜，每一次升级都会成为大家谈论得焦点，人们会在他的BLOG和各种地方为你做宣传，这样你可以更加有效的获得用户的 反馈，并且能够知道下一个主要改进的方向。
持续更新你的BLOG：用你的开发BLOG告诉你的用户，你还在积极地开发产品。一个开发BLOG能够带给用户更加亲近产品的感觉，因此你需要经常的更新BLOG，至少每周一次，或者更频繁一点。你的开发BLOG主要包括以下内容：
常见问题解答 使用教程和指南 使用技巧与提示 新特性介绍、升级说明和得到修正的错误 官方的新闻发布 别人是怎样评价你的产品的
BLOG不仅仅表示你在积极地开发产品，还能够让你的公司更加亲近用户，在这里你可以把用户到做朋友，彼此之间能够真心交流。
不要拿”beta”当借口：最近好像受到了 Web 2.0 和 Google 的影响，所有的产品都处于 beta 阶段。beta 意味你的产品还没有最终完成，就像在对用户说：“你来用吧，它还不完美，如果除了问题不是我的错”。要面向用户推出产品，还是要发布最终正式版，但是一个 内部的beta 测试还是必要的，你可以邀请用户请入，但不要对所有用户开放。最终的发行版本不是在你推出 beta 之后等来的，你需要从用户那里获得反馈，改进产品，直到你认为可以发布正式版本了。
不要对”bug”一视同仁：不要因为你产品的 bug （小错误）而显得惊慌失措，所有的软件都会有 bug，这就是现实。你不可能在短时间内修复所有的 bug，并不是所有的 bug 都是具有危害性的，可能很多只有有一点点烦人而已，你把他们记录下来就行，并标记上严重程度（有很多优秀的 bug 跟踪软件，例如bugzilla、trac 等）。如果是一个导致你的数据库崩溃的错误，那就应该立即解决。还有一点就是要通过用户的反馈来收集 bug 所影响的用户数，如果波及面很广，那就是优先级高的 bug，应该尽快修复。不要营造一个恐惧 bug 的氛围，要让用户理解为什么会有这些问题，你需要尽快地给用户关于错误的反馈，告诉他们你已经在处理这些问题了，真诚的面对用户才是最好的方法。
安然的度过困难：当你推出一个新的特性、改变一个规则或者是移除了 一格功能，通常都会有突如其来的反应，而且还是负面的。这时你只需要静观其变，等到平静之后再采取行动。用户在看到变化时，最初的反应都会是很激烈的，这 会持续24-48个小时，用户在此期间会去体验新的特性（或者是习惯已经移除的功能），当这段时间度过之后，你就可以给出更加合理的回应，而不至于显得太 突然。
关注你的竞争对手：订阅关于你的竞争对手的新闻，这通常是了解你竞 争对手的最好方法。利用PubSub、Technorati、Feedster 等服务，你只需要使用对手产品的关键词、例如公司名和产品名，就能够很容易的获取到对手更新 RSS 的订阅，这些更新可能来自于BLOG、新闻报道或者是其他的讨论话题，你能够在第一时间内掌握对手的动向。
当心功能的臃肿：更加成熟并不意味着更加复杂。如果你的用户只喜欢 在浅水区游游泳，你就不需要设计一个能够在5000米水下都能够工作的深水手表给他们。更新并不是一定要增强或者是添加新的功能，保持现有功能的稳定和易 用才是一款成熟产品应有的风格。这也是基于Web的软件和传统的桌面软件最大的区别，像 Micorosft、Adobe 这样销售桌面软件的公司必须每年推出新的版本才能保证自己的销售利润，要让用户接收新的东西，就必须用新的功能区吸引用户，最终导致80%以上的功能对大 多数人都是无用的。Web 软件使用付费租用的模式，每月支付费用来使用，你不需要用新的功能区吸引他们继续购买，只需要保证现有的功能稳定就行。
顺其自然：Web 程序最美妙的地方就是它的可变性。你不需要包装它、运输销售它、等着下一年再推出新版本。Web 程序可以在你需要的时候随时去调整它，可能你最初的产品都不是你预想中最好的那个。看看filckr，它最初是被设计成为一个多人的在线游戏（名字叫做 The Game Neverending），但是它的创建者却发现它在分享照片的特性上已经超过了它的游戏性，于是就有了现在的最著名的照片分享服务。因此，你应该像一个 冲浪者那样，跟着下一个浪尖前进。