Getting Real 是一种更小规模，更快速，更高质量的软件构建方法。

旗下图书

• ReWork
• remote
• It Doesn't Have to Be Crazy at Work

第一章 引言

什么是 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应用的价值。

###如何编写健壮的软件 How To Write Vigorous Software

健壮的著作是简明的。句子无废词，段落无废句子。同样的原因，画应无多余的线条，机器应无多余的零件。这不是要作者刻意缩句来逃避细节，从而提纲挈领，而是要作者字字珠玑。

—来自 "The Elements of Style" by William Strunk Jr.

不再发胖

旧方式：冗长，官僚主义的，“我们正在这么做来控制这些蠢驴” 的流程。典型后果是：臃肿，过目即忘，平庸得掉渣的软件。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 Manjoo说：“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年的书 1cc;面了。这是完全可能的。这些技术并不是37signals的独创。我们只是告诉你我们怎样工作和是什么带给我们成功的。

"你们的观点过于绝对"

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

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

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

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

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

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

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

推进微软的 Start.com

在大公司中，流程和会议是非常平常的。数月的时间被浪费在规划功能，争论细节，力求达到每个人在什么是对于客户来说是“正确”的东西上达成一致。

这可能是塑料包装软件的正确途径，但是基于Web的软件有难以置信的优势。立刻发布！让用户告诉你这是不是正确的东西。如果你愿意，你可以当天修正它然后发布最新版。没有话比客户的意见更有用 — 拒绝举行罗嗦的会议和争论。仅仅发布产品，并且证明这个观点。

知易行难 — 这说明：

数月的规划没有必要。
花费数月来写规格说明根本没必要 — 规格说明应该在开发过程中理清框架，描述并且精化细节。不要试图在开发开始之前解决所有选而悬而未决的问题，并且敲定所有细节。

发布更少，但高质量的功能.
你不需要一道电闪雷鸣伴随着全新的发布和一捆新功能。一小块一小块地喂用户，让他们能够消化。

如果发现了细微的bug，先发布敲定的核心功能，然后发布补丁。动作越快用户反馈越好。纸上谈兵听起来不错，但是实践中往往不理想。你越快发现观点的关键错误越好。

一旦你快速迭代，并且响应用户反馈，你就和用户建立了一种关系。记住目标是通过构建用户所想来赢得客户。

—Sanaz Ahari, Start.com, Microsoft 的程序经理

---

第二章 起跑线

建构从简

做得比竟争对手少

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

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

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

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

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

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

---

是什么问题一直困扰你？

为自己而做这个软件

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

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

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

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

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

自助（自挠其背而止痒）

这是很长一段时间以来被开源领域奉为箴言的 — 他们叫它做“自挠其背而止痒”。对开源软件开发者来说，这意味着他们将自己去组织必需的工具，用自己的方式来推出产品。不仅于此，这样做的有着更深远的裨益。

作为一个新软件的网页设计师和程序开发者，每天你要面对上百个细小的决策：是要蓝色的还是绿色的？用一个表格还是两个？静态的或是动态的页面？放弃重新来过还是修复？一般我们是怎样来做这些决定的呢？如果那是我们认为很重要的我们也许会提出来讨论。其余的我们就靠猜想。最终所有那些猜想的部分将积累成软件的一种债务 — 一堆互相交织着的错综复杂的充满不确定因素的网。

作为一个开发者，我厌恶这种现象。想到有那么多的小型定时炸弹分布在这个软件中，给我带来了很大的压力。 自己帮助自己的开源软件开发者不会有这样的困扰。因为他们就是用户本身，90％的情况下他们了解他们应该做什么决定。我想这是为什么这些人能够在一天辛苦的工作回家后还能继续编写开源程序的众多原因之一，因为它反而是一种放松。

_—Dave Thomas, 一个实用主义编程者 _

一切源于必要性

Campaign Monitor公司的成立事实上是来源于必要性。多年来各种email市场营销工具的低劣品质一直困扰着我们。一个工具可以做到x和y却总也做不到z，另一个能搞定y和z却总也做不好x。老是这么下去我们将无法成就赢家。

我们于是决定整顿我们的时间表，着手开发我们理想中的email市场营销工具。我们很清醒地决定不看其他人在做什么而是专心做一个能让我们自己和客户都活得自在一些的产品出来。

事实证明，我们并不是惟一对现状感到不满的人。我们对软件成品做了一些改动，这么一来所有的设计公司（不仅我们自己）都能使用它并且开始帮我们推广。不到6个月，数以千计的设计师开始用Campaign Monitor来发布他们自己和客户的email推广信了。

—David Greiner, 创始人, Campaign Monitor

你必须在乎这个东西

当你在写一本书，你必须要有一个以上的有趣故事可讲。你必须有强烈地要讲叙这个故事的欲望。你必须要以某种方式把自己投入到故事中去。如果你要和一件事业共存两年，三年或你地一生，你必须要真正在乎它

_—Malcolm Gladwell, 作者 (from 杂看Malcolm Gladwell) _

---

找自己募资

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

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

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

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

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

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

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

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

两条路

[Jake Walker拥有的一家公司是用投资者的钱创立的 (Disclive) 另有一家不是 (The Show)。 在这里他探讨了这两条路的不同风景。]

所有问题的根本并不是筹募资金本身，而是随之而来的一系列事情。基本上就是更高的期望值。人们于是开始领工资，然后动力就成了做一个软件然后把它卖了，或想办法把种子基金给还了。就我前面的第一家公司（Disclive)，出于必要性我们起步得比我们原先设想的高很多 —

[关于第二家公司The Show] 我们发现我们可以推出一个花更少的钱却可以做得更好得产品，只不过要多花些时间。我们把很多自己的钱赌到一个人们愿意牺牲一点时间来换取品质的产品上面。但公司一直保持着小规模（也预计会一直这么走下去）。从那以后，我们就全部是内部募资。通过采取一些灵活的交易方式和我们的供应商合作，我们从不需要投入自己很多的资金。并且我们并不是做大后卖了，而是随需要而发展，走持续的可盈利道路。

_—评论来自于 Signal vs. Noise _

---

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

准时地在预算内推出

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

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

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

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

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

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

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

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

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

一天，两天，三天...

知道一个项目是怎样拖到最后比预计迟一整年的吗？就是这么一天一天拖出来的。

—Fred Brooks, 软件工程师，电脑科学者

---

找个敌人

挑选一场战斗

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

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

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

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

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

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

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

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

别老跟着领头羊

营销人员 (和几乎所有人) 都被培训要跟从领导者。自然的本能都是在思考竞争对手做对了什么，然后你在那个基础上做得更超过。 — 如果你的对手在竞价你就一定要比他更便宜，如果他在竞速你就要比他做得更快。这么一来出现的问题是万一消费者听信了别人的故事（或谎言），你再要把他说转回来就会象要说服他承认他是错的一样。没人喜欢承认他是错的。

于是你应该创造一个不同的故事来说服听众，告诉他们你的故事要比他们在其他地方听到的更重要。如果你的竞争对手是在竞速，那么你就必须转到竞价上来。如果他们强调的是健康，那么你就必须推销方便性。并不是简单地在x/y轴图表上标出“我们比较便宜”的声明，而是实实在在地用真实的完全不同于他人正在推销的故事。

—Seth Godin, 作家/企业家(from 做个更好的骗子)

问题的关键是什么?

老是看你的竞争对手在做什么是你给自己找麻烦的最快的方式之一。对于我们建造BlinkList这个平台来说尤其确实。从我们推出以来已经有其他10个类似的社交关系网软件相继出现。有些人已经开始在网上用并排图表来做不同软件之间功能特色的详细比较。

这是很容易误导的。我们不随大流，相反的，我们只看大方向，时时提醒自己什么是我们想要解决的问题关键，怎样去解决它。

_—Michael Reining, 共同创立人, MindValley 和 Blinklist _

---

它不该成为一种交易

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

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

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

激情的体现

在设计这个高度主观，具争议性且难以界定的领域里，没有什么是能做到比表达激情更直接清晰的了。一个产品会使你欢欣或让你无动于衷是很显而易见的; 不管是前者或后者，要人们不发现软件背后那些创造者的感情投入是很困难的。

热情是很容易凸显出来的，漠然也是同样难以掩饰的。如果你并非带着一种诚挚的心去对待手头上的产品，那么它留下的漠然与空白是几乎不可能掩饰的，不管一个设计作品表面看来多么精细吸引人。

—Khoi Vinh, Subtraction.com

烘培师

在美国，在这个时代生意经往往是提出一个构想，让它能盈利，在还能盈利的时候把它卖了，然后改行或不干了。这往往是一个能否挺下去的问题。对我而言: 去热爱烘培，卖你自己做的面包，人们如果喜欢它我就卖多些。我就这么把烘培事业做下去，因为我知道我在做好吃的人们爱吃的东西。

_—Ian MacKaye, Fugazi的会员， Dischord Records的合伙人
(from Salon.com People | Ian MacKaye) _

---

第三章 保持精益

更小的质量

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

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

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

质量会由于以下因素增加

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

质量会由于以下因素减少

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

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

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

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

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

---

减少改变的成本

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

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

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

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

顺其自然

顺其自然是敏捷的根本原则之一，也是最接近纯正魔术的一个。顺其自然的特性不是设计的或内建的，它自然的发生，就如系统其余部分的动态结果。“顺其自然”来自于17世纪中期的拉丁文，意思是“无法预见的出现”。你不可能为它做计划，或者做时间表，但是你可以为它营造一个环境，让它发生并受益于它。

顺其自然一个经典的例子是鸟群的迁徙行为。计算机模拟只需要少至三个原则（按照“不要撞到一起”），你会一下子得到非常复杂的行为来描述鸟群在天空中优雅的飞行和滑翔，重组队形绕开障碍，等等。没有一个高级行为（比如躲开障碍重组形成的相同形状）是被规则规定的；都是由系统动态衍生的。

简单的规则，就像鸟群的模拟一样，导致复杂的行为。复杂的规则，就像许多国家的税法一样，导致愚蠢的行为。

许多常见的软件开发实践带来了令人遗憾的边际效应，他们消除了顺其自然行为的发生机会。大多数优化的尝试——直率的敲下一些代码——减少了互动和关联的宽度和范围，而这些正是顺其自然的来源。在鸟群迁徙的例子中，正如一个设计良好的系统，正是互动和关联创造了有趣的行为。

我们把事物绑的越紧，留给创新的、顺其自然的解决方式的空间就越少。不管是在需求被完全理解前就锁定了需求，还是不成熟地优化代码，让终端用户使用系统前引进了复杂的导航和工作流场景，结果都是一样的，一个过分复杂、愚蠢的系统，而不是顺其自然带来的清洁和优雅的系统。

保持小，保持简单，顺其自然。

—安德鲁·亨特(Andrew Hunt)， 实效程序员网站(The Pragmatic Programmers )

---

三个火枪手

用三人小组构建1.0版本

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

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

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

梅特卡夫定律(Metcalfe's Law)和项目团队

保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law)，“网路的价值，为使用者的平方”，应用到项目团队的时候得到一个推论：团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布是最优的...从减少你计划添加到团队的人数开始，接着减少更多。

—Marc Hedlund, 奥莱利媒体（O'Reilly Media）入住企业家(entrepreneur-in-residence)

通信流

通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人，通信是简单的。唯一的通信通路是你和客户之间。但是，随着项目人员数目的增长，通信通路的数量也随之增长。它并不是加法形式的增长，随着人员数目的增长，它是乘法形式的增长，正比于人员数目的平方。

—史蒂夫·麦克科耐尔(Steve McConnell）, Construx软件公司（Construx Software Builders Inc.）首席软件工程师。
(摘自 《少即是多——小团队的第一生产力》，Less is More: Jumpstarting Productivity with Small Teams)

---

拥抱约束

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

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

这是一件好事情

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

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

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

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

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

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

与枯萎作斗争

曾经被称作“缓慢增长的优雅”可以被更恰当的叫做“特征枯萎病”，就像植物上的真菌一样，它节外生枝，模糊了产品的轮廓并吸干了它的汁液。特征枯萎病的解药是，当然是，“限死的最后期限”。这导致特征被按照实现所需时间的比例被抛弃。经常出现的情况是最有用的特征需要最长的时间。于是枯萎和最后期限的结合产生了许多我们知道和喜爱的软件，包含了充足的没有用的特征。

—Jef Raskin, 作者 (摘自 "为什么软件是它的方式")

---

做你自己

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

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

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

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

骄傲地、无所畏惧地做到真实

虽然你可能认为，顾客可以被夸大员工数字或者你的支付能力欺骗，但是精明的，你真正希望的顾客，永远会知道真相 — 无论通过直觉还是推理。尴尬的是，我曾经参与过这样的善意谎言，所有谎言都没有带来对商业最重要的东西：和真正需要你的服务的顾客建立的有意义的、持久的和互利互惠的关系。更好的应对应该是骄傲地、无所畏惧地对公司的实际规模和宽度做到真实。

—Khoi Vinh, Subtraction.com

不论何时

不管你在哪个行业，良好的顾客服务应该是所有客户最大的要求。我们自已对于服务是这样要求的，我们的客户又怎么会有区别？从一开始，我们就做到让客户和我们的接触容易和明晰，不管他们有多少、甚至没有问题。在我们的网站上，我们列出了一个免费号码会转接到我们的手机；在我们的名片上，每个人都列出了手机号码。我们向顾客强调，不管他们有什么问题，他们随时可以联系到我们。我们的顾客感谢我们这样的信任，没有人滥用过我们的服务。

—Edward Knittel, 销售和市场总监, KennelSource

---

第四章 首要任务

什么理念才是伟大的

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

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

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

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

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

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

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

白板上的哲理

有一次Andy Hunt和我编写一个借记卡的交易开关。有一个要点就是同一个交易不许向用户的借记卡二次收费。也就是说，不管操作过程中怎样出错，错误都只能发生在交易最终产生前，不能允许出现重复的交易。

因此，我们在共享信息的白板上用大字写下：要从客户角度出发，容许客户犯错误的可能。

还有其他大约半打多类似这样的信条，在我们创建一些复杂的产品，需要下有技巧性的决定时，这些信条给我们指引了方向。它们使我们的软件有强大的内部凝聚力和外部的统一性。

—Dave Thomas, 一个实用编程者

编写座右铭

组织需要指导原则。需要有一个纲要; 员工每天醒来时应该要知道他们为什么而工作。这个纲要最好言简意赅，富有激情：为什么你会在这里？是什么激励了你？我把这看做是座右铭 — 一段三或四个字的描述你存在的意义。

—Guy Kawasaki, 作者 (摘自 编写座右铭)

---

在初期时忽略细节

先粗后细

我们太过痴迷于细节。

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

成功和满意来自于细节

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

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

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

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

魔鬼隐藏在细节中

在选修了几堂绘画课后，我彻底摆脱了“马上投入到细节中”的态度...如果你一开始就画细节十有八九出来的画作会不怎么样。事实上，从你一开始那么做就完全错了。

你必须一开始把全局的比例分配搞对。你要从最大的一块着手，慢慢过渡到最小的。草稿必须体现模糊的主题。然后你着手润色，使整体画作具有生命力。着色先从浅，中，深三个色调下手。这么一来你的草稿就会有明暗了。接下来，在你画作的其他部分都要秉持三个色调的应用原则。如此反复直到整体成型...

永远，都要从大到小去做。

—Patrick Lafleur, Creation Objet Inc. (摘自 Signal vs. Noise)

---

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

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

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

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

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

就先掠过吧

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

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

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

---

去网罗对味的顾客

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

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

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

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

我们最成功的一步棋

把Campaign Monitor（市场策略观察）这个产品严格地定位在网页设计这块市场是我们走得最好得一步棋。它使我们能很容易地分辨出什么产品特色才是真正有用，更重要地是，什么特色是该舍弃地。这样一来，我们不仅能靠瞄准一个比较小地目标市场来争取更多地客人，也因这些客人都有相近的需求使得我们的开发工作更容易些。在Campaign Monitor中有大量的功能对其他人是毫无用处的完全针对网页设计者做的。

关注在一个核心市场也便于产品的宣传。我们有了这么一个定位精准的用户群，就能知道要在他们网上经常出没的地方做广告，发布他们可能会感兴趣的文章，然后逐步建立一个产品的用户社区。

—David Greiner, 创始人, Campaign Monitor

---

过后才去做规模调适

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

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

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

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

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

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

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

###反正你怎么也得回头重新审视

事实上，每个人都会有规模调整的问题，当服务人群从零到几百万的时候，所有人都必须回过头去重新审视产品设计架构的方方面面。

—Dare Obasanjo, 微软 (摘自 规模调适和创业公司)

---

软件要有自己的主张

你的软件应该要有倾向

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

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

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

一个著名的例子就是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件无关紧要的事情。你喜欢它因为它不试图始终讨好任何人。”

“我们不想要一千个功能”

关于iTunes音乐商店，Steve Jobs 私下为独立唱片制作人做了一个小型的演讲。我喜欢的瞬间是，当观众不停地举手说：“可以做[x]么？”，“你计划添加[y]么？”。最终Ｊｏｂｓ回答：“ 等等 — 放下你们的手。听着：我知道关于iTunes应该具有很酷的特性你有一千个主意。我们也是。但是我们不想要一千个功能。那样做很恶心。创新不是关于对每件事说yes。而是对每一件事说NO，除了至关重要的特性。”

Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

—-Derek Sivers, president and programmer, CD Baby and HostBaby
(from Say NO by default)

---

隐藏的成本

看清功能的成本

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

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

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

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

---

你能把握住它么?

构建你有把握的

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

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

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

---

人本主义

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

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

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

We kept the tool clean and uncluttered by letting people get creative. People figured out how to solve issues on their own. If they wanted to add a date to a to-do item they could just add (due: April 7, 2006) to the front of the item. If they wanted to add a category, they could just add [Books] to the front of the item. Ideal? No. Infinitely flexible? Yes.

If we tried to build software to specifically handle these scenarios, we'd be making it less useful for all the cases when those concerns don't apply.

Do the best job you can with the root of the problem then step aside. People will find their own solutions and conventions within your general framework.

---

Forget Feature Requests

Let your customers remind you what's important

Customers want everything under the sun. They'll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.

We'll hear about "this little extra feature" or "this can't be hard" or "wouldn't it be easy to add this" or "it should take just a few seconds to put it in" or "if you added this I'd pay twice as much" and so on.

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

How did we come to this conclusion? When we first launched Basecamp we tracked every major feature request on a Basecamp to-do list. When a request was repeated by someone else we'd update the list with an extra hash mark (II or III or IIII, etc). We figured that one day we'd review this list and start working from the most requested features on down.

But the truth is we never looked at it again. We already knew what needed to be done next because our customers constantly reminded us by making the same requests over and over again. There was no need for a list or lots of analysis because it was all happening in real time. You can't forget what's important when you are reminded of it every day.

And one more thing: Just because x number of people request something, doesn't mean you have to include it. Sometimes it's better to just say no and maintain your vision for the product.

---

Hold the Mayo

Ask people what they don't want

Most software surveys and research questions are centered around what people want in a product. "What feature do you think is missing?" "If you could add just one thing, what would it be?" "What would make this product more useful for you?"

What about the other side of the coin? Why not ask people what they don't want? "If you could remove one feature, what would it be?" "What don't you use?" "What gets in your way the most?"

More isn't the answer. Sometimes the biggest favor you can do for customers is to leave something out.

Innovation Comes From Saying No

[Innovation] comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much. We're always thinking about new markets we could enter, but it's only by saying no that you can concentrate on the things that are really important.

—Steve Jobs, CEO, Apple (from The Seed of Apple's Innovation)

---

第六章 操作

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

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

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

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

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

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

办实事能导致共识

当一群不一样的人开始尝试寻找和谐共鸣的时候...如果他们是一建立一个全方位的真实的产品那么他们的意见总会趋于一致。当然，如果他们只是打打草稿或是生出一些点子的话是很难达成共识的。因此，当你真正开始做一个实在的产品时，共识就比较容易达成。

_—Christopher Alexander, Professor of Architecture
(摘自 Contrasting Concepts of Harmony in Architecture（对比和谐建筑中的概念）) _

尽快地运作起来

我不认为我有参加过任何软件项目，不管大的或小的，是从一段漫长的规划讨论起步，不求同步发展，而又能在进度，成本或功能上成功的。把宝贵的时间浪费在发明一些不必要的或难以实施的性能上是容易的，有趣的，仅此而已，别无益处。

这个道理适用于软件开发的所有层面，“把一个产品搞起来”是一个灵活的思想。它不仅适用于一个整体的项目，微观上也适用于小规模的组件开发。

当一个可操作的组件做成后，开发者就希望知道它是否能和应用程序配合，因此他们就会尽可能快的去用它。即使一开始组件的实施并不完全，这种初期的开发协作通常会产生一个比较规范的界面和一些物尽其用的功能。

—Matt Hamer, 开发者和产品经理, Kinja公司

---

冲洗一下再来过

在不断反复中工作着

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

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

反复能解脱你

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

可能你比我聪明

可能你比我聪明的多。

这是完全有可能的。事实上，是非常有可能。但是，如果你象大多数人的话，那么你就会象我一样，在对看不见摸不着的东西的想象方面有困难。

人类极度善于对环境周遭的事物作出反应。一只老虎走到房间里时我们会惊慌失措，灾难性的洪水过后我们懂得去清理。遗憾的是，我们在事先计划方面，在理解我们行为带来的后果方面，在重要事情的优先排序方面，却很糟糕。

或许你是少数人中能把所有事情都把握在你的脑子里的，但这也并不重要。

Web 2.0, 在这个时代我们预定每个人都已经开始使用网络，这就为一些聪明的开发者运用人类行为的不确定性创造机会。怎么说呢？就是在允许你的用户告诉你他们想法的同时，留有空间去做改进。

最后那句同时也解释了为什么你应该以这种方式开发在线软件，以怎样的方式去推广推出产品。

把你想做到的说清楚。确保各个环节无误。然后就推出和进行改进。没有哪个人自己一个能比大伙儿加起来更聪明。

—Seth Godin, 作家/企业家

---

从概念到实施

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

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

脑力激荡

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

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

纸上草稿

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

创建HTML页面

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

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

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

上代码编程

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

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

---

远离设置首选项

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

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

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

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

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

你要拿主意

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

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

做设置首选项是要付出代价的

事实证明，加设置首选项是有代价的。当然，有些首选项也有重要的作用 — 并且可能是关键的页面职能。但每提供一个选项都有不菲的代价，你应当仔细考量其价值。很多的用户和开发者都没能理解这个道理，最终付出很大成本，宝贵的资本只带来一点点的价值...我发现，如果你是信奉要靠设计优秀默认功能而不是懒惰地去添加设置首选项的人，那么自然而然地你的总体UI（用户界面）会走上正确的道路。

—Havoc Pennington, 首席技术指导, Red Hat (from Free software and good user interfaces （自由软件和优秀用户界面）)

---

"搞定!"

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

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

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

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

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

做一个执行者

当我听说有人对自己的点子很具保护性时觉得很可笑。（那些在告诉我一些简单的概念之前希望我签定保密协定的人。）

对我而言，如果不去执行的话点子是一无用处的。它们只是倍数。执行才是价值万金的。

理由:

• 糟糕的点子 = -1

• 脆弱的点子 = 1

• 普通的点子 = 5

• 好点子 = 10

• 伟大的点子 = 15

• 超闪亮的点子 = 20

• 没有执行 = $1

• 柔弱的执行 = $1000

• 普通的执行 = $10,000

• 好的执行 = $100,000

• 伟大的执行 = $1,000,000

• 超强的执行 = $10,000,000

如果要成就一番事业，你必须将二者相乘。

最闪亮的点子，如果没有执行，最多值$20。如果它乘以优秀的执行，那么就值$20,000,000。

那就是为什么我不爱听他人的点子。只有当看到它被确实执行下去了我才有兴趣。

—Derek Sivers， 总裁，程序员， CD Baby公司 and HostBaby公司

---

放飞去让大众测试

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

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

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

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

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

Beta书的发布

如果开发者在发布代码的时候都很紧张，那么书的发行商和作者在推出一本书时岂不得吓死。当一部书付诸印刷时，要做修改是一件无比麻烦的事。（事实上并非如此，但这些和旧技术联系在一起的感觉和记忆还弥漫在行业中。）因此，发行商总是花很大的功夫（和成本）要在书发行前争取把书做到“对”为止。

当我写Agile Web Development With Rails（用Rail做前卫的网页开发）这本书时，很多的开发者有相当明确的需求：我们现在就需要这书 — 我们想要知道更多有关Rails。我也可能从出版商的角度出发。“它还没完成”，我会这么说。但来自社区压力和David Heinemeier Hansson的督促使我改变了想法。我们在书最后完成前两个月以pdf的格式预先发布了这书。结果是令人难以置信的。我们不仅卖了很多书，而且得到了反馈 — 许多的反馈意见。我开发了一个自动化系统来攫取读者发布的看法，最终得到差不多850个有关错字和技术错误的报告，另有添加新内容的建议。所有这些的解决方案都浓入到最后的书面出版中。

这是一个双赢的局面：我能提交一个完善了的纸面出版书籍，社区也能及早地得到他们需要的内容。如果你是在一场赛跑竞争中，早些把作品交出去可以争取更多的追随者而不是过后引来更多的竞争对手。

—Dave Thomas, The Pragmatic Programmers（《实干的编程者》）

要快

• 1. 决定它是否值得做，如果是的话:
• 2. 尽快去做 — 不需完美，只需做下去
• 3. 保存。上传。发布。
• 4. 看人们的反应 虽然我并不总爱给产品加新功能，但一旦那个值得去做的"yeah!"时刻到来，新的功能一般几个小时后就能上到网页上去，有瑕疵但就这么发布了，让用户反馈来引导下一步的修补工作。

—Derek Sivers, 总裁，程序员，CD Baby公司 和HostBaby公司

---

缩短你的时间

把它分块来做

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

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

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

小一些的任务和时间表

软件开发者是一群特殊的乐观主义物种：面对放在他们面前的编程任务时，他们总会想，“那不难！花不了多少时间。”

所以，如果给一个程序员3周去完成一个大型任务，她会花两周半拖拉，然后用一周的时间在编程上。这种不按期执行结果就会造成和预期任务要求脱节，因为每个任务总是会比表面看起来更复杂。还有，谁还记得三周前整个团队达成的详细共识是什么？

给程序员一个下午去编一个小的特定的模块，她就会有办法把它赶出来，然后准备进入到下一个任务。

小一些的任务和时间表比较好管理，可以省去一些可能由于繁多产生的误解，同时你改变主意或重新做的成本也会较小。小一些的时间表可以督促开发者，让他们更有机会去享受某种成就感，同时不让他们有更多的理由去想，“哦，我还有很多时间去做那个项目。现在让我给我iTunes宝库里的歌曲评评级先。”

—Gina Trapani, 网页开发者，编辑 Lifehacker, the productivity and software guide（效率和软件指南）

事实的真相

下次如果有人硬要你回答一个答案尚未可知的问题 — 不管它是有关一个截止日，一个项目的最终成本，或填满Grand Canyon（大峡谷）需要多少牛奶 —这类不发生无法知道的问题，你尽管可以从避免空谈的角度出发：说“我不知道”。

这不仅远不会毁坏你的信用，同时能显示你对下决定的慎重和用心。不要只说些听起来精明的话。你还需平衡游戏规则，将问题重整成有利协同合作的对话。通过对你的预期所能达到的效果的逐步明确化的讨论，你就能和其他人一起打造一个共识的平台，揭开数字背后的真相。

—Merlin Mann, 创造者和编辑， 43folders.com

解决冲着你来的那个问题

近来我的网络记忆中最自豪的一件事就是发布和引进"nofollow（译者注，一个HTML属性值）"的态度。没人事先讨论过它。没有一大堆的会议座谈可以让一些无聊人用来进行其含义和编程本质的争论。没有征求意见的过程，于是不需要把一个简单的理念做成得花上20行xml的小程序（还得花时间解读如何用这个程序，最终结果就是不用它，因为我不清楚是否设定在版本0.3或3.3b）。

它简单，有效，只提供选项给需要的人 — 这对于网络中不在乎技术规格的框框条条或觉得遵礼节太费时的一群，无疑是非常重要的。

有时，解决后来的20个难题往往不如搞定直冲你来的那一个问题来得有用和审慎。它不仅仅是一个战胜滥码的一个小胜利（所有和冗余代码的斗争胜利都不会是大的），而且是对那些热爱简洁和迅速的结果并以之为己任的网页开发者的一个大胜仗。

—Andre Torrez, 程序员和副总工程师， Federated Media Publishing

---

第七章 组织

一致性

拒绝分隔

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

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

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

---

独处的时间

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

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

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

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

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

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

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

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

进入最佳状态

我们都知道知识工作者在稳定状态工作最出色，这种状态也被称作“渐入佳境”，他们全神贯注于工作，开足马力，忘了周围的环境。他们忘了时间的流逝，在绝对的集中精力下产生了巨大的成果...那番在于这种情境太容易被破坏。噪声，电话呼叫，吃午餐，需要开车5分钟去星巴克喝咖啡还有合作者的打扰 — 特别是合作者的打扰 — 都破坏了这个情境。 如果你需要花一份钟处理合作者问问题的干扰，这足以破坏你的集中经历，那么你需要花费一个小时重新达到有效率，你的总生产力变得很糟糕。

—Joel Spolsky, 软件开发者, Fog Creek Software
(摘自 这些人从哪里得到他们(非原创的) 思想?)

---

会议有毒

不要会议

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

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

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

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

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

少开会

有太多的会议了。放弃那些没有意义的和没有效果的会议。只有当需要讨论重要的商务议题的时候或者你需要建议，赞同或者一致意见的时候才召开会议。即便如此，不要不加选择的邀请人 — 不要不必要的浪费人们的时间。

—Lisa Haneberg, 作者 (摘自 不要让会议统治你！)

分解它

当子昂目增长的时候，增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。两个人只需要相互沟通；只有一条简单的交流途径。三个人有三条交流途径；4个人有6条。事实上，交流途径的增长是指数级的……很快，备忘录和会议汇占据整个工作时间。

解决方法是明显的：把团队分解成小的，自治的和独立的小单位以减少这些交流途径。

详细的，把程序也分解成更小的单位。既然问题的一大部分起源于相互的依赖（全局变量，函数间传送的数据，共享的硬件等等），找一个方法分割程序以消灭— 或者减少— 个体间的相互依赖。

—The Ganssle Group (from Keep It Small)

---

寻找和庆祝小的胜利

每天发行点什么

The most important thing in software development is motivation. Motivation is local — if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be. In fact, it's probably going to suck.

Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.

So, if you're in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories. Ask yourself "What can we do and release in 4 hours?" And then do it. It could be...

• A new simple feature
• A small enhancement to an existing feature
• Rewriting some help text to reduce the support burden
• Removing some form fields that you really don't need

When you find those 4-hour quick wins, you'll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.

---

第八章 人员配备

不需过早招聘太多员工

慢慢加人迅速发展

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

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

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

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

Brooks的原则

给延期的软件开发项目添加人手只会更加拖延进度。

—Fred Brooks

编程与莫扎特的安魂曲

一个优秀的程序员在完成单个工作任务时不存在因沟通和分工而产生的额外开销。而五个程序员坐到一起完成同一个任务的时候必须分工合作，那将花费很多时间……用很多一般的程序员而不是几个足够好的程序员将产生的真正问题在于：无论让他们干上多久，也绝对没有优秀程序员干得出色。五个Antonio Salieris也永远写不出莫扎特的安魂曲，哪怕给他们100年的时间。

—Joel Spolsky, Fog Creek Software的软件开发人员 (摘自Hitting the High Notes)

---

摸底

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

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

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

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

小处着手

从分派一个小的测试任务开始。不要一股脑把你的工作任务都拿出来。给你的新虚拟助理一两个测试项目来做，看看化学作用如何发生。开始的时候，大家很容易在和和气气的氛围中忽略掉潜在的问题。记住这只是在试车。

_—Suzanne Falter-Barns, 作家和创意专家
(摘自How To Find And Keep The Perfect VA) _

---

行胜于言

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

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

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

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

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

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

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

对开源社区的热情

你最希望从新员工身上看到的就是他对自己工作任务的热情，而最能看出这点的办法就是在开源项目中去追溯他的提交记录。

_—Jarkko Laine, 软件开发人员
(from Reduce the risk, hire from open source) _

---

寻找全面发展的人

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

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

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

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

---

热情是装不出来的

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

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

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

为提问加分

留意候选人是否对你的项目提出很多疑问。热心的程序员总是想尽量去理解存在很多疑点的问题并快速提出可能的解决办法和改进方案。阐明问题能产生一种认识：项目的做法很多，但基本上取决于你对你的Web应用如何运作的想象。当你深入到细节，你能感觉到这个人是否在文化水平上符合。

—Eric Stephens, BuildV1.com

---

炼字师

招文字功底好的人

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

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

条理清晰的头脑

好的写作风格是头脑清晰的指示器，清晰的头脑能有条絮地梳理信息和论点，还能帮助（而不是逼着）其他人去理解。这种技巧能渗透到代码的编写、口头表达、即时通信（对于那些远程协作的人来说），甚至更深层次的职业素养和可靠性等领域。

—Dustin J. Mitchell, 开发人员 (摘自Signal vs. Noise)

有清晰的文字才有清晰的思路

清晰的文字能带来清晰的思路。表达它的时候你才知道你对它了解些什么。好的写作风格也从一定程度上反映出人的性格。让读者省事，而不是给自己省事。

—Michael A. Covington, 佐治亚州立大学计算机科学教授
(摘自How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily)

---

第九章 界面设计

界面先行

开始编程之前先设计界面

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

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

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

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

开创Blinksale的橙色钢笔

当我意识到现有的帐单管理软件都无法让我满意的时候，我决心把我想要的帐单管理解决方案画出来。我拿出一支橙色钢笔，因为它是那晚上唯一好用的东西，然后我用了几小时画出了75％的用户界面。我把它拿给我妻子Rachel看，当时她正在烫衣服，我问她：“你觉得怎么样？”她微笑着回答：“你真该把它实实在在的做出来。”

接下来的两个星期里我重新斟酌了设计，并且做好了当时可能成为Blinksale第一版的大部分静态页面。除了那些用橙色钢笔画的草图，我们从来没有做过其它网格之类的东西。而且直接进入html页面的设计让我们一直为项目变得现实起来而感到激动，即使在当时我们并不知道我们正在陷入什么当中。

html页面一完成，我们就和开发员Scott一起商量关于Blinksale的想法。已经设计好的用户界面在好些层面都发挥了非常好的作用。首先，它让Scott能亲眼看到，使他为我们的目标感到激动。它远远不止是一个创意，它是真实的。其次，它帮助我们可以精确衡量Scott需要花多长时间和精力才能把设计变成能跑的应用。当你在对一个项目的孵化提供资金上的支持，越早能做出预算越好。界面设计成为了我们在项目初期的评估基准。最后，用户界面的设计就像一个向导，能在我们进一步开发的时候提醒我们这个应用程序的核心目标。当我们临时决定添加新功能的时候，我们不能简单地说：“好的，那就加吧！”我们必须回到设计上来，问自己新功能应该放在哪，如果没有它的位置，它就不该加。

—Josh Williams, Blinksale创始人

---

震中设计

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

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

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

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

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

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

---

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

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

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

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

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

---

初始界面

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

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

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

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

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

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

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

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

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

没有第二次机会……

我觉得苹果OS x操作系统的界面中另一个深受Steven Jobs影响的是安装和初次运行的体验。我想Jobs一定深深理解到第一印象的重要性……也许Jobs在考虑初次运行的体验时会想，它可能是一个用户对电脑上千次用户体验中的一次，但是它将是最重要的千分之一，因为它是一千次中的第一次，人们对它寄予了期望并形成初步印象。

_—John Gruber, 撰稿人和开发人员 (摘自 Interview with John Gruber) _

---

做好防御

出错时的设计

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

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

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

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

---

Context Over Consistency

What makes sense here may not make sense there

Should actions be buttons or links? It depends on the action. Should a calendar view be in list-form or grid-form? It depends where it's being shown and how long the time period is. Does every global navigation link need to be on every page? Do you need a global search bar everywhere? Do you need the same exact footer on each page? The answer: "It depends."

That's why context is more important than consistency. It's ok to be inconsistent if your design makes more sense that way. Give people just what matters. Give them what they need when they need it and get rid of what they don't. It's better to be right than to be consistent.

Intelligent Inconsistency

Consistency is not necessary. For years, students of ui and ux have been taught that consistency in the interface is one of the cardinal rules of interface design. Perhaps that holds in software, but on the Web, it's just not true. What matters on the Web is whether, on each individual page, the user can quickly and easily advance the next step in the process.

At Creative Good, we call it "intelligent inconsistency": making sure that each page in the process gives users exactly what they need at that point in the process. Adding superfluous nav elements, just because they're consistent with the rest of the site, is just silly.

_—Mark Hurst, founder of Creative Good and creator of Goovite.com
(from The Page Paradigm) _

---

Copywriting is Interface Design

Every letter matters

Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you're writing your interface, always put yourself in the shoes of the person who's reading your interface. What do they need to know? How you can explain it succinctly and clearly?

Do you label a button Submit or Save or Update or New or Create? That's copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

You need to speak the same language as your audience too. Just because you're writing a web app doesn't mean you can get away with technical jargon. Think about your customers and think about what those buttons and words mean to them. Don't use acronyms or words that most people don't understand. Don't use internal lingo. Don't sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more.

Good writing is good design. It's a rare exception where words don't accompany design. Icons with names, form fields with examples, buttons with labels, step by step instructions in a process, a clear explanation of your refund policy. These are all interface design.

---

One Interface

Incorporate admin functions into the public interface

Admin screens — the screens used to manage preferences, people, etc. — have a tendency to look like crap. That's because the majority of development time is spent on the public-facing interface instead.

To avoid crappy-admin-screen syndrome, don't build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface.

If you have to maintain two separate interfaces (i.e. one for regular folks and one for admins), both will suffer. In effect, you wind up paying the same tax twice. You're forced to repeat yourself and that means you increase the odds of getting sloppy. The fewer screens you have to worry about, the better they'll turn out.

No Separate Interface

The application is everything. Anything that can be changed, added, or adjusted can be done directly through the management area of the application. This allows us to see exactly what our customers see to help them through any problems or questions that they have. And our customers don't have to worry about logging into a separate interface to do different tasks. One minute they might be dealing with appointments for their clients and the next minute they might have to add a new employee. They can't be bothered with jumping between different applications and maintaining a consistent interface they're able to adapt to the application even quicker.

—Edward Knittel, Director of Sales and Marketing, KennelSource

---

10 Code

Less Software

Keep your code as simple as possible

You'd think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you'll have created the dreaded Big Ball of Mud.

The way you fight this complexity is with less software. Less software means less features, less code, less waste.

The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that's alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it's worth five times the effort to solve it.

Less software means you put away the crystal ball. Instead of trying to predict future problems, you deal only with the problems of today. Why? Fears you have about tomorrow often never come to fruition. Don't bog yourself down trying to solve these phantom issues.

From the beginning, we've designed our products around the concept of less software. Whenever possible, we chop up hard problems into easy ones. We've found solutions to easy problems are not only easier to implement and support, they're easier to understand and easier to use. It's all part of how we differentiate ourselves from competitors; Instead of trying to build products that do more, we build products that do less.

• Less software is easier to manage.
• Less software reduces your codebase and that means
• less maintenance busywork (and a happier staff).
• Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code.
• Less software results in fewer bugs.
• Less software means less support.

Which features you choose to include or omit have a lot to do with less software too. Don't be afraid to say no to feature requests that are hard to do. Unless they're absolutely essential, save time/effort/confusion by leaving them out.

Slow down too. Don't take action on an idea for a week and see if it still seems like a great idea after the initial buzz wears off. The extra marinading time will often help your brain come up with an easier solution.

Encourage programmers to make counteroffers.
You want to hear: "The way you suggested will take 12 hours. But there's a way I can do it that will only take one hour. It won't do x but it will do y." Let the software push back. Tell programmers to fight for what they think is the best way.

Also, search for detours around writing more software. Can you change the copy on the screen so that it suggests an alternate route to customers that doesn't require a change in the software model? For example, can you suggest that people upload images of a specific size instead of doing the image manipulation on the server side?

For every feature that makes it into your app, ask yourself: Is there a way this can be added that won't require as much software? Write just the code you need and no more. Your app will be leaner and healthier as a result.

There is No CODE That is More Flexible Than NO Code!

The "secret" to good software design wasn't in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.

_—Brad Appleton, software engineer
(from There is No CODE that is more flexible than NO Code!) _

Complexity Does Not Scale Linearly With Size

The most important ruleof software engineering is also the least known: Complexity does not scale linearly with size...A 2000 line program requires more than twice as much development time as one half the size.

—The Ganssle Group (from Keep It Small)

---

Optimize for Happiness

Choose tools that keep your team excited and motivated

A happy programmer is a productive programmer. That's why we optimize for happiness and you should too. Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here? Would you truly be happy working in this environment eight hours a day?

This is especially important for choosing a programming language. Despite public perception to the contrary, they are not created equal. While just about any language can create just about any application, the right one makes the effort not merely possible or bearable, but pleasant and invigorating. It's all about making the little details of daily work enjoyable.

Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.

We found programming bliss in the language Ruby and passed it on to other developers with our framework Rails. Both share a mission statement to optimize for humans and their happiness. We encourage you to give that combination a spin.

In summary, your team needs to work with tools they love. We've talked here in terms of programming languages, but the concept holds true for applications, platforms, and anything else. Choose the fuse that gets people excited. You'll generate excitement and motivation and a better product as a result.

The kinds of engineers you want

The number one reason I wanted to build our app using Ruby on Rails is that it is so elegant, productive, and beautifully designed. It tends to attract the kind of engineers who care about just those sort of things...those are exactly the kinds of engineers you want on your team because they create the kind of beautiful, elegant and productive software you need to win the market.

—Charles Jolley, Managing Director at Nisus Software (from Signal vs. Noise)

---

Code Speaks

Listen when your code pushes back

Listen to your code. It will offer suggestions. It will push back. It will tell you where the pitfalls reside. It will suggest new ways to do things. It will help you stick to a model of less software.

Is a new feature requiring weeks of time and thousands of lines of code? That's your code telling you there's probably a better way. Is there a simple way to code something in one hour instead of a complicated way that will take ten hours? Again, that's your code guiding you. Listen.

Your code can guide you to fixes that are cheap and light. Pay attention when an easy path emerges. Sure, the feature that's easy to make might not be exactly the same as the feature you originally had in mind but so what? If it works well enough and gives you more time to work on something else, it's a keeper.

Listen up

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.

—Martin Fowler, Chief Scientist, ThoughtWorks (from Is Design Dead?)

If Programmers Got Paid To Remove Code...

If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better.

—Nicholas Negroponte, Professor of Media Technology at MIT
(from And, the rest of the (AIGA Conference) story)

---

Manage Debt

Pay off your code and design "bills"

We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt.

Hack together some bad code that's functional but still a bit hairy and you're building up debt. Throw together a design that's good enough but not really good and you've done it again.

It's ok to do this from time to time. In fact, it's often a needed technique that helps you do the whole Get-Real-asap thing. But you still need to recognize it as debt and pay it off at some point by cleaning up the hairy code or redesigning that so-so page.

The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don't, you'll just be paying inter est (fixing hacks) instead of paying down the principal (and moving forward).

---

Open Doors

Get data out into the world via RSS, APIs, etc.

Don't try to lock-in your customers. Let them get their information when they want it and how they want it. To do that, you've got to give up the idea of sealing in data. Instead, let it run wild. Give people access to their information via rss feeds. Offer apis that let third-party developers build on to your tool. When you do, you make life more convenient for customers and expand the possibilities of what your app can do.

People used to think of rss feeds as merely a good way to keep track of blogs or news sites. Feeds have more power than that though. They also provide a great way for customers to stay up to date on the changing content of an app without having to log in repeatedly. With Basecamp feeds, customers can pop the url into a newsreader and keep an eye on project messages, todo lists, and milestones without having to constantly check in at the site.

APIs let developers build add-on products for your app that can turn out to be invaluable. For example, Backpack supplies an api which Chipt Productions used to build a Mac os x Dashboard widget. The widget lets people add and edit reminders, list items, and more from the desktop. Customers have raved to us about this widget and some have even said it was the key factor in getting them to use Backpack.

Other good examples of companies letting data run free in order to get a boomerang effect:

• The Google Maps API has spawned interesting mash ups that let people cull information from another source (e.g. apartment listings) and plot that data on a map.
• Linkrolls offer a way for people to get their latest del.icio.us bookmarks displayed on their own sites.
• Flickr allows other businesses access to commercial apis so customers can buy photo books, posters, dvd backups, and stamps. "The goal is to open it up completely and give you the biggest variety of choices when it comes to doing things with your photos," says Stewart Butterfield of Flickr.

A Widget Makes the Difference

When 37signals released Backpack a while back, my first impression was...eh.

So it was around the time that Chipt Productions released a Backpack widget for Tiger — which was too cool not to download and try — that I gave Backpack a second look. The result? Quite a difference.

Now whenever an idea hits, I pop up the widget, type, and submit — done. Email arrives with something I want to check out? Pop up the widget, type, and submit — done. The widget is an immediate brain dump readily available on each Mac I use. And because everything is web based, there isn't any version control or syncing — just the fluid input of content without having to be concerned about where it's going or how I'll access it later.

—Todd Dominey, founder, Dominey Design
(from Trying on Backpack)

---

#文字 第11章 {#ch11}

功能定义一点用都没有

不要写功能定义文档

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

功能定义文档是虚幻的

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

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

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

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

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

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

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

功能定义导致功能泛滥

There's no pushback during spec phase. 写点东西加个标注，看上去并不需要什么代价。你可以加上他们欣赏的功能，让那些令人头疼的人高兴。然后你按照那些写下来的文字标注设计，而不是为人设计。最终你得到的将是一个拥有30个栏目的臃肿站点

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

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

So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.

Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.

Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.

Useless Specs

A "spec" is close to useless. I have never seen a spec that was both big enough to be useful and accurate.

And I have seen lots of total crap work that was based on specs. It's the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

—Linus Torvalds, creator of Linux (from: Linux: Linus On Specifications)

Fight the blockers

I found the people insisting on extensive requirements documents before starting any design were really 'blockers' just trying to slow the process down (and usually people with nothing to contribute on design or innovative thinking).

All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static), changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype, we usually had a real project in motion and good result.

—Mark Gallagher, corporate intranet developer (from Signal vs. Noise)

---

Don't Do Dead Documents

Eliminate unnecessary paperwork

Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don't produce it.

Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Here's an example: If a wireframe document is destined to stop and never directly become the actual design, don't bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.

Documents that live separately from your application are worthless. They don't get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it's dead.

No One's Going to Read It

I can't even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user testing as we went. I've even worked with developers who've spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don't move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don't waste your time typing up that long visionary tome; no one's going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won't resemble anything you wrote about anyway.

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide

---

Tell Me a Quick Story

Write stories, not details

If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don't get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.

It doesn't need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.

Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.

---

Use Real Words

Insert actual text instead of lorem ipsum

Lorem ipsum dolor is a trusted friend of designers. Dummy text helps people get what the design will look like once it's fleshed out. But dummy text can be dangerous too.

Lorem ipsum changes the way copy is viewed. It reduces text-based content to a visual design element — a shape of text — instead of what it should be: valuable information someone is going to have to enter and/or read. Dummy text means you won't see the inevitable variations that show up once real information is entered. It means you won't know what it's like to fill out forms on your site. Dummy text is a veil between you and reality.

You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like.

As soon as you can, use real and relevant words. If your site or application requires data input, enter the real deal. And actually type in the text — don't just paste it in from another source. If it's a name, type a real name. If it's a city, type a real city. If it's a password, and it's repeated twice, type it twice.

Sure, it's easier to just run down the forms and fill the fields with garbage ("asdsadklja" "123usadfjasld" "snaxn2q9e7") in order to plow through them quickly. But that's not real. That's not what your customers are going to do. Is it really smart to take a shortcut when customers are forced to take the long road? When you just enter fake copy in rapid-fire fashion, you don't know what it really feels like to fill out that form.

Do as your customers do and you'll understand them better. When you understand them better, and feel what they feel, you'll build a better interface.

Lorem Ipsum Garbage

By not having the imagination to imagine what the content "might" be, a design consideration is lost. Meaning becomes obfuscated because "it's just text", understandability gets compromised because nobody realized that this text stuff was actually meant to be read. Opportunities get lost because the lorem ipsum garbage that you used instead of real content didn't suggest opportunities. The text then gets made really small, because, it's not meant to be used, we might as well create loads of that lovely white space.

—Tom Smith, designer and developer (from I hate Lorem Ipsum and Lorem Ipsum Users)

---

Personify Your Product

What is your product's personality type?

Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trusting? As a know-it-all? Or modest and likable?

Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app's personality.

Your product has a voice — and it's talking to your customers 24 hours a day.

---

#定价和注册 第12章 {#ch12}

免费样品

免费赠送

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

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

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

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

Bite-size chunks

Make bite-size chunks: Devise specialized, smaller offerings to get customers to bite. Resolve to sub-divide at least one product or service into bite-size chunks that are inexpensive, easy or fun.

_—Ben McConnell and Jackie Huba, authors of Church of the Customer Blog
(from What is customer evangelism?) _

Give Away Your Hit Single

Consider giving one of your songs (per-album) as a free promotional download to the world — to be like the movie trailer — like the hit single sent to radio — the song that makes people want to go buy your music.

Don't worry about piracy for this song. Let people play it, copy it, share it, give it away. Have the confidence that if the world heard it, they will pay for more.

—Derek Sivers, president and programmer, CD Baby and HostBaby (from Free Promo Track)

---

来去自如

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

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

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

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

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

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

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

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

轻松离开

不要勉强留住用户。如果他们要离开，就让他们带上在你网站创造出来的全部内容，然后自由离去。必须敞开粮仓，集中精力留住客户，所以他们愿意回来，而不是因为被门卡住了才不得不回来。

_—Charlie O'Donnell， 分析师， Union Square Ventures
(摘自 10 Steps to a Hugely Successful Web 2.0 Company) _

---

Silly Rabbit, Tricks are for Kids

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

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

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

---

塑料子弹

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

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

---

13 Promotion

Hollywood Launch

Go from teaser to preview to launch

If an app launches in a forest and there's no one there to use it, does it make a noise? The point here is that if you launch your app without any pre-hype, people aren't going to know about it.

To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch.

Teaser

A few months ahead of time, start dropping hints. Let people know what you're working on. Post a logo. Post to your blog about the development. Stay vague but plant the seed. Also, get a site up where you can collect emails from folks who are interested.

At this stage, you should also start seducing mavens and insiders. These are the folks on the cutting edge. They're the tastemakers. Appeal to their vanity and status as ahead-of-the-curvers. Tell them they're getting an exclusive sneak preview. If a site like Boing Boing, Slashdot, or Digg links up your app, you'll get loads of traffic and followers. Plus, your page rank at Google will go up too.

Preview

A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Describe the theme of the product. For Basecamp, we posted screenshots and highlighted reminders, milestones, and other features.

Also, tell people about the ideas and principles behind the app. For Backpack, we posted our manifesto before launch. This got people thinking and talking about the app.

You can also offer some special "golden tickets" to a few people so they can start using the app early. You'll get the benefit of having some beta testers while they'll feel that special glow that people get from being early adopters.

And again, encourage people to sign up so you've got a foundation of emails to blitz once you launch. By the time we launch our apps, we have thousands of emails to ping which is a big help in gaining traction.

Launch

It's release time. Now people can actually go to the "theater" and see your app. Get emails out to those who signed up. Launch your full marketing site. Spread the gospel as much as possible. Get blogs to link to you. Post about your progress: How many people have signed up? What updates/tweaks have you made? Show momentum and keep at it.

The Road to Launch Day

As soon as we knew Blinksale was really going to happen, we began floating some teasers to our mailing list. These are people who have asked to receive information from us about our projects. These are our fans, if you will. If you already have permission to talk to a group of people, they are the best place to start.

The second thing we did is get permission to talk to more people about our product. About six weeks before the Blinksale launch we put up a teaser page at our website that proclaimed the coming of an easier way to send invoices online. The page gave just enough information to build excitement and suspense, without giving away sensitive details that needed to remain confidential. Prominently displayed on the page was a newsletter subscription form, requiring nothing but an email (keep it simple) so that those interested could be notified when the product launched.

We spread the word to a dozen or so friends and colleagues that we felt would be interested in the product as well, and they began to spread the word about the teaser page through their blogs and websites. Within a few days, we had thousands on our mailing list. These were extremely important people — people who are asking to learn more about our product and who wanted to know when we launched.

Finally, about two weeks before we launched, we invited a handful of friends, colleagues, and industry mavens to help us beta test Blinksale. This allowed us to get the product in front of people we felt could benefit from its use and who could help us spread the word about the product when we launched. It's important to note that we didn't force anyone to use or write about the product. We simply wanted it to be seen and wanted people to talk about it when it launched. In the end, if you're going to build buzz this way, you better be sure your product can deliver. Otherwise, it's like clouds without rain.

When launch day arrived, we sent an email to our mailing list, notified our blogging friends, and encouraged our beta testers to speak their minds. And to our great delight, the effort paid big dividends. Shortly after launch tens of thousands had visited our site and thousands of those had signed up to use the product.

—Josh Williams, founder, Blinksale

---

A Powerful Promo Site

Go from teaser to preview to launch

The best promotional tool is a great product. Word will get out if you've got an app that people find really useful.

Still, you need an ace promotional site too. What should you include on this site? Some ideas:

• Overview: Explain your app and its benefits.
• Tour: Guide people through various features.
• Screen captures and videos: Show people what the app actually looks like and how to use it.
• Manifesto: Explain the philosophy and ideas behind it.
• Case Studies: Provide real life examples that show what's possible.
• Buzz: Testimonial quotes from customers, reviews, press, etc.
• Forum: Offer a place for members of the community to help one another.
• Pricing & Sign-up: Get people into your app as quickly as possible.
• Weblog: Blogs keep your site fresh with news, tips, etc.

---

Ride the Blog Wave

Blogging can be more effective than advertising (and it's a hell of a lot cheaper)

Advertising is expensive. And evaluating the effectiveness of various types of advertising can wind up being even more expensive than the advertising itself. When you don't have the time or money to go the traditional advertising route, consider the promote-via-blog route instead.

Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc. Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.

So when it came time to promote our first product, Basecamp, we started there. We got the word out on SvN and it started to spread. Folks like Jason Kottke, the BoingBoingers, Jim Coudal, and a variety of other people with popular blogs helped raise the visibility and things took off.

Ta-da Lists is another great example of the power of blog-based marketing. We launched Ta-da with a single post on Signal vs. Noise, and a few weeks later it had been mentioned on over 200 blogs and over 12,000 people had signed up for their own Ta-da account. Word about Backpack spread even faster. Within 24 hours of launch, more than than 10,000 signed up.

---

Solicit Early

Get advance buzz and signups going ASAP

We've already touched on it but it bears repeating: Get some sort of site up and start collecting emails as soon as possible. Pick your domain name and put up a logo and maybe a sentence or two that describes, or at least hints at, what your app will do. Then let people give you their email address. Now you're on your way to having a foundation of folks ready and waiting to be notified of your launch.

---

Promote Through Education

Share your knowledge with the world

When a teacher appears as a contestant on Jeopardy, Alex Trebek often comments that it's a "noble profession." He's right. There's definitely something wonderful and rewarding about sharing your knowledge with others. And when the subject you're teaching is your app, it serves a dual purpose: You can give something back to the community that supports you and score some nice promotional exposure at the same time.

As a promotional technique, education is a soft way to get your name — and your product's name — in front of more people. And instead of a hard sell "buy this product" approach, you're getting attention by providing a valuable service. That creates positive buzz that traditional marketing tactics can't match. People who you educate will become your evangelists.

Education can come in many forms. Post tips and tricks at your site that people will want to share with others. Speak at con- ferences and stay afterwards to meet and greet with attendees. Conduct workshops so curious fans can learn more and talk to you in the flesh. Give interviews to publications. Write articles that share helpful information. And write books. ;)

An example from our own history is the Yellow Fade Technique, a method we invented to subtly spotlight a recently changed area on a page. We wrote a post about it on Signal vs. Noise. That post made the rounds and got thousands and thousands of page views (to this day it's doing huge traffic).

The post worked on both an educational and a promotional level. A lesson was learned and a lot of people who never would have known about our products were exposed to them. Another example: During our development of Ruby on Rails, we decided to make the infrastructure open source. It turned out to be a wise move. We gave something back to the com- munity, built up goodwill, garnered recognition for our team, received useful feedback, and began receiving patches and con- tributions from programmers all over the world.

Teaching is all about good karma. You're paying it forward. You're helping others. You get some healthy promotion. And you can even bask in a bit of nobility. So what do you know that the world wants to hear about?

Pay It Forward

The articles and tips section of our blog is one of the most popular sections of our site. Passing on our knowledge about email marketing ensures our customers get the most out of our software. If they can provide a better service to their customers, then they're likely to get more business, which in turn creates more business for us — everyone wins.

Freely sharing our knowledge has also helped position us as experts in the industry and strengthened our relationship with existing customers. They know we care about the quality of their work. Finally, we get loads of targeted inbound traffic from search engines and bloggers who share our articles with their readers. These are people that would never have heard of our software had we not written that article.

—David Greiner, founder, Campaign Monitor

---

Feature Food

They're hungry for it so serve it up

New or interesting features are a great way to generate buzz for your application. Special interest groups love to chew up "feature food" and spit it back out to the community. Alright, that's kind of an unpleasant analogy but you get the point.

For example, by using Ruby on Rails, a new development platform, we generated a ton of attention for Basecamp within the developer community.

The Ajax elements we used in our applications got lots of buzz and even led to Business 2.0 magazine naming 37signals a "key player in Ajax" alongside big names like Google, Yahoo, Microsoft, and Amazon.

Another example: Bloggers took notice of Basecamp's RSS support since it was one of the first business examples of RSS.

iCal integration, a seemingly minor feature, got us press on a ton of Mac-related sites which probably never would have mentioned the app otherwise.

Small teams have a leg up on integrating new ideas into software. While bigger companies have to deal with bureaucratic bottlenecks, you can rapidly implement new ideas and get attention for using them.

Riding the hype coattails of the technology du jour is an effective and cheap way to build your buzz. That said, don't go adding the latest obscure technology just to gain some notice. But if you are using something new or noteworthy, go ahead and spotlight it for special interest groups.

---

Track Your Logs

Study your logs to track buzz

You need to know who's talking about you. Check your logs and find out where the buzz is coming from. Who's linking to you? Who's bitching about you? Which blogs listed at Technorati, Blogdex, Feedster, Del.icio.us, and Daypop are hot on your trail?

Find out and then make your presence felt. Leave comments at those blogs. Thank people for posting links. Ask them if they want to be included on your special advance list so they'll be among the first to know about future releases, updates, etc. Collect positive praise and create a "buzz" page at your site. Testimonials are a great way to promote your app since third-party praise is more trustworthy to most people.

If the comments are negative, still pay attention. Show you're listening. Respond to critiques thoughtfully. Something like: "We appreciate the feedback but we did it this way because..." Or "You raise a good point and we're working on it." You'll soften up your critics and put a human face on your product. It's amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists.

---

Inline Upsell

Promote upgrade opportunities inside the app

Everyone knows to pitch at the marketing site. But the sell shouldn't stop there. If you have a tiered pricing plan (or a free version of your app), don't forget to call out upgrade opportuni ties from within the product.

Tell folks that you'll remove barriers if they upgrade. For example, in Basecamp you can't upload files if you have a free account. When someone tries to upload a file, we don't just turn them away. We explain why file uploading isn't available and encourage them to upgrade to the paid version and explain why that's a good idea. The same approach is used to encourage ex isting customers to upgrade to a higher level account when they max out their current plan.

Existing customers are your best bet for sales. Don't be shy about trying to get repeat business from people who already know and use your product.

---

Name Hook

Give your app a name that's easy to remember

A big mistake a lot of people make is thinking their app's name needs to be ultradescriptive. Don't worry about picking a name that vividly describes your tool's purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress. Writeboard is better than CollaborEdit.

Also, don't focus group or committee-ize the naming process too much. Pick a name that's short, catchy, and memorable and then run with it.

And don't sweat it if you can't get the exact domain name you want. You can always be creative and get close with a couple of extra letters (e.g. backpackit.com or campfirenow.com).

Easy Does It

Doesn't the tech industry realize that thinking up catchy, self-explanatory names would ultimately benefit it in the same way? They'd sell more of whatever it was, because they wouldn't scare off consumers who think they're being kept out of the high-tech club by a bunch of arrogant engineers. The technology would catch on quicker, too. The new product would be easier to describe, easier to use and easier to buy — which, for the companies, means easier to sell.

—David Pogue, columnist, New York Times (from What's in a Product Name?)

---

14 Support

Feel The Pain

Tear down the walls between support and development

In the restaurant business, there's a world of difference between those working in the kitchen and those out front who deal with customers. It's important for both sides to understand and empathize with the other. That's why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it's actually like on the front lines.

A lot of software developers have a similar split. Designers and programmers work in the "kitchen" while support handles the customers. Unfortunately, that means the software chefs never get to hear what customers are actually saying. That's problematic because listening to customers is the best way to get in tune with your product's strengths and weaknesses.

The solution? Avoid building walls between your customers and the development/design team. Don't outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too.

At 37signals, all of our support emails are answered personally by the people who actually build the product. Why? First off, it provides better support for customers. They're getting a response straight from the brain of someone who built the app. Also, it keeps us in touch with the people who use our products and the problems they're encountering. When they're frustrated, we're frustrated. We can say, "I feel your pain" and actually mean it.

It can be tempting to rely on statistical analysis to reveal your trouble spots. But stats aren't the same as voices. You need to eliminate as many buffers as possible between you and the real voices of your customers.

The front lines are where the action is. Get up there. Have your chefs work as waiters. Read customer emails, hear their frustrations, listen to their suggestions and learn from them.

Cut Out the Middle Man

Almost all Campaign Monitor development, support and marketing are performed by two people. Even if we're forced to expand the team, we'll never separate support from development. By personally responding to every request, we force ourselves to sit in our customers shoes and see things from their perspective.

It's important to understand why your customer needs something, not just what it is they need. That context often has a direct impact on how we design something. Cut out the middle man. It's much easier to give your customers what they want when your ears are that close to the ground.

I've discussed this setup with loads of people and the first response is often "shouldn't you just hire a junior to handle your support?" Put yourself in your customer's shoes. If you want your steak cooked just how you like it, would you rather talk to the bus boy or the chef that's actually cooking it?

—David Greiner, founder, Campaign Monitor

---

Zero Training

Use inline help and FAQs so your product doesn't require a manual or training

You don't need a manual to use Yahoo or Google or Amazon. So why can't you build a product that doesn't require a manual? Strive to build a tool that requires zero training.

How do you do this? Well, as we've mentioned before, you start by keeping everything simple. The less complex your app is, the less you'll need to help people out of the weeds. After that, a great way to preempt support is by using inline help and faqs at potential points of confusion.

For example, we offer preemptive support on the screen that allows people to upload their logo to Basecamp. Some people experienced a problem where they would keep seeing an old logo due to a browser-caching issue. So next to the "submit your logo" area, we added a link to an faq that instructed customers to force-reload their browsers in order to see the new logo. Before we did this, we would get 5 emails a day about this problem. Now we get none.

---

Answer Quick

Quick turnaround time on support queries should be a top priority

Customers light up when you answer their questions quickly. They're so used to canned responses that show up days later (if at all) that you can really differentiate yourself from competitors by offering a thoughtful response right away. During business hours, we answer 90% of all email support requests within 90 minutes — and often within a half-hour. And people love it.

Even if you don't have a perfect answer, say something. You can buy goodwill with a response that is delivered quickly in an open, honest way. If someone is complaining about an issue that can't be fixed immediately, tell them something like, "We hear what you're saying and we'll be working on it in the future." It's a great way to diffuse a potentially negative situation.

Customers appreciate directness and will often shift from angry to polite if you respond quickly and in a straight-shooting manner.

An Army of Many

How can a small team of just three developers create an innovative product and successfully compete with the big guys? The answer is to enlist an army of many.

Remember from your first day that your customers are your most important asset and that they are absolutely vital to your long-term success so treat your community of users like royalty. The way to compete with the big guys is by starting small and paying attention to every one of your customers.

It is your customers that will be the first to alert you of bugs, that will be the first to alert you of needs that have not been met and it is your first customers that will carry the flag and spread your message.

This does not mean that your product has to be perfect when you launch. Quite to the contrary, release early and often. However, when your customers encounter bugs, make sure to send a reply to them quickly thanking them for their input.

Customers don't expect your product to be perfect and they don't expect that all of their features will be implemented. However, customers do expect that you are listening and acknowledging that you care, so show that you care. This is one area where most large companies show a huge deficit so develop a sense of community early.

At Blinklist, every single customer email is answered, usually within the first hour (unless we happen to be asleep). We also have an online forum and we make sure that every single post and comment gets acknowledged.

Equally important, all of our developers receive our customer feedback and they are active participants in the online discussion forums. This way, we are slowly but surely building an active and loyal BlinkList community.

—Michael Reining, co-founder, MindValley & Blinklist

---

Tough Love

Be willing to say no to your customers

When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products.

If we obeyed every whim of our customers, Basecamp would have: comprehensive time tracking, comprehensive billing, comprehensive meeting scheduling, comprehensive calendaring, comprehensive dependency task systems, comprehensive instant message chatting, comprehensive wiki functionality, and comprehensive whatever-else-you-can-imagine.

Yet, the #1 request we get on customer surveys is to keep Basecamp simple.

Here's another example: Despite some complaints, we decided not to support ie5 with our products. That was 7% of the market we were writing off. But we decided it was more important to worry about the other 93%. Fixing bugs and testing for ie5 just isn't worth the time. We'd rather make a better product for everyone else.

As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C'est la vie.

Related to this, it's critical that you as a development company love your product. And you won't love your product if it's filled with a bunch of stuff you don't agree with. That's yet another justification for vetoing customer requests that you don't believe are necessary.

---

In Fine Forum

Use forums or chat to let customers help each other

Forums and web-based group chat are a great way to let customers ask questions and help one another out. By eliminating the middleman — that's you — you provide an open stream of communication and save yourself time in the process.

At our product forums, customers post tips and tricks, feature requests, stories, and more. We pop in from time to time to offer some assistance but the forums are mainly a place for the community to help each other and share their experiences with the product.

You'll be surprised how much people want to help one another.

---

Publicize Your Screwups

Get bad news out there and out of the way

If something goes wrong, tell people. Even if they never saw it in the first place.

For example, Basecamp was down once for a few hours in the middle of the night. 99% of our customers never knew, but we still posted an "unexpected downtime" notice to our Everything Basecamp blog. We thought our customers deserved to know.

Here's a sample of what we post when something goes wrong: "We apologize for the downtime this morning — we had some database issues which caused major slowdowns and downtimes for some people. We've fixed the problem and are taking steps to make sure this doesn't happen again...Thanks for your patience and, once again, we're sorry for the downtime."

Be as open, honest, and transparent as possible. Don't keep secrets or hide behind spin. An informed customer is your best customer. Plus, you'll realize that most of your screwups aren't even that bad in the minds of your customers. Customers are usually happy to give you a little bit of breathing room as long as they know you're being honest with them.

A side note about delivering news, bad and good: When bad news comes, get it all out in the open at once. Good news, on the other hand, should be trickled out slowly. If you can prolong the good vibes, do it.

Be Swift, Direct, and Honest

It may sound strange, but the best-case scenario is when the company itself reports the bad news. This is proactive and prevents your company from being put in a weakened, defensive position.

—Greg Sherwin, Vice President of Application Technology, CNET, and Emily Avila, Principal, Calypso Communications (from A Primer for Crisis PR)

---

#Post-Launch chapter 15 {#ch15}

One Month Tuneup

Issue a major update 30 days after launch

A quick update shows momentum. It shows you're listening. It shows you've got more tricks up your sleeve. It gives you a second wave of buzz. It reaffirms initial good feelings. It gives you something to talk about and others to blog about.

Knowing a quick upgrade is coming also lets you put the focus on the most crucial components before launch. Instead of trying to squeeze in a few more things, you can start by perfecting just the core feature set. Then you can "air out" the product in the real world. Once it's out there you can start getting customer feedback and you'll know which areas require attention next.

This baby-step approach worked well for Backpack. We launched the base product first and then, a few weeks later, added features like Backpack Mobile for handhelds and tagging since those things are what our customers told us they wanted most.

---

Keep the Posts Coming

Show your product is alive by keeping an ongoing product development blog post-launch

Don't stop blogging once you launch. Show your product is a living creature by keeping a dedicated blog that you update frequently (at least once a week, more often if you can).

Things to include:

• Faq
• How-tos
• Tips & tricks
• New features, updates, & fixes
• Buzz/press

A blog not only shows your app is alive, it makes your company seem more human. Again, don't be afraid to keep the tone friendly and personal. Small teams sometimes feel like they need to sound big and ultra-professional all the time. It's almost like a business version of the Napoleon Complex. Don't sweat sounding small. Revel in the fact that you can talk to customers like a friend.

It's Alive

A frequently-updated product blog is the best indicator that a webapp is in active development, that it's loved and that there's a light on at home. An abandoned product blog is a sign of an abandoned product, and says the people in charge are asleep at the wheel.

Keep the conversation going with your users on your product blog, and be transparent and generous with the information you share. Let your company's philosophies shine through. Openly link and discuss competitors. Hint at upcoming features and keep comments open for feedback.

A living product is one that's talking and listening to its users. A frequently-updated product blog promotes transparency, a sense of community and loyalty to your brand. Extra, free publicity is a bonus.

As editor at Lifehacker, I scan the product blogs of webapps I love continuously — like Google, Flickr, Yahoo, del.icio.us, and 37signals product blogs. I'm much more likely to mention them than webapps that send out one-sided press releases out of the blue and don't maintain an open conversation with their users and fans.

_—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide _

---

Better, Not Beta

Don't use "beta" as a scapegoat

These days it feels like everything is in beta stage forever. That's a cop out. An interminable beta stage tells customers you're not really committed to rolling out a finished product. It says, "Use this, but if it's not perfect, it's not our fault."

Beta passes the buck to your customers. If you're not confident enough about your release then how can you expect the public to be? Private betas are fine, public betas are bullshit. If it's not good enough for public consumption don't give it to the public to consume.

Don't wait for your product to reach perfection. It's not gonna happen. Take responsibility for what you're releasing. Put it out and call it a release. Otherwise, you're just making excuses.

Beta is Meaningless

Blame Google, et al, for causing problems like this. For now, users have been trained by the aggregate of developers to think "beta" doesn't really mean anything.

—Mary Hodder, information architect and interaction designer (from The Definition of Beta)

All the Time

Is it just me, or are we all in beta, all the time?

—Jim Coudal, founder, Coudal Partners

---

All Bugs Are Not Created Equal

Prioritize your bugs (and even ignore some of them)

Just because you discover a bug in your product, doesn't mean it's time to panic. All software has bugs — it's just a fact of life.

You don't have to fix each bug instantly. Most bugs are annoying, not destroying. Annoyances can be tabled for a bit. Bugs that result in "it doesn't look right" errors or other misdemeanor miscues can safely be set aside for a while. If a bug destroys your database, though, you obviously need to fix it immediately.

Prioritize your bugs. How many people are affected? How bad is the problem? Does this bug deserve immediate attention or can it wait? What can you do right now that will have the greatest impact for the greatest number of people? Often times adding a new feature may even be more important to your app than fixing an existing bug.

Also, don't create a culture of fear surrounding bugs. Bugs happen. Don't constantly seek someone to blame. The last thing you want is an environment where bugs are shoved under the rug instead of openly discussed.

And remember what we said earlier about the importance of honesty. If customers complain about a bug, be straight up with them. Tell them you've noted the issue and are dealing with it. If it won't be addressed right away, tell why and explain that you're focusing on areas of the product that affect a greater number of people. Honesty is the best policy.

---

Ride Out the Storm

Wait until knee-jerk reactions to changes die down before taking action

When you rock the boat, there will be waves. After you introduce a new feature, change a policy, or remove something, knee-jerk reactions, often negative, will pour in.

Resist the urge to panic or rapidly change things in response. Passions flare in the beginning. But if you ride out this initial 24-48 hour period, things will usually settle down. Most people respond before they've really dug in and used whatever you've added (or gotten along with what you've removed). So sit back, take it all in, and don't make a move until some time has passed. Then you'll be able to offer a more reasoned response.

Also, remember that negative reactions are almost always louder and more passionate than positive ones. In fact, you may only hear negative voices even when the majority of your base is happy about a change. Make sure you don't foolishly backpedal on a necessary, but controversial, decision.

---

Keep Up With the Joneses

Subscribe to news feeds about your competitors

Subscribe to news feeds about both your product and your competitors (it's always wise to know the ways of one's enemy). Use services like PubSub, Technorati, Feedster, and others to stay up to date (for keywords, use company names and product names). With rss, this constantly changing info will be delivered right to you so you're always up to speed.

---

Beware the Bloat Monster

More mature doesn't have to mean more complicated

As things progress, don't be afraid to resist bloat. The temptation will be to scale up. But it doesn't have to be that way. Just because something gets older and more mature, doesn't mean it needs to get more complicated.

You don't have to become an outer space pen that writes upside down. Sometimes it's ok to just be a pencil. You don't need to be a swiss-army knife. You can just be a screwdriver. You don't need to build a diving watch that's safe at 5,000 meters if your customers are land-lovers who just want to know what the time is.

Don't inflate just for the sake of inflating. That's how apps get bloated.

New doesn't always mean improved. Sometimes there's a point where you should just let a product be.

This is one of the key benefits to building web-based software instead of traditional desktop based software. Desktop software makers such as Adobe, Intuit, and Microsoft need to sell you new versions every year. And since they can't just sell you the same version, they have to justify the expense by adding new features. That's where the bloat begins.

With web-based software based on the subscription model, people pay a monthly fee to use the service. You don't need to keep upselling them by adding more and more and more, you just need to provide an ongoing valuable service.

---

跟著潮流走

對於新的方向保持開放的態度

網路應用程式的美麗之處在於它的流體性。你沒有必要把它包裝在一個盒子裡，寄送出去，然後枯等幾年後的下一個版本；你可以一邊進行一邊調整。寶持開放的態度，尤其是您原始的點子可能不是最好的點子這事實。

看看 Flickr。一開始它是個叫做 The Game Neverending（無結尾遊戲）的線上遊戲，但它的創始人很快的發現遊戲內分享照片的功能比起遊戲本身，反而是個比較可能的產品（遊戲最後是擱在架上塵封了）。要願意承認錯誤並且修改方向。

當個衝浪者。仔細看海。想出大浪什麼時候來並且依照它來調整。

---

16 结论

结论

达成了！

您达成了！希望您已经跃跃欲试，等不及在您的软体上开始 Getting Real。世上真的没有一个以最少资源写优秀软体的更好时机。找要有对的点子、热情、时间和技能，只有天边才是你的极限。

一些收尾的想法：

执行力

每个人都能读书，每个人都能想到好点子，每个人都可以是网页设计师，每个人都会写网志，每个人都能雇用程式设计师写程式。

您和其他人的差别将会在于您如何执行。成功仅在于优秀的执行力。

以软体来说，那代表很多事情要做对。您不能只有好的写作能力却无法实现文章中的承诺；乾淨的介面设计仍然不能挽救杂乱无章的程式码；一个优秀的软体要是没有好的宣传，没有人知道，仍然是不值分文的。如果要得阵达分，你必须综合前述的所有元素。

重点是平衡。如果你向某一方向倾斜，你正走向失败。不断的试著找出你并且专注于您最弱的一环，直到他们达到标淮。

人

写一个成功的网路应用程式最重要——也值得我们再次强调——的原料：有关的人。如果你没有正确的人来执行，印度教箴言、地震中心设计、较少的软体，和其他精采的概念将没办法发挥。

你需要对他们工作有热忱的人。这些人在乎他们的工艺——他们真的认为这是种工艺。这些人对他们的作品感到骄傲，无论财务上的酬劳有多少。这些人会在细节上挥汗努力，即使 95% 其他的人不知道差别在哪裡。这些人想要建立优秀的软体但不愿以次等货和解。这些人需要其他人。 ok, not really that last one but we couldn't resist throwing a little Streisand into the mix. 总而言之，当你找到上面所述的这些人，留住他们。再怎么说，产品的成败——也是公司的成败——是操之在小组的成员。

不只是软体

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

• 特别作战部队，例如绿色贝雷帽或海豹小组，使用小队以及快速部署来达到其他单位太大或太慢而没办法完成的工作。
• The White Stripes embrace restraints by sticking to a simple formula: two people, streamlined songs, childlike drumming, keeping studio time to a minimum, etc.
• 苹果电脑的 iPod 选择不提供例如内建收音机或是录音机的附加功能，反而在竞争者中脱颖而出
• Hurry up offenses in football pick up big chunks of yards by eliminating the "bureaucracy" of huddles and play-calling.
• Rachael Ray 和她成功的食谱与电视节目建立于 30 分钟就可以淮备好的餐饮
• 海明威和卡佛用简单、明瞭的语言，但仍能在他们的文学著作中达到最大的影响力。
• 莎士比亚陶醉于十四行诗（商籁诗）的限制内：十四行、抑扬格、五音步的诗词
• 还有很多……

当然，Getting Real 是关于写出优秀的软体，但没有画地自限的必要。将这些概念套用在生活上别的领域，您或许会碰上好的结果。

保持联繫

让我们知道 Getting Real 如何帮您得到好结果，请写信到gettingreal [at] 37signals [dot] com.

另外，参观我们的网志 Signal vs. Noise ，了解 37signals 最新的产品、Getting Real、可用性、设计和一些其他的东西

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

---

37signals Resources

• 37signals site
• Signal vs. Noise weblog
• Basecamp — Web-based project collaboration
• Campfire — Web-based group chat for business
• Backpack — Web-based information organizer
• Writeboard — Web-based collaborative writing
• Ta-da List — Web-based dead-simple to-do lists
• Ruby on Rails — Open-source web application framework

---

Translation

Thanks to the following translators: "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.

Getting Real Overview