什么是 Getting Real?
Getting Real 是一种更小规模，更快速，更高质量的软件构建方法。
Getting Real是关于省略所有表达现实（图表，曲线，矩形，箭头，统计图），而构建现实。
Getting real 是追求精炼。更少的代码量，更少的软件，更少的功能，更少的文档工作，更少无所谓的东西（而且大部分你认为必要的，其实不是）。
Getting Real 是保持精益，变得敏捷。
Getting Real从界面开始，也就是用户使用的屏幕。它从实际的用户体验开始，并且构建似曾相识的体验。这让你在软件误入歧途之前得到正确的用户界面。
Getting Real 是关于迭代和降低变化成本的方法。Getting Real基本上是关于上线，调整，持续改进，其目标的开发Web软件的最佳途径。
Getting Real只交付客户所需的，摒弃任何客户不需要的。
Getting Real 的优点：
更好的交付结果
更注重用户体验
-----------------内容-----------------
建构从简
和竞争对手形成差异性，从解决简单的问题入手，提供更少的功能，更少的选择和更少的承诺。
自筹资金
尽量用自有资金开启项目，项目开启以后，最好有自我造血能力。外部融资永远是第二选择，不要为了融资而融资。
很多伟大的产品都是在有限的资金里创造的。拮据的资金能够激发创造力，迫使自己想出更好的创意。
控制时间和预算
产品计划一定要定额定量：要么缩小规模，要么缩小范围。
在具体执行过程中遵循：优先级，现实性和灵活性。
锁定对手
确定自己的产品不应该成为什么样子，有时和对手的产品反其道而行之是一个不错的主意。
借助于对手的营销理念，灌输用户对立信息，可以吸引用户接受新观点。
不要跟随领头羊，找出差异化，用自己的优势去打击对手的弱势。
对产品倾注感情
不能把产品简单当作一门生意，要注入自己的感情。一个有感情的产品才能激发用户的渴望。
精益求精
必须保证产品的迭代是迅速、简易和低廉的。
设计产品时要保持小，顺其自然，通过减少改变的成本来保持灵活。
三个火枪手
初始团队三个人就足够了：一个开发，一个设计，一个两者兼顾。
拥抱约束
人生不如意，十有八九。不要抵触，不要抱怨，接受这些约束，让约束来指导你。
伟大的理念
通过亲切友善和人性化把自己和大公司区别开来。给自己制定一个简洁的理念，随时自我监督。
忽略细节
先粗后细。不要一开始就考虑细节，那样只会让你停滞不前。从大局出发，然后慢慢细化。
不要急着未雨绸缪
永远不要考虑那些还没有出现的问题，当一个问题出现的时候，必然就会有解决的方法。
找准自己的用户
细分市场，不要一上来就考虑所有的用户，最开始的用户要足够精准。一旦确定，就全身心的投入。
规模是以后才要考虑的
先把一个伟大的产品推出，然后才去担心它无比成功了以后该怎么办的问题。
产品要有倾向性
伟大的产品必须要有自己的理想。伟大的产品必定是有倾向的。
构建一半产品，而非半成品
专注于真正必须的。列出产品应该成为什么样的任何点子，然后砍掉一半。减少功能直到只剩下最必要的功能。周而复始。
只留精髓
抛弃不重要的工作和思考，你将会获得不可思议的生产力。
学会说不
不轻易实现功能
不要有求必应
只做有把握的
构建你能够掌握的产品和服务。许诺容易遵守难。确保你所作所为是在承担范围内— 从组织，战略和财政上
忘记功能需求
看完功能需求后就扔掉。让用户来提醒你什么是真正重要的。
抓住核心，多问问用户不想要什么。
和时间赛跑
尽快推出真实的产品，真实的产品导致真实的行动。这才是你走向真理之路。
一定要快。决定一个产品是否去做，如果是，尽快去做，然后上线，看用户的反应。
不断反复
不要指望产品一出世就完美。任何一款伟大的产品都是成长的过程中不断蜕变的。
从概念到实施
灵感 -> 纸上草稿 -> 创建HTML页面 -> 编码
替用户决定
不到万不得已，不要让用户做出选择。
决定好了就放手去做
任何创意如果没有执行就一文不值，只有执行才是价值万金。
让用户测试
让真人在真实的环境中使用你的软件，这是无可代替的。取得真实的数据。取得真实的反馈。然后在那些信息的基础上进行改进。
缩短时间
把时间分成小块，然后建立小的任务和时间表。
步调一致
不要尝试建立多个部门，尽可能整合团队。最好的情况是找到有多项天赋的人，在开发过程中担负不同角色。最终的结果是一个更加协调的产品。
独处
深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法发生的地方。
让团队尽量独处，不被打扰，保持全神贯注，进入最佳状态。
会议有毒
不要会议。用任何即时沟通的工具来保证信息沟通，不到万不得已，不要开会。即使开会，也要尽量让会议简短，参会人员尽量精简。
不断激励
可以尝试每天都发布一些新功能，让这些新功能来鼓舞士气，激励团队。
招聘要精打细算
不要随便招人。当招一个人时，只要有条件，应该让候选人和团队磨合一下。
行胜于言
典型的通过学历、简历等方式来招聘技术人员在很多方面都是很愚蠢的。你需要采取不同的方式。开源社区是一个很好的了解程序员的方式。
寻找多面手
选择能快速学习的多面手，而不是专攻一面的专家。
选择快乐的和技术水平中等的，而不是令人不满的专家。
如果你在琢磨从几个人选中挑出哪一个来填补空缺，选文字功底好的那位。无论他是设计师、程序员、市场人员、销售人员还是其他，写作技巧都很有用。
界面先行
先做界面。界面设计相对来说是比较轻量级，而且对用户来说，界面才是你的产品。
震中设计
震中设计就是关注于页面的本质——震中，然后再向外拓展。一开始要忽略细枝末节的东西，从震中着手，先设计页面中最重要的内容。
考虑三种情况
考虑常规、初始、错误三种情况下的设计。
初始界面一定要提供周到的初次运行体验。一个有用的初始页面应该包括：
添加新手指南和热门推荐
让人们有所期待
讲解如何上手
回答关键问题
做好预期准备
出错时要做好保护型设计。
应用环境胜过一致性
这里有意义的那里不一定有意义。如果你的设计在那种状况下有意义，不一致也没有什么大不了的。 只给人们重要的。 给他们所需的，并且去掉其不需要的。比保持一致性更好的是保持正确。
拷贝书写是页面设计
每个字都很重要。
伟大的界面是写出来的 。
好的书写就是好的设计。
更精简的产品
代码尽量简化。每当你增加代码量，软件的复杂程度就成指数化的上升。
简化的产品便于管理
简化的产品意味着简化的代码库
更少的复杂维护
降低变化成本
较少错误
较少的支持
鼓励程序员的相反提议。
为了快乐而优化
选择使团队兴奋和倍感激励的工具。快乐的程序员是高产的程序员。
代码说话
废话少说，放码过来。倾听你的代码。它会提建议。它要推动你。它将告诉你缺陷在哪里。它将建议做事的新途径。它将帮助你坚持精简代码的模式。
管理欠债
初期欠下的技术债务，要做到心中有数，该还就还。
开放
通过RSS、API引入数据，扩展应用程序的能力。
别写死文档
不要写功能定义文档
根除不必要的文档工作
写故事，别写细节
使用平实的语言
个性化产品
好的产品都是有个性的。
体验
通过免费赠品、样品来吸引用户的关注。
注册和注销应该尽可能简单。
规避长期合同和注册费用等，用提前通知和保留条款来缓和坏消息给用户带来的打击。
好莱坞运作
挑逗 -> 预演 -> 上线
找到一个强大的推广站点，发布以下内容：
概览
导游
屏幕截图和录像
宣言
案例研究
共鸣
论坛
费用注册
博客、微博、微信公众号
驾驭网络推广，网络推广比广告更有效，而且更便宜。
通过教育推广
与世界分享知识。当你教的主题是你的应用时 ，这具有双重目的:你能回馈社区，这不仅支持了你，还可以在同一时间 为你的那些漂亮的宣传曝光取得加分。
要有特色
新的或有趣的特性是一为你的应用引起共鸣的很好的办法。
跟踪用户反馈
研究用户反馈并跟踪。无论评价是否正面，都要认真回复，让用户感知你的存在。
内线+促销
现存用户是你最佳销售对象。勇敢向这些已经熟知并已使用你的产品的用户进行重复销售时。
名字的魔力
一个好的名字胜过任何高明的营销。
感知痛苦
拆除部门团队之间的墙壁。不要把客户支持外包给呼叫中心 或 第三方。你自己做。
零培训
使用内嵌的帮助和常见疑难解答，产品就不需要手册或使用培训。任何需要培训手册的产品都是设计不极致的。
快速回答
在疑难问题上的快速响应时间应该置于最高优先级。
勇于说不
至于特性需求，用户并不总是正确。如果我们把用户需求的每个零零碎碎都加入产品中，没有人会要我们的产品。
公开错误
如果某事出错就告诉人们。 即使他们开始并未曾发现。
关于发布消息的旁注，好和坏: 当坏消息来时，立即把全部公开。另一方面 ，应该慢慢地一点一滴地透露好消息，如果您能延长好的信息起到的效果，那么一定要这样作。
一个月调整期
上线 30 天后发布一个重大更新。快速迭代显示你的实力，也显示更多后手。
保持发文
上线后保持网络推文的发布，显示你的产品充满活力。内容可以包括：
FAQ疑难解答
如何操作
小贴士、技巧
新功能、更新、补丁
共鸣、新闻
更好的版本
不要用"测试版"作替罪羊。对你发布的东西要负责。把它推出并称其为发布版。否则，你只是在找借口而已。
正视缺陷
分清缺陷的轻重缓急，必要时可以带着 bug 上线。
同时，要创造一种别害怕周围缺陷 bug 的文化。 缺陷发生，别总是找人去责怪。 你最不需要的就是这样一个环境，缺陷被私下解决，而不是通过公开讨论。
安度风暴
危机出现时，要抵制恐慌情绪，和拒绝作出迅速改变的反应。
保持领先
关注竞争对手。
更成熟并不意味着更复杂。