Getting Real 第六章
第六章 过程
第一节 尽快拿出实物###
确定真实的产品，尽快实现
想要建立势头，集结团队，清除无用的点子，最好的方式就是把软件运行起来。从第一天起，这就应该是你的首要任务。
如果能让软件更快地运行起来，精简内容、略过细节等都是都是可以接受的。一旦你开始了，你会对如何继续下去有更清晰的认识。故事、线框图、html 原型都只是假设。运行起来才是真实的。
对于真正运行起来的软件，每个人都能更容易理解并达成一致。你避免了在无关紧要的草图上浪费时间。你会认识到那些被你忽视的部分才是真正关键的。
真实的产品产生真实的反应，这能让你获得真相。
真实带来共识
如果有一个完整的、真实的模型，当一群人聚在一起想要找到一个和谐一致的答案，他们的观点会更容易趋同。如果只是在画草图，或随意抛出观点，他们是无法达成一致的。如果你拿出实物，共识就比较容易达成。
—— Christopher Alexander，建筑学教授 (from 对比建筑和谐的概念 )
尽快运转起来
我所参与过的所有大大小小的软件项目，他们的成功，没有一个是来自脱离并行开发，对计划、成本、功能进行长期的规划讨论而得来的。你太容易把时间浪费在开发无用的功能上。
这个道理适用于软件开发的所有层面，把软件尽快运行起来是一个分形的咒语。这不仅适用于项目整体，也适用于其中的任意一个开发组件。
当一个重要的组件可用时，开发者想知道这个组件能否和自己的应用配合，他们会尽快尝试。即使组件的配置不完美或不完整，这种早期的合作会产生良好的界面和功能。
—— Matt Hamer, 开发者和产品经理, Kinja
第二节 反反复复
用迭代的方式工作
不要期望第一次就把事情做对。让软件成长并与你对话。让他变形、进化。基于网络的应用，无需在发布时就做到完美。设计界面，使用他们，分析他们，周而复始。
迭代过程能让你随时做出有效的决策，而不是寄希望于预先做好一切。在需要引起注意的地方，你会获得真实的反馈和引导。
迭代带来自由
如果你知道有些事可以稍后再做，就不必在首次尝试就追求完美。了解到将来你还要重新审视这些问题，这样你就有巨大的动力把想法尽快实现，看看是否可行。
或许你比我聪明
或许你比我聪明的多。
这完全可能。事实上，是非常有可能。如果你和大多数人一样，也就是像我一样，对无法感知的事物缺乏想象。
人类能对环境做出极好的回应。一只老虎走进房间我们会慌张，破坏性的洪水过后我们知道如何收拾。不幸的是，在预先制定计划，理解行为带来的后果，以及排定重要事项优先级方面，我们很不擅长。
或许你是少数能把所有事情都装在脑子里的人，但这不重要。
Web 2.0 ，我们假定世界上的所有人都在使用网络，聪明的开发者能够利用这种人性的弱点。怎么做？让用户把他们的想法告诉你，你还有时间进行改进。
最后一个句子解释了你为何应该用这种方式开发，以及如何推广/发布你的产品。
把你的故事讲清楚。确保它能工作。然后发布，修订。没人能比集体更有智慧。
—— Seth Godin, 作家/企业家
第三节 从想法到执行
头脑风暴 > 草图 > HTML > 代码
这是我们回归现实的过程：
头脑风暴
提出想法。这个产品要做什么？对于 Basecmap ，看看我们的需求。我们希望公布项目更新，希望用户参与。我们知道项目有时间表。我们想把归档集中，这样用户能够很容易地查看旧文档。我们希望能有一个鸟瞰视图来查看所有项目的进展。以上这些，大致组成了我们的基础。
这个阶段不考虑细枝末节，而是考虑大的框架问题。这个应用要解决什么需求？我们何时能知道这是有效的？我们究竟要做什么？这些都是战略层的问题，而不是像素级别的讨论。这个阶段，任何的细节都是没有意义的。
草图
草图应该是快速、潦草、廉价的，是关于你想怎么开始的问题。框架、线条、图形，寥寥几画，勾勒出你脑袋中的想法。这个阶段，应该是把概念性的东西转化成粗略的界面设计。这是一个试验阶段，没有什么答案是错的。
创建 HTML 界面
创建一个 HTML 版本的功能模型，放上一些真实的内容，让每个人都知道在屏幕上是如何展现的。
对于 Basecamp ，我们先做了“发送一条信息”的界面，然后是 “编辑信息”的界面，一切都从这开始。
不要在这个阶段编写任何的代码。只用 html 和 css 创建一个模型。稍后再考虑执行。
写代码
当原型看起来不错了，演示了足够的必备功能，就可以开始写代码了。
在这个过程中，记得要保持灵活，并进行几次迭代。如果有任何不好的结果，不要犹豫，重新来过就好。经历几次的迭代循环是很正常的。
第四节 避免偏好设置
不要将小细节留给用户来选择
你面临一个艰难的决定：在每个页面里应该包含几条信息？你的第一反应也许是，“只要设定一个选项，让用户去选择25，50，或是100。”虽然这是个简单的办法，但是你要做出决定。
偏好设置是避免做出艰难决定的一个方法
你把问题留给用户，而不是利用你的专业知识来选择最好的途径。看起来你是帮了客户一个忙，但你只是把工作留给了他们（而很可能他们已经够忙了）。对于客户来说，偏好设置里无穷无尽的选项是很头疼的，绝不是一件好事。客户不应该替你考虑这些细节，不要把这些负担转移给客户，这是你的职责。
偏好设置是魔鬼，因为他们创造了更多的软件。更多的选项需要更多的代码，也意味着你需要完成额外的测试和设计工作。你还得解决你永远都看不见的偏好设置选项排列和屏幕界面。这意味着你不了解的 bug ：破碎的布局，崩溃的表格，奇怪的页码问题，等等。
做出选择
代替你的客户来做这些简单的决定。我们在 Basecamp 中就是这么做的。每页的信息数量是 25 条。在概述页面，只显示最后的 25 个项目。信息按从新到旧的日期排列。最新的 5 个项目显示在仪表盘上。没有任何选项，这就是它应该有的处理方法。
是的，你可能做了一个错误的决定，但那又怎样？如果你做了，人们会抱怨，然后告诉你。你永远都可以作出调整。回归现实就是为了能够随时作出改变。
偏好设置是有成本的
有些偏好设置能带来重要的好处，也可能是重要的界面要素。但每个都是有成本的，你必须仔细衡量它的价值。很多用户和开发者不知道这个，结果在一些价值不大的选项上浪费了大量的时间和金钱。
第五节 搞定！
决定是暂时的，迅速作出，继续前进
搞定。把它想像成是一个神奇的词汇。当你搞定了某个事，意味着有什么事情你已经完成了。一个决定已经作出了，你可以继续前进。搞定意味着你已经建立起了势头。
但请稍等，如果你搞砸了并作出了一个错误的决断呢？没关系。这不是脑外科手术，只是个网页应用。如我们一直所说的，在开发过程中，你可能要要对功能和想法进行好几次的重新审视。无论作出多么详尽的计划，还是有大半的可能出错。
重视前进的重要性。进入决策的正确节奏。作出快速、简单的决策，如果不行，快速返回修改。
接受“决策是暂时的”这个概念。接受错误是会发生的，别把错误太当回事因为你可以快速修正他们。执行、建立势头、前进。
成为一个刽子手
想法只有被执行出来才有意义。他们只是一个乘法器，执行才是关键。
解释：
糟糕的想法 = -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
第六节 在自然环境下测试
在真实的使用场景下测试你的应用
没有什么能替代真实用户在实际场景下使用你的 app。获取真实的数据。获取真实的反馈。然后基于这些信息来改进。
正式的可用性测试太生硬了。实验室无法反映真实的情况。如果你监视用户的行为可以获得一些信息，但用户在镜头前通常表现地不够自然。有人在一旁观察的时候，人们会格外小心不犯错误，但错误正是你所寻找的东西。
取而代之的，在实际应用中添加一些 beta 功能，向经过筛选的小部分用户发放。这会揭示用户的真实使用数据和工作流。你会从中获取真实的结果。
此外，不要区分发行版本和 beta 版本，他们应该始终是同一个东西。一个独立的 beta 版本只能触及表明，在正式版本中加入 beta 功能，才能得到全貌。
Beta 书
如果开发者对发布代码感到紧张，那出版商或作家岂不是要被出书这件事吓坏了。书籍一旦付诸印刷，想改变就不太可能了。（实际上并非如此，但对旧技术的感知和记忆仍然徘徊在行业里。）所以，出版者在出版前会耗费大量的精力把事情做对。
当我写《基于 Rails 的敏捷开发》这本书时，开发者们有巨大的潜在需求：我们现在就需要这本书，我们想学习 Rails 。如果我站在出版商的角度考虑，我会说，“它还没准备好。”但来自社区的压力和 Heinemeier Hansson 的怂恿改变了我的想法。我在书籍完稿前的两个月发布了 pdf 版本，结果很惊人。我们不仅卖出了许多书，还得到了反馈 —— 大量的反馈。我设置了一个系统来自动捕获读者的评论，最终我们获得了大约 850 条关于字体或技术错误的报告，以及对新内容的建议。几乎所有这些报告和建议都以不同的方式融合进最后的成书。
这是一个双赢：我发布了一本更完善的纸质书，社区也更早地接触到了他们想要的东西。如果你处于一场竞赛，尽早拿出些东西可以让人们拥护你，而不是你的竞争对手。
—— Dave Thomas, 实用主义的程序员
快速行动
- 判断一个事情是否值得做
- 尽快实施——不求完美。只管做。
- 保持，上传，发布。
- 看看人们是怎么想的。
虽然我并不乐于给产品添加新功能，可是一旦发现某个事情是值得做的，我通常在几个小时后就会让它上线，虽有瑕疵但不影响发布，让反馈来引导未来的修正工作。
—— Derek Sivers, 董事长/程序员，CD Baby and HostBaby
第七节 压缩你的时间
分解
要估计未来几个星期或几个月的工作是妄想，你根本无法预知接下来会发生什么。
所以，压缩你的时间。把时间表分解成小块。把项目看成是 12 个持续一周的小项目，而不是一个 12 周的大项目。把任务分解成 6-10 小时的小任务，而不是自己瞎猜的超过 30 个小时的任务。然后一步一个脚印。
相同的理论也适用于其它问题。你是否被一个巨大的问题缠绕着找不到出路？把它分解。持续地把问题分解成更小的部分直到你能够消化他们。
更小的任务和更短的时间线
软件开发者是一类特别的乐观主义者：当拿到一个编程任务时，他们会想，“这很容易，不会花费太多的时间。”
给一个程序员三周的时间完成一个巨大的任务，他会拖延两周半，然后用一周的时间来写程序。偏离进度通常伴随着错误的需求，任务通常比想象中更复杂。此外，谁能记住三周前达成的共识呢？
给一个程序员一下午的时间去完成一小段特定模块的代码，他能迅速完成并进入下一阶段。
更小的任务和更短的时间线是更可控的，降低需求误解的可能性，减少改变和返工的成本。更短的时间线让开发者更容易体会到完成任务的快感，避免他们有这样的想法，“我还有大把时间来做这件事，现在，还是让我先给 iTubes 的歌曲评分吧。”
—— Gina Trapani, 网页开发者/ Lifehacker（效率和软件指南） 编辑
主要因素
下次有人向你就一些不可知的问题寻求一个确切答案时，无论是截止日期，最终成本或是需要多少牛奶才能填满大峡谷之类的，你只需回答：“我不知道。”
这并不会伤害你的信誉，这表明你对于决策是小心谨慎的。你不会随便说个词来表现自己的聪明。也能把问题转变为一个合作性的对话。通过学习如何评估你的需求，你们可以对数字背后的真相达成共识。
—— Merlin Mann, 43folders.com 的创建者和编辑
解决近在眼前的那个问题
近年来我最喜欢的一件事就是 "nofollow" 属性（一个 HTML 属性）的发布和采用。没人事先讨论过它。没有一大堆的会议或委员会来讨论它的语义或语法属性。没有复杂的注解把一个简单的想法转变成繁杂的文档，以至于我要通篇阅读才知道如何使用，但最终却因为不清楚该采用 .3 或 3.3b 格式而选择放弃。
它简单有效，为需要的人提供了一个选项，对于不关心技术规格条条框框的人来说，这尤其重要。
有时，解决近在眼前的问题是更有用的，胜于解决未来的 20 个问题。他不是针对垃圾邮件的一个小胜利，对以简洁、优雅为己任的开发者而言，这是一个大胜利。
—— Andre Torrez, Federated Media Publishing 程序员/副总裁
