操作第六章

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

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

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

做少一些功能，跳过一些细节，如果一些捷径能加快软件进度就大胆用，这些都是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的敏捷 Web 开发）这本书时，很多的开发者有相当明确的需求：我们现在就需要这书 — 我们想要知道更多有关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, 程序员和副总工程师

Getting Real 第六章：操作

操作 第六章