Getting Real

Getting Real 是一种更小、更快、更好的软件构建方式，它关注于构建真实的产品，而非纸上谈兵。

• 它代表更少的东西：更少的体量、软件、功能和文书工作。本质是精简和敏捷。
• 传统的功能规格说明书（Functional Spec）是虚构的，而一个真实的网页才是现实。

• 跳过所有代表“真实”的东西（图表、线框图等），直接构建“真实”的东西。
• 从界面（用户真实体验的屏幕）开始，然后向后构建。
• 拥抱迭代、启动、调整和持续改进，这是Web应用的巨大优势。

要做得比你的竞争对手少，以此来击败他们。

• “比对手多一个功能”的冷战心态是昂贵、防御性和偏执的，它让你只能跟随，无法引领。

• 解决简单的问题，把那些棘手、复杂的问题留给别人。
• 少即是：更少的功能、更少的选项/偏好、更少的人员和结构、更少的会议和抽象、更少的承诺。

为自己构建软件，解决你自己的问题（“挠自己的痒”）。

• 如果你自己有这个问题，那么很可能有成千上万的人和你在一条船上，这就是你的市场。
• 为自己解决问题会带来激情，这是关键。激情意味着你会真正地使用和关心你的产品。

• 将自己作为目标受众，你就能知道什么是重要的，什么不是。

外部资金是 B 计划。约束能激发创造力。

• 拿了投资人的钱，你就得对他们负责，赚钱常常会压倒构建高质量产品。
• 如今启动成本很低（硬件便宜、开源软件免费）。

• 用手头的现金做事，思考用3个人代替10个人能做什么，用3个月代替6个月能做什么。
• 利用约束，它会迫使你更早地面对现实，更快地将想法推向市场。

要按时按预算发布，就把时间和预算定死，然后缩减功能范围。

• “按时、按预算、按范围”完成的神话几乎从不发生，且质量往往受损。
• 发布一个范围虽小但很棒的产品，胜过一个功能齐全但平庸且充满漏洞的产品。

• 如果无法在规定时间和预算内完成所有事情，那就缩减范围。以后总有时间添加东西。
• 这会迫使你做出艰难的决定，优先处理真正重要的事情。

明确你的应用“不应该”是什么，这能帮你找到方向。

• 当你决定创建一个与敌人（如 Microsoft Project）完全相反的产品时，你的方向就非常清晰了。
• 冲突能激发人们的兴趣，并帮助他们通过对比来理解你的产品。

• 找到你的敌人（一个产品、一个理念、一种做事方式），然后把自己定位为它的对立面。
• 这会带来一个非常清晰的营销信息。

你越精简，改变方向就越容易。

• 商业世界和物理世界一样，体量越大的物体，改变其方向所需的能量就越多。

• 通过即时思考、小团队、更少的软件、精简的界面和开放文化来减少体量。
• 避免长期合同、多余员工、永久性决策和办公室政治，这些都会增加体量。

用一个三人团队来开发 1.0 版本。

• 团队效率与成员数量的平方成反比。沟通路径随着人数增加而呈指数级增长。

• 三人是神奇数字：一个开发者，一个设计师，一个“清道夫”（能在两者之间游走的人）。
• 人力不足会迫使你更早地做出权衡，明确优先级。

让限制引导你走向创造性的解决方案。

• 约束能驱动创新并强迫你保持专注。它们是伪装的优势。

• 不要试图移除约束，而是利用它们。没有足够的钱、时间、人手？这是好事。
• 忘掉风险投资、长发布周期和快速招聘。用你已有的东西工作。

为你的应用明确定义一句话的愿景。

• 这个愿景将指导你所有的决策，让你保持在正确的道路上。
• 例如，Basecamp的愿景是：“项目管理就是沟通。”

• 在开始设计或编码之前，想清楚你的产品为什么存在，它与其他产品有何不同。
• 当遇到难题时，问自己：“我们是否忠于这个愿景？”

从大处着手，再到小处。不要过早陷入细节。

• 过早关注细节会导致停滞、分歧、会议和延迟，这些会扼杀士气。
• 细节会在你使用产品的过程中自然浮现。

• 第一周不要担心标题字体大小，第二周不要纠结完美的绿色阴影。先把东西放到页面上，让它能用。
• 以后有的是时间做个完美主义者。

你现在还没有扩展性问题。等到问题真的发生了再说。

• 绝大多数Web应用永远不会达到需要大规模扩展的阶段。
• 如果你真的遇到了，恭喜！这是一个好问题。届时你将有真实数据来指导你如何解决。

• 初期，把构建一个坚实的核心产品作为你的首要任务，而不是痴迷于可扩展性和服务器集群。
• Basecamp第一年只用了一台服务器。

构建一个出色的一半产品，而不是一个功能齐全但粗制滥造的半成品。

• “厨房水槽里什么都有”的开发方式只会让你得到一个糟糕的产品版本。

• 坚持只做最本质的东西。把你的产品构想砍掉一半，再砍掉一半，直到只剩下最核心的功能。
• 从一个精简、智能的应用开始，让它获得牵引力，然后在这个坚实的基础上添砖加瓦。

让每个功能都努力证明自己值得被实现。

• 每次你对一个功能说“是”，你就像领养了一个孩子，需要对它负责到底。

• 对每一个新功能请求的初始反应应该是“暂时不做”。
• 只有当一个功能请求反复出现，你才应该开始认真考虑它。

创新不是对所有事情都说“是”，而是对除了最关键的功能之外的所有事情说“不”。

让你的客户来提醒你什么是重要的。

• 真正重要的请求会像气泡一样不断冒出来。它们是唯一你需要记住的。

• 读客户的功能请求，然后把它们扔掉。不要费心去追踪和保存每一个请求。
• 让你的客户成为你的记忆。如果一个东西真的值得记住，他们会一次又一次地提醒你。

尽快让一些真实的东西跑起来。

• 可运行的软件是建立动力、团结团队和排除行不通想法的最佳方式。
• 故事、线框图，甚至HTML模型都只是近似物。可运行的软件才是真实的。

• 可以少做、跳过细节、走捷径，只要能更快地得到可运行的软件。

遵循一个从抽象到具体的过程：头脑风暴 -> 纸上草图 -> HTML屏幕 -> 编码。

• 头脑风暴： 关注宏大问题，不是细节。
• 纸上草图： 快速、粗糙、廉价。将概念转化为粗略的界面设计。
• 创建HTML屏幕： 用HTML和CSS构建一个静态模型，让每个人都能看到真实屏幕的样子。先不要写任何程序代码。
• 编码： 当模型看起来不错并展示了必要功能后，再开始编写后端代码。

替你的客户做决定，不要用偏好设置来逃避艰难的决策。

• 提供无尽的选项对客户来说是头痛，而不是福音。这是把你的责任推给了他们。
• 偏好设置是魔鬼，它们会创造更多的软件、更多的代码和更多的测试工作。

• 做出简单的决定。比如，每页显示25条消息。就是这样，没有选项。
• 如果你的决定错了，人们会抱怨，你随时可以调整。

在开始编程之前设计界面。

• 编程是构建应用中最“重”的部分，最昂贵也最难改变。
• 界面就是你的产品。人们看到的就是你卖的东西。

• 从界面开始，这样你可以从一开始就看到和感受到应用的样子。
• 先用纸笔画草图，然后用HTML设计。这些都很轻量，易于修改或丢弃。

从页面的核心开始，然后向外构建。

• 传统模式是“先建框架再填内容”，这是一种落后的流程。

• 关注页面真正的本质——震中。例如，博客文章页的震中就是文章本身，而不是导航或页脚。
• 先设计最重要的内容，完成之后再考虑第二重要的元素，以此类推。

为每个屏幕设计三种状态：常规、空白和错误，并特别关注首次运行的“空白”体验。

• 空白状态是你应用的第一印象，却常常被设计师忽略，因为他们总是在填充了数据的模板上工作。

• 常规状态 (Regular): 应用正常工作，数据充足。
• 错误状态 (Error): 出现问题时。
• 空白状态 (Blank): 用户第一次使用，没有任何数据时。利用这个机会提供教程、帮助信息和示例，设定用户的期望。

每一个字母都很重要。优秀的界面是写出来的。

• 如果你认为每个像素都重要，那么你也必须相信每个字母都重要。

• 用你用户的语言说话，避免技术术语和内部行话。
• 保持简短、甜美。按钮上的文字是“提交”还是“保存”？这是文案，也是设计。

如果出了问题，告诉大家。即使他们一开始并不知道。

• 一个知情的客户是你最好的客户。开放、诚实和透明会为你赢得信任。

• 当坏消息来临时，一次性全部公开。当好消息来临时，慢慢地、一点点地放出来。

不要用“Beta”作为借口。

• 永久的Beta阶段告诉客户，你并未真正致力于推出一个成品。它是在推卸责任。

• 不要等待产品完美。它永远不会完美。为你的发布负责，把它发布出去，称之为一个“发布版”。

更成熟不意味着更复杂。

• 传统桌面软件为了每年卖新版本，必须不断增加功能，这就是臃肿的开始。
• 基于订阅的Web软件没有这种压力，你只需提供持续的价值。

• 抵制臃肿。有时候，一支铅笔就够了，你不需要一支能在太空倒着写的笔。
• 有时候，你应该让一个产品保持原样。

成功的关键在于卓越的执行和优秀的人才。

• 每个人都可以读书、想出点子。你和别人之间的区别在于你执行得有多好。
• Getting Real 的理念不仅适用于软件，它无处不在：特种部队、The White Stripes乐队、海明威的写作...

• 执行： 寻求平衡。好的文案、干净的界面、可靠的代码和有效的推广，缺一不可。
• 人才： 找到那些对自己的手艺充满激情、关心细节、追求卓越的人。他们是你项目成败的关键。