Getting Real 是一种更小规模，更快速，更高质量的软件构建方法。
Getting Real的优点
Getting Real能够交付更好的结果，是因为它强迫你处理真正要解决的问题，而不是关于那些问题的空想。它迫使你面对当下。
Getting Real更注重实际的用户界面，而不是功能规格说明书和其他昙花一现的文档。只有当一个真实的网页呈现出来，相关的功能规格才是可信的，被证明是可接受的。那才是是我们的客户将要看到和使用的。那才是需要关心的。Getting Real帮助你更快达到这个目的。并且那意味着你正在基于真实需求，而不是异想天开来构建软件。
这本书将带给你...
信仰之重要
为什么小是好事情
怎样构建更少
怎样从现实世界中快速找到创意
怎样培养团队
为何要由内到外的设计
为什么写作至关重要
为什么要比对手少做
如何升级你的应用和散播文字
成功维护的秘诀
发布后能够持续保持后劲的秘诀
找自己募资
外部资金只是第二条路(plan B)
资源拮据往往能激发想象力
固定时间和预算，但灵活控制产品外延
以下是一些固定时间和预算，灵活控制产品外延的好处:
要有优先级
你一定要搞明白什么才是最重要的。什么是首发的产品中必须要具备的特性功能？这个限制思维逼迫你下一些痛苦但必要的决定，而不是挑挑拣拣的拿不定主意。
要现实些
设定期望值是关键。如果你同时要固定死时间，预算和产品的外延，你将不能推出高层次的产品。当然你可能推出个东西，但那个“东西”会是你真正想做的吗？
要有灵活性
及时应变的能力很重要。如果什么都固定死就很难应变。给产品的外延注入机动性，当真正做起来就有比较多的选择空间。机动灵活是你的良师益友。
我们建议：范围缩小些。做半个产品比做半拉子的产品好（后面将进一步论述这点）
通过减少改变的阻碍保持灵活
用三人小组构建1.0版本
对于产品的1.0版本，请从只有三个人开始。三是一个魔力数字，提供足够人力的同时允许你保持流畅和敏捷。从一个开发者，一个设计者，和一个清道夫（一个可以在开发和设计中随意切换的人）开始。
让限制带领你到创新的解决方法
通过亲切友善和人性化来把自己和大公司区分开来
在初期时忽略细节
先粗后细
我们太过痴迷于细节。
当问题成为问题的时候才去担心
不要把时间浪费在还未成为问题的问题
找到你产品的核心市场然后就专注进去
顾客并不总是对的。
软件要有自己的主张
你的软件应该要有倾向
一个著名的例子就是wiki的最初设计过程。Ward Cunningham和他的朋友们有意把传统上认为协作文章不可或缺的许多功能都舍弃不用。他们不把每次文章的修改归功于特定哪个人，而把所有权标识都去除了。这么一来，内容就不再自我，而成为永恒。因为他们相信重要的不是谁或什么时候写的文章。这个理念改变了一切。这个决定孕育了一个以共享己任的社区，成为Wikipedia（维基百科）日后的主旋律。
构建一半产品，而非产品有一半缺陷
只留精髓
不轻易实现功能
对于每一个新功能你需要……
1. 对它说不
2. 强迫它证明自己的价值
3. 如果得到否定的答案，就此打住。如果是yes，继续往下……
4. 为界面绘制草图
5. 设计界面
6. 编写代码
7-15. 测试，改进，测试，改进，测试，改进，测试，改进……
16. 检查帮助文字是否需要修改
17. 更新产品预览流程（如果有必要的话）
18. 更新用于销售的拷贝（如果有必要的话）
19. 更新服务条款（如果有必要的话）
20. 检查是否违背之前的任何许诺
21. 检查价格体系是否受影响
22. 上线
23. 深吸一口气
你能把握住它么?
构建你有把握的
一场把软件运作起来的比赛
尽快地推出一个真实的产品
从概念到实施
从灵感，到草稿，到HTML，到代码
放飞去让大众测试
在现实使用中测试你的软件
独处的时间
为了让事情做好，人们需要不被打扰的时间
不需过早招聘太多员工
慢慢加人迅速发展
行胜于言
根据对开源社区的贡献选择潜在的技术人才
寻找全面发展的人
选择能快速学习的多面手，而不是专攻一面的专家。
热情是装不出来的
选择快乐的和技术水平中等的，而不是令人不满的专家
炼字师
招文字功底好的人
界面先行
开始编程之前先设计界面
震中设计
始于页面的核心然后向外延展
出错时的设计
功能定义一点用都没有
不要写功能定义文档
这些蓝图文档通常和成品几乎毫无关系。
免费赠送
让注册和注销的过程毫不费力
规避长期合同和注册费用等
跟著潮流走
對於新的方向保持開放的態度
執行力
不只是軟體
在這裡提醒您，Getting Real 的概念不只是適用於建立網路應用程式。當您開始了解裡面蘊含的點子，到處都可以發現他們的蹤跡。