读书课：Getting Real——反常识的做产品宣言

37signals（Basecamp 的缔造者）在 2006 年公开了这本《Getting Real》，全文免费在线。它是一份反常识宣言：别写需求文档、别做完整规划、别等完美、先上线再改。二十年后回头看，它几乎预写了今天所有独立开发者的操作手册。这篇把书里最经得起时间检验的做法挑出来讲。

核心立场：做的产品越少，越好

全书第一原则是"做一半的产品，而不是半成品"。半成品是缺功能的大产品，一半的产品是只解决核心问题的完整小产品。判断标准：砍掉一个功能后，产品还成立吗？成立就砍。功能意味着维护、解释、教程、客服——每加一个功能，你欠的债就多一笔。独立开发者的死法大多不是"做得太少"，是"做得太多"。

关于计划：计划是猜测

书里对计划的态度很直白：计划只是猜测，写在纸上的计划越详细，错得越自信。正确姿势是只规划"本周必须决定的事"，远期的问题等临近了再决定——那时你手里的信息比现在多得多。别把"我们有个路线图"当成安全感，真正的安全感来自每周都在上线真实的改进。

关于流程：先做界面，别先写代码

这条对程序员尤其反直觉：先设计界面，再写代码。因为界面是用户唯一能看见的东西，功能藏在界面后面，界面撒谎最难。做法是先画真实尺寸的界面（纸上或简单工具），对着界面问"这个屏幕要解决什么问题"，问题清楚了再动手写。代码是界面决策的仆人，不是主人。

规格文档也别写。写文档的时候一切都很和谐，写完之后现实立刻变脸——文档成了没人遵守的摆设。真实的需求藏在"你和用户对着一版可点的东西来回讨论"里，不藏在三十页的 Word 里。

关于上线：上线不是终点，是起点

书里的原话大意是：赶在完美之前上线。担心功能不够？你永远觉得不够。上线后你会立刻知道真正缺什么——用户的抱怨比你的想象准。修 Bug 别攒：一个 Bug 修起来超过几小时就拆小，立刻修，因为拖着的不只是 Bug，还有用户的耐心和你自己的心理负担。

被别人抢先做了怎么办？书里的回答很提气：别人做完了不等于你输了——他们验证了市场，你带着更好的方案进场，这叫后发优势。别把"有人做了"当成放弃理由。

关于团队和沟通

能一个人做就别加人，能异步沟通就别开会。会议是"两个人以上一起浪费时间"的高效形式，能用文档说清的别拉会，必须开会就开"边走边聊"的小会，会上必须产出一个决定。招人同样晚招：先被工作量逼到极限，再招，并且先招"能直接交付的那块活"的人，别招"以后可能用得上"的潜力股。

关于心态：做你自己想用的东西

全书落点其实在态度：做解决你自己问题的产品，你是自己的第一个用户，口味就是标准；把产品当自己的作品而不是"项目"，细节里那点执念用户能感觉到。赚钱只是把好产品做对了之后的副产品。

和本系列的衔接

一人公司的 30 天清单教你"怎么开始"，这本书教你"开始之后克制什么"：砍功能、晚招人、少开会、早上线。配合使用，一个管节奏，一个管手艺。

最后交底：本文是对 37signals《Getting Real》公开免费版本的中文自站讲解，用于教学目的并注明出处；建议读原文获得完整表达。