Getting Real（推荐）

转自： http://cnborn.net/docs/getting_real/index.html#ch01

 

 

Getting Real

中文版最后修订： 2010年5月25日， CNBorn

• 引言
• 第二章 起跑线
• 第三章 保持精益
• 第四章 首要任务
• 第五章 挑选功能
• 第六章 操作
• 第七章 组织
• 第八章 人员配备
• 第九章 界面设计
• 第十章 编码
• 第十一章 文字
• 第十二章 定价和注册
• 第十三章 推广
• 第十四章 技术支持
• 第十五章 上线之后
• 第十六章 总结

 

---

引言 第一章

什么是 Getting Real?

想构建一个成功的Web应用么? 那么正是时候Getting Real. Getting Real 是一种更小规模，更快速，更高质量的软件构建方法。

• Getting Real是关于省略所有表达现实（图表，曲线，矩形，箭头，统计图），而构建现实。
• Getting real 是追求精炼。更少的代码量，更少的软件，更少的功能，更少的文档工作，更少无所谓的东西（而且大部分你认为必要的，其实不是）。
• Getting Real 是保持精益，变得敏捷。
• Getting Real从界面开始，也就是用户使用的屏幕。它从实际的用户体验开始，并且构建似曾相识的体验。这让你在软件误入歧途之前得到正确的用户界面。
• Getting Real 是关于迭代和降低变化成本的方法。Getting Real聚焦于上线、调整、持续改进，使得其成为开发Web软件的最佳途径。
• Getting Real只交付客户所需的，摒弃任何客户不需要的。

Getting Real的优点

Getting Real能够交付更好的结果，是因为它强迫你处理真正要解决的问题，而不是关于那些问题的空想。它迫使你面对当下。

Getting Real更注重实际的用户界面，而不是功能规格说明书和其他昙花一现的文档。只有当一个真实的网页呈现出来，相关的功能规格才是可信的，被证明是可接受 的。那才是是我们的客户将要看到和使用的。那才是需要关心的。Getting Real帮助你更快达到这个目的。并且那意味着你正在基于真实需求，而不是异想天开来构建软件。

最后，Getting Real是适合于Web软件的理想途径。那种把软件包装在盒子里，再等一年到两年才发布一个更新的学院派方法已经过时了。不像需要安装的软件，Web应用能够以天为单位持续改进。Getting Real利用了这种优势来提升Web应用的价值。

 

不再发胖

旧方式：冗长，官僚主义的，“我们正在这么做来控制这些蠢驴” 的流程。典型后果是：臃肿，过目即忘，平庸得掉渣的软件。Blech。

Getting Real 除掉...

• 花费数月，甚至数年的进度表
• 不切实际的功能规格文档
• 可伸缩性的争论
• 又臭又长的员工大会
• 大量招人的需求
• 毫无意义的版本号
• 憧憬完美未来的幼稚“路线图”
• 无穷尽的偏好设置选项
• 外包支持
• 不切实际的用户测试
• 写无用文档
• 自顶向下的管理结构

你不需要成吨的钞票或者庞大的团队或者漫长的开发周期来构建伟大的软件。那些正是缓慢，晦涩，变化成本高昂的应用程序的帮凶。Getting real反其道而行之。

这本书将带给你...

• 信仰之重要
• 为什么小是好事情
• 怎样构建更少
• 怎样从现实世界中快速找到创意
• 怎样培养团队
• 为何要由内到外的设计
• 为什么写作至关重要
• 为什么要比对手少做
• 如何升级你的应用和散播文字
• 成功维护的秘诀
• 发布后能够持续保持后劲的秘诀。
• 其他...

本书关注于理论高度。我们不会使你陷入代码片段细节，或者是CSS窍门。我们会坚守在驱动Getting Real过程的主要思想和价值观上。

本书适合你么？

你是管理者，设计师，程序员，或者市场人员。

你意识到旧规则不再管用了。每年通过光盘分发你的软件？2002这个版本号怎么样？

或者你对敏捷开发和企业组织结构略懂皮毛，但是热切的想多了解一些。

如果听起来你是其中之一，那么这本书就是为你准备的。

注意：虽然这本书着重在构建Web应用上，很多理念也可以应用到非软件活动。关于小型团队，快速原型，期望迭代，和许多提到的其他经验能够为你引 路。无论你正在开始一项业务，写一本书，设计一个网站,记录签名册，还是其他各种各样的活动。一旦你在你生活中的某一领域开始Getting Real，你就或发现这些概念能适用的非常广泛。

 

---

关于 37signals

我们做什么

37signals是一个创造简单的，专一的软件的小团队。我们的产品帮助你协同工作，组织团队。超过35000个人和企业使用我们的Web应用来搞定他们的业务。 来自华尔街杂志的Jeremy Wagstaff写到 “37signals 的产品是超简单，精致，直接了当的工具，这些工具让微软的Outlook软件使用起来像受刑 。”我们的软件不会把你推到这种境地。

我们的习惯做法

我们相信软件太复杂了。太多的功能，太多的按钮，需要学习太多东西。 我们的产品比对手做的少 — 故意地. 我们构建的产品运行灵巧，感觉舒适，允许你以自己的方式做事，并且容易使用。

我们的产品

当这本书出版之即，我们有5个商业产品和一个开源框架。

Basecamp 把项目管理作为首要问题。Basecamp提供了消息板，待办事宜，简单调度，协同写作，文件共享。 而不是甘特图，炫丽的曲线图，和繁重的电子表格。目前，成千上万的人同意这是一种更好的方式。来自Salon.com的Farhad anjoo说：“Basecamp代表了Web软件的未来。”

Campfire 提供了业务模式下的简单群聊方式。实时持久的群聊对于业务来说非常重要。传统的实时聊天对于快速的一对一模式很有效。但是对于3个或者更多的人同时聊天来说异常痛苦。Campfire解决了此问题和其他相关问题。

Backpack 是一种替代那些玄乎，复杂，“通过25个步骤管理人生”之类的个人信息管理系统的产品。Backpack在页面，笔记，待办事宜，电话和电子邮件通知上的 简单尝试，在受“statis-quo-itie”折磨的一类产品中，是一个独具匠心的创意。Wall Street Journal的Thomas Weber说它是同类产品中最出众的。 New York Times 的 David Pogue说它是一个“非常酷”的组织工具。

Writeboard 使你能够撰写，分享，修订，和比较自己或者他人的文章。臃肿的文本处理工具，对于你95%的文字是功能过剩的，而Writeboard是一个全新的替代品。Web-guru Jeffrey Zeldman说：“37signals 的天才思想王者归来。”

Ta-da List 维护聚合你的所有待办清单，并且以在线方式组织。为你自己维护待办清单，或者通过和其他人分享来协作。没有更好的方式来搞定这些了。迄今为止，其创建了超过100，000个清单和1，000，000项行动。

Ruby on Rails, 对于开发者来说，是一个用Ruby编写的全栈式的开源Web框架。其使得开发真是应用快速而简单。你可以关注在你的思想上面，而由Rails操心杂事。 O’Reilly的Nathan Torkington说：“Ruby on Rails太令人震撼了。使用它像是观赏一个功夫片，片中一堆流氓框架准备痛扁这个小新人，没想到却被各种充满想象力的方式揪住了屁股。”Gotta喜欢 这段话。

你可以从www.37signals.com找到更多关于我们产品和我们的公司的信息.

 

---

告诫，免责，和其他丑话说在前头

为了扫清障碍，下面是我们对于一些不时听到的抱怨的答复。:

"这些技术不适合我"

Getting real 是一套对我们来说效果非凡的系统。但是本书的思想并不是放之四海皆准。如果你正在构建一套武器系统，一个导弹控制设备，一个为数以百万用户服务的银行系 统，或者其他对生命、财产至关重要的系统，你将会回避一些我们的放纵主义态度。请继续前行并且采取一些其他的防范措施。

而且不必全部采纳或者全盘否定我们的主张。即使你没能力完全Getting Real，一定有少许观点你能够偷偷摸摸避开当权者而实行。

"这些思想不是你们发明的"

我们没有声明我们发明了这些技术。许多概念已经以各种形式伴随我们很久了。当你读到一些我们的建议，并且它提醒你读到 的一些东西已经在一些人的日记或者一些已经出版了20年的书里面了。这是完全可能的。这些技术并不是37signals的独创。我们只是告诉你我们怎样工作和是什么带给我们成功的。

"你们的观点过于绝对"

如果我们的口吻看起来好像无所不知，目中无人，请宽容我们。我们认为果敢地提出观点要比唯唯诺诺，模棱两可要好得多。 如果这是骄傲自大的形象，它就是。我们宁愿具有煽动性，也不愿意用“那要看…”这样的话来和稀泥。当然这些规则需要时间来完善或者打破。而且一些策略可能 不适合你的场合。请运用你的判断力和想象力。

"我们公司内部不适用."

觉得你的公司太大以至于难以Get Real？连微软也Getting Real（而且我怀疑你的公司更大）。

即使你的公司典型地执行长期，大型团队的调度计划，仍有方式Get real。第一步是分解成更小的团队。当太多的人牵扯进来，什么事都搞不定。你越轻装上阵，事情就做的越快越好。

没错，这需要一些推销潜质。让你们的公司投身于Getting Real过程中。给他们出示这本书。向他们炫耀你用更少时间和更小团队所得到的真实成就。

解释Getting Real是一种尝试新概念的低风险，低投入的方式。

如果你有勇气的话，秘密行动。在雷达下面飞行来证明真实结果。这正是Start.com团队在微软运用Getting Real的方式。“我观察过Start.com团队的工作方式，而他们没有经过许可”，微软的技术传播者Robert Scoble说。“他们有一个老板作为空中掩护。他们每次只接受一点功能，实现他们，并且响应反馈。”

 

---

起跑线 第二章

建构从简

做得比竟争对手少

常规的思维方式告诉我们，不管竞争对手做什么你总是要比他们加多一些。如果他们有4个特色功能，你就需要做出5个（或15个，或25个）。如果他们花了x，你就该花xx。如果他们有20，你就得有30。

这种强调更多一层的冷战竞争思维是行不通的死胡同。如此创造产品的方式是昂贵的，过分防御的，并且有点偏执不正常的。防御性的偏执的公司是做不到前瞻性思维的，他们只能做事后思维。他们不可能领导，只能跟从。

如果你只想创建一个随大流的公司，那么你现在就可以放下这本书，无需继续读下去了。

那怎样才是有效的方法呢？答案是：做少。靠做得比对方少来打败他。解决简单的问题，把繁复困难棘手的问题留给大众。不做更多，相反的我们做的更少。不赶超，相反的我们试着退一步，守后。

我们将会将贯穿全书论述“少做”的概念，现在先简要介绍“少做”的含义作为热身：

• 更少的功能
• 更少的选择项和首选项
• 更少的配备人员和企业架构
• 更少的会议和抽象讨论
• 更少的承诺

 

---

是什么问题一直困扰你？

为自己而做这个软件

一个很好的做软件的方式就是一开始用它来解决你自己的问题。由于你自己变成了软件的目标受众因此你会知道什么是重要的什么不是。这样做下去将会是推出一个突破性产品的伟大起始点。

关键是你要了解你并不孤单。如果你有一个困扰你的问题那么非常有可能成百上千的其他人业有同样的烦恼。这，就是你产品的市场。看，不难找到吧？

Basecamp这个产品来自于一个困扰我们的难题：做为一个设计公司，我们需要有一个很简单的方式来和客户做项目沟通。一开始，我们建了一个外部 网，通过不断更新其内容来连线客户。但每次一个项目需要更新我们就得手动更改HTML，这实在不是一个解决方案。这些项目网站总是看起来不错但最终总是被 放弃了。这是很令人恼火的，因为它使我们变得很没有组织性，也让客户感到无所适从。

于是我们开始寻找其他解决方案。但每样我们找到的工具都是 1)并不能做我们想做的 或 2)充斥着我们所不需要的功能 — 比如象账单，登录权限控件，图表，等等。我们觉得一定会有更好的方案，最终我们选择了自己来做这个软件

当你在做软件解决你自己问题的时候，你创造的工具是你对之有激情的。那激情就是关键所在。激情意味着你真正去用这个软件，去关心这个软件。这是能感动他人并一起为之所动的最好的方式。

 

---

找自己募资

外部资金只是第二条路(plan B)

很多创业者的首要任务就是找投资者募集资金。但必须记住，当你寻求外部资金的时候就意味着你不得不向别人汇报。于是别人对你的期望值将提升。投资者无不希望他们能够收回资金 — 并且是以最快的速度收回。导致一个不幸的事实就是往往抢钱优先过做一个优质的产品。

现时创业并不需要太多的启动资金。硬件便宜了，大量的优秀框架软件也都开源免费了。而且创业的激情是不需要标价的。

因此手头有多少钱就先动起来做多少事。用心想想决定什么是你最基本需要的，什么是可以先舍弃不做的。什么事是你可以三个人就搞定而不必用到十个人？什么是两万块而不用十万块就能办到的？什么样的软件你可以一边白天打工用业余时间做出来的？

资源拮据往往能激发想象力

当在有限的资源平台上运作，你往往会被迫更早的更紧迫的认识到这种压力。那是一件好事。有压力才会促使创新。

拮据也能迫你更早地将你的点子推出来 —这是另一件好事。这么跨出去一两个月后你就会比较清楚的了解这个点子是否有戏。这样一来，你就会在短时间内树立起自信心，不再那么急切寻求外部资金了。 如果你的点子行不通，是虚的（酸柠檬），那么就是重新来过的时候了。坏消息至少你现在知道比几个月后或几年后知道好。至少你比较容易退出。当有投资者涉入 的时候退出方案要复杂的多了。

如果你做软件只是想搞一度快钱，那么事实是瞒不住的。想很快的回本实践中是不大可能的。所以，专心做一个优质的软件，做出一个你和你的客户都能长久依赖的工具才是正道。

 

---

固定时间和预算，但灵活控制产品外延

准时地在预算内推出

一个简单方法让你能准时地在预算范围内推出产品：定额定量。绝对不要在一个难题上多投时间和金钱。要么缩小规模，要么缩小范围。

总会有一个这样误区：我们能做到准时地，在预算内发布一个规模完整的产品。这可以说完全不可能的，如果真是这样的话一定是以质量做为代价的。

如果你不能在预定的时间和预算内完成所有的东西的话，就不要拉长时间和增加预算。相反的，把产品的外延缩小些。下一步总是有时间可以加东西进去 — 过后有的是时间，当下却是稍纵即逝的。

做一个比预计要小巧些的好东西比做一个庞大平庸而又漏洞百出的东西要现实的多，因为你要象魔术师一样巧妙的照顾到时间，预算和产品内容的方方面面。变魔术就交给Houdini（魔术大师）。你所做的可是在运作一个真正的事业，在推出一个真实的产品。

以下是一些固定时间和预算，灵活控制产品外延的好处:

• 要有优先级

  你一定要搞明白什么才是最重要的。什么是首发的产品中必须要具备的特性功能？这个限制思维逼迫你下一些痛苦但必要的决定，而不是挑挑拣拣的拿不定主意。

• 要现实些

  设定期望值是关键。如果你同时要固定死时间，预算和产品的外延，你将不能推出高层次的产品。当然你可能推出个东西，但那个“东西”会是你真正想做的吗？

• 要有灵活性

  及时应变的能力很重要。如果什么都固定死就很难应变。给产品的外延注入机动性，当真正做起来就有比较多的选择空间。机动灵活是你的良师益友。

我们建议：范围缩小些。做半个产品比做半拉子的产品好（后面将进一步论述这点）。

 

---

找个敌人

挑选一场战斗

有时了解你的应用程序应该做成什么样子的最佳方式就是，认识到它不应该成为什么。搞清楚你的软件的对手是谁，就象点一盏灯，能照亮你前行的道路。

当我们决定开发项目管理软件的时候，我们清楚的知道微软项目软件（Microsoft Project)是这个小舞台上的一个庞然大物，大猩猩。我们不是去害怕这个大家伙，相反的我们把它做为一个刺激我们前进的引擎。我们决定 Basecamp将做成一个完全不同的项目管理软件，就是反Microsoft Project而行。

我们意识到项目管理并非就是有关图表，报告和统计数据 — 它更重要的是沟通。它并不是要一个项目经理坐得高高在上去传达一个项目计划。它应该是每个人都参与的，一起担起责任来使项目付诸实现。

我们的敌人就是项目的独裁者和他们用来指手画脚的工具。我们要把项目管理民主化 — 让每个人都能成为它的一份子（包括客户）。只有每个人都承担负责流程的一部分，这样整合起来项目才能做得更好。

说说Writeboard这个协同文字编辑软件，我们知道有很多的竞争对手的产品内建了许多复杂玄妙的功能。正因为如此，我们决定着重从“不花哨” 入手。我们开发了这个程序仅仅来让人们共享和协作，而不用一些非必要的功能来使他们举步维艰。只要是不必要的我们就不做。推出后仅3个月的时间，已经超过 10万个用户在使用Writeboards。

当我们开始着手Backpack这个资讯管理软件的时候，我们的敌人就是严格的组织框架和规章制度。人们应该要能够用他们自己的方式来管理他们的信息 — 而不是在一堆预先规定好的格式和众多的表格中填空。

你能从敌人那里得到的一个好处就是：一个非常清晰的营销理念。人们很容易被冲突对立挑动。并且通过把一个产品和另一个作比较能更多地了解这个产品。 选中了这么一个敌人，你给人们灌输了他们想要知道的对立的信息。这样一来，他们不仅能更好更快地认识你的产品，也会站到你的这边。这是一个吸引注意力和引 发产品倾向性的一个万无一失的方法。

说了这么多，必须指出的是，也不要太过着迷于竞争。过分地去分析其他产品会慢慢限制你的思维想像力。很快地看一下他们在做什么，然后就要回到你自己地理念和理想上来。

 

---

它不该成为一种交易

你的激情 — 或者冷漠 — 会起作用的

如果你越不把软件当作一种交易去做，你就越能做得好。把它控制在一个你能把握的小范围内，你就有可能真正地享受过程。

如果你做这个软件一点不兴奋，那就是什么地方出了问题了。如果你只为了赶紧抢点钱做掉它，那这种影响会出现在最终产品上。同样地，如果你满怀热情地去做它，结果也会反映在产品上。人们是能够分辨出个中的区别的。

 

---

保持精益 第三章

更小的质量

你越做到精益，改变越容易

一个物体的质量越大，改变方向需要的能量越多。物理世界的这个真理同样适用于商业世界。

当真理应用到Web技术的时候，改变必须是简易和低廉的。如果你不能如飞一样的改变，你就会败给能够做到的竞争者。这就是你需要追求更小质量的原因。

质量会由于以下因素增加

• 长期合同
• 多余的职员
• 固执的决策
• 关于会议的会议
• 厚重的流程
• 存货（物理的或者头脑的）
• 硬件，软件和技术的锁定
• 专有数据格式
• 未来被过去支配
• 长期的路线图
• 办公室政治

质量会由于以下因素减少

• 必要而及时的思考
• 多面手的团队成员
• 拥抱限制，而不是试着移除他们
• 更少的软件，更少的代码
• 更少的特征
• 小规模团队
• 简单
• 被拆分为正交的接口
• 开源产品
• 开放的文件格式
• 开放的文化，使承认错误更容易

更小的质量使你快速的改变方向。你可以随机应变和演进。你可以集中于好的主意，摈弃坏的。你可以倾听并尊重你的客户。你可以集成新技术现在而不是以后。你驾驶的是蒸汽船而不是飞机货舱。为这个事实骄傲吧。

举例来说，想象一个精益，小质量的公司，用更少的软件，更少的特征制造了一个产品。另一方面是一个更大质量的公司拥有一个带有明显更多软件和特征的 产品。那么试想一下，随着新技术，比如Ajax，或者新概念，比如标签的出现，谁会更快的调整他的产品？拥有更多软件更多特征还带着12个月路线图的团 队，还是另一个团队，拥有更少软件更少特征和一个更有机的流程——“让我们集中于我们当下应该集中精力的地方吧”。

很明显，更小质量的公司在适应市场真实需要的方面处于更有利的位置。当小质量公司已经完成转换很久以后，更大质量的公司有可能仍然在争论变化或者将他们推入官僚主义的流程中。小质量公司会领先两步于仍然在争论如何走的大质量公司。

反应快，敏捷，小质量的公司可以快速的改变他们整个业务模型，产品，特征集和营销信息。他们可以犯错并快速的修复。他们可以改变他们的优先级，产品组合和重点。还有最重要的，他们可以改变他们的想法 。

 

---

减少改变的成本

通过减少改变的阻碍保持灵活

改变是你最好的朋友，改变的代价越大，你越不可能做出改变。如果你的竞争对手可以比你更快的改变，你会处于一个很大的劣势。如果改变变得过于昂贵，你已经死了。

这就是保持精益真正帮助你的地方。很短时间内改变的能力是小团队与生俱来而大团队永远不会有的。这是大家伙嫉妒小家伙的地方。让巨大组织里的大团队花费数周才能改变的，对于小团队可能只需要1天。这个优势是无价的。低廉和迅速的改变是小团队的秘密武器。

请记住：所有的现金，所有的营销策略，所有的世界上的优秀人物，都买不到小带来的敏捷。

 

---

三个火枪手

用三人小组构建1.0版本

对于产品的1.0版本，请从只有三个人开始。三是一个魔力数字，提供足够人力的同时允许你保持流畅和敏捷。从一个开发者，一个设计者，和一个清道夫（一个可以在开发和设计中随意切换的人）开始。

现在显而易见的是用很少的人建造一项应用是一个挑战。但是如果你有一个正确的团队，挑战是值得的。有才能的人不会需要无尽的资源。他们会在约束限制 下的工作和利用创造力解决问题的挑战中成功。缺少人力意味着你会被迫更早的应对权衡——那是没问题的。这种情况会让你更早而不是更晚的指出你的重点。你也 能够与人交流，不用经常地担心他们不了解前因后果。

如果你不能够用三个人建造第一个版本，那么你或者需要更改人数或者需要缩减初始的版本。记住，保持你的第一个版本小而紧凑是没有问题的。你会快速的发现你的想法是否快速的进展，如果是，你会拥有一个清洁的简单的基础可以继续建造。

 

---

拥抱约束

让限制带领你到创新的解决方法

总是有不充足无法满足所有需要。不充足的实践。不充足的金钱。不充足的人。

这是一件好事情

不要被这些约束逼得发疯，拥抱他们。让他们指导你。约束驱动创新并强迫集中精力。不要试着移除它们，使用它们带来你的优势。

当37signals构建Basecamp的时候，我们有非常多的限制。我们有：

• 一个需要运营的设计公司
• 已有的客户工作
• 一个七小时的时差（David在丹麦编程序，我们其余的人在美国）
• 一个小团队
• 没有外部的资金

我们感受到了“不充足“的忧伤。所以我们让我们的盘子保持小。那时我们只能够往上方这么多。我们选取大任务，把它们分解成我们一时间能够处理的小任务。我们一步一步的行动并在前进的过程中分清主次。

”不充足“强迫我们使用创新的方法解决。我们通过始终构建更少的软件减少改变的成本。我们给人们仅仅足够的特色让它们以自己的方式来解决自己独特的 问题 — 于是我们便不再是障碍。时差和空间上的距离让我们在交流中更加有效。不是人参加会议，我们的交流几乎毫无例外通过及时通讯软件和电子邮件，它们强迫我们快 速的到达重点。

约束经常是伪装的优势。忘掉风险投资，长发布周期和快速招聘。代替的是，和你目前拥有的合作。

 

---

做你自己

通过亲切友善和人性化来把自己和大公司区分开来

大量的小公司犯了试着装作大公司的错误。就好像他们意识到他们的规模是一个缺点，需要隐藏。太糟糕了。小型实际上可以是一个巨大的优势，尤其是在通讯方面。

小公司享受着更少的形式主义，更少的官僚主义，和更多的自由。小公司天生和顾客更亲近。 那意味着他们可以以一种更加直接和人性化的方式和顾客沟通。如果你是小公司，你可以用熟悉的语言而不是晦涩的行话。你的网站和产品可以用一种人类的声音，而不是操着公司的腔调。小型意味着你可以和你的顾客在一起谈话，而不是居高临下的方式。

小公司在内部的交流生同样有优势。你可以摈弃形式主义。所有事情都不再需要繁杂的流程和多重的签字确认。参与流程的人都可以开放和诚实的发言。这个没有被束缚的思想流是保持小型的巨大优势。

 

---

第四章 首要任务

什么理念才是伟大的

明确定义产品的闪光点

竭尽全力将你的软件定位在一个点上。你的软件代表的是什么？它到底是有关什么的？在你开始设计或写任何代码之前你必须清楚地知道你做这个产品的目的 — 它的前景。把理想放大些。为什么要有它？它和其他类似产品不同的地方在哪里？

这个理念会引导你的每个决定，指引你不偏离航线。任何时候有比较出格的举动时，问自己，“我们是不是还在坚守着自己的理念做事？”

你的理念必须是简洁的。应该一句话就能把想法传达到。以下是我们每个产品的理念：

• Basecamp: 项目管理即是沟通
• Backpack: 把生活中的凌乱归整
• Campfire: 用及时通讯软件来开展团体交流太逊了
• Ta-da List: 和及时贴便条做斗争
• Writeboard: 用不着麻烦微软的WORD

举个例，我们Basecamp软件的理念是，“项目管理即是沟通”。我们强烈的感觉到对一个项目的有效沟通是引导一系列责任，参与，投资和能量的关键。它把大家统到同一个目标上来增强共识。我们清楚地知道如果Basecamp能做到这点，那么其他事情也就会一一水到渠成。

这个理念引导着我们尽可能地保持Basecamp的透明性和开发性。我们不把沟通局限在公司内部，相反我们向客户敞开。我们不考虑太多权限地问题， 相反我们更鼓励各方的参与。就是这个理念使我们放弃了图表，表单，报告，状态分析和电子表格的功能，相反的我们专注在优先问题的沟通上，如果每日新信息， 评论，该日备忘项目和文件的共享。把有关你理念的重大决定做在前面，将来其他小的决定就会变得容易多了。

 

---

在初期时忽略细节

先粗后细

我们太过痴迷于细节。

• 两个原素之间的留白空间
• 完美的首个字母大写字形
• 完美的颜色
• 完美的用词
• 代码只能四行长，不能七行
• 90%与89%之差
• 760px与750px之差
• $39/月与$49/月之差

成功和满意来自于细节

然而，细节中并不只有成功。细节中你还会遇到停滞不前，意见不合，无数的会议和延迟。这些东西会掩煞你的信念，降低你成功的几率。

你可有常常一整天被困死在一个设计原素或一个程序代码上？可有不时觉得你今天的进展实在算不上什么真正进展？过早专注于细节就会导致这些结果。要做完美主义者有的是时间。但不是现在。

别在第一周就担心标题字体的大小。不需要在第二周就搞定什么是最佳的绿色的色调。更不用在第三周就要把“提交”按钮向右移动三个像素。先把该放的东西放上去。然后去用它。保证它是可用的。最后才去把它调整到完美。

细节是在你使用的过程中才会显露出来的。只有在使用中你才能看到什么需要进一步关注。在使用中你才会感到缺了些什么。常常走路绊倒脚你才会清楚地上什么坑洼是需要填补的。那些是当你被迫要留意的时候才需要的细节，不是一想到细节就去搞定它。

 

---

当问题成为问题的时候才去担心

不要把时间浪费在还未成为问题的问题

你真的的需要考虑当用户到达10万以上的时候会出现的问题吗？它可能已经是两年以后的事了。

如果你现在只需要三个程序员你真的有必要雇八个吗？

你难道真的马上需要12台高端服务器即使两台就足以让你顶一年？

就先掠过吧

人们总是预先花很多时间在还不知道会不会发生的问题上。靠，我们推出Basecamp的时候还不知道如何向客户收费！因为产品是月付费的，我们知道 还有30天的时间来搞定付费方式。我们把预先省下的时间用在解决更紧急的问题，直到产品推出后，我们才着手付费问题。结果很顺利（它迫使我们用最简单的解 决方案，没什么花哨的东西）。

别整天操心还没成型的麻烦。别过度开发一个产品。到适当的时候再添加硬件和系统软件。如果进度推迟了一两个星期，别担心，还没到世界末日。只要诚实: 解释给你的客户听，说你们正经历着成长的烦恼。他们也许不会因此无比感动，但他们起码会赞同你的坦诚。

关键是: 如果你已经掌握了你需要的信息就及时做决定。这样你就能把注意力集中到需要马上解决的问题上来。

 

---

去网罗对味的顾客

找到你产品的核心市场然后就专注进去

顾客并不总是对的。现实中你要能分辨出谁是你该针对的顾客，谁是你该放弃的。庆幸的是，互联网使得发掘有共识的顾客的过程变得无比容易。

如果你想讨好每个人那么你什么人也讨好不了。

当我们做Basecamp的时候，我们把市场营销集中在设计公司这块上。如此缩小市场范围，我们就更有可能吸引一些有心的顾客来成为产品的追随者。要清楚地知道你的产品是为谁推出的，集中精力去讨好这部分人。

 

---

过后才去做规模调适

你还没有必要现在就做调整

"我的应用程序能否适应万人的使用规模?"

等那真发生了再说，明白吗？如果用户的数量大大超过你的系统负荷那么恭喜！太喜欢这种麻烦事了。但在现实世界中，超大多数的网络应用程序从来都没有 到达那一步。即使你真的开始超负荷了，也不会到马上就挂了的地步。你将会有时间反应和调适。还有一点就是，只有推出产品后你才有机会采集真实的数据指标， 然后你才能用它们来推断哪些领域需要改进。

举例说明，推出的第一年我们的Basecamp只是在一台服务器上运作。因为这样的一个简易设置，整个实施只花了我们一周。我们并没有一开始就搞个15台服务器的集群或是花好几个月的时间担心规模调适的问题。

我们这么做有碰到什么问题吗? 有一些。但我们也发现大多数我们害怕的问题，比如短暂的系统滞缓，对用户来说并不是什么不得了的事。只要你及时和用户沟通，诚实地面对问题，他们是会谅解的。回头看，我们真的非常高兴当时并没有为了”完美的呈现“而把产品的发布推后数月。

开始阶段，要把建造强有力的核心产品做为首要任务，不要过分执迷于需不需要服务器组和是否有能力调整规模应变。 先把一个伟大的产品推出，然后才去担心它无比成功了以后该怎么办的问题。 否则你可能只是把精力，时间和金钱花在一个永远不会发生的预期上。

信不信由你，最大的问题不是规模调适，而是怎样达到你不得不需要去调适的那一刻。没有第一个麻烦哪来下一个麻烦。

 

---

软件要有自己的主张

你的软件应该要有倾向

一些人在论证软件应该保持中立的问题。他们说开发者限制或忽视大众诉求的软件功能是一种傲慢的表现。他们说软件应该总是能随机应变的。

我们认为那都是扯淡。伟大的软件必须要有自己的理想。伟大的软件必定是有倾向的。当人们使用软件的时候他们不只是在看功能，同时他们也在寻找一个解决方案，一种理想。决定你的理想而后追求不懈。

同时谨记，如果他们不认同你的理念的话还有无数的其他理念可供选择。没有必要总追逐你永远无法讨好的人。

一个著名的例子就是wiki的最初设计过程。Ward Cunningham和他的朋友们有意把传统上认为协作文章不可或缺的许多功能都舍弃不用。他们不把每次文章的修改归功于特定哪个人，而把所有权标识都去 除了。这么一来，内容就不再自我，而成为永恒。因为他们相信重要的不是谁或什么时候写的文章。这个理念改变了一切。这个决定孕育了一个以共享己任的社区， 成为Wikipedia（维基百科）日后的主旋律。

我们的软件走的是一条类似的路。我们的软件并不追求成为所有人的宠儿。我们的软件是有自己的性格的。他们找寻的是志同道合的用户伙伴。他们是在和有着同样理想的用户对话。你要么上来一起，要么下车。

 

---

挑选功能 第五章

部分，而不是残缺不全

构建一半产品，而非产品有一半缺陷

小心“所有东西除了厨房水池”的Web应用开发途径。投身于出现的每一个合适的点子上，你将会终结在产品的一个半傻不陧的版本上。你真正想要做的是构建一个把愚蠢一脚踢开的产品。

专注于真正必须的。好点子可以尽量坦白。摆出产品应该成为什么样的任何点子，然后砍掉一半。减少功能直到只剩下最必要的功能。周而复始。

对于Basecamp，我们从Message开始。我们知道它是这个应用的灵魂，所以我们暂时忽略了Milestone，Todo-list，以及其他功能。这让我们基于真实的使用情况来决定下一步怎么走，而不是凭空猜测。

从一个精简，聪明的应用开始，然后让它得到关注。就能开始在你构建的坚实基础上添砖加瓦。

 

---

无所谓

只留精髓

对于“为什么你们做这个而不做那个？”这种问题，我们青睐的回答总是“因为无所谓。” 这个陈述表达了是什么让产品变得伟大。找出紧要的，略去其他。

当我们发布Campfire时，我们从第一次尝试此产品的人中听到下面一些问题：

“为什么只有每五分钟才有时间戳？为什么不是每一行聊天都有？ 回答：无所谓。有多少次你需要每秒或者每分钟记录谈话内容？当然不是95%的情况下，5分钟时间戳足够了，因为任何更多的细节都不重要。

“为什么你不允许粗体，斜体或者有色字体格式在聊天中出现？”回答：无所谓。如果你希望强调某事，使用可信赖的caps lock键，或者在词语或者段落周围投放几个 * 字符。那些方法不需要额外的软件，技术支持，处理能量，或者学习曲线。除此之外，在简单的基于文本的聊天中重量级的格式无关紧要。

“为什么你不显示当前时间房间里的总人数？”回答：无所谓。每个人的名字被列出来，所以你知道谁在那儿，但是12个还是16个人有什么区别？如果它不改变你的行为，那么无所谓。

这些功能如果有就更好么？当然。但是他们是不可或缺的么？他们真的重要么？不是。这就是为什么我们把他们刨除在外。最好的设计师和最好的程序员不是 技能最好的，或者手指最敏捷的，或者用Photoshop用的神乎其神的人。他们是能够决定什么不重要的人。真正的收获源自于此。

你的大部分时间浪费在无关紧要的东西上。如果你能抛弃不重要的工作和思考，你将会获得不可思议的生产力。

 

---

从说“不”开始

不轻易实现功能

构建部分而不是残缺不全的秘诀是说不

每一次你对一个功能说yes时，你正在收养一个小孩。你必须带着你的孩子通过一连串事件（例如设计，实现，测试等）。一旦这个功能出现了，你就被拖住了后腿。尽量为客户少发布一个功能，再看客户是否愤怒地离开。

不要成为 yes-man

不要轻易实现每个功能。而要让每个功能证明自己，并且表明自己是幸存者。这就像加入搏击会一样（参考电影 Fight Club）。你应该只考虑那些好像为了能加入进来而站在走廊苦候了三天的功能。

这就是为什么你从说“不”开始。每一个向我们提出的 — 或者我们自己提出的 — 新功能需求都遇到一个 NO 。我们倾听但是不采取行动。最初的回应是“不是现在”，如果一个需求或者功能不停的过来，我们知道这才是时候对它进一步观察。然后，只在那时，我们才开始考 虑实现这个功能。

当你不采纳他们的功能建议时，你如何回复他们的抱怨呢？首当其冲的是，你要提醒他们为什么他们喜欢这个应用。“你喜欢它因为我们说NO。你喜欢它因为它没有做其他100件无关紧要的事情。你喜欢它因为它不试图始终讨好所有人。”

 

---

隐藏的成本

看清功能的成本

即使一个新功能通过了对其说不的阶段，你还需要去发现它隐藏的成本。

比如，我们应该注意到功能循环（带来更多功能的功能）这种现象。我们曾经有一个需求是在Basecamp里加上一个“会议标签”。如果不仔细权衡这看上去 好像很简单。但是想想“会议标签”需要的不同元素：地点、时间、房间号、人员、邮件邀请、日历的整合、支持文档等等。这还不包括修改推广活动中的截图、用 户预览页、常见问题及帮助页、服务条款以及更多。在你还没搞清楚它是怎么回事之前，一个简单的想法就象滚雪球一样弄得你大伤脑筋。

对于每一个新功能你需要……

• 1. 对它说不
• 2. 强迫它证明自己的价值
• 3. 如果得到否定的答案，就此打住。如果是yes，继续往下……
• 4. 为界面绘制草图
• 5. 设计界面
• 6. 编写代码
• 7-15. 测试，改进，测试，改进，测试，改进，测试，改进……
• 16. 检查帮助文字是否需要修改
• 17. 更新产品预览流程（如果有必要的话）
• 18. 更新用于销售的拷贝（如果有必要的话）
• 19. 更新服务条款（如果有必要的话）
• 20. 检查是否违背之前的任何许诺
• 21. 检查价格体系是否受影响
• 22. 上线
• 23. 深吸一口气

 

---

你能把握住它么?

构建你有把握的

如果你发布一个会员程序，你的系统能够处理帐户和支付问题么？可能你应该只让用户根据会员身份通过信用卡支付，而不是让他每个月撰写，签名，并且邮寄一张支票。

你能承受得起1G的免费空间么？还是仅仅因为Google这么作了？可能你应该从100M开始，或者只给付费用户提供空间。

底线：构建你能够掌握的产品和服务。许诺容易遵守难。确保你所作所为是在承担范围内 — 从组织，战略和财政上

 

---

人本主义

为一般概念构建软件，并且鼓励人们创建自己的解决方案。

不要约束人的习惯。而是令软件宽容的接纳每个人自己的解决方案。给人们足以通过自己的方式解决他们自己的问题的能力。然后解决之。

当我们构建 Ta-da List的时候我们故意忽略掉了一堆东西。不能分配某人一个to-do，不能标记时间范围，条目不能分类，等等。.

我们保持工具干净整洁,让人们富有创造性。人们自己琢磨出了如何解决问题。 如果想要添加一个日期到代办事宜项目,他们可以在该项目前添加 (至: 2006年4月7日) 。 如果想要添加分类,也可以在该项目前添加[图书]。 理想吗? 不 。 无限弹性? 是的。

如果我们试图写软件专门处理这些情景, 我们就会使它在这些担忧并不适用时的所有情况下，变得不怎么有用。

把问题的根尽力处理好，然后走开。人们将会在你的总框架内找到自己的解决方案和约定。

 

---

忘掉功能需求

让你的顾客提醒你什么是最重要的

顾客想要一切在阳光下。 他们会用雪崩似的功能和特性要求淹没你。看看我们的产品论坛，功能类别的要求总是盖过其它要求一大截。

我们会听到："这一点点额外的特征" ，或 "这不难办到"或"加入这个不是很简单么？"或"仅用短短几秒钟就可以把这个加进去" ,或 "如果你加上这个，我付两倍的钱" ,等等。

当然,我们并没责怪人们提出要求。我们鼓励这样,并想听听他们怎么说。我们加入产品的几乎一切,起初都是作为客户的一个要求提出来的。但是,正如我们前面提到的,你的第一反应应该是一个No 。 所以,你究竟应该怎样对待这些纷至沓来的要求呢? 你怎样储存它们?你如何管理它们? 你不需要，看完之后，把它们扔掉。

是啊,看完之后，扔掉,并且忘记它们。 听起来象亵渎了用户,但其中真正重要的会不时冒泡，提醒你。 这些都是你唯一要记住的。 这些才是根本必要的。 不必为跟踪和保留进来的每一请求而操心,让你的客户成为你的记忆仓库. 如果它真的值得一记,他们就会提醒你,直到你不能忘记。

我们是如何得出这个结论的? 当我们第一次启动 Basecamp 时，我们在Basecamp 的一个代办事宜列表中跟踪每一个主要功能的要求 。 当一个需求被某人重复提出后,我们就用一个额外的记号更新名单上的项目(II或III或IIII等) 。 我们计划有一天我们要检阅这份名单，并从被请求最多的功能开始依次实现之。

但事实是,我们从来没有再去看它一遍。 我们已经知道下一步需要做什么,因为我们的客户在通过重复同样的需求不断提醒我们。 没有必要留一份名单或进行太多分析,因为这一切都在实时发生。 当每天都被不停地提醒时， 你不可能忘记什么是最重要的。

另外一件事要注意:不能因为有 X 人提出需要什么,就把它列入你的产品功能。 有时不如只说不,并维持你心目中的产品。

 

---

抓住核心

问人们不想要什么

大多数的软件调查和研究都是围绕人们想要的产品 。"你认为有还缺失什么特征？" ， "如果你可以加入一个功能,那会是多少?" ， "如何使这个产品对你更有用" ?

硬币的另一面会是怎么样呢? 为什么不问人们，不想要什么? "如果你可以去掉其中一个功能,那会是哪个呢? " ，"你为啥不用? " ， "什么让你觉得最碍事？" 。

答案并不是“更多”。有时你对用户最大的优惠就是把一些东西去掉，拿出来。

 

---

操作 第六章

一场把软件运作起来的比赛

尽快地推出一个真实的产品

一个可运作的软件是积蓄动力，整合团队，去除行不通的点子的最佳方式。你必须从第一天开始就将它摆在首要位置。

做少一些功能，跳过一些细节，如果一些捷径能加快软件进度就大胆用，这些都是OK的。当你做下去的时候，你会对下一步的方向有更准确的把握。太多的故事，建模，甚至HTML演示都是比较虚的构想。一个运作着的软件是真实的。

只有一个真实的，可操作的软件才能拉近每个人对现实的理解和认同。避免了为一些草图和段落争得面红耳赤，最终发现这些都是无谓的。同时，你也会发现有些你想像中无关痛痒的事情事实上是很重要的。

真实的产品导致真实的行动。这才是你走向真理之路。

 

---

冲洗一下再来过

在不断反复中工作着

别期望一开始就做得好。让软件自然成长，和软件对话。让它自然蜕变而进化。做为一个在线的软件是不需要在完成后才推出的。设计一些界面，使用它们，分析它们，反复地做。

与其停止在把一切都事先做好做对的思路上，不如在经反复求证得出的分析判读中前行。同时，你可以更快的推出一个积极的产品，因为你并不是一味追求一出门就完美的产品。结论是是由真实世界里的反馈，真实的目标来引导你的注意重心。

反复能解脱你

如果你知道过后总是要重来一遍，你就不需追求一开始就达完美。这种明了不管如何你总是得过后重新审视一些问题的理念，能引发你先把产品想法推出去看看是否可行的激情。

 

---

从概念到实施

从灵感，到草稿，到HTML，到代码

以下是我们Get Real（求实）的过程:

脑力激荡

先要有个点子。这产品要给我们带来什么？以Basecamp来说, 我们是要满足自己的需要。我们想要用它来发布项目的一些更新信息。我们希望能让用户一起参与。我们知道项目都有里程碑。我们希望能有个集中归档的地方让大 家能回过头去温习一些旧的东西。我们想要有个全局观，从一定的高度来鸟瞰所有项目的进度。归结起来，这些假想和一些其他设想打下了我们日后着手的基础。

这个阶段并不是有关一些实施的具体细节。这是一个大方向。软件需要为我们做什么？什么时候才能知道它有用？确切的说我们要做出个什么东西来？这是高阶的理念，不是像素阶段（细节）的推敲。在这个阶段，那些细节是没有意义的。

纸上草稿

草稿是迅速的，实用的和便宜的，这就恰恰是你想要开始的方式。涂些东西，画些东西，方块，圆圈，线条，什么都行。把你脑子里的想法搬到纸上。这阶段的目标是把概念转成一个界面设计的粗稿。这个阶段完全是试验性的。不存在什么答案是错误的。

创建HTML页面

做一个HTML版本的功能界面（或一个区间界面或流程界面，如果这么做更合适的话）。发布一个实在的东西，这样一来大家就都可以看到它出现在屏幕上的样子。

以Basecamp而言，我们先做“发布一条信息”的界面，然后是“编辑信息”的界面，然后一步步下去。

先别写任何程序代码。只把HTML和CSS的框架搞出来。有关细节实施是后面的事。

上代码编程

当模型框架看起来过得去又兼具一些足够必要的功能时，就是开始上代码编程的时候了。

在这整个过程中要记住保持机动弹性，要有多次反复的思想准备。应该随时有这个意识：舍弃某些已完成的步骤重新来过，如果成品看起来丑陋不堪。数次重复这个过程是很自然的。

 

---

远离设置首选项

要帮你的客户决定一些小处细节

假设你将面临一个困难抉择：在一个页面上可以发布多少条信息？你的第一反应可能是，“不如做个设置首选项，在那里人们可以选择25，50，或100条每页”。这么做可是一个方便自己之门。你必须要自己做一个决定。

设置首选项是一种逃避困难抉择的方式

你不是运用你的专业去决定最佳的选择，相反地把问题留给了客户。表面看起来好像是你在帮客户的忙，事实上你只是会使他们更忙（客户自己已经是够忙的 了）。对客户而言，面对无穷无尽的设置选项是一个很令人头痛的问题，不是一件好事。客户不应该去烦恼细枝末节 — 当是你的责任的时候就不要让别人去担待。

设置选项也是邪恶的因为他们使软件变得冗余。更多的选项就需要更多的编程代码。而且你还要花额外的时间在测试和设计上。还有很多选项排序和显示界面等你可能从来没见过的东西。这意味着隐藏的软件瑕疵：破碎的布局，凌乱的表格，奇奇怪怪的页面排序问题等等。

你要拿主意

替你的客户下简单的决定。这也是我们在Basecamp上用到的诀窍。每页可发布信息数是25条。项目总览页显示最近的25条信息。信息反时序排（最新的在上面）。最新近的5个项目会显示在控制面板上。不需要任何设置选项。它本来就该这样。

是的，你有可能下了一个不太好的决断。没什么大不了。如果事情发生了，人们会抱怨，会让你知道。照样，你可以做调整。Getting Real（求真求实）说的就都是有关能够一路做灵活修改的道理。

 

---

"搞定!"

决定都是暂时的，那么拿定主意就继续到下一步

搞定。现在就开始把它看成一个有魔力的词。当你到达“搞定”的阶段就表明你已完成某事。一个决定已经下了，走下一步。“搞定”也表明你已经聚集了能量。

慢着，如果你搞砸了，下了一个错误的决定怎么办？没问题。这并不是什么开颅手术，它是一个在线应用程序。 我们一再强调，在开发过程中你总是需要不时回过头去调整软件的功能及想法。不管你计划得多周密总有可能一半左右的东西没做好。所以，不要做“到死都要调查分析”的傻事。那样做只会慢了进度和磨去意志。

相反地，要知道以“朝前看向前走”为重。要跟上拿主意的节拍。做一个迅速简单的决断，如果它行不通那就再回头修改。

要接受多数决断都是暂时的有时效性的现实。要接受错误必将发生的现实，同时也要认识到这并不是什么大不了的，只要你能迅速改正之。执行，积蓄能量，而后前行。

 

---

放飞去让大众测试

在现实使用中测试你的软件

让真人在真实的环境中使用你的软件，这是无可代替的。取得真实的数据。取得真实的反馈。然后在那些信息的基础上进行改进。

常规的可行性测试太死板了。实验室的设置并不能反应现实。如果你站在别人的背后观察监视，你可能多少了解一个方案是否行得通，但人们普遍在摄像机面前无法自然表现。当被别人这么看时，大家都会很小心地不去犯错 — 但错误却正是你所要获知的信息。

相反，在正式软件中发放beta功能给一些有选择的用户。让他们能同时使用beta功能和已发布的功能。这样这些测试的功能就能曝露在真实的数据和流程中。从这你就能取得真实的数据。

另外，不要搞正式版和beta版的游戏。两者不应该有区别。另外做一个beta版本只会得到一个轻描淡写的试用。正式版本，注入一些beta的功能，才能得到全方位的体验。

 

---

缩短你的时间

把它分块来做

做几周甚至几个月的预期是不现实的。事实上你无法预见那么远的将来会发生什么状况。

所以，缩短你的时间范围。把一个时间段分成一个个小块。把一个12周项目看成是12个周项目。与其去推演一个要花30个工作小时的任务，不如把它们分成更现实的6-10个小时的小任务。然后一块一块地去执行。

这个理论同样适用与其它问题。你是否有碰到一个很大的问题想都想不过来？把它划分开来想。就这么一直把问题分成小块及更小块直到你能消化它为止。

 

---

组织 第七章

一致性

拒绝分隔

很多公司将设计，开发，广告撰写，支持和营销分隔成不同的战斗单位。虽然专业化有它的好处，但是它创作的环境却让员工只看到自己的小世界而不是web应用的整个背景。

尽你所能的，整合你的团队，这样才能有一个健康的，反复的讨论贯穿整个流程。建立一个制约平衡的系统。不要让事情在翻译中迷失。让广告撰写者和设计者一起工作。支持的疑问一定要让开发者看到。

更好的情况是，雇用拥有多项天赋的人，他们可以在开发过程中担任不同的角色。最终的结果是一个更加协调的产品。

 

---

独处的时间

为了让事情做好，人们需要不被打扰的时间

37signals跨越4个城市和8个时区。从犹他州的普罗沃到代码的哥本哈根。我们五个人分隔了8个小时。这8个小时的距离的一个积极的副作用是独处的时间。

一天中只有四到五个小时我们都醒着并在一起工作。其他的时间，美国团队在睡觉而David，人在丹麦，在工作。剩下的时间，我们在工作而David在睡觉。这让我们一天中一半在一起而另一半独处。

猜猜在一天中哪一部分完成我们完成的工作最多？独处的那部分。这没有什么惊奇的。很多人喜欢的工作时间是清晨或者午夜 — 他们不会被打扰的时间。

如果你有很长时间没有被打扰，你就能渐入佳境。这个情境是你最有生产力的时间；这个时间内你不必在各种各样的任务中切换思维；这个时间你不会受到干扰，比如回答问题或者是查找东西，发送邮件或者应答即时通讯。独处的时区是产生真正进展的地方。

渐入佳境需要时间。这就是为什么干扰是你的敌人。这就像深度睡眠 — 你并不直接进入深度睡眠，你先进入浅睡眠，然后你会逐渐进入深度睡眠。任何干扰都会让你从头开始。深度睡眠是真正的睡眠魔法发生的地方；独处的时间是真正的开发魔法发生的地方。

在工作中建立一条规定：一天中一半的时间作为独处时间。从上午10点到下午两点，任何人都不可以和别人谈话（除了午餐时间）。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的，为了避免破坏生产力的干扰。

成功的独处时间意味着赶走交流痴迷。在独处时间中，放弃即时通讯，电话呼叫和会议。不要打开随时更新的email程序。只需闭上嘴去干活。（Just shut up and get to work.）

 

---

会议有毒

不要会议

你真的需要会议吗？会议经常出现在概念不够清楚的时候。不要求助于会议，试着简化概念，于是你可以快速的讨论它，通过电子邮件，即时通讯或者Campfire。目标就是避免会议。你避免花费在会议上的每一分钟是你真正做事情的每一分钟。

对于生产力的毒性没有比会议更厉害的了。以下是几点原因：

• 他们将工作日分解成小的，不连续的片段从而打乱了你的日常工作流程
• 他们经常是关于词语或者抽象概念，并非真实的事物（比如代码片段或者一些接口设计）
• 他们经常每分钟传达非常小的信息量
• 他们通常包含至少一个笨蛋，轮到他时不可避免的通过无意义的话浪费大家的时间
• 他们偏离主题比大雪中的芝加哥出租车还容易
• 他们的议程经常非常模糊以致于没有人真正的明确他们的目的T
• 他们经常需要精心的准备但是人们无论怎样罕能做到

在你确实地必须 开会（这必须是一个少见的事情）的时候 , 坚持这些简单的原则：

• 设定一个30分钟的计时器。当它响的时候，会议结束。句号。
• 邀请尽可能少的人。
• 没有明确议程的时候不要开会。

 

---

寻找和庆祝小的胜利

每天发行点什么

软件开发中最重要的就是激励。激励是局部的 -- 如果你没有被你正在做的事所激励， 机会就没有应有的那么好。 实际上，很有可能变得更糟糕。

冗长，滞后的发布周期是激励的杀手。 这使得庆祝活动之间间隔太长的时间。 另一方面， 可以庆祝的迅速胜利是极大的激励动因。 如果你让冗长的发布周期压碎迅速的胜利，就杀死了激励。 并且这样也会杀死你的产品。

所以， 如果你的发布周期是在一个月以内， 拿出每周一天（或者没2周拿出一天）对取得的小胜利进行庆祝。 并扪心自问： “我们可以在4个小时内发布些什么？” ， 然后去实现它。 这可以是

• 一个新的简单特性
• 一个对现有特性的小改进
• 为了减低支持负担，重写一下帮助信息
• 去除那些并不需要的表格项

当你发现这些 4小时的迅速胜利时， 你将发现庆祝的理由。 这样鼓舞了士气， 增强了激励 并且 再次肯定了团队正在向着正确的方向前进。

 

---

人员配备 第八章

不需过早招聘太多员工

慢慢加人迅速发展

初期后期都并不一定要壮大队伍。即使你接触过100个顶级人才，一口气把他们全招来也并不是什么好主意。没有办法能让这么多人迅速的融入到统一的企业文化中去。你将遭遇令人头痛的人员培训、性格不和、沟通不畅、发展方向不同等诸多麻烦。

所以不要随便招人。真的。不要招人，另想办法。让你陷入烦恼的这件事是真正必要的吗？你不做又会如何呢？能不能用某种软件或者改变做事方法来解决呢？

ge前执行总裁Jack Welch每次裁掉一个人之后并不会马上招人来顶替他的位置。他想看看在那个职位和人员空缺的情况下能支撑多久。我们当然不主张用裁人来验证这个理论，但是我们的确认为Jack的做法有一定道理：你并不需要你考虑中的那么多人手。

如果没别的办法再考虑招人。但是你应该清楚知道你需要什么样的人，怎么向他介绍工作任务，以及具体要他负责解决什么样的棘手问题。

 

---

摸底

先和候选员工在测试项目中协作

看作品、简历、例程、工作经历是一码事，和他在一起工作是另外一码事。只要有条件，应该和准团队成员一起去“试试车”。

在聘用人之前，我们会给他们一个小项目琢磨琢磨。我们能从中看出他们怎么管理这个项目，他们怎样进行沟通，他们具体怎么做等等。和他们一起设计或者编写几屏代码能看出很多东西。你能迅速摸清和他们是否心有灵犀。

这种事规划起来比较难，但即使只能拿出20或者40小时来做也比没有强。适合不适合都能看得很清楚。如果不适合，先摸清情况能给双方避免很多麻烦和风险。

 

---

行胜于言

根据对开源社区的贡献选择潜在的技术人才

典型的通过学历、简历等方式来招聘技术人员在很多方面都是很愚蠢的。应聘者毕业于什么学校、学习成绩如何真的那么重要吗？一份简历或介绍信真能信得过吗？

开源社区是为那些需要招聘技术人员的人准备的礼物。通过开源社区，你可以在很长的时间跨度里跟踪某人的成果和贡献，无论好坏。

这意味着你能以他做过什么而不是说过什么来判断他是否合适。你可以通过考察真正重要的方面来做决定：

• 工作质量
  很多程序员说的时候口若悬河，实际去做的时候却错漏百出。通过开源社区，你可以直观的了解这个人的编程技巧和素养。
• 文化视角
  编程就是做判断。很多很多的判断。判断力遵循于这个人的文化水平、价值观和观念。考察候选人在编码、测试和社区讨论（争吵）中作出的具体决定，看看他在文化上是否和你有共同点。如果没有共同点，每个决定都将引发一场争论。
• 热情程度
  根据定义，参与到开源项目至少是需要一些热情的。不然为什么他要在屏幕前浪费业余时间？对开源项目的投入程度就能看出候选人对编程的热衷程度。
• 执行力
  如果完不成任务，再聪明的头脑、再合适的文化倾向和再高的热情也带不来有价值的软件。不幸的是，很多程序员都做不到这点。应该去找那些热忱工作的人。要做比买卖的时候，需要有这样的人——这个人要把货带出门，而且他也愿意去做。
• 社会经验
  和人一起共事很长时间，一起经历过紧张和悠闲，一起经历过起起落落，才能看出他们的真实性格。如果他缺乏教养，没有社交技巧，把他排除掉。

说到程序员，我们只聘用通过开源社区认识的人。我们认为其他任何方式都是不负责任的。我们聘用Jamis是因为我们关注过他在Ruby社区的参与程度和发布成果。他在前文所述的各个方面都做得很好。不需要次要原因，我们只评判真正重要的——他的工作质量。

不用担心团队成员“课外活动”的活跃度带走他们的注意力和工作热情。有句老话是这么讲的：如果你想做好一件事，去找你所认识的最忙的人。Jamis 和David两个都是对Rails 社区有重大贡献的人，同时，他俩还驾驭着37signals的技术部门。热爱编程并且能干活的人就是你真正需要的团队成员。

 

---

寻找全面发展的人

选择能快速学习的多面手，而不是专攻一面的专家。

我们从来不会用一个信息架构师。那实在太狭隘了。对于我们这样的小团队，招技术层面那么窄的人没用。

小团队需要能扮演不同角色的人。你需要会编程的设计师。你需要懂设计的程序员。每个人都应该对怎么构建信息（无论它指的是什么）有自己的想法。每个人都应该思路清晰。每个人都需要能和客户打交道。

而且每个人都需要能”在路上换档“。要记住小团队经常需要迅速改变前进方向。你需要有人能持续的调整和学习，而不是固步自封，只会干一件事。

 

---

热情是装不出来的

选择快乐的和技术水平中等的，而不是令人不满的专家

热情，是无法伪装的。招人的时候，不要认为你需要一个技术大师或者技术名流。他们往往自以为是。一个水平说得过去的快乐员工胜过于愁眉苦脸的专家。

寻找充满热情的人；寻找你信任他可以独立完成任务的人；寻找在发展缓慢的大公司受过折磨，并且渴望新环境的人；寻找为一起去建造你正在建造的东西而感到激动的人；寻找对你所厌恶的事物同样感到厌恶的人；寻找为入你的伙而感到兴奋不已的人。

 

---

炼字师

招文字功底好的人

如果你在琢磨从几个人选中挑出哪一个来填补空缺，选文字功底好的那位。无论他是设计师、程序员、市场人员、销售人员还是其他，写作技巧都很有用。简洁高效的写作和文字编辑能力可以带来简洁高效的代码、设计、邮件、即时信息以及更多。

这是因为要当好写手并不只是堆砌词藻。好写手懂得沟通的技巧，他们让事情易于理解，他们能站在别人的立场考虑问题，他们知道什么是可以忽略的，他们思路清晰。而这正是你需要的才能。

 

---

界面设计 第九章

界面先行

开始编程之前先设计界面

很多应用人们在开始做的时候都抱着先编程的心态——那是个坏主意。编程是构建应用的过程中最笨重的部分，也就是说，它改动起来最复杂，成本也最高。做应用应该始于界面设计。

界面设计相对来说是比较轻量级的。一纸草图修改起来简单，成本也低。html页面的设计修改起来或是推翻也比较简单。修改程序就不是这么回事了。界面先行可以让你保持灵活；先行编程则会让你陷入花费额外开销的圈套。

界面设计先行的另一个原因是——界面就是你的产品。你向人们销售的产品正是他们能看到的。如果你最后才推出界面，就会出现缺口。

我们先从界面开始，所以从一开始我们就知道这个应用看上去如何，给人感觉怎样。在开发过程中，界面将会不断的改进。合理吗？易用吗？是不是解决了手里的问题？这些问题只有你和真实的界面打交道的时候才能回答。设计优先让你保持灵活而且让你能更早地回答那些问题。

 

---

震中设计

始于页面的核心然后向外延展

震中设计就是关注于页面的本质——震中，然后再向外拓展。这意味着，一开始要忽略细枝末节的东西：导航条或者导航标签、页脚、用色、边栏、标识等，从震中着手，先设计页面中最重要的内容。

页面赖以生存的是其核心。举例来说，如果你正在设计显示博客文章的页面，那么核心就是博客文章本身。不是在边栏里的文章分类，不是顶部的页头，不是底部的评论提交表单，而是实际的博客文章单元。没有博客文章单元，这就不是一个博客文章页。

只有当这个单元完成之后你才能开始考虑页面中次重要的元素。次重要的元素完成之后，你再转战第三重要的元素，以此类推。这就是震中设计。

震中设计规避了传统中 “先搭建框架，再填充内容”的方式。在那种方式里，人们先建立好页面布局，然后把导航条包含进去，然后插入有关销售推广方面的东西，到最后才把核心功能——页面的实际意义所在用来填充剩下的空间。这是本末倒置的做法。

震中设计让你从一开始就关注于真正重要的部分。先做必需要的，再做其他的。结果是给用户一个更友好、重点清晰的界面。并且，这样可以让你马上和设计、开发人员展开对话而不是等到页面所有部分都各就各位之后。

 

---

考虑三种情况下的解决方案

常规、初始、错误三种情况下的设计

对于每一个界面，你需要考虑可能出现的三种情况：

• 常规
  一切运行正常的话，人们看到的是一个充满内容的界面。
• 初始
  人们第一次使用这个应用，在加入内容前的界面。
• 错误
  有错误发生时，人们看到的界面。

常规的情况众人皆知，它将花去你最多的时间。但别忘了也要为初始和错误两种情况花些时间（接下来的文章作更详细地说明）。

 

---

初始界面

期待一个周到的初次运行体验

忽略初始界面的阶段是你会犯的最大错误之一。初始界面是应用留给人们的第一印象，永远不会有第二次这样的机会……这个么，你应该知道。

问题是，设计界面时，通常是事先用数据填充起来。设计者总是用临时数据填满页面模板，每一个列表、文章、输入框、边边角角里都填上内容。这时候界面看上去很棒。

然而，产品在初始状态下是没有内容的。当新人注册，他们将从初始界面开始。就像是一个博客，用户需要自己去充实它。而在用户输入文章内容、链接、评论、日期、边栏的信息或其它数据前，整体外观无法成形。

不幸的是，用户会在初始界面时决定产品是否值得一用——在这个内容和信息最少的阶段来判断产品的适用性。如果你设计的初始界面有缺陷，人们就不知道缺少些什么，因为他们感觉什么都没有。

然而大多数设计者和开发人员仍然认为这种状况理所当然。他们没有很多时间为初始界面做设计，因为当他们开发和使用产品的时候，里面填满了他们用来测 试的数据。他们甚至没遭遇过初始界面。当然，他们可能也以新用户的身份登录过几次，不过他们主要的时间是沉浸在一个充满数据的产品里。

一个有用的初始界面应该包含些什么？

• 利用它作为添加新手指南和热门推荐的机会。
• 给出一个填满内容的页面截图，这样能让人们有所期待。
• 讲解如何上手，页面最终会像什么样子等。
• 回答第一次来的访客会问到的关键问题：这是什么页面？我在干什么？页面有内容的时候是什么样子？
• 做好预期准备，帮助减少挫折感、恐惧感和大的迷惑。

第一印象太关键了。如果没有设计出周到的初始界面，会为你的产品或服务留下反面的（错误的）印象。

 

---

做好防御

出错时的设计

我们得承认：在线上的程序总有出错的情况。无论应用设计得多么用心，无论做了多少测试，用户仍然会遇到问题。那么如何处理这些不可避免的故障呢？做好保护性设计。

保护性设计就像是在小心驾驶。和司机在行车时必须留意道路是否打滑、鲁莽的司机以及其它危险情况一样，网站建设者们必须不断寻找会造成访问者困惑和不满的故障点。好的保护性设计能决定用户体验的好坏。

关于保护性设计的内容我们可以单独写成一本书。实际上，我们已经写了。这本叫《网站的保护性设计》的书对于想学习如何改进出错界面和其他故障点的人来说是非常好的资源。

记住：你的应用可能90％的时间都运行良好。但是如果在用户需要帮助时置之不理，他们是不会忘记这一点的。

 

---

应用环境胜过一致性

这里有意义的那里不一定有意义

动作是使用 按钮 还是用 链接 来实现 ？ 这取决于那个动作。 一个日历视图是应该使用列表方式还是表格方式实现？ 这取决于 它要用在哪里 并且 要显示多长的时间。 全局的导航链接是否需要出现在每个页面上 ？ 是否每个地方都需要一个全局的搜索条 ？ 是否在每一页上需要一个完全相同的页脚？ 答案是“这取决于应用环境” 。

这就是应用环境比一致性重要的原因。 如果你的设计在那种状况下有意义， 不一致也没有什么大不了的。 只给人们重要的。 给他们所需要的，并且去掉其不需要的。 比保持一致性更好的是保持正确。

 

---

文案也是界面设计

每个字母都重要

文案也是界面设计，伟大的界面是写出来的。 如果你认真考虑每个像素，每个图标，每个字体， 那么你要相信每个文字都是至关重要的。 当你写界面时，要常常要设身处地的为阅读你的界面的人着想。 他们需要了解什么？ 你怎样才能简洁明了地阐述 ？

你标注一个按钮的名字是 提交 还是 保存 或者 更新 还是 新建 或 创建 ？ 这就是文案。你是写3句话还是5句？是用一般的举例说明，还是详细阐述？ 如何标注新内容？是 ‘新增的’ 还是 ‘更新的’ 抑或是 ‘最新更新’ 还是 ‘修改的’ ？ 是使用：‘新消息： 5’ 还是 ‘5个新消息’？是 ‘5个’ 还是 ‘五个’ ，是‘5个消息’还是‘5个帖子’？ 所有这些都很重要。

你也需要和你的读者讲同样的语言。 只因为你写的是一个Web应用，这并不意味着你可以使用技术行话。想想你的客户，想想这些按钮和词语对其意味何如。 不要使用缩写 或者 大多数人不懂的词语。 不要使用内部隐语。不要听起来象一个工程师和另一个工程师的谈话。 保持简短和亲切。 说你要说的，别说废话。

好的书写就是好的设计。 界面用词和设计要相辅相成，这很少有例外。 图标要有名字， 表单项要有示例， 按钮要有标签，流程要有一步一步的指示， 退款政策也要有一个清楚的说明。这一切都是界面设计。

 

---

统一界面

合并管理功能到公共界面

管理界面—就是那些用来管理选项，人员等的屏幕界面。—看起来很低劣。这是因为大多数时间都花在了对公共界面的设计上。

为了避免 这种 低劣管理界面 的并发症， 不要分开去开发系统管理界面。 而要把管理功能（例如，编辑，增加，删除）嵌入到应用界面开发中。

如果你必须维护2套分开的界面（如： 一个一般用户用，另一个管理员用）， 这2个都会很难受。 实际情况就像同一个税你交了2次。 你强迫自己重复 并且 这还意味着事情变麻烦的机会大大增加。

 

---

第十章代码

更少的软件(Less software)

让你的代码尽可能简单

你或许认为代码量加倍软件复杂性也相应加倍，但实际上，每增加一些代码，软件的复杂性就随之指数式增长。 代码的每一点增加，每一点改动，每一个相依性，每一个前指性（Preference) 都有着联动效应。轻率地增加代码，不用多久，你就会造出一个可怕的大稀泥巴。

对付复杂性的办法就是更少的软件。更少的软件意味着更少的特征（features），更少的代码和更少的浪费。

关键在于将每一个困难的问题（要求很多的软件）重新描述成一个简单的问题（要求少得多的软件）。你解决的问题也许不是和原先百分之百一样的问题，那也没关系。用20%的努力解决原先问题的80%就是一个很大的胜利。原先的问题几乎从来就没有糟糕到值得花5倍的精力去解决。

更少的软件意味着撇开水晶球。处理今天面对的问题而不是预测未来的问题。为什么？对明天的恐惧常常是毫无结果的。不要让幻想的问题把你拖住。

从一开始，我们就将产品的设计基于更少软件的概念。只要可能，我们就将问题简单化。我们发现，对简单问题的解决方案不仅更容易实施和支持，也更容易理解和使用。这都是我们用来区别于竞争对手的做法的组成部分。我们造的产品要做更少，而不是做更多。

• 软件越少，管理越易
• 软件越少，代码就越少，维护就越少（员工更快乐）
• 软件越少，改变的代价就越低，适应也更快，改变主意也无需更改如山的代码
• 软件越少，臭虫越少
• 软件越少，支持越少

决定哪些特征包括进去，那些特征拒之门外，这也和更少软件相关甚密。不要怕对难以实现的特征说不。只要不是必不可少的基本特征，就不要包括进来。这样既省时省力，也减少混乱。

同时也要慢下来。把一个主意丢在一边，平静一个星期后，再看看这是否还是一个好主意。这额外的酝酿时间，常常会让你想出一个更简便的解决方案。

鼓励程序员提出反建议
你想听到："你建议的方法要花12小时，但我这样做只需1小时，它不做x，但它做y。"让软件推你回来。告诉程序员用他们认为最好的方法去战斗。

还有，寻找可以避免编写更多软件的途径。用屏幕文字的方式建议用户绕道而行，从而避免对于软件模型的更改。比如，建议用户上载指定尺寸的图片，而不是在服务器端作图像处理。

对你的应用（app）中的每一个特征，问问自己：有没有不需要这么多软件的方法来加进这个特征？只写需要的代码，不多不少。你的应用将会更简练而健康。

 

---

为快乐而优化

选择能让你的团队欢欣鼓舞的工具

快乐的程序员也是多产的程序员。这就是我们为什么要为快乐而优化。你也应该这样。不要单凭行业标准或性能指标来选择开发工具和开发方法。看看无形的东西：这其中存在激情、骄傲和精湛技艺吗？每天8小时在这样的环境下工作真的会快乐吗？

这一点在选择编程语言上尤为重要。尽管与公众看法相悖，编程语言并非个个生而平等。虽然几乎每个语言都能写出几乎每一个应用，对口的那个（the right one）不仅仅是让你的努力成为可能和可以忍受，而是让你觉得愉快和充满干劲。这都是为了使得每天工作的小小细节快乐有趣。

快乐有联动效应。快乐的程序员做正确的事情。他们写出简单易懂的编码。他们采用简洁、清晰、易懂和优雅的方法。他们乐在其中。

我们发现了使用语言Ruby编程的极致快感并通过我们的Rails框架（framework）将其传递到其他开发人员身上。Ruby 和 Rails都遵循为人类、为快乐而优化的信条。我们鼓励你尝试一下这对组合，给它们一个一展身手的机会。

总而言之，你的团队需要使用他们喜爱的工具。我们这里谈的虽然只是有关编程语言，但其原理也适用于应用、平台和其它任何东西。选择让人们兴奋的导火线，带来激动和鼓舞，更好的产品也就接踵而至。

 

---

代码在说话

当你的代码将你打回，聆听

聆听你的代码。它将提出建议。他将把你打回。它将告诉你毛病在那。他将建议新的做事方法。他将帮你遵循更少软件的模式。

一个新特性需要几个星期的时间和几千行代码？这是编码在告诉你很可能有更佳的方法。有没有简单的方法让你一小时完成代码而不是需要十小时的复杂的方法？这又是代码在指引着你。仔细聆听。

你的代码将引导你找到又便宜又轻易的修补办法。在捷径显露出来时要倍加注意。当然了，容易做的特性也许与你原先所想的特性并不完全一致，那又何妨？只要它足以胜任，并且给你更多时间作别的事情，那就留着它。

 

---

管理债务

还清你的代码和设计"账单"

我们通常将债务与金钱挂钩，但债务还有别的形式。你可以很容易就拖欠代码和设计的债务。

东拼西凑一些能用但让人汗毛直竖的代码，你就是在增加债务。随便搞一个足够好但并非真正好的设计，你还会再来一遍。

偶尔为之，不足为虑。实际上，它常常是你完成整个"迅速实现"事情所需的技巧。但还是应该认识到它是一笔债并需要在其他时候通过清理可怕的代码和重新设计差强人意的页面这种方式进行偿还。

就像你该定期将部分收入纳税一样，定期将一部分时间偿还你的代码和设计债务。否则，你只是付着利息（修理劣作），而不是偿还本金（并迈步前行）。

 

---

开放门户

让数据通过 RSS，API等途径走向世界

不要试图锁住你的客户。客户想什么时候，以何种方式拿他们的数据都要悉听尊便。要做到这一点，我们必须放弃将数据封存的念头。而要让数据遍地跑。让人们通过 RSS Feed 取得他们的数据。提供 API 让第三方开发商在你的工具上进行开发。这样做不仅让你的客户的日子更好过，而且还扩大了你的应用所能做的事情的可能性。

过去人们常常认为 RSS Feed 只是用来跟踪博客和新闻网站的好方法。但它要比这更强大。它也是客户无需一次次地登录就能获得一个应用的内容最新变化的绝妙方法。Basecamp 的 RSS 使得用户只需将 URL 放入新闻阅读器（newsreader），从而无需频繁登录网站就可以留意项目信息、任务列表（to-do lists）和项目里程碑。

API 让开发者为你的应用建造附加（add-on）产品。这些产品的价值很可能难以衡量。例如，Basepack 提供的 API 让 Chipt Production 公司开发出在苹果Mac OS X 上使用的任务栏组件（Dashboard widget）。这个小组件让人们从桌面电脑增加、编辑提醒单（reminders），列表项和更多信息。客户们对此欣喜若狂，甚至说这是促使他们使用 Backpack 的关键因素。

公司让数据自由流动以获得回荡效应的其它好榜样：

• Google Maps API催生了有趣的结合应用（mash ups）。这些结合让人们把从其它来源摘取的数据（比如公寓租售列表）绘到地图上。
• Linkrolls提供办法让人们获得最新的 del.icio.us书签并显示在他们自己的网站上。
• Flickr 让其它公司使用商业 API 以便顾客能购买相册、海报、DVD 备份和邮票。来自Flickr的 Stewart Butterfield 说："我们的目的是百分之百开放，并对你需要用照片来做的事情提供最多的选择。"

 

---

文字 第11章

功能定义一点用都没有

不要写功能定义文档

这些蓝图文档通常和成品几乎毫无关系。理由如下：

功能定义文档是虚幻的

功能定义文档不反映真实情况。一个应用只有在被构造时、被设计时，和被使用时才是真实的。功能定义文档只是纸上谈兵

功能定义文档是无关痛痒的

功能定义文档可以用来让人感受到参与的乐趣，措辞温和但是并不是那么有用。它们不关心艰难的抉择，不关心成本——而这些正是建立一个成功的应用所必须考虑的。

功能定义文档只能达成虚幻的共识

看文字并不能让人们达成共识。大家可以读到同样的文字内容，但每个人的想法却可能不同。以后将不可避免地发生这种情况：“等下，我不是那样想的。”“啊？我们可不是这么说的。”“是的，就是这样的，我们大家都同意了——你还签过字呢。”我相信，你知道该怎么做。

功能定义文档逼迫你在拥有最少资讯时作出最重要的决定

当你刚开始构建时，你知道的是最少的。而做得越多，用得越多，你才能了解得越多。这才是你应该做出决定的时候——即当你有足够多信息，而非信息少的时候。

功能定义导致功能泛滥

功能定义阶段对整个过程没有什么推动。 写点东西加个标注，看上去并不需要什么代价。你可以加上他们欣赏的功能，让那些令人头疼的人高兴。然后你按照那些写下来的文字标注设计，而不是为人设计。 最终你得到的将是一个拥有30个栏目的臃肿站点

功能定义让你无法变通、变化和重新评估

一个功能一旦得到认同，即使在开发阶段你就意识到它是个坏主意，你也不得不照做。一旦你开始做某事，一切都在变化，而定义却不会去处理这些实际情况。

那么，你应该做什么去替代功能定义呢？ 去写一个简明的替代文档，以此引导你去做那些真正的事。 写一页的说明去描述这个应用要做什么。 使用平实的语言并且要简短。 如果要阐述的内容超过了一页纸，就太复杂了。 这个过程不应该超过一天。

接下来开始建立界面----界面将成为功能文档的替代物。 在纸上简单快速地画些草图。 然后把它写成html代码。 界面设计是每个人都会认同的共同基础，这不同于，大段的文字可以有不同的理解。

人人都使用同样的屏幕界面时， 混乱不见了。在你开始担心后台代码之前，要建立一个人人都可以看得见的，使用的，点击访问的，并且可以“感受到的” 界面。 一定要尽量把自己置于客户体验之前。

忘记那些锁定的功能定义。 它们迫使你做大，在太早的时候逼你作关键决策。 略过功能定义阶段，你将可以便于改变并且保持灵活性。

 

---

别写死文档

根除不必要的文书工作

避免写功能规格定义是一个好的开始,但不要仅只于此；要处处避免过分的写文档工作。除非有个文件确实要演变成现实, 否则别写它。

建造出来,别写出来。如果你需要解释什么,先建造一个原型而不是写一份冗长的文档。实际的界面或原型是你正在构建一个真正的产品的很好说明。另一方面,一纸文档,只能说明它们终将被丢入垃圾桶。

这里有一个例子:如果一个线框文件是注定要停止,并且永远也不会直接变为实际设计,不要为此烦恼。而如果线框开始作为一个线框造型并且演变为实际设计,那就用它。

脱离实际应用而存在的文档是没用的。 它们对你没有帮助。 你在作的所有事都应该最终变为真实存在的。 如果一个文档在变为真实之前，就停止了，那它完蛋了。

 

---

告诉我一个短故事

写故事,别写细节

如果你发现你确实需要来解释一个新的特征或概念,写一个简短的故事说明之. 别陷入技术或设计的细节,只讲一个短故事. 象你在正常的交谈时和一个人讲话的方式一样。

它并不需要成为一个短文。只要象记流水账似说明发生什么事。如果拿出你正在开发的屏幕作背景，来简述这个故事,那就更好了。

坚持经验,而不是越来越拘于细节。考虑战略,而不是战术。一旦你开始建立的你的那部分应用，战术自然就会适得其所。现在你只是要想出一个故事,发起讨论,然后使你步入正轨。

 

---

使用平实的语言

填入真实的文字而不是测试用的胡乱用语

测试用的胡乱文字（Lorem ipsum dolor）一直是设计者的忠实伙伴。 虚拟文字帮助人们认清设计完成后的观感。但是这些虚拟文字会很危险。

测试用的胡乱文字改变了拷贝的视像。 使得文本内容弱化为一个视觉设计元素 --- 文本形状 ---而不是其本来面目：有价值的某人录入/或要读的信息。 虚拟文本意味着你不会看到当真实信息录入后出现的不可避免的改变。这意味着你不会知道在你的站点填写表格时会是什么样子。 虚拟文字是隔在你和现实之间的面纱。

你需要真实的拷贝去认识某个字段要多长才合适； 你需要真实的拷贝去懂得表格是怎样扩展或收缩的； 你需要真实的拷贝去感知你的应用看起来究竟怎么样。

只要有可能，你就要使用真实，准确的用语。 如果你的站点或应用需要数据输入，那就录入真正的交易数据。并且要敲入实际的文本--不要从其他来源拷贝粘贴。 如果那是一个姓名，就敲入一个真实的姓名。 如果是个城市， 录入一个真正的城市。如果是一个密码，就要重复2次，录入2次。

确实，从上到下过一遍表格并把每项都填入垃圾数据（"asdsadklja" "123usadfjasld" "snaxn2q9e7"）是很简单。但是这不真实。 你的客户一定不会这样使用。当客户被强迫要长途跋涉时，你却走捷径，这能算是精明么？ 当你用连发开火的方式快速录入假数据时， 你根本不会体会到填表格时的真实感受。

象你的客户那样去做，你才能更好的理解他们。 当你更好的理解他们时， 你会感同身受，做出更好的界面。

 

---

个性化你的产品

你的产品的个性类型是什么？

把你的产品想象成一个人。 你要赋予他什么个性类型？ 有礼貌？ 严肃的？ 慈悲的？ 精确的？ 有趣的？ 无表情的？ 认真的？ 自由的？ 你想它以怎样的面目示人，是偏执的 还是令人信服的？ 是作为一个万事通？ 抑或是谦逊并且人见人爱 ？

一旦你确定下来，就要在构建产品的过程中时刻记得保持这些个性特征。利用这些个性指导拷贝写作，界面设计 和 功能项配置。 一旦你想要改变什么， 自问一下这会不会改变你的应用的个性特征。

你的产品有声音---会一天24小时的不停地与你的客户交谈。

 

---

定价和注册 第12章

免费样品

免费赠送

外面的世界很嘈杂。为了让人们在喧嚣中注意到你，免费赠送一些东西吧。

聪明的公司都知道免费发赠品是吸引顾客的一个好方法。看看苹果公司，他们提供免费的 iTunes 软件，是为了建立客户对iPod 和 iTunes 音乐存储的需求。在网下的世界里，零售商们也这么做。星巴克公司认为，每送出5个饮料赠品，就刺激了一种新商品的购买。不要太小气。

对于我们来说，Writeboard 和 Ta-da list 是完全免费的应用，用来吸引人们逐渐使用我们的其他产品。同时，对于我们所有的应用，我们总是提供一些免费的版本。

我们希望人们来体验我们已经完成的产品、界面和有用的东西。一旦他们着迷了，就更有可能升级到一个付费产品（付费产品提供更多的项目或页面，让人们获得更多的功能，比如：文件上传和ssl数据加密）。

 

---

来去自如

让注册和注销的过程毫不费力

在你的程序里注册和注销应该尽可能简单。

如果我是一个客户，想用你的产品，这应该是一个毫不费力、轻松容易的事。在销售站点的每一页都放上一个大大的、清楚的注册按钮。告诉大家这是多么容易的事：“从注册到登录仅仅只需要1分钟！”

应该总是有个自由选项，让客户不用输入信用卡信息就能进行产品演示。有些公司需要用户确认、预约或者特殊密码才能体验他们的产品，根本就没有必要这么做。任何人随时都可以自由地体验我们的产品而无须提供任何信息。

注册表单要尽可能短。不要问一些并不需要的问题，不要抛出一个长得吓人的表来为难大家。

这些原则同样适用于注销过程。永远不要指望把人们“困在”你的产品里。当有人决定注销他们的Basecamp 帐户时，尽管我们感到遗憾，但是我们不会让注销过程繁琐或是含混不清。个人帐户页就有一个“注销我的帐户”的链接，并不需要发邮件、填写特殊表格或者是回答问题。

同时，如果他们决定离开，要确保能导出他们的数据。我们确保客户随时可以轻易地导出xml 格式的所有信息和评论。那是他们自己的数据，他们理应能按自己的意愿来处理。

这一点很重要。因为给予人们掌握他们自己信息的能力可以塑造对我们的信任。这给了他们一座通向自己的数据岛的桥梁。如果他们找到了一个能提供更优服务的地方，让他们自由离开。这么做是对的，而且可以建立良好的声誉。

 

---

Silly Rabbit, Tricks are for Kids

规避长期合同和注册费用等

谁都不会喜欢长期条款，提前终止费或是一次性的安装费，所以要避免这么做。我们的产品付费方式为月付，不用签订条款，你可以随时取消，而且从不会有什么安装费。

别企图去找什么“高明”的方式以赚得更多的钱。Earn it.

 

---

塑料子弹

用提前通知和保留条款来缓和坏消息给用户带来的打击

要发布类似提价这样的坏消息啦？应该多次提前通知，尽量把坏消息带给用户的痛苦降到最低。同时，应考虑在保留条款中规定，现有客户在一定时间内仍可以原价使用产品。用户就是你的奶油和面包，你要让他们感受到被重视，而不是被欺骗。

 

---

第十三章 推广

好莱坞运作

从挑逗 到 预演 到 开幕

如果你的应用选在森林中发布，每人会去使用， 它弄出动静了么？ 关键一点是，如果你在发布应用之前没有一些事前吹嘘，人们根本就不知道有这回事。

为了闹出个大动静和引起期待， 学学好莱坞风格的运作： 1） 挑逗 ， 2） 预演， 3）上演

挑逗

提前几个月要开始不断透露些暗示。 让人们知道你在干什么。 发布一个徽标。 在你的博客中发布一下进展。 保持神秘，但是要播下种子。同样，建立一个网站，好让你可以从那些感兴趣的人那里收集电子邮件。

这个阶段， 你也要开始引诱专业和业内人士。 这些家伙站在前沿。 他们是引领时尚潮流的人。他们的虚荣心和其作为时尚领导者的地位,使其容易被吸引。 告诉他们，要安排他们参加秘密进行的内部预演。 如果有一个象 Boing Boing， Slashdot 或者 Digg 这样的站点链接了你的（Web）应用，你就会有大量的浏览访问量跟进。另外，你在Google的网页评级也会水涨船高。

预演

发布前的几周， 开始预演特征。 给人们幕后入口。 描述产品的主题。 对于Basecamp ， 我们发布了屏幕截图 和 高亮度的提示条， 里程碑 和其他一些特性。

同样， 告诉人们此应用背后的思想和原则。例如 Backpack ， 我们在上线前公布了产品宣言。 这使得人们去思考并且谈论这个应用。

你也可以给少数人发放一些特殊“金元券”，让他们可以提早开始使用这个应用。 这些自我感觉提前被选中，享受了特殊荣耀的人其实充当了你的beta版测试人员，你从中获益。

同理， 一旦上线发布，鼓励人们来注册，你因此可以得到大量的电子邮件用来发起闪电般的宣传攻势。 当我们的应用正式发布时，成千上万的电邮向我们涌来，这对赚取眼球帮了大忙。

上线（开演）

正式上线时间到了。 现在人们可以真正地去“剧院”看你的应用了。 发邮件给那些注册的用户。 发布你的全面营销网站。 尽力到处散布你的信条。 让博客都链接到你。 公布你的进步： 已注册了多少用户？已经进行了那些更新/调整 ？ 显示你的成长势头并且保持住。

 

---

强大的推广网站

从 花絮 到 预演 到 上线

最佳推广工具是一个伟大的产品 。 全世界会发现你拥有一个确实有用的应用

即便如此， 你仍需要一个顶级的推广站点。 在这个网站中要有什么？ 这是一些主意：

• 概览: 说明你的应用及其益处
• 导游: 引导人们体验各项特性
• 屏幕截图和录像: 展示应用面貌并演示如何使用
• 宣言: 阐述其背后的哲学和思想
• 案例研究: 展示现实生活中的案例的可能性
• 共鸣: 引用来自客户，评论，新闻的证明材料
• 论坛: 提供社区会员相互帮助的场所
• 费用和注册: 尽快让人们使用你的应用
• 博客: 博客提供新闻，技巧等，使你的网站保持活力

 

---

驾驭博客潮流

博客可以比广告更具效力（而且便宜很多）

广告很贵。 而且评估各种类型的广告的效果，已被证明比广告本身还有昂贵。 当你没有财力和时间去走传统的广告路径时，应该考虑一下通过博客推广的路线。

应该一开始就建立一个博客，不仅可以招揽顾客，还可以提供有帮助的建议，技巧，花招，链接等等。 我们的 信号vs噪音 博客，由于每天都张贴出一些 有帮助的，启迪的 和 有趣的信息和奇闻轶事，每周都会吸引来成千上万的读者。

因此，当要推广我们的第一个产品 Basecamp 时。 我们在SVN上透露了这个消息，并开始传播。 象 强森 考特克，BoingBoing用户，吉姆 库都 这些人，和身份各异的其他一些拥有博客的人，帮我们提升了可见度。推广工作起飞了。

Ta-da 代办事宜列表是另一个显示了基于博客进行市场营销威力的伟大案例。 我们在 信号vs噪音 上只发了一个关于Ta-da 上线的帖子，几周后就有 200 多个博客提到了它，并且 12000 人注册了自己的Ta-da 待办事宜列表 帐户。 关于Backpack的消息传的更迅速。上线后24小时， 就有 10000 个用户注册。

 

---

尽早征集

尽早获得议论和注册

我们已经略微谈到这点，并且认为值得重复： 要建立某类网站 , 要尽快征集邮件。选定你的域名并且发布你的徽标，还要写上一两句，或者至少也要暗示一下，你的应用是作什么用的。然后，要求人们留下电子邮件地址。现在，你已步入正轨，因为已经有了一帮想在上线发布时准备得到通知的人。

 

---

通过教育推广

与世界分享知识

当一个老师作为选手出现在 Jeopardy 电视节目上时，亚历克.特别可 常常评论说，教师是个高尚的职业。因此可以肯定和别人分享知识是十分美妙和很有收获的一件事。 他是对的。 当你教的主题是你的应用时 ，这具有双重目的：你能回馈社区，这不仅支持了你，还可以在同一时间 为你的那些漂亮的宣传曝光取得加分。

作为一项推广技术，教育是用一种软的方式来 把你的名字---你的产品的名字----摆到更多的人面前。而不是采用强硬推销 "购买此产品"的方法，通过提供有价值的服务，你越来越引起重视。此举激发了积极的共鸣，是传统的营销策略不能比拟的。那些受你教育的人将成为你的福音传播者。

教育可以有许多形式。人们通过在你的网站上发表窍门希望同他人分享。在会议上发言并且会后和与会者见面。举办讲习班，让好奇的粉丝可以学到更多并且与你恳切交谈。 接受出版物的采访。写文章，分享有益的资料。并且写书出版。 ; ）

如我们历来采用的例子，使用“黄色渐淡技术”，这是我们发明的一种方法，用来巧妙地高亮标明页面上最近修改过的区域。 关于它，我们在“信号与噪音”写了一个帖子。这个帖子不断被浏览，已经被浏览了成千上万次（至今应该已有极大的访问量）。

那个帖子在教育和推广层面都起了作用。学了一招，并且原先很多绝不会知道我们的产品的人也被暴露在产品面前。 另一个例子：在我们的使用Ruby on Rails研发的阶段，我们决定把基础框架开放源代码。这被证明是个明智之举。我们把一些成果回馈社区，建立商誉，赢得我们团队的认可，收到了有益的反馈，并开始收到来自世界各地的程序员的补丁和无私奉献。

教学总是好事。 你先付出。你在帮助别人,就会得到一些很好的促销效果。你甚至可以沐浴在一丝高尚的荣耀里。那么，你知道世界想要听到什么？

(译注： Jeopardy! 摘自：维基百科， 一个国际电视测试游戏节目

 

---

特色食品

他们渴望得到的,就给他们

新的或有趣的特性是一为你的应用引起共鸣的很好的办法。特殊兴趣小组爱咀嚼"特色食品"，并且吐回回馈社区。 好吧，这是一种不愉快的比喻，但你得明白这一点。

举例来说，通过使用Ruby on rails，一个新的开发框架，我们的basecamp引起了开发社区的巨大关注。

在我们应用中使用的ajax的元素引起许多反响，甚至连 “商业2.0杂志” 也把 37sigals作为一个"Ajax的关键角色"， 把我们与一些响当当的公司，如：谷歌，雅虎，微软以及亚马逊等并列。

另一个例子：很多博客注意到了 Basecamp 的rss支持，因为它是企业的rss的最早的应用之一 。

集成iCal，一个看似轻微的小特色，使我们得到了原本永远也不会提到我们的应用的Mac(苹果)相关站点的大量关注。

小团队时刻准备把新想法整合到软件中去。而大公司要处理官僚主义瓶颈，你能够迅速实施新想法并且因此受到重视。

掌握使用最新时髦技术的花边噱头，是一种有效且廉价的方式来引起轰动效应。那种不要加入最新暧昧技术的说法只是为了引入注意。但是如果你正在使用了一些新的或引入瞩目的技术，一定要继续使用并且把它在特殊兴趣社区中大肆宣传。

译注：iCal 摘自： Apple中国- Mac OS X - iCal iCal 允许你以天，星期或者月查看你的计划表。并且使用iCal 强大的搜索功能，找到你日程表上的内容就更容易了。）

 

---

跟踪你的日志

研究日志并跟踪共鸣

你必须知道谁在谈论你。检查你的日志，找出共鸣来自哪里。谁链接了你？谁在诽谤你？ 哪些列在 technorati blogdex ， feedster ， del.icio.us 和Daypop 上的关于你的博客文章最热门。

找出来这些博客，然后让感觉到你的存在。在这些博客上留下评论。感谢他们链接到你。问他们，是否想被列入你的特别提前通知名单，这样他们将最先知道你的应用的未来发布，更新等等。在你的站点上收集积极的赞扬并建立一个"共鸣"网页。 证人证言是一个推广你的应用的伟大的方式，对于广大的人群而言，来自第三方的赞美更值得信赖。

如果评论是负面的，你还要注意。显示你在认真听。 仔细地回应批评意见。可以这样说： "我们很感激你的反馈，但我们这样做是因为....." ,或者, "您提出一个好一点，我们正在加紧努力实现。"，这将软化对你的批评，并使你的产品显出了一副人性化面孔。在博客上的深思熟虑的评论可以驱散唱反调者，甚至把抱怨的人转化成了你的福音传播者，这真是令人惊奇的事。

 

---

内线追加促销

在应用内部推销升级机会

谁都知道选择网站营销。但是销售不仅止于此。 如果你有一个分级的定价策略（或，你的应用有个免费版），不要忘了在产品内部大声呼吁升级的机会。

告诉人们 他们升级后，你会撤除限制。 例如： 在Basecamp 中，使用免费帐号是不能上传文件的。当有人试图上载一个文件，我们并不是简单的拒绝。 我们会解释，因何文件上传不能用，并鼓励他们升级到一个付费版本，并说明这样的好处。同样的方法也用来鼓励现有用户当其现有规模已达极限时 升级到更高一级的用户帐户。

现存用户是你最佳销售对象。在向这些已经熟知并已使用你的产品的用户进行重复销售时，请不要害羞。

 

---

名字的魔力

给你的应用起个好记的名字

好多人都想给其应用起一个极其具有描述意义的名字，这是一个大错误。不用担忧 挑一个能生动说明你的应用的用途的名字。这通常会产生一个一般意义上的，容易被遗忘的名字。 Basecamp 是一个比什么 “项目管理中心” 或者 “项目特快”更好的名字。 Writeboard(写字板)这个名字要比 CollaborEdit(协作编辑)这个名字要好。

同样在起名过程中也别太指望群策群力。 挑选一个简短，上口，好记的名字并且马上使用之。

并且，如果你没有取得那个你想要的确切域名，也别急躁。 你经常可以有创造性的使用一些其它的字母。（例如： backpackit.com 或 campfirenow.com）

 

---

第十四章 技术支持

感知痛苦

拆除研发和技术支持之间的墙壁

餐饮业中，在厨房干活和在前台服务顾客是两个截然不同的世界。这两边的相互理解和支持尤为重要。这就是烹饪学校和餐馆经常让厨师在前台作侍者服务顾客的原因，这样厨房的员工就可以和顾客接触并且体会到前台工作的真实情况。

很多软件开发人员也有类似的分工。 设计者和程序员在“厨房”工作， 支持人员应对客户。 不幸的是，这意味着软件大厨从来不会听到客户的真实意见。这是很有问题的，因为倾听客户的声音是你改善产品优缺点的最好途径。

解决方案？ 避免在你的客户和研发/设计之间竖起一堵墙。 不要把客户支持外包给呼叫中心或第三方。而是自己来做。你，和你的整个团队，应该搞清楚客户的意见。 当客户烦恼时，你需要知晓。你要听他们的抱怨。你也要因此烦恼。

在 37signals公司， 所有我们的技术支持邮件，都是真正的产品构建者亲自回复。 为何如此？ 首先， 这为客户提供更好的支持。 他们得到了从构建应用的某人脑中想出的一个 直接回应。 其次，这使我们和使用我们的产品并且遇到问题的人们保持接触。 当他们受挫时， 我们也受挫。我们可以说， “我感知到了你的痛苦”，并且我们感同身受。

依靠统计分析来揭示问题点，很有诱惑力。但是统计数字和真实声音不可能一样。 你需要尽力去消除尽可能多的这种缓冲区，它挡在你和客户的真实声音之间。

前台是行为发生的地方。 去那里。 让你的大厨干侍者的活。 读客户邮件，听到他们的挫折，倾听他们的建议并且向他们学习。

 

---

零培训

使用内嵌的帮助和常见疑难解答，产品就不需要手册或使用培训

你不需要一个手册去使用Yahoo 或者 Google ， Amazon。 因此， 为什么你不能也建立一个不需要手册的产品呢？ 力争建立一个这样无须培训的工具

你该怎样去做？ 好吧， 就像我们以前提到的，你开始就要保持简单。 你的应用越不复杂，你就越能免除帮助人们摆脱困境的麻烦。之后，一个伟大的事前支持途径是在潜在的、容易引起疑惑的地方，使用内嵌的帮助和常见疑难解答。

例如, 我们在屏幕上给出事先支持，允许 Basecamp 用户上传他们的 徽标。 有些人经历过这样一个问题，他们老是看到老的徽标，这是浏览器缓存引起的一个问题。因此在"提交你的徽标" 旁边的一个区域，我们增加了一个链接指向 这个常见疑难解答，来教客户 强行刷新 浏览器 以便看到新的徽标。在我们这样做之前， 我们每天都要接到5个关于此问题的邮件。现在一个也没有了。

 

---

快速回答

在疑难问题上的快速响应时间应该置于最高优先级

当你快速解答他们的问题时，客户很高兴。 他们已经习惯了录音电话式的支持，需要等几天（如果有的话），因此你可以通过提供体贴的即时响应区别于你的竞争者。 在工作时间， 我们在90 分钟内答复百分之九十的支持邮件，并且经常不到半个小时就完成了这项工作。人们喜欢这样。

即使你没有一个完美的答复，说点什么。 你可以用开放，诚实的方法 一个快速回复来赢得善意。 若有人抱怨有个不能马上得到解决的问题，象这样告诉他们, "我们已知道你所言那个问题，我们即将在不久之后仔细研究一下。" 这是驱散潜在负面困境的一个很好的方法。

客户欣赏直率，并且经常转怒为喜，如果你用一种切中要害的方式快速响应。

 

---

强硬的爱

乐于向客户说 不

至于功能需求，客户并不总是正确。如果我们把客户需求的每个零零碎碎都加入产品中，那么没有人会要我们的产品。

如果我们屈从一个客户的一时的兴致， Basecamp 中就会有： 全面的时间跟踪， 全面的帐单，全面的会议安排，全面的日程安排，全面的附属任务系统，全面的即时消息聊天，全面的wiki功能，和全面的随便什么你能想到的。

然而， 我们通过客户调查得到的第一号 需求就是 要 保持 Basecamp 简单。

这里还有另一个例子： 尽管有一些怨言， 我们决定产品不支持IE5， 这样就有 7% 的市场被我们抹去了。但是我们认为我去关心剩下的 93% 更加重要。 为IE5 修补产品错误和测试在时间上不划算。 我们宁愿为其它93%的每个人作一个更好的产品。

作为一间软件研发公司，你必须扮演过滤器的角色。 并不是每个人建议的每件事都是正确答案。 我们认为客户所有的需求并不总是正确。 你不得不时常让一些人伤心失望。

关于这点， 作为一间研发公司热爱你的产品是最重要的。如果你的产品中掺和了一些你不认可的因素，你将不会爱你的产品。这是必须要否决你不认同的客户需求的另一个明证。

 

---

良好的论坛

使用论坛或聊天室让客户互相帮助

论坛以及基于Web的讨论组是让客户提问及互相帮助的绝佳方式。通过提供开放的交流平台，消除了中间人——即你自己的角色，为你节约了流程时间。

在我们的产品论坛中，客户发布应用技巧及窍门、功能需求、故事等诸多信息。 我们常常参与其中以为他们提供帮助。但论坛应主要是社区成员互相帮助及分享产品体验的地方。

你会惊奇地发现有那么多人是如此乐于助人。

 

---

公开你的错误

拿出坏消息别让它挡道

如果某事出错就告诉人们。即使他们开始并未曾发现。

例如， Basecamp曾经在半夜宕机了数小时。 99%的顾客都未曾察觉，但是我们仍然在我们的Basecamp博客大全上张贴了“意外停机”的公告。 我们认为顾客该知道此事。

这是一个在我们出错时，张贴的公告的一个样本： “我们为今晨停机谨此致歉-我们有一些数据库问题，导致了某些用户的重大减速和故障。我们已经修复问题，并正在采取步骤，保证这个故障不会再次发生… …感谢你的耐心，并再次，为停机道歉。”

要尽可能开诚布公和透明。 不要保秘也不要遮遮掩掩。知情的客户是你最好的客户 。 另外，你也会意识到大多的错误,在你的顾客的心中并不是那样地糟糕。 客户通常乐意给你一点喘息空间，只要他们知道你对他们是诚实的。

关于发布消息的旁注，好和坏： 当坏消息来时，立即把全部公开。另一方面 ，应该慢慢地一点一滴地透露好消息，如果您能延长好的信息起到的效果，那么一定要这样作。

 

---

第十五章 上线之后

一个月调整期

上线30天后发布一个重大更新

快速更新显示你的干劲。也表示你在听。还显示你有更多的后备招数。这使你能引起第二波的共鸣。加强了最初的好印象。 这给你一些谈资的和其他博客评论的话题。

明知快速升级迫近，使你在发布前把精力集中放在最关键的部件。 与其试图加入更多东西，不如开始真正完善核心功能群。 那么你就可以在真实世界推出产品。 一旦它在那里了，你可以开始收集客户的反馈意见，你就会知道其后的哪些方面需要注意。

这个婴儿学步的做法在 Backpack 行之有效。我们首先发布了基础产品，然后在数周后，加入一些新功能，象 Backpack移动手持设备和标签，因为这些东西是我们客户告之的，他们最想要的功能。

 

---

保持发帖量

上线后维护一个持续的产品开发博客，显示你的产品充满活力

上线后不要停止写博客。 用一个专门的经常更新的博客，显示你的产品是充满活力的，（至少每周一次，如果可能应该时常更新） 。

这些事情包括：

• FAQ 疑难解答
• How-to 指南
• 小贴士 & 技巧
• 新功能，更新 & 补丁
• 杂碎/新闻

一个博客不仅标志着你的应用充满活力，也使你的公司似乎更加人性化。 再次，不要害怕保持友善的和个性化的语气。小团队有时感觉需要保持一种听起来像大公司一样的语气，并且在所有时间里都要表现的极其专业。这几乎就像一个商业版本的拿破仑综合症（译注：矮人自卑心理）。 不要因为听起来小就害怕。 事实上这其实很好，你可以跟客户像朋友那样聊天。

 

---

更好，而不是测试版

不要用"测试版"作替罪羊

这些日子感觉一切都是永远在测试阶段。 这真是一个好推辞。 一个无休止的测试阶段告诉客户你不是真的决心生产出成品。 像在说 ， "先用这个，但如果它不完美，这不是我们的错" 。

测试版将球推给你的客户。如果你对你的发行版没有足够的信心，你怎能期望公众会有呢？私下的测试版还好，公开的测试版简直就是胡扯。 如果产品对于公众使用而言还不足够好，就不要让公众去使用它。

不要等待你的产品尽善尽美。这不会发生。 对你发布的东西要负责。把它推出并称其为发布版。否则，你只是在找借口而已。

 

---

所有缺陷并不生而平等

分清缺陷的轻重缓急（甚至可以忽视其中一些）

只因为在你的产品中发现一个缺陷（bug） ，并不意味着这时候要引起恐慌。 所有软件都有缺陷---这是一个活生生的事实。

您不必每次马上就修补漏洞。 大多数缺陷（bug）是让人烦恼的，但都不是毁灭性的。 困扰问题可以搁置一会儿。 那些导致"看起来不太对"的错误的缺陷或其他小错误可以安全地预留一会儿。 如果一个缺陷（bug）破坏你的数据库，这时，显然需要修补。

分清缺陷的轻重缓急。 有多少人受到影响？ 问题坏到什么程度？ 这个缺陷bug值得立即重视吗或可以等待？ 你现在做什么将对绝大多数人产生最大影响？ 很多时候，加入新的功能，甚至比更改现有缺陷更为重要。

同时，要创造一种别害怕周围缺陷bug的文化。 缺陷发生，别总是找人去责怪。 你最不需要的就是这样一个环境，缺陷被私下解决，而不是通过公开讨论。

记得我们以前说过诚实的重要性。 如果客户抱怨的一个缺陷bug ，可以与他们坦诚相见。 告诉他们你已经注意到这个问题并在处理。 如果不能马上纠正，你要说明理由，并且说明你在专注于改进产品的某些影响更广泛的方面。 诚实是最好的政策。

 

---

安度风暴

等到要求改变的应激反应停止后再采取行动

当你在小船上摇晃，将会激起波浪。 当你引入一个新的功能，改变了一个政策，或删除了什么，应激膝跳反应，往往负面的，就会涌入。

要抵制恐慌情绪，和拒绝作出迅速改变的反应。 激情在开始时闪耀。 但如果你安然度过这最初的24-48小时，事情通常会平静下来。大多数人在向你反应之前，他们并没有认真的使用和挖掘你添加的功能（或习惯你已经删除的那些功能） 。所以你要坐稳，让这些反应都进来，并且在没有等待一段时间的情况下，别采取任何行动。 然后你可以采取一种更合理的反应。

还记得负面反应几乎总是高过正面的，而且更加充满激情。 事实上，你可能仅呢个听到负面声音，即使在大多数的用户对变化感到高兴的情况下。 请务必不要愚蠢到为了一个有争议的，但却必须要的决定，而作出后退的妥协。

 

---

保持先知先觉

订阅你的竞争对手新闻消息

订阅你的产品和你的竞争对手的新闻消息（知己知彼总是明智的）。 使用像 PubSub, Technorati, Feedster的这些新闻反馈服务，得到最新更新（用关键字，公司名称和产品名称） 。使用RSS ，这个不断变化的信息源将把信息直接传递给你，是你总能跟上前进的速度。

 

---

小心那个臃肿的怪物

更成熟并不意味着更复杂

事物发展中，不要担心抵制臃肿。 诱惑将是做大。 但是那样并不总是正确。 只因为有些事物长大并且更加成熟， 但这不意味着要变得更加复杂。

你并不需要成为一个外太空钢笔，要上下颠倒地书写。 有时成为一支铅笔就挺好。 你不需要是一把瑞士军刀。你可以作一把螺丝刀。 你不需要做一个潜水表，在5000米下还安全工作，假如你的客户是陆地爱好者，只想知道现在几点了。

不要因为膨胀而膨胀。这是许多应用变得臃肿的原因。

新的并不总是意味着改进，有时你应该找准你的产品的定位点。

这是基于Web的应用优于传统桌面软件的主要好处之一。 桌面软件生产商 如： Adobe， Intuit，和微软每年都要向你兜售新版本。 只因为他们不能总是卖给你相同的版本， 他们不得不通过添加新功能为收费提供正当理由。 正是从这里软件变得臃肿了

Web软件是基于订阅收费的模型之上， 人们按月付费使用服务。 你不需要通过不断增加更多更多的功能来进行增值销售，你只需要提供一个持续的有价值的服务。

 

---

跟著潮流走

对于新的方向保持开放的态度

Web 应用的美丽之处在于它的流动性。你沒有必要把它包裝在一個盒子里，邮寄出去，然後枯等几年后的下一个版本；你可以一边实施一边调整。保持开放的态度，尤其是您原始的点子可能并不是最好的这种情况下。

看看 Flickr。一开始它是个叫做 The Game Neverending（无结尾游戏）的网络游戏，但它的创始人很快地发现游戏內分享照片的功能比起游戏本身，反而是个比较可能的产品（游戏最后是搁在架上尘封了）。要愿意承认错误并且修改方向。

当个冲浪者。观察海洋。想出大浪什么时候來並且依照它來调整。

 

---

第十六章 总结

发动引擎

完成了！

完成了！希望您已经跃跃欲试，急不可待地在您的软件上开始 Getting Real。但是想用最少的资源来创造伟大的软件，决不是那么简单。您需要有正确的点子、激情、时间与能力——决定着您最终所能达到的高度。

最后一些收尾的想法：

执行力

每个人都能读书，每个人都能想到好点子，每个人都可以是网页设计师，每个人都会写博客，每个人都能够雇佣程序员写程序。

但您和其他人的差別在于您如何将他们变成现实。成功取决于伟大的执行力。

以软件來說，这就意味着很多事情要做得正确。您不能只有好的写作水平却无法实现文章中的承诺；干净的界面设计不能拯救糟糕的代码；一个优秀的软件要是沒有好的宣传，沒有人知道，仍然是不值分文的。如果要有所成就，就必须综合前述的所有元素。

其关键在于平衡能力。如果你向某一方面倾斜了，这就意味着你正走向失败。应该不断试着找出并且专注于最弱的一环，直到所有要素达到平衡。

人

创造一个成功的Web应用最重要的，也是值得我们再次强调的一点——参与其中的人。如果没有合适的人来实现，那么诸如印度教箴言、中心设计、更小的软件、以及其他精采的概念將没法发挥他们应有的作用。

你需要对工作有激情的人。这些人在乎他们的技术——他们真的会认为这是种艺术。这些人对他们的作品感到骄傲，而不关心所获得的报酬有多少。这些人会在细节上挥汗如雨，即使 95% 的人不知道这些细节间的差別在哪里。这些人想要创建伟大的作品并且不与劣质品妥协。这些人需要其他人，可能不止一个，但我们也很难不想多来上几个。总而言之，当你找到上面所述的这些人，留住他们。再怎么说，产品的成败——也是公司的成败——掌握在团队的成员手中。

不仅只限于软件

在这里提醒您，Getting Real 的概念不只适用于建立Web应用程序。当您开始了解里面蕴含的点子，到处都可以发现他们的踪迹。举些例子：

• 特种部队，如“绿色贝蕾帽”或“海豹小队”，使用小队以及快速部署來达到其他单位因太大或太慢而不可能完成的工作。
• 白条乐队(White Stripes) 始终遵循一些简单的标准：两个人、流水线式生产的歌曲、儿童般的鼓点、最大程度缩短在录音棚的时间等。
• 苹果 iPod 选择不提供如内置收音机或录音等附加功能，反而在竞争者中脱颖而出。
• 美式足球的快速进攻方法(Hurry up offenses) 通过消除“官僚”化的球队聚商和队友呼叫，显著提高了球队成绩。
• Rachael Ray 的食谱与电视节目专注于可“30分钟完毕”的佳肴，获得了成功。
• 海明威和卡佛使用简单、明了的语言，但仍能使他们的文学著作有着最大的影响力。
• 莎士比亞陶醉于十四行诗的限制內：十四行、抑扬格、五音步的诗词
• 还有很多……

当然，Getting Real 是关于编写伟大的软件，但沒有画地自限的必要。将这些概念套用在生活中別的领域中，您或许会偶然发现结果十分不错。

保持联系

要让我们了解 Getting Real 如何帮助您解决问题，请写信至：gettingreal [at] 37signals [dot] com.

另外，访问我们的博客 Signal vs. Noise ，来了解 37signals 的最新产品、Getting Real、关于可用性、设计以及一些其他内容。

感谢您的阅读，祝您好运！

 

---

37signals 资源

• 37signals 网站
• 信号 vs. 噪音(Signal vs. Noise) 博客
• Basecamp — 基于Web的项目协调网络应用
• Campfire — 基于Web的商务群组聊天应用
• Backpack — 基于Web的信息组织工具
• Writeboard — 基于Web的协同写作工具
• Ta-da List — 基于Web的极简单的待办事宜列表工具
• Ruby on Rails — 开源Web应用框架

 

---

翻译

感谢如下译者的辛勤工作: "Bin Dong":http://dongbin.javaeye.com (dongbin.cn@gmail.com); "Jeff Chang" (x12345678@gmail.com); "Tom Liu":http://tarkus.2gang.net (tarkus.nnkh@gmail.com); "Glory Yu":mailto:glory.nnkh@gmail.com

The rest of the book is not yet translated into this language. Contact us via email if you'd like to help translate. The entire book is available in English.

 

---

整合中文版编后

本版本在37signals未翻译完成的原版基础上，通过采用如下网友的翻译以及相关工作增订而成（排名不分先后）

• jpeng21@yeeyan.com, http://www.yeeyan.com/space/show/21700
• 第10章 还有待和catlinux的翻译比较 TODO
• http://www.yeeyan.com/articles/view/21700/5269?yeeyan=1

• catlinux, http://www.yeeyan.com/space/show/4811
• 第五章 第六、七、八节
• 第七章 第四节
• 第九章 第六、七、八节
• 第十章 编码
• 第十一章第一节后半部分，第十一章其余全部
• 第十二章 第一节部分
• 第十三章 推广（原译：促销）
• 第十四章 1－4节，第6节
• 第十五章 上线之后
• 第十六章 总结 第二节 37signals 资源

• CNBorn, http://cnborn.net
• 第九章 第7、8节修订
• 第十章 完整翻译修订
• 第十四章 第5节：良好的论坛 翻译；全章修订
• 第十六章 总结，由繁体中文翻译成简体中文、重新修订
• 其余各章零散问题修订

• 感谢
• zxweitju
• kuber
• jinguoli

 

总体修订：CNBorn