此书是管理者、程序员或设计师必学的宝典。它以更小的规模，更快的速度，更高的质量来完成软件开发，使产品更简单、粗暴（精致）。
近百条精炼总结，不要奢望一次全部记住或理解，只要能理解或做到其中几条对你的收获都是巨大的。37 signals真是一个让人非常尊敬和佩服的团队。感谢它们提供给我们这么实用的经验（里面有很多敏捷开发的精髓）。非常推荐与开发有关的同志阅读它。
Getting Real 除掉...
花费数月，甚至数年的进度表
不切实际的功能规格文档
可伸缩性的争论
又臭又长的员工大会
大量招人的需求
毫无意义的版本号
憧憬完美未来的幼稚“路线图”
无穷尽的偏好设置选项
外包支持
不切实际的用户测试
写无用文档
自顶向下的管理结构（金字塔管理）
这本书将带给你...
信仰之重要
为什么小是好事情
怎样构建更少
怎样从现实世界中快速找到创意
怎样培养团队
为何要由内到外的设计
为什么写作至关重要
为什么要比对手少做
如何升级你的应用和散播文字
成功维护的秘诀
发布后能够持续保持后劲的秘诀
其他...
构建从简：做的比竞争对手更少更准确
更少的功能
更少的选择和首选项
更少的配备人员和企业架构
更少的会议和抽象讨论
更少的承诺
是什么问题一直困扰着你：
为自己而做这个软件，先解决自己的问题。
一切源于必要性
你必须在乎他
找自己募资
外部资金仅是第二条路，找别人投资你就会听别人的，而且收回资金的希望远远高于优质产品的开发速度。手里有多少钱就启动多少钱的项目。
资源拮据往往会激发想像力。有压力是好事，他往往会激发创新。
固定时间和预算，但要灵活的控制产品的外延
准时得在预算内推出。
推出只有必要功能，总比漏洞百出得大软件要强。
一天，两天，三天。。。就是这么一天一天拖成一年半年得。
找个敌人，挑选一场战斗
通过学习敌人战胜敌人就是对用户最好得宣传，让用户有对比得去选择产品
不要过于模仿敌人，要有自己得亮点。
问题得关键是什么，不要老看竞争对手，明确什么才是我们最应该解决得关键性问题。
他不应该成为一种交易
如果你对开发得软件一点也不兴奋，或无激情，那么肯定是哪里出了问题。因为在最终产品里会体现出你全部的努力。如果你仅仅是想赚点钱那肯定会影响你最终的产品。
更小的质量
你做的越精越容易改变
减少改变成本
小团队的灵活与敏捷，是大团队永远比不了的。
顺其自然，不要把系统写的过于复杂，有很多操作是用户顺其自然就做得。
三个火枪手
用三个人组建1?0版本，保持你得软件小而紧凑是没有问题，有一个清洁的基础架构是非常重要。
团队的工作效率、沟通效率和人数的平方成反比
拥抱约束
让限制带领你到创新的解决办法。这些限制都是你伪装的优势（没有人、资金、运营等）。攻破他们
做你自己
如果你是小公司就不要去模仿大公司，小的优势巨大，没有官僚，没有复杂的流程，直接面对客户。
骄傲地、无所畏惧地做到真实，你真正的地服务不是欺骗，而是长期、持久地互利互惠地关系。
无论何时何地，客户都能随时找到我们任何人。
什么理念才是伟大的
通过亲切友善的和人性化把自己公司和大公司区分出来
竭尽全力的将你的软件定位到一个点上，你的软件代表着什么，他到底是干什么的，他有前景吗，别人真的喜欢用吗
初期时忽略细节
先粗后细：不要上来就完美主义。
当问题成为问题时候再去担心
不要把时间浪费在还未成为问题的问题。
只解决当前重要紧急的问题。
去找网络对味的顾客
找到你产品的核心市场然后专注进去
如果你想讨好每一个人那么你将谁也讨好不了要清楚你的产品是给谁用的，然后集中精力服务于他们
过后才去做规模调试
要把产品的核心功能作为首选任务，而不是把时间和精力放在永不会发生的预期上。先核心后规模。
软件要有自己的主张
你的软件不是所有人的宠儿，应该有自己的性格，他只会和志同道合的同志成为火伴，要么上车要么下车。
部分而不是残缺不全
从一个精简、聪明的应用开始，让他得到关注，然后你就可以在坚实的基础上添砖加瓦。
无所谓
只留精髓，如果你能对除核心以为的功能都说无所谓，那么你的生产力将翻倍
从说不开始
不轻易实现功能，要对每一个功能负责。
我们不要一千个功能，那样很愚蠢。
创新来自说不：否定一千件事情，以确保我们不误入歧途或做的太多，我们总是考虑进入新的市场，通过说不，让我们集中精力去做那些真正很重要的事情。
隐藏的成本
看清功能的成本，否则会增加你的开发成本。
你能把握住吗
构建你有把握的
底线：构建你能掌握的产品或服务，许诺容易遵守难。
人本主义
把问题的根尽量处理好，然后走开，人们将会在你总的框架内找到自己的解决方案
忘记功能需求
不用刻意记住所有人的需求，重要的功能每个用户都会经常提醒你。你经常听到的功能就是你优先实现的。
抓住核心
问人们你们不需要什么：很多时候都是问用户需要什么，如果能问一些用户不需要什么会更好。
有时候你对用户最大的优惠就是把一些东西去掉
一场把软件运作起来的比赛
尽快能推出一个真实的产品，尽快的运作起来。
冲洗一下再过来
在不断反复中工作着，像软件开发永不变的真理就是change，从零点几开始。。。。尽快的推出。
从概念到实施
从灵感，到草稿，到Html（伪界面或流程界面），到代码。
远离设置首选项
要帮你的客户决定一些小处的细节
你要拿主意，首选项很重要但也会有很大的代价。
搞定
决定都是暂时的，拿定主意就马上到下一步。
作为一个执行者：有个好的点子必须有超强的执行，否则无价值。
那就是我为什么不爱听他人的点子，只有看到它确定被执行下去我才感兴趣。
放飞去让大众测试
在现实中测试你的软件，只有这样才能获取最真实的数据。
有好的点子就要尽快的实现，尽快的保存、上传、发布，即使不完美，也要坐下去，不停的迭代直达客户满意为止，而不是等待其他的竞争对手。
缩短你的时间
把它分块来做，大的叫未来打算，中的叫工作计划，小的叫任务安排。
一致性
拒绝分离，尽量整合你的团队，方便沟通。
独处时间
在不被打扰的情况下，最容易进去最佳工作状态。可以参考番茄工作法很有效果。
会议有毒
减少会议：会议上废话多、傻子多会浪费大家很多时间
会议要求：必须有主题，尽量不开研讨性会议，尽量人少，控制在三十分钟以内。
寻找和庆祝小的胜利
软件开发中最重要的事情就是激励：缩小你的软件发布周期，如果能四个小时发布一次，结果不可想像
不需过早的招聘过多的员工
慢慢加入快速发展：前期和后期都不适合招大量的人员。
摸底
可先从小的地方测试，人员能力、工作方法等
行胜于言
根据对开源社区的贡献挖掘潜在的技术人才
通过工作以外的事情去了解一个人是非常真实的，那就是他喜欢做的。
寻找全面发展的人才
选择能快速学习的多面手，而不是某方面的专家
炼字师
当你不知选择时，就选文字功底好的：清晰的文字能带来清晰的思路，从而反映出一个人的性格，让读者省事而不是方便自己。
界面先行
修改界面要比修改内部程序容易得多，先画出界面或用软件生成都是比较高效的方式，有着清晰的开发思路，逐步完善。
震中设计
先把重要的功能放上去，然后再添加辅助功能。而不是先把框架搭好，先把其他辅助功能都放好，剩下的位置再填充核心的功能。
考虑三种情况下的解决方案
常规：正常使用的界面
初始：第一次使用时的界面
错误：当报错时显示的界面
初始界面
期待一个周到的初次运行的体验：用户第一次使用非常重要，它将决定用户是否使用此产品，所以要避免空数据等，可加入新手指南或截屏等
做好防御
即使程序90%运行良好，也会让用户感到不适，做好报错机制。
精简的软件
使代码更少，没有什么代码比没有代码更灵活。
很多时候我们的竞争力是比对手做的更少。
管理欠债
把一些不好的代码删掉，可能会比你经常维护的成本低很多，学会取舍。
功能定义一点用都没有
用最简短的语言去描述这个应用是干什么的，而不是长篇大论的把所有功能都写出来，使程序非常臃肿
通过简单的界面代替功能文档，可以最直接的去感受这个应用
别写死文档
根除不必要的文档工作
真正的使用者和维护者都不会去看那像一本小说的产品规格书和业务需求文档。因为它并不能解决任何问题。
个性化你的产品
每个产品都有自己的特征和个性，做任何改变都要保持这些特性。
免费样品
免费赠送会让用户对你有更多关注，拿出你一部分好的产品去与大家分享。
来去自由
在用户注册和注销时一定要简单，不要过于复杂吓走用户，更不要勉强留住用户，永远保持尊重用户
好莱坞的运作
挑逗：提前发出消息，让更多的人关注，并收集大家的意见等
预演：发给少数人做内部测试，享受特殊荣耀来做你的beta版测试人员
发布：大面积的发布你的应用，让更多的人知道它使用它。
强大的推广网站
概览：说明你的应用与益处
导游：引导用户体验各种特征
截屏与录像：
宣言：阐述其背后的哲学与思想
案例
共鸣
论坛
费用与注册
博客：实时更新最新咨询与技巧
驾驶博客波浪
博客可以比广告更具有效力，而且便宜。
通过教育推广
与世界分享知识：教育总是件好事，你先付出，你会帮到很多人，也会得到很好的营销效果。
学会分享，你会得到更多
特色食品
加入一些新的技术，会有更多人的关注，执行或改革都比大公司快。所以可以多一些特色，勇于创新
跟踪你的日志
关注对产品好的评价和坏的评价，并正面引导，逐步驱除坏的影响。
名字的魅力
给应用起个好记得的名字
感知痛苦
拆除研发和技术支持中间的墙壁：让研发人员自己去做技术支持，能更好的感受用户的需求和抱怨。
零培训
使用内嵌的帮助和常见疑难解答，不需要手册或用户培训。
支持在线问题解答，控制在一个小时之内。
混合部队
如何用最少的人开发最好的产品，就是组合混合队伍。
强硬的爱
不是每个用户的需求都是有用的或是有必要的，要保持产品的特色然后满足大部分用户即可。
公开你的错误
不要对错误做遮掩，真诚的对待用户，没人会不理解。承认错误是主动防御，而不会被动狡辩。
好的消息要慢慢的渗透。
一个月调整期
上线30天之后发布一个重大更新，这样更能通过应用的热度。
保持发帖量
上线后维护一个持续产品开发博客，保持产品的活力
FAQ疑难问题解答、how-tos、小贴士和技巧、新功能和补丁、共鸣和新闻。
还活着：保持长时间更新
更好，而不是测试版
不要用测试版做替罪羊：要对发布所有的版本负责，不要拿测试版作为出错的借口。
所有缺陷并不生而平等
当有bug出现时，不要马上就去修复，先的严重性，再考虑它是否值得现在马上就修复，是否对其他用户有影响等。
安渡风暴
有些时候要求是没有约束的，经常改变不固定，需要等到应激反映过后或表面的激情过后，再重新考虑需求。
保持先进性
订阅你的竞争对手新闻消息，不断的掌握竞争对手的最新信息，知己知彼。
小心那个臃肿的怪物
更成熟并不意味着更复杂：持续更新并非都是增加功能，明确你的产品定位，避免愚昧的增加。
Getting Real 开发宝典,布布扣,bubuko.com
原文地址：http://www.cnblogs.com/basetd/p/3760559.html
