对于任何构建Web应用的人来说，这是一本必读的书。《Getting Real》充满了保持简单的见解、对立的观点和非常规的软件设计方法。这不是一本技术书，也不是一本设计教程，而是一本**之书。任何从事网络应用的人--包括创业者、设计师、程序员、管理人员或营销人员--都会在本书中找到价值和灵感。
下面是我们对时常听到的一些抱怨的回应。
实事求是是一个对我们非常有效的系统。也就是说，本书中的想法并不适用于的每一个项目。如果你正在建造一个武器系统、一个核控制工厂、一个为数百万客户服务的银行系统，或者其他一些对生命/财务至关重要的系统，你会对我们的一些放任态度表示异议。去吧，采取额外的预防措施。
而且这不一定是一个全有或全无的命题。即使你不能完全接受 "真实"，这里也一定会有至少一些想法，你可以从权力者那里溜走。
我们并没有宣称自己发明了这些技术。许多这些概念已经以一种或另一种形式存在了很长时间。如果你读了我们的一些建议，并且它让你想起了你在某某博客上或20年前出版的某本书中读到的东西，不要气急败坏。这绝对是有可能的。这些技术根本不是Basecamp独有的。我们只是告诉你我们是如何工作的，以及什么对我们来说是成功的。
如果我们的语气显得太过知无不言言无不尽，请耐心等待。我们认为，以大胆的笔触提出想法，总比含糊其辞要好。如果这显得自大或傲慢，那就这样吧。我们宁愿挑衅，也不愿用 "看情况 "来冲淡一切。当然，有些时候，这些规则需要被拉伸或打破。而其中一些策略可能并不适用于你的情况。运用你的判断力和想象力。
觉得自己太大，无法 "Get Real"？连微软都在 "动真格"（我们怀疑你是否比他们更大）。
即使你的公司通常是以大团队的长期计划来运行，仍然有办法去实现.第一步是分解成更小的单位。当有太多的人参与时，什么也做不了。你越精简，事情完成得越快--也越好。
当然，这可能需要一些销售技巧。向你的公司宣传 "做实 "过程。向他们展示这本书。向他们展示你可以用更少的时间和更小的团队取得的实际成果。
解释 "真实 "是一种低风险、低投资的测试新概念的方式。看看你是否能从母舰上分出一个较小的项目作为概念验证。展示成果。
或者，如果你真的想胆大妄为，那就隐蔽起来。在雷达下飞行，展示真正的成果。这就是Start.com团队在微软Getting Real时使用的方法。"我看过Start.com团队的工作。他们不要求许可，"微软的技术布道师Robert Scoble说。"他们有一个老板，提供空中掩护。而且他们每次都会咬断一点，做到这一点，并对反馈做出回应。"
在大公司，流程和会议是常态。很多个月的时间都花在规划功能和争论细节上，目的是让每个人都能就什么是对客户 "正确 "的事情达成一致。
这可能是收缩包装软件的正确方法，但对于网络，我们有一个令人难以置信的优势。只管发货吧！让用户来告诉你是否正确。让用户告诉你是否是正确的事情，如果不是，嘿，你可以修复它，如果你想的话，当天就可以把它运到网络上! 没有比客户的话更强烈的了--抵制进行长篇大论的会议和争论的冲动。只要发货并证明一个观点。
说起来比做起来容易得多--这意味着。
几个月的计划是不必要的。 几个月的写规范是没有必要的--规范应该在开发阶段就把基础钉好，把细节想好，并加以完善。不要试图在开发开始前就关闭所有开放的问题，钉好每一个细节。
少发功能，但要发高质量的功能。 你不需要用一个大爆炸的方法，用一个全新的版本和一堆功能。给用户提供他们可以消化的字节大小的片段。
如果有小的bug，在你搞定核心方案后就发货，之后再逐步向网络发货修复bug。越快得到用户反馈越好。想法在纸面上听起来很好，但在实践中却变成了次优。你越早发现一个想法有问题的基本问题越好。
一旦你快速迭代并对客户反馈做出反应，你就会建立起客户联系。记住，目标是通过打造客户想要的东西来赢得客户。
传统的说法，要想打败你的竞争对手，你需要超越他们。如果他们有四个功能，你需要五个（或15个，或25个）。如果他们花费x，你需要花费xx。如果他们有20个，你需要30个。
这种单打独斗的冷战心态是一条死胡同。这是一种昂贵的、防御性的、偏执的产品制造方式。防守型、偏执型的公司不能超前思考，他们只能在后面思考。他们不领先，他们跟随。
如果你想建立一个跟随的公司，你最好现在就放下这本书。
那么该怎么做呢？答案是少做。比你的竞争对手做得更少，才能打败他们。解决简单的问题，把毛躁、困难、讨厌的问题留给别人。与其说是超越，不如说是单打独斗。与其说是超越，不如说是低于。
我们将在本书中涉及少的概念，但对于初学者来说，少意味着。
- 减去特征
- 减去选项/偏好
- 减少人员和公司结构
- 减去会议和抽象的内容
- 减去承诺
构建软件的一个好方法就是从解决自己的问题开始。你将成为目标受众，你将知道什么是重要的，什么是不重要的。这让你在交付突破性产品时有了一个很好的开端。
这里的关键是要明白你并不孤单。如果你有这个问题，很可能有成千上万的人在同一条船上。这就是你的市场。是不是很简单？
Basecamp起源于一个问题：作为一家设计公司，我们需要一种简单的方式来与客户沟通项目。我们一开始是通过客户的外联网来实现，我们会手动更新。但是，每次项目需要更新时，都要手动更改html，这是不可行的。这些项目网站似乎总是变质，最终被放弃。这是令人沮丧的，因为它让我们失去了组织，让客户在黑暗中。
所以我们开始寻找其他选择。然而，我们找到的每一个工具要么是1）不能满足我们的需求，要么是2）臃肿的功能，我们不需要--比如计费，严格的访问控制，图表，图形等。我们知道一定有更好的方法，所以我们决定建立自己的方法。
当你解决了自己的问题，你就创造了一个你所热衷的工具。而激情是关键。激情意味着你会真正使用它，关心它。而这也是让别人也感受到激情的最好方式。
开源世界很早以前就接受了这个口号--他们称之为 "挠自己的痒痒"。对于开源开发者来说，这意味着他们得到了他们想要的工具，以他们想要的方式交付。但好处还远不止于此。
作为一个新应用的设计者或开发者，你每天都要面对数以百计的微观决策：蓝色还是绿色？一个表还是两个表？静态还是动态？中止还是恢复？我们如何做出这些决定？如果是我们认识到重要的事情，我们可能会问。剩下的，我们猜测。而所有的猜测都会在我们的应用中建立起一种债务--一个相互关联的假设网络。
作为一个开发者，我讨厌这样。在我编写的应用程序中，对所有这些小规模定时炸弹的了解，增加了我的压力。开源的开发者，挠着自己的痒痒，就不会受这个罪。因为他们是自己的用户，他们知道90%的决策的正确答案。我想这也是大家在辛苦编码一天后，回家后再进行开源工作的原因之一。这是一种放松
Campaign Monitor的诞生确实是出于需要。多年来，我们一直对电子邮件营销选项的质量感到沮丧。一个工具可以做x和y，但从不做z，下一个工具可以做y和z，但就是不能做好x。我们无法取胜。
我们决定清除我们的日程表，并有一个去建立我们的梦想的电子邮件营销工具。我们有意识地决定不看别人在做什么，而是建立一个能让我们和客户的生活更轻松的东西。
事实证明，我们并不是唯一一个对现有选项不满意的人。我们对软件做了一些修改，使任何设计公司都可以使用，并开始传播这个词。在不到六个月的时间里，数千名设计师使用 Campaign Monitor 为自己和客户发送电子邮件通讯。
-David Greiner，Campaign Monitor 创始人
当你写一本书时，你需要的不仅仅是一个有趣的故事。你需要有讲述这个故事的欲望。你需要以某种方式亲自投入。如果你要和一件事生活两年，三年，你的余生，你需要关心它。
许多初创企业的首要任务是获得投资者的资金。但请记住，如果你向外人寻求资金，你也必须向他们负责。期望值会提高。投资人想要回他们的钱--而且要快。可悲的是，兑现往往开始胜过打造优质产品。
如今，不需要太多的时间就可以开始运作。硬件很便宜，大量优秀的基础设施软件都是开源和免费的。而且激情是不需要价格标签的。
所以，用手头的现金做你能做的事情。认真思考并确定什么是真正必要的，什么是你可以不做的。你可以用三个人而不是十个人做什么？用2万美元而不是10万美元能做什么？你可以在三个月而不是六个月内做什么？如果你保持你的日常工作，并兼职建立你的应用程序，你能做什么？
在有限的资源上运行，你将被迫更早、更强烈地考虑到各种限制。这是件好事。限制因素会推动创新。
制约也迫使你尽早地把你的想法付诸实施，这也是一件好事。出门一两个月后，你应该对自己是否有收获有一个很好的想法。如果你是，你很快就能自我维持，不需要外部资金。如果你的想法是一个柠檬，它的时间回到绘图板。至少你现在就知道，而不是几个月（或几年）后才知道。而且至少你可以轻松地退出。一旦涉及到投资者，退出计划就会变得更加棘手。
如果你创建软件只是为了赚快钱，就会表现出来。事实是快速支付是很不可能的。所以，专注于打造一个你和你的客户可以长期使用的优质工具。
所有问题的根源并不是筹钱本身，而是随之而来的一切问题。人们的期望值简直更高。人们开始拿工资，动机是把它建立起来，然后把它卖掉，或者找到其他方式让最初的投资者把钱赚回来。在第一家公司的情况下，我们只是开始表现得比我们大得多--出于需要......。
我们意识到我们可以用更少的成本提供更好的产品 只需要更多的时间。我们用自己的一点钱打赌，人们会愿意等待质量而不是速度。但公司一直保持（并可能继续保持）小规模运营。而从第一个项目开始，我们就完全自筹资金。只要我们的供应商提供一点创造性的条款，我们就根本不需要真正投入多少自己的钱来运营。而我们的期望也不是为了成长和销售，而是为了成长而成长，并在经济上继续受益。
这里有一个简单的方法，可以在预算内按时推出：让它们固定下来。永远不要在一个问题上投入更多的时间或金钱，只是缩小范围。
有一个神话是这样的：我们可以按时、按预算、按范围发布。这几乎从来没有发生过，而当它发生时，质量往往会受到影响。
如果你不能在分配的时间和预算内装下所有的东西，那么就不要扩大时间和预算。相反，把范围拉回来。总有时间以后再加东西--以后是永恒的，现在是短暂的。
推出一些伟大的东西，范围比计划的小一点，总比推出一些平庸的、充满漏洞的东西要好，因为你不得不打一些神奇的时间、预算和范围窗口。把魔法留给胡迪尼吧。你有真正的业务要经营，有真正的产品要交付。
以下是固定时间和预算，并保持范围灵活的好处。
你必须搞清楚什么才是真正重要的。哪些东西会进入这个初始版本？这就给你施加了一个约束，这会促使你做出艰难的决定，而不是胡思乱想。
设定期望是关键。如果你试图固定时间、预算和范围，你将无法以高水平的质量交付。当然，你也许可以交付一些东西，但 "一些东西 "是你真正想交付的吗？
改变的能力是关键。把所有东西都固定下来，就很难改变。注入范围灵活性将根据你构建产品的真实经验引入选项。灵活性是你的朋友。
我们的建议是 范围缩小 做一半的产品总比做一半的产品要好（稍后再谈）。
有时候，知道你的应用应该是什么的最好方法就是知道它不应该是什么。弄清楚你的应用程序的敌人，你就会照亮你需要去的地方。
当我们决定创建项目管理软件时，我们知道Microsoft Project是房间里的大猩猩。我们没有害怕这只大猩猩，而是把它作为一种动力。我们决定Basecamp将是完全不同的东西，反项目。
我们意识到项目管理不是关于图表、图形、报告和统计，而是关于沟通。它也不是一个项目经理坐在高处广播一个项目计划。而是每个人都要共同承担责任，使项目成功。
我们的敌人是项目管理**者和他们用来破解鞭子的工具。我们想让项目管理**化--让它成为每个人（包括客户）的一部分。当每个人都拥有集体所有权的时候，项目就会变得更好。
当谈到Writeboard时，我们知道有很多竞争者都有很多的功能。所以我们决定强调 "不费力 "的角度。我们创造了一个能让人们简单地分享和协作想法的应用，而不是用非必要的功能拖累他们。如果不是必要的功能，我们就把它删掉。而在推出后的三个月内，就有超过10万个Writeboards被创建。
当我们开始使用Backpack时，我们的敌人是结构和僵化的规则。人们应该能够以自己的方式组织信息--而不是基于一系列预先格式化的屏幕或大量的必填表格字段。
你从拥有一个敌人中得到的一个好处是一个非常清晰的营销信息。人们会被冲突激起。而且他们也会通过将产品与其他产品进行比较来了解产品。有了一个选定的敌人，你就给人们提供了一个他们想听的故事。他们不仅会更好更快地了解你的产品，而且会站在一边。而这也是吸引关注、点燃激情的不二法门。
现在说了这么多，也不要过于迷恋竞争，这一点很重要。过度分析其他产品，你会开始限制你的思维方式。看一看，然后再去实现自己的愿景和自己的想法。
营销人员（以及所有的人）都受过良好的训练，以跟随领导者。自然而然的本能是找出竞争对手的工作方法，然后试图超越它--比靠价格竞争的竞争对手更便宜，或者比靠速度竞争的竞争对手更快。问题是，一旦消费者相信了别人的故事，相信了这个谎言，劝说消费者改换就等于劝说他承认自己错了。而人们讨厌承认自己错了。
相反，你必须讲一个不同的故事，并说服听众，你的故事比他们目前相信的故事更重要。如果你的竞争对手速度更快，你必须更便宜。如果他们卖的是健康的故事，你必须卖的是方便的故事。不仅仅是定位x/y轴那种 "我们更便宜 "的说法，而是一个真正的故事，与已经讲的故事完全不同。
最快让自己陷入困境的方法之一就是看看你的竞争对手在做什么。这对我们BlinkList来说尤其如此。自从我们推出以来，已经有大约10个其他社交书签服务被推出。有些人甚至开始在网上生成电子表格，对功能进行详细的比较。
然而，这可能很快就会让人误入歧途。相反，我们一直专注于大局，不断地问自己，我们要解决的关键问题是什么，如何解决它。
你的应用程序越少是一个繁琐的构建，它就会越好。让它小而可控，这样你才能真正享受这个过程。
如果你的应用不能让你兴奋，那就有问题了。如果你只是为了兑现而工作，就会表现出来。同样，如果你对你的应用充满激情，它将在最终产品中体现出来。人们可以从字里行间读到。
在设计中，意义往往是有争议的主观的，或者是痛苦的不可捉摸的，没有什么东西比激情的存在更明显和清晰。无论产品的设计是让你高兴还是让你冷淡，都是如此；无论哪种情况，都很难不察觉到建造它的人的情感投入。
热情当然很容易表现出来，但冷漠同样不可磨灭。如果你的投入没有包含对手头工作的真正热情，那就会成为一种几乎无法掩饰的空虚，无论它设计得多么精致或吸引人。
美国企业在这一点上其实就是开发一个想法，让它有利可图，在有利可图的时候把它卖掉，然后退出或者多元化发展。这只是关于吸纳一切。我的想法是："享受烘焙，卖你的面包， 享受烘焙的乐趣，卖出你的面包，人们喜欢它，卖出更多。让面包店继续经营下去，因为你做的食物很好吃，人们很开心。
物体越庞大，改变方向所需的能量就越大。这在商业世界和物理世界一样正确。
当涉及到网络技术时，改变必须是容易和便宜的。如果你不能飞快地改变，你就会输给能改变的人。这就是为什么你需要开发更少的质量。
- 长期合同
- 过剩的工作人员
- 永久决定
- 关于其他会议的会议
- 厚实的工艺
- 盘点（身体或精神）
- 硬件、软件、技术锁定
- 专有数据格式
- 过去**未来
- 长期路线图
- 办公室政治
- 及时思考
- 多任务小组成员
- 拥抱制约因素，而不是试图解除这些制约因素。
- 减少软件，减少代码
- 减去特征
- 团队规模小
- 简洁
- 缩减接口
- 开放源码产品
- 开放数据格式
- 一个开放的文化，使其容易承认错误。
ajax这样的新技术，或者标签这样的新概念。谁能更快的适应自己的产品呢？是拥有更多的软件和更多的功能，以及12个月的路线图的团队，还是拥有更少的软件和更少的功能，以及更有机的 "让我们专注于我们现在需要关注的事情 "的团队？
显然，质量较低的公司更有条件适应市场的实际需求。质量较高的公司很可能在质量较低的公司做出转换后很久，仍在讨论变革或通过其官僚程序推动变革。当更大众化的公司还在摸索如何行走的时候，少大众化的公司将领先两步。
灵活、敏捷、少大众化的企业可以迅速改变整个商业模式、产品、功能集和营销信息。他们可以犯错，并迅速修正错误。他们可以改变他们的优先事项、产品组合和重点。而且，最重要的是，他们可以改变自己的想法。
改变是你最好的朋友。做出改变的代价越大，你就越不可能做出改变。而如果你的竞争对手能比你更快地改变，你就会处于巨大的劣势。如果改变的成本太高，你就死定了。
这里是保持精简真正帮助你的地方。瞬间改变的能力是小团队默认拥有的，大团队永远无法拥有的东西。这就是大人物羡慕小人物的地方。在一个庞大的组织中，一个大团队可能需要几周时间才能改变的事情，在一个小型的精益组织中可能只需要一天时间。这种优势是无价的。廉价而快速的变革是小人物的秘密武器。
而且要记住。所有的现金，所有的营销，所有的人在世界上都买不到你从小规模中得到的敏捷性。
当涉及到网络技术时，改变必须是简单而廉价的。如果你不能飞快地改变，你就会输给能改变的人。这就是为什么你需要拍摄更少的质量。
涌现是敏捷性的创始原则之一，也是最接近纯粹魔法的原则。Emergent属性不是设计或内置的，它们只是作为系统其他部分的动态结果发生的。"Emergence "来自17世纪中叶的拉丁语，意思是 "不可预见的发生"。你不能计划它或安排它，但你可以培养一个环境，让它发生并从中受益。
出现的一个典型例子在于鸟类的成群行为。一个计算机模拟可以只使用三个简单的规则（沿着 "不要互相撞到 "的思路），突然间你就会得到非常复杂的行为，因为鸟群在天空中优雅地穿梭，绕过障碍物进行重组，等等。这些高级行为（比如围绕障碍物重新形成相同的形状）都不是由规则指定的，而是从系统的动态中产生的。
简单的规则，如鸟类模拟，会导致复杂的行为。复杂的规则，就像大多数国家的税法一样，会导致愚蠢的行为。
许多常见的软件开发实践有一个不幸的副作用，就是消除了任何出现行为的机会。大多数优化的尝试--非常明确地捆绑一些东西--减少了交互和关系的广度和范围，而这正是涌现的来源。在鸟群的例子中，就像一个精心设计的系统一样，是互动和关系创造了有趣的行为。
我们越是把事情紧缩，就越是没有空间去创造一个有创意的、有涌现性的解决方案。不管是在需求还没有被充分理解之前就将其锁定，还是过早地优化代码，或者在让最终用户使用系统之前就发明了复杂的导航和工作流场景，结果都是一样的：一个过于复杂、愚蠢的系统，而不是一个干净、优雅的系统，它能够驾驭突现。
保持小规模。保持简单。让它发生。
对于你的应用的第一个版本，只从三个人开始。这是一个神奇的数字，它能给你足够的人力，同时又能让你保持精简和敏捷。从一个开发人员、一个设计师和一个扫地员（可以在两个世界之间游走的人）开始。
现在当然，只用几个人就能构建一个应用是个挑战。但如果你有合适的团队，那是值得的。有才华的人不需要无尽的资源。他们在约束下工作的挑战中茁壮成长，并利用他们的创造力来解决问题。你缺乏人力意味着你将被迫在这个过程中更早地处理权衡--这没关系。这将使你更早而不是更晚地弄清你的优先事项。而且你将能够进行沟通，而不必经常担心将人们排除在圈子之外。
如果你不能和三个人一起建立你的版本一，那么你要么需要不同的人，要么需要瘦身你的初始版本。记住，让你的第一个版本保持小而紧凑是可以的。你很快就能看到你的想法是否有翅膀，如果有的话，你就有了一个干净、简单的基础来建立。
尽可能保持团队规模小。梅特卡夫定律，即 "通信系统的价值大约以系统用户数的平方增长"，在项目团队方面，有一个必然的结论。团队的效率大约是团队成员人数的平方的倒数。我开始觉得对于一个1.0的产品发布来说，三个人是最理想的......一开始先减少你计划加入团队的人数，然后再减少一些。
小团队的沟通比大团队更容易流动。如果一个项目中只有你一个人，沟通就很简单。唯一的沟通路径就是你和客户之间的沟通。然而，随着项目人数的增加，沟通路径的数量也会增加。它不是加法增加的，随着人数的增加，它是乘法增加的，与人数的平方成正比。
永远都不够用 没有足够的时间。没有足够的钱。没有足够的人。
这是件好事。
与其对这些限制感到恐惧，不如拥抱它们。让它们引导你。限制因素会推动创新，迫使你集中精力。与其试图消除它们，不如利用它们来发挥你的优势。
当我们在构建Basecamp时，我们有很多限制。我们有
一个设计公司来运行 现有的客户工作 7个小时的时差（David在丹麦做节目，我们其他人在美国）。 一个小团队 无外部资金 我们感到 "不够 "的忧郁。所以我们把盘子放得很小。这样，我们只能把这么多的东西放在上面。我们把大的任务分解成小的部分，一次解决一个。我们按部就班，按轻重缓急来处理。
这迫使我们想出了创造性的解决方案。我们总是通过减少软件的开发来降低我们的变更成本。我们给人们提供了足够的功能，让他们以自己的方式解决自己的问题--然后我们就离开了。我们之间的时差和距离使我们的沟通更有效率。我们没有当面见面，而是几乎完全通过im和电子邮件进行沟通，这迫使我们快速进入正题。
制约往往是变相的优势。忘掉风险投资、长的发布周期和快速招聘。相反，用你所拥有的东西来工作。
被描述为 "爬行的优雅 "的东西，也许更适合描述为 "特征枯萎"，因为就像植物上的真菌一样，它在吸干植物汁液的同时，会逐渐阐述和模糊产品的真实轮廓。当然，特征枯萎的解药是 "紧缩的期限"。这导致功能被抛弃的时间与实现它们所需的时间成正比。通常情况下，最有用的功能需要最长的时间来实现。因此，"枯燥 "和 "最后期限 "的结合，产生了我们所熟知和喜爱的软件，由大量的无用功能组成。
很多小公司都会犯一个错误，那就是试图表现得很大。就好像他们认为自己的规模是一个需要被掩盖的弱点。太可惜了。小公司实际上可以是一个巨大的优势，特别是在沟通方面。
小公司享受更少的手续，更少的官僚主义，更多的自由。小公司在默认情况下更接近客户。这意味着他们可以以更直接和个人的方式与客户沟通。如果你是小公司，你可以使用熟悉的语言而不是行话。你的网站和你的产品可以有一个人类的声音，而不是听起来像一个企业的无人机。小规模意味着你可以与你的客户交谈，而不是向他们低头。
小公司的内部沟通也有优势。你可以摒弃正式的手续。不需要繁琐的流程，也不需要每件事都要多次签字。在这个过程中，每个人都可以开诚布公地说话。这种不受约束的**流动是保持小公司的一大优势。
尽管你可能会认为客户会被你公司员工数量或产品范围的夸大其词所蒙蔽，但聪明的客户，你真正想要的客户，总会了解到真相--无论是通过直觉还是推理。令人尴尬的是，我过去也曾参与过这样的白色谎言，而这些情况都没有带来对企业最重要的东西：与真正需要所提供服务的人建立有意义的、持久的、互利的关系。更好的做法应该是自豪地、不顾一切地如实说明公司的具体规模和广度。
无论你从事什么行业，良好的客户服务一定是任何客户提出的最大要求。从一开始，我们就为我们的客户提供了方便和透明的服务，让他们可以通过任何号码或问题与我们取得联系。在我们的网站上，我们列出了一个免费号码，转发到我们的手机和我们的名片上，我们每个人都列出了我们的手机号码。我们向客户强调，无论遇到什么问题，他们都可以随时与我们联系。我们的客户很欣赏这种信任程度，从来没有人滥用这种服务。
你的应用代表什么？它的真正目的是什么？在你开始设计或编码任何东西之前，你需要知道你的产品的目的 - 愿景。想得远一点。它为什么存在？是什么让它与其他同类产品不同？
这个愿景将指导你的决策，让你在一条一致的道路上前进。每当有一个症结所在，就问："我们是否忠于愿景？"
你的愿景也应该很简短。一句话就应该足以让人明白这个想法。以下是我们每个产品的愿景。
Basecamp 项目管理就是沟通 背包。把生活中的琐事都集中起来 篝火。在IM上的群聊很烂 哒哒清单。跟便签纸竞争 写板。词不达意 例如，对于Basecamp，我们的愿景是 "项目管理就是沟通"。我们强烈地感觉到，项目上的有效沟通会带来集体的所有权、参与、投资和动力。它让每个人都在同一页上朝着一个共同的目标努力。我们知道，如果Basecamp能做到这一点，其他一切都会顺理成章。
这个愿景促使我们尽可能地保持Basecamp的开放和透明。我们没有将沟通限制在公司内部，而是让客户也能访问。我们不再考虑权限问题，而是鼓励所有参与者参与其中。这就是为什么我们跳过图表、图形、表格、报告、统计和电子表格，而专注于信息、评论、待办事项列表和共享文件等沟通重点。先期做出关于愿景的重大决定，你未来所有的小决定都会变得简单很多。
安迪-亨特和我曾经写过一个借记卡交易开关。一个主要的要求是，借记卡的用户不应该将相同的交易申请到他们的账户两次。换句话说，无论可能发生什么样的故障模式，错误都应该在不处理交易的一方，而不是处理重复的交易。
于是，我们在共享白板上用大字写了下来。"有利于用户的错误" Err in favor of users.
它加入了其他六条格言。这些格言共同指导着你在构建复杂的东西时做出的所有棘手的决定。这些法则共同赋予了我们的应用强大的内部一致性和强大的外部一致性。
组织需要指南针。他们需要一个纲要；员工每天醒来时需要知道自己为什么要去工作。这个大纲应该是短小精悍、包罗万象的。你为什么存在？是什么在激励你？我把它称为口头禅--用三四个字来描述你为什么存在。
我们为细节而疯狂。
物体之间的空间 完美的类型引导 完美的颜色 完美的词语 四行代码而不是七行 90%对89% 760px vs 750px 39美元/月VS 49美元/月 成功和满意都在细节中。
然而，成功并不是你在细节中唯一能找到的东西。你还会发现停滞、分歧、会议和延误。这些事情会扼杀士气，降低你成功的机会。
你有多少次发现自己在一个设计或代码元素上卡了一整天？你有多少次意识到你今天取得的进展并不是真正的进展？当你在过程中太早关注细节时，就会发生这种情况。有足够的时间去做一个完美主义者。以后再做就好。
不要在第一周担心你的标题字体的大小。你不需要在第二周钉上那个完美的绿色阴影。你不需要在第三周将 "提交 "按钮向右移动三个像素。只要暂时把东西放在页面上就可以了。然后使用它。确保它能用。以后你可以调整和完善它。
当你使用你正在构建的东西时，细节就会显现出来。你会看到什么需要更多的关注。你会感觉到什么是缺失的。你会知道哪些坑需要铺平，因为你会不断地撞到它们。那就是你需要注意的时候，而不是越早越好。
我在上了一些绘画课之后，才真正克服了 "马上进入细节 "的态度......如果你马上开始画细节，你可以肯定画得会很烂。事实上，你完全没有抓住重点。
你应该先把整个场景的比例画好。然后你要画出场景中最大的物体，直到最小的物体。在这之前，草图必须非常松散。然后，你可以继续进行着色，这包括使体积生动起来。你只用三种色调（浅色、中色、深色）开始。这样你就有了一个色调的素描。然后，对于你画的每一部分，你重新评估三个色调并应用它们。做到体积有了为止（需要多次反复）......
工作从大到小。总是。
如果你需要两年时间才能达到10万用户，你真的需要担心今天的规模吗？
如果你今天只需要三个程序员，你真的需要雇佣八个程序员吗？
如果你能用两台服务器运行一年，你现在真的需要12台顶级服务器吗？
人们往往在前期花费太多时间，试图解决他们还没有的问题。不要。哼，我们推出Basecamp的时候，还没有给客户计费的能力呢! 由于产品以月度为周期进行计费，我们知道我们有30天的空档期来解决这个问题。我们利用这段时间来解决更多的紧急问题，然后，在推出后，我们解决了计费问题。结果很好（它迫使我们采用了一个简单的解决方案，没有不必要的钟声和口哨声）。
在你真正必须要做的事情之前，不要出汗。不要过度建设。必要时增加硬件和系统软件。如果你慢了一两个星期，这不是世界末日。只是要诚实：向你的客户解释你正在经历一些成长的痛苦。他们可能不会很激动，但他们会感激你的坦诚。
底线。当你能获得所需的真实信息时，及时做出决定。同时，你将能够把注意力放在需要立即处理的事情上。
已经翻译到第四节 https://basecamp.com/gettingreal/04.4-hire-the-right-customers