Indigo 的数字镜像

Web 应用服务先行者 37Signals，是一家位于芝加哥的小公司，他们提供订阅收费的软件服务（面向中小企业和团队的在线协同服务软件，Basecamp 和 Backpack），而不是传统的打包出售软件，现在已经有超过50万的用户在使用他们的软件服务，同时还提出了一套颠覆传统的研发方式和经营理念 —— 贵在神速，小即是美。37Signals 在引领新网络应用的潮流，拥抱开源（让 Ruby 这个被冷落的语言成为了大家关注的焦点）、宣扬概念（Ajax、ROR 模式）、成功的实现了服务订阅收费的盈利模式，最后还有教育大众。他们周游各国，举办各种网络技术的研讨会，并推荐他们的成功宝典《Getting Real》。商业周刊中文版将书名翻译成《把握现实》，是否合理，大家读过之后就能体会。

我觉得每个准备或者已经投身到 Web 2.0 服务开发中的团队都应该倾听一下成功者的经验之谈，无论你是否认可，Getting Real 告诉我们了走向 Web 开发成功的过程，而不是最终结果。至少我觉得它能够让我们更加专心的完成一个目标，不会把时间浪费在繁杂的规划、设计、沟通和实现之中。

Getting Real – The smarter, faster, easier way to build a successful web application

如果你是一位企业家、设计师、程序员或市场人员，如果你有一个伟大的想法，当你发现那些旧的软件开发流程、模式和经验已经无法适用时，你应该看看这本书。Getting Real 将告诉你：

• 为什么保持小巧是一件好事
• 尽量少做功能
• 如何快速的从想法变成现实
• 如何搭建你的团队
• 为什么需要从外在的设计开始
• 为什么书写至关重要
• 如何推广你的服务
• 还有更多…

现在 37Siganls 已将在网络上发布了 Getting Real 的免费版本，优秀的成功经验终于可以和大家分享了。我将完整的学习笔记内容在这里整理出来，其实也不能算是”笔记”了，应该叫做原文内容的”概要翻译”，希望能够用简洁的表达形式将原书内容的精髓传达给大家。

• 设定你的起跑线
  先满足自己的需求、从自己的投资开始、限定时间和预算、设定一个假想敌
• 保持精简
  保持小规模和低成本、开发三人组、做回你自己
• 学会把握优先级
  抓住最主要的想法、在初期要忽略细节、找对你的用户群、以后再考虑扩展性、让你的软件保持风格
• 功能选择
  先实现最关键的功能、从说不开始、做你可以控制的事情、给用户最大的自主权、问问用户不需要什么
• 执行过程
  让你的软件尽快地运行起来、用跌代的方式开发、从想法到实现、真实测试、缩短计划周期
• 团队组织
  尽可能的整合人员、提供独立的时间、避免会议、庆祝小小的胜利
• 关于雇员
  尽可能的少雇人、炒掉不合格的人、雇佣能力全面的人、不要只说不做、你需要”语言大师”
• 界面设计
  界面优先、核心式设计、注意初始化界面、防止错误的设计、文字也是界面、统一界面
• 关于编码
  小巧的软件、为快乐而编码、倾听你的代码、使用开放的格式
• 关于文档
  不需要冗长的功能说明、给我讲述一个故事、使用真实的内容、拟人化的产品
• 服务定价
  提供免费使用、避免长期的租约、制定有弹性的价格策略
• 产品推广
  好莱坞式的产品发布、建一个强大的推广网站、利用BLOG来宣传、以教育的方式推广、跟踪用户的访问记录、取一个有吸引力的名字
• 用户支持
  感受用户的痛苦、零培训、快速解答、坚持自己的原则、将失误公诸于众
• 产品推出之后的工作
  每月更新、持续更新Blog、不要拿”beta”当借口、不要对”bug”一视同仁、关注你的竞争对手

以上基本就是 Getting Real 这本书的全部内容了，由于自己也没有什么成功经验可以分享，学习笔记就成了简要翻译，完整的内容还请大家阅读英文原版，或者支持一下 37Signals ，购买一个PDF版本（很有意思，购买了之后PDF的每一页下面都有你自己的名字）。

一个月的调整期：在你推出产品之后，每隔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），但是它的创建者却发现它在分享照片的特性上已经超过了它的游戏性，于是就有了现在的最著名的照片分享服务。因此，你应该像一个 冲浪者那样，跟着下一个浪尖前进。

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)