《Getting Real》书摘

比竞争对手做得少，做得多是冷战思维。

更少的功能

更少的选择项

更少的会议

更少的人员

更少的承诺

产品应该首先来自于解决自己遇到的问题，这样你才能有激情和想法完成。

在自己的能力范围内设计，完成产品，更少的资金意味着缩小规模，减少功能。

弄清楚产品要做成什么样，有时候最好是搞清楚不要做成什么样。那么就可以找个敌人来做比较。 以三个人完成1.0版本，人少可以使你认识到工作重点，交流成本也低。

约束，不充足是经过伪装的优势，它驱动创新，强迫集中精力，关注真正重要的事情。
要拥抱约束。

小公司有其“小”的优势，相对于大公司，它少了形式主义，官僚主义，它可以更真实和人性化的和客户面对面交流。小公司内部也可以真诚的交流。

一定要想清楚你的软件的理念是什么，和其他产品的区别是什么，把理想尽可能放远一点。

在设计，开发初期不要纠结于细节，从大到小，从整体到细节。有些细节问题一定是在你使用产品的过程中发现的，所以，先把产品做出来，可以使用，然后再改进细节。

不要浪费精力在还没有出现的问题上，利用你手头上已知的信息，尽快做决定，解决当前的问题。

你的产品只能针对某一类用户，只解决这部分用户的问题。专注。

对于产品支持规模的问题，不需要太担心，先把产品做出来再说，不要搞预先优化。
软件是有倾向的，只为志同道合的人提供服务，你不可能取悦得了所有人。

问用户哪个功能是你不需要的，创新来自于说“不”，集中精力干真正重要的事情。

尽快把软件做出来，只有可运行的软件能在此之上进行改进，也容易让各方达成一致。

我的思考：这种方式和所谓的“第一次把事情做对”有相冲突之处，“第一次”会导致更多的讨论，计划，不敢开始，害怕犯错，因为一次就把事情做对就意味着没有错误发生。我们应该看一下提出“第一次”理论的背景，也许这种context根本不适用于软件开发，不适用于迭代开发，不适用于web开发。“第一次做对”应该有几个前提，第一要做的事情很明确，即需求很明确（质量就是符合要求，这个要求一定很明确），这在软件开发时不一定成立，用户没见到的东西他们自己也不知道应该长什么样。第二，这件事情应该是个不太具有创造性的工作，例如流水线上的某到工序。创造性的工作是需要试错的，不断尝试，也意味着不断失败。

鼓励程序员的相反的意见，为了实现简单，更少的代码，可以引导客户需求。
选择语言，框架，工具时，除了使用性以外，可以考虑程序员的激情和快乐。
   

对于web开发，功能文档的用处不大了，有用的是原型或者HTML页面。这里的前提是基于页面的web开发，以及功能本身较小，涉及的人员较少。

我的思考：对于大型通信软件可能不适用。

对于表单测试，一定要使用真实数据，不能胡乱键入数据，'这样才能体会用户的感觉，才能改进表单设计。