Getting Real 第一章
第一章 介绍
第一节 什么是 Getting Real ？###
想搭建一个成功的网络应用？是回归现实的时候了。 Getting Real 是用更小、更快、更好的方式来搭建软件。
- Getting Real 是跳过所有象征真实的事物（图表、曲线、方框、箭头、线框等）来构建真实。
- Getting Real 是做减法。更轻，更少的软件，更少的功能，更少的文档，更少的无关紧要的事物（大部分你认为必要，实际却不是的）。
- Getting Real 是维持小规模，保持敏捷。
- Getting Real 从界面开始，那个用户会真正使用的屏幕。它从用户的实际体验开始，并从这里向后搭建。这让你在软件出错之前获得正确的用户界面。
- Getting Real 是关于迭代和降低改变成本。Getting Real 是关于发布、调整，和持续改进的，使之成为一个构建网络软件的完美方法。
- Getting Real 只提供客户需要的，摈弃他们不需要的。
Getting Real 的好处
Getting Real 逼迫你处理那些真正需要解决的问题，而不是你对于这些问题的想法，因此能够提供更好的结果。它逼迫你面对现实。
Getting Real 倾向于构建真实的界面，摈弃功能规格书和其它的临时文档。功能规格书是虚假的，是达成一致的幻觉，而一个实际的网页才是现实。这是你的用户将要看到并使用的。这才是重要的。Getting Real 能让你更快做到这点。这也意味着你是基于实际情况来做出决定，而非抽象的概念。
最后，Getting Real 是适用于网络软件的一个理想途径。把软件装在盒子里售卖，每个一两年发布一个更新，这种过时的模式已经逐渐淘汰。与需要安装的软件不同，网络应用能够以天为单位持续进化。Getting Real 利用这种优势，充分发挥网络应用的价值。
如何写出有活力的软件
有活力的编写是简洁的。一个句子不应包含无用的词汇，一个段落也没有无用的句子。同样的原因，一幅画不该有多余的线条，一台机器不需要无用的零件。这不是要求作者将所有的句子缩短，或者只描述概要而忽略细节，而是要让每个词都掷地有声。
—— from "The Elements of Style" by William Strunk Jr.
不再膨胀
老方法：冗长、官僚、人人都明哲保身的流程。典型的结果：膨胀，表现平庸、过目即忘的软件。让人恶心。
Getting Real 能够避免 ...
- 长达数月甚至数年的时间表
- 不切实际的功能规格书
- 可扩展性的争论
- 无休止的员工会议
- 雇佣大量员工的伪需求
- 毫无意义的版本号
- 想完美预测未来的蓝图
- 无尽的偏好设置选项
- 将技术支持外包
- 不现实的用户测试
- 无用的文档
- 至上而下的管理层级
要开发一个伟大的软件，你不需要巨额的资金，庞大的团队，或冗长的开发周期。这些只会产生缓慢、晦涩、单调的应用。Getting Real 采用完全相反的途径。
**在本书中，我们将向你展示 ... **
- 经营哲学的重要性
- 为何小就是好
- 如何做减法
- 如何快速地从想法过渡到现实
- 如何配置团队成员
- 为何应该由内而外地设计
- 为何写作是至关重要的
- 为何要比竞争对手做的少
- 如何传播信息，推广你的应用
- 技术支持的秘密
- 在发布后继续保持势头的技巧
- 以及更多的 ...
我们将关注于宏观的概念。不会让你陷入代码的细节或是 CSS 的技巧。我们会围绕于驱动 Getting Real 进程的主旨和哲学。
本书适合你吗？
你是一个企业家，设计师，程序员，或市场营销人员。
你意识到旧规则已不再适用。每年通过 CD 来发行你的软件？2002 这个版本号怎么样？将这些抛到窗外。你需要搭建、发布、调整，然后重复上述步骤。
或者你对敏捷开发和商业结构还不熟悉，但你渴望了解更多。
如果这些听起来像你，这本书就是适合你的。
备注：虽然本书的重点是如何搭建网络应用，但其中的许多观点也适用于非软件领域。无论你正在开展一项业务，写书，设计网页，录制专辑，或从事其它的活动，书中关于小团队、快速原型、期望迭代，以及许多其它的观点都能给你一些指引。一旦你将 Getting Real 应用于生活中的某个方面，你就会发现这些概念能够适用于广泛的领域。
第二节 关于 37signals
我们做什么
37signals 是一个小团队，我们创造简单、专注的软件。我们的产品帮助你更好地组织协作。超过 350,000 的个人和小企业使用我们的网络应用来完成工作。华尔街日报的 Jeremy Wagstaff 写道，“37signals 的产品简洁、美丽、优雅、直观，与之相比，Outlook 的界面看起来就像是一个审讯室。”我们的应用绝不会让你受此折磨。
我们的行事方法
我们认为软件太复杂了。太多的功能，太多的按钮，太多需要学习的内容。我们有意地让产品比竞争对手做的更少。我们的产品工作起来更智能，感觉更好，能让你按自己的方式来做事，也更容易使用。
我们的产品
截至本书的发行，我们一共有五个商业产品和一个开源框架。
Basecamp 把项目管理作为首要功能。Basecamp 提供了 留言板，待办事项，简单的行程安排，协同写作，文件分享，以此来取代甘特图，华丽的曲线、沉重的电子表格。目前，成千上万的人都认同这是一个更好的方式。Salon.com 的 Farhad Manjoo 说，“Basecamp 代表了网络软件的未来。”
Campfire 为商务场合提供简单的群聊功能。企业知道持续稳定的实时群聊有多重要。传统的即时通讯工具在应付快速的一对一聊天时是很好的，但面对三人以上的场景就很糟了。Campfire 解决了这个问题但不止于此。
Backpack 是一个个人信息管理工具，用于替代那些复杂且令人困惑，“用 25 个步骤管理人生”的软件。在一个苦于维持现状的类别里，Backpack 给页面、笔记、待办事项、基于电话/邮件的通知带来了一种全新的理念。华尔街日报的 Thomas Weber 说这是该类别里最好的产品，纽约时报的 David Pogue 把它称为一个 “非常酷”的组织工具。
Writeboard 让你撰写、分享、修订，将文字与自己的或他人的作品进行比较。对于一个臃肿的文字处理软件，95% 的功能对你的写作是无用的，Writeboard 是一个新鲜的替代品。Daring Fireball 的 John Gruber 说，“Writeboard 可能是我见过的最清晰、最简洁的网络应用。” 网络专家 Jeffrey Zeldman 说，“37signals 的天才们又一次做到了。”
Ta-da List 在线存储并管理你的待办列表。你可以自己保存列表，或分享给他人进行简单的协作。没有比它更简单的方式来把事情搞定。迄今为止，已经创建了超过 100,000 的列表和将近 1,000,000的项目。
Ruby on Rails，对开发者来说，这是一个基于 Ruby 的全栈式的开源网络框架，可以快速、方便地开发出真实的应用。Rails 帮你解决那些繁杂的工作，这样你就可以专注于思考。O'Reilly 出版集团的 Nathan Torkington 说，“Ruby on Rails 令人震撼。使用它就像在看一部功夫电影，一群流氓框架想要痛打这个新人，却被各种充满想象力的方法修理了一顿。” 非常喜欢这个说法。
你可以在 www.37signals.com 上找到更多关于我们产品和公司的信息。
第三节 注意事项、免责声明、及先发制人
为了提前扫清障碍，以下是我们经常遇到的一些抱怨：
这些技术不适合我
对我们来说，Getting Real 是一个工很好的系统。也就是说，书中的观点不可能放之四海皆准。如果你在建造武器，核电站，应付百万客户的银行系统，或其它关乎生命/财产的系统，我们的某些自由的处事态度对你是有害的。继续前进，并采取一些额外的预防措施。
这不是一个非黑即白的命题。即使你无法完全接受 Getting Real 的方法，还是悄悄地使用其中一小部分观点。
点子不是你发明的
我们没有申明自己发明了这些技术。许多概念都以某种方式存在了很长的时间。如果书中的某些观点是你很早之前就接触过的，不要发怒，这完全可能。这些技术不是专属于 37signals 的。我们只是将我们工作和成功的经验告诉你。
你的许多观点太绝对了
如果我们的语气太自大了，请原谅。我们认为观点应该大胆地说出来，而不是畏畏缩缩。如果这看起来骄傲自大，那就让它去吧。我们愿意激进一些，而不是和稀泥，事事都要依情况而定。当然，这些规则有时需要扩展或打破，有些策略可能也不适用于你的情况。请运用你自己的判断和想象力来决定。
这不适用于我们的公司
你认为你的公司太大了，不能回归现实？即使微软也可以做到（我们怀疑你会比微软还大）。
即使你公司的发展是基于庞大的团队和长期的规划，还是有一些方法可以让你回归现实。第一步就是分散成小团队。太多人参与会导致一事无成。更精简一些，事情就能更好更快地完成。
当然，这需要一些推销能力。让你的公司进入 Getting Real 的流程。向他们展示这本书，展示你用更少的时间和更小的团队所获的的成就。
向人们解释，Getting Real 是一个测试新概念的低风险，低投入的方法。
或者，如果你有胆量，可以采取秘密行动。Start.com 团队就是用这种方法在微软悄悄地执行 Getting Real 。“我们看过 Start.com 团队的工作，他们没有征求许可。” Robert Scoble 如是说，他是微软的技术传道者。“他们的老板提供空中支援，他们一次只吃一小口，然后执行，作出反馈。”
发布微软的 Start.com
在大公司里，流程和会议是司空见惯的。人们花费数月的时间来讨论功能和细节，期望所有人能够达成一致，确定什么对用户是“正确”的。
对于塑料包装的软件，这个方法可能是对的，但是网络有惊人的优势。只要发布就行。让用户来告诉你这是不是正确的，如果不是，你甚至可以在发布的当天就作出修正。用户的话语是最重要的，抵制冗长的会议和讨论。
知易行难，这意味着：
- 不需要长达数月的计划
- 不需要在撰写规格书上耗费几个月的时间，应该在开发的过程中确定基础，敲定细节。不要在开发前尝试结束任何开放的问题，确定所有的细节。
- 发布高质的，少量的功能
- 你不需要一个包含众多功能的大更新。慢慢来，让用户能够消化。
- 如果有一些小 bug ，一旦确保核心功能是完好的就可以发布产品，之后通过网络来修复 bug 。尽快获得用户的反馈。纸上谈兵或许听起来不错，但实践结果未必如此。对于根本问题，越快发现问题越好。
- 一旦你快速迭代，对客户反馈作出回应，你就建立来客户联系。记住，你的目标是通过搭建客户需要的东西来赢得客户。
