1. 之前在新浪的微博上看到有人提到Getting Real这本书，于是就从网上找到了这边书。看完之后感觉书中的一些思想值得我们在做产品的过程中借鉴，所以今天就给大家做一个简短的分享。
2. 《Getiing Real》是一本由37signals出品的一本书，在这本书中它介绍了一种更小规模，更快速，更高质量的软件构建方法，可以帮助你构件一个成功的Web应用。而这个方法也是他们自成立之初至今在不断实践的一个方法并且获得了成功，甚至包括微软的一个研发团队也在暗中实践这种方式。
3. Getting Real这个方法的精髓就是少做。常规的思维方式告诉我们，不管竞争对手做什么我们总是要比他们加多一些。比如说他们有4个特殊功能，我们就需要做出5个来。而按照Getting Real的思想，我们需要通过少做，也就是做的比竞争对少更少来战胜对手。“少做”的含义是更少的功能，更少的选择项和首选项，更少的配备人员和企业架构，更少的会议和抽象讨论，更少的承诺。下面分享的书中的一些理念都是围绕“少做”这个主题。
4. 有的时候我们太过于痴迷于细节，比如说选用哪个字体，用多大号的字体，两个元素之间留多少空白，输入框的宽度是120px还是180px。固然成功和满意来自细节，但是细节中并不只有成功。细节中你还会遇到停滞不前，意见不合，无数的会议和延迟。这些东西都会降低你成功的几率。有时候我们会常常一整天纠结于这些小细节间，觉得自己今天的进展实在算不上什么真正进展。过早专注于细节就会导致这些结果。细节是在你使用的过程中才会显露出来的。只有在使用中你才能看到什么需要进一步关注。
5. 不要把时间浪费在还未成为问题的问题。当一个新产品上线之前，你真的需要考虑当用户到达10万以上的时候会出现的问题吗？它可能已经是两年以后的事了，也可能永远不会出现。人们总是预先花很多时间在还不知道会不会发生的问题上。当作者的公司推出第一款产品的时候还不知道如何向客户收费！因为产品是月付费的，他们知道还有30天的时间来搞定付费方式。他们把预先省下的时间用在解决更紧急的问题，直到产品推出后，他们才着手付费问题。结果很顺利（它迫使他们用最简单的解决方案，没什么花哨的东西）。所有我们没有必要整天操心还没成型的麻烦。也用不着去过度开发一个产品。
6. 专注于用户真正需要的东西，而不是搞一个庞然大物出来。摆出产品应该成为什么样的任何点子，然后砍掉一半。减少功能直到只剩下 最必要的功能。周而复始。先发布用户最需要的功能，这让我们基于真实的使用情况来决定下一步怎么走，而不是凭空猜测。从一个精简，聪明的应用开始，然后让它得到关注。就能开始在你构建的坚实基础上添砖加瓦。
7. 我们的客户或者用户总会有很多的问题，比如说“为什么你们做这个而不做那个？”，“为什么你们不增加这个功能？”。对于这一类的问题，作者的回答基本都是五个字“无所谓”。比如“为什么只有每五分钟才有时间戳？为什么不是每一行聊天都有？ ”回答：无所谓。因为作者认为任何更多的细节对于用户而言都被重要，95%的情况下，每五分钟增加一个时间戳就可以了，完全没有必要每秒或者每分钟记录谈话内容。我们的大部分时间可能都会浪费在无关紧要的东西上。如果我们能抛弃不重要的工作和思考，将会获得不可思议的生产力。
8. 每一次你对一个功能说yes时，你正在收养一个小孩。你必须带着你的孩子通过一连串事件（例如设计，实现，测试等）。一旦这个功能出现了，你就被拖住了后腿。尽量为客户少发布一个功能，再看客户是否愤怒地离开。不要成为 yes-man，不要轻易实现每个功能。而要让每个功能证明自己，并且表明自己是幸存者。在作者的公司，每一个向他们提出的功能或者他们自己提出的新功能需求都遇到一个 NO 。他们倾听但是不采取行动。最初的回应是“不是现在”，如果一个需求或者功能不停的过来，他们才对它进一步观察。然后，只在那时，他们才开始考虑实现这个功能。
9. 抓住核心功能，我们应该去问用户不想要什么，而不是用户想要什么。大多数的软件调查和研究都是围绕人们想要的产品 。“你认为有还缺失什么特征？” ， “如果你可以加入一个功能,那会是多少?” ， “如何使这个产品对你更有用” ?硬币的另一面会是怎么样呢? 为什么不问人们，不想要什么? “如果你可以去掉其中一个功能,那会是哪个呢? ” ，“你为啥不用? ” ， “什么让你觉得最碍事？” 。砍掉那些用户普遍觉得没有必要的功能，会使你的产品更受欢迎。
10. 做少一些功能，跳过一些细节，如果一些捷径能加快产品进度就大胆用，这些都是OK的。当你做下去的时候，你会对下一步的方向有更准确的把握。只有一个真实的，可操作的产品才能拉近每个人对现实的理解和认同。避免了为一些草图和段落争得面红耳赤，最终发现这些都是无谓的。同时，你也会发现有些你想像中无关痛痒的事情事实上是很重要的。
11. 缩短你的时间范围，把一个时间段分成一个个小块。因为做几周甚至几个月的预期是不现实的。事实上你无法预见那么远的将来会发生什么状况。一个12周项目看成是12个周项目。与其去推演一个要花30个工作小时的任务，不如把它们分成更现实的6-10个小时的小任务。然后一块一块地去执行。这个理论同样适用与其它问题。你是否有碰到一个很大的问题想都想不过来？把它划分开来想。就这么一直把问题分成小块及更小块直到你能消化它为止。
12. 在我们设计某个具体页面的时候我们需要考虑三种情况下的解决方案，常规、初始和错误。常规，就是一切运行正常的话，人们看到的是一个充满内容的界面。初始是指人们第一次使用这个应用，在加入内容前的界面。错误指的是有错误发生时，人们看到的界面。常规的情况众人皆知，它将花去你最多的时间。但别忘了也要为初始和错误两种情况花些时间。
13. 统一界面，就是合并管理功能到公共界面。管理界面—就是那些用来管理选项，人员等的屏幕界面。—看起来很低劣。这是因为大多数时间都花在了对公共界面的设计上。为了避免这种低劣管理界面的并发症， 不要分开去开发系统管理界面。 而要把管理功能（例如，编辑，增加，删除）嵌入到应用界面开发中。如果你必须维护2套分开的界面（如： 一个一般用户用，另一个管理员用）， 这2个都会很难受。 实际情况就像同一个税你交了2次。 你强迫自己重复 并且 这还意味着事情变麻烦的机会大大增加。
14. 使用内嵌的帮助和常见疑难解答，产品就不需要手册或使用培训。你不需要一个手册去使用Yahoo 或者 Google ， Amazon。 你的应用越不复杂，你就越能免除帮助人们摆脱困境的麻烦。还有一个不错的事前支持途径是在潜在的、容易引起疑惑的地方，使用内嵌的帮助和常见疑难解答。作者在书中举了个实例，他们的一款产品允许用户上传他们的 徽标。 有些人经历过这样一个问题，他们老是看到老的徽标，这是浏览器缓存引起的一个问题。因此在“提交你的徽标” 旁边的一个区域，他们增加了一个链接指向 这个常见疑难解答，来教客户强行刷新浏览器 以便看到新的徽标。在他们这样做之前，他们每天都要接到5个关于此问题的邮件。现在一个也没有了。
15. 独立宣言说“人生而平等”，但所有缺陷并不生而平等。分清缺陷的轻重缓急（甚至可以忽视其中一些）只因为在你的产品中发现一个缺陷（bug） ，并不意味着这时候要引起恐慌。 所有软件都有缺陷—这是一个活生生的事实。你不必每次马上就修补漏洞。 大多数缺陷（bug）是让人烦恼的，但都不是毁灭性的。 那些导致“看起来不太对”的错误、或其他小错误搁置一会儿。 如果一个缺陷（bug）影响到了数据库，这时，显然需要修补。分清缺陷的轻重缓急。 有多少人受到影响？ 问题坏到什么程度？ 这个缺陷bug值得立即重视吗或可以等待？ 你现在做什么将对绝大多数人产生最大影响？ 很多时候，加入新的功能，甚至比更改现有缺陷更为重要。
16. 以上就是我所要分享的内容。这本书可以从以下两个网站找到。如何大家对今天分享的内容有自己的想法的话欢迎交流想法。
下载Getting Real 分享PPT和讲稿