我最近看到一个很有意思的现象很多做技术分享的人总喜欢把一个本来很朴素的问题包装成“XX 实战指南”“XX 从入门到精通”好像不叠加几个关键词文章就失去了存在的意义。但真正在项目里摸爬滚打过的人通常会对另一类内容更敏感——那种不谈大词、不堆概念甚至有点“反效率”的行动原则。这两年我印象最深的是 37signals 那本《Getting Real》。它不叫《做大产品》《打造完美团队》也不讲“增长黑客”或者“组织进化”而是直接把“真实”两个字摆出来。我最早读到它时差点以为是一本项目管理鸡汤后来按照里面的思路做了两三个内部工具才意识到它真正讲的不是流程而是“怎么用更少的资源做出真正有人用的东西”。这篇文章我想从一次真实的重构经历讲起聊聊我对“Getting Real”的理解它为什么适合小团队为什么不适合所有项目以及它里面那些看似反常识的原则放在今天的开发环境里还成不成立。1. 先搞清楚这本书真正反对的是什么很多人在讨论《Getting Real》时第一反应是“这是一本讲敏捷开发的书”。这个理解不算错但很容易把它窄化。我曾经也这么想直到自己经历了一次失败的需求评审。1.1 它反对的不是规划而是“用规划代替验证”当时我们在做一个内部运营后台客户方提了一个特别完整的权限矩阵九个角色、三十二个功能点、每个按钮都有独立的可见性规则。Excel 表做了五页流程图画了两个晚上看起来非常“靠谱”。但我按照 Getting Real 里“No Meetings”和“No Reports”的思路做了一个小调整先砍掉所有后续优化项只保留一个最小闭环——超级管理员和普通操作员两个角色能提交订单、能看自己的订单列表其他全部不加。结果上线后才发现客户真正高频使用的是“批量导入”权限矩阵里那一大套规则用得极少。如果当时把五页 Excel 全部落地相当于花了两个月做了一个低频功能。这就是 Getting Real 的第一个价值它逼你把资源放到真实反馈上而不是放到文档协定上。它反对冗长的会议和需求文档不是因为它讨厌流程而是因为流程本身不能证明需求真实存在。1.2 它追求的“少”是刻意选择不是能力不足有人会误解觉得 Getting Real 是小团队没钱没人的妥协方案。实际上它的核心假设恰恰相反少不是限制而是优势。我在一个五六人的小团队里维护过一个数据可视化产品当时竞品功能非常全地图、大屏、报表、告警、订阅每个方向都有百人团队在迭代。我们如果照着“功能对标表”去做很快就会被拖死。后来我们只做一件事把 CSV 上传到生成图表的时间压缩到 10 秒以内。用户只要上传一个文件几分钟内就能得到一个可分享的链接。这个选择让我们的产品价值变得异常清晰不是“功能更多”而是“更快得到结果”。Getting Real 强调的“用更少的功能服务更真实的场景”本质上不是在给产品做减法而是在给团队做减法——减掉那些分散注意力、消耗资源、却不能产生反馈的环节。1.3 为什么“少”在今天更适用今天打开任何一个开发工具面临的主要矛盾已经变了。过去是工具匮乏缺少能力现在是信息过载缺少焦点。一个团队如果每两周开三次会每次会议都要对齐需求、进度、风险那么真正写代码和观察用户的时间就被挤压了。Getting Real 式的方法论是在用一种近乎“断舍离”的方式把团队从流程泥潭里拉回来。它真正解决的问题不是“怎么做计划”而是“怎样让做出来的东西被真实使用”。2. 我对“Getting Real”落地路径的拆解读完书之后我把它重构成了一套更适合普通开发团队的落地流程。不是照搬章节而是提炼出三个关键词最小真实版本、短周期观察、砍功能而非砍质量。2.1 最小真实版本不是最小可展示模块而是最小可验证闭环网上很多人把 MVP最小可行产品理解成“能把界面跑起来的最小 Demo”。但 Getting Real 里的思路更接近“最小真实版本”——这个版本必须包含一个真实使用路径用户能进去、能操作、能走完一个完整动作、能看到结果。我做过一个团队内部的知识库工具第一版只包含三个页面文档列表、文档编辑、文档详情。当时很多同事说至少要有目录树、标签、全文搜索不然没法用。但我坚持先不做搜索因为第一版的核心验证点是“大家是否愿意把文档从 Flyhub 迁过来”。如果没有这个验证点即使做了搜索也只是为一个空库做功能。结果第一版上线后一周内只有三篇文档被创建。问题不是出在功能上而是出在“是否真实需要”上。后来我们改成在原来同步文档里嵌入一个入口把新工具作为“整理后的知识库”来推两周后内容量才逐渐上来。这个例子说明最小真实版本不是为了炫技而是为了确认“用户是否愿意走完关键路径”。2.2 短周期观察先把研发周期压到可控范围获取真实反馈的前提是反馈周期足够短。如果从需求提出到功能上线要三个月那反馈就变成了猜谜。实际落地时我一般会把一个“Getting Real”迭代控制在两周以内第一周明确一个关键待验证假设只做一条用户路径。第二周准备上线、内部试用、收集日志和行为数据。第三周开始前决定继续加功能、调整方向还是砍掉整个模块。这种节奏反直觉的地方在于它要求团队放弃“一版做完整”的安全感。很多工程师喜欢把所有边界情况都处理好再发布但 Getting Real 的逻辑是先让真实用户用手点的速度跑赢我们写代码的速度。我在实践中发现两周已经是一个比较长的周期。如果能一周内上线一个实验性页面反馈效率会更高。2.3 砍功能而非砍质量两者不能划等号有一段时间我特别纠结如果功能砍得太少会不会给用户留下“工具很简陋”的印象后来想明白砍的是“场景外”的功能不是砍“场景内”的质量。比如用户在关键路径上填写一个名称字段如果这个字段没有校验应该补上如果用户上传文件失败错误提示必须清晰不能只是控制台有日志。这些属于场景内质量不能砍。而像“暗黑模式”“国际化语言切换”“第三方登录”这类功能即使技术上不复杂如果没有真实需求在早期也属于可以砍掉的部分。Getting Real 强调的核心不是凑合而是把有限的精力集中到关键体验上。砍功能是一种风险控制砍质量才会真正伤害产品。3. 最容易误判的三个关键点如果不理解 Getting Real 的适用边界很容易把它变成“不做文档、不开会”的借口。这里我总结三个最容易误判的点也是我踩过的坑。3.1 不做文档不等于不留痕迹在书里“No Documentation”建议的是不要写大量没人看的功能说明文档而不是不记录设计决策。我在一个工具项目里曾经为了省事完全不做方案记录。结果三个月后新同事要接手一个模块完全不知道该模块为什么这么设计。后来不得不通过 git log 去反推思路效率极低。现在我会在代码仓库里放一个很短的 README里面只记录三件事这个模块解决什么问题、当前的关键取舍是什么、最重要的运行参数是什么。真正的“少文档”是只留下能帮助团队理解项目根因的记录。不需要写页面式的说明只需要写清“为什么”。3.2 不做大计划不等于不设目标Getting Real 反对的是“长期计划成为僵化的承诺”。它不反对“我们准备下个月做一件事”这样的方向感。我有一次负责一个数据导入功能因为不想做详细计划就一直停留在“调研”阶段。拖了两周后我们被迫启动才发现目标其实非常清晰用户能上传 Excel、能处理十种常见格式、能返回错误行号。这三条边界定下来之后功能很快就做完了。这说明很多时候我们需要的不是大计划而是一个明确的边界。计划可以短边界必须清晰。没有边界的“走一步看一步”不是 Getting Real是对真实性的误解。3.3 以“不必要”为标准不是以“会不会做”为标准新人很容易犯一个判断错误因为某个功能技术上简单就顺手做了。比如加一个重置密码邮件模板、加一个简单的统计图表接口、加一个导出 PDF 按钮。这些功能单个成本都不高但合起来会不断扩散注意力。Getting Real 的判断标准不是“能不能做”而是“在当前阶段是不是必须做”。我一般会用一个问题帮助判断如果不做这个功能用户会流失吗如果不会那就先不做。做功能的时候容易产生的错觉是“用户的未来需求”但真正的需求是现在就有痛点的场景。一个功能如果没有当下真实使用者就不应该成为第一优先级。4. 它真正改变的是工作流而不是某一个动作很多人以为用了 Getting Real 就等于“小步快跑”“快速迭代”但它比较深刻的影响是把团队的工作方式从“等待完整再行动”切换到“尽早暴露问题”。这种改变会渗透到开发习惯、沟通方式、协作节奏里。4.1 开发习惯从“先做扩展性设计”到“先做可运行设计”过去写代码时我喜欢为将来可能出现的功能预留接口。比如要做一个文章模块就先把标签、分类、评论、审核都设计进去。这样系统看起来很完整但代价是代码复杂度大幅上升而且很多预留功能根本没有被使用过。Getting Real 一个明显的影响是让我先做“可运行”的代码而不是“可扩展”的代码。比如我会先写一个直接处理上传文件的函数不去抽象“云存储接口”等真的有第二个存储需求时再重构。这里有一个重要前提要确保核心代码结构清晰哪怕没有扩展接口也要方便后续修改。否则“先做可运行设计”会退化成“怎么快怎么写”。4.2 沟通方式用实物界面替代抽象讨论很多团队开会时讨论的往往是“我希望能有一个强大的筛选器”“我们要做一个更智能的推荐”这种描述在概念层很难达成共识。Getting Real 会建议先做出一个可点击的原型哪怕只有一个页面然后把讨论放到原型上。这个变化很微妙。当大家面对真实界面时讨论会迅速变得具体“按钮位置不对应该放在右上角。”“这个筛选项太多了一开始只需要两个。”“上传之后的反馈文案不清晰。”这样的讨论虽然有时候会让做原型的人觉得麻烦但远比“我觉得需要更完善一些”有效。用实物界面替代抽象讨论本质上是在用可感知的东西降低沟通成本。4.3 协作节奏从“每个人忙自己的模块”到“持续集成反馈”如果团队真正遵循 Getting Real协作节奏会变成每个人都随时能拿出可以运行的东西然后一起在运行版本上找问题。交互设计师、后端、前端、测试不是按阶段交接而是围绕一个真实可操作的产品共同迭代。这样做的好处是没有人能在“我觉得会好用”“我猜用户这样用”的假设里停留太久。因为只要产品能跑起来假设就会被验证或推翻。不过这种节奏对团队要求比较高不是每一个组都能适应。它要求大家在心理上接受“当前版本不完美”同时有足够强的自驱力去持续打磨。5. 为什么我觉得它更像一个人文判断而不是技术框架回到我自己的经验一个团队要不要采用类似 Getting Real 的原则本质上不是技术问题。5.1 它要求先承认“我们不知道用户要什么”在很多软件项目里最大的障碍不是技术难度而是团队不愿意承认自己的不确定性。一旦需求文档写得很清楚、计划排得很满大家就容易产生一种“一切都在掌握中”的幻觉。Getting Real 要求你承认你不知道用户最后会怎么用这个功能。因为你不知道所以你需要尽快做出一个最小的东西让用户告诉你答案。这种姿态在工程文化里不太常见。因为工程师习惯了“问题-方案”的线性思维不太习惯“我们先做个实验看看吧”。但真正能长期做出好产品的人通常都愿意保留这种开放心态。5.2 它对“低成本”的推崇背后是“敬畏真实反馈”很多人会把低成本误解为“省钱”“省时间”。但 Getting Real 对低成本的理解更接近“降低尝试的门槛”。真实反馈是昂贵的。通常需要你投入研发资源、投入维护精力、投入用户信任后才能得到。任何能降低反馈获取成本的环节都值得推崇。比如做一个小工具如果能在两天内上线用户使用三天后反馈这个循环的成本就很低。如果做成一个需要审批、预算、资源调配、多部门合作的系统反馈成本就一下子高到大多数团队无法承受。低成本的本质是让团队敢做、敢改、敢放弃。当试错成本变得可控团队才会真正保持灵活。5.3 在技术圈里“显得很忙”是另一种浪费现在很多团队有一个隐性焦虑如果不开会、不搞流程、不写周报是不是显得不够专业Getting Real 其实是把这个问题撕开了一个口子专业不等于忙碌效率不等于产出。我见过一些团队每天都有晨会、有排期、有进度看板但季度末发现真正交付到用户手里的变化很少。相比之下一个只做最小真实版本、每周和用户交流、及时调整方向的团队反而更容易做出有效果的东西。Getting Real 的长期价值就在于把团队从“用流程证明自己在干活”中解放出来把注意力重新放回“真实用户在真实场景里的真实需求”。6. 如果你现在就想试着落地可以从这里开始说了这么多最后给出一个可以直接上手的行动清单。它不是 Getting Real 的完整复刻而是一套适合技术团队常跑的“轻量验证法”。6.1 第一步锁定一个真实场景问题不要从一个宏大产品概念出发而是从一个具体场景问题出发。比如“用户上传一个大文件时很容易因为超时失败”或者“运营每天手动同步数据容易漏掉某一行”。锁定问题后写下一句话目标我们想让谁在什么场景下更方便地完成什么动作。这一句话会成为后续所有判断的标准。6.2 第二步列出这个场景的“最小功能闭环”把解决问题的路径拆成一个最小闭环。例如用户上传文件系统解析文件系统返回结果用户下载或查看结果这个闭环里可以砍掉的是历史记录、批量处理、权限细分、消息通知。不可以砍掉的是上传成功/失败的状态反馈、解析结果的关键信息、错误时的可读提示。判断标准是如果用户无法走完这个闭环那么这个功能就不能算“真实存在”。6.3 第三步限定时间盒两周内必须上线给闭环设一个时间盒建议一到两周。这里的关键不是“尽量快”而是“必须有截止日”。如果两周做不完说明这个闭环还不够小需要继续拆。上线时不需要做宣传不需要做完整帮助文档只需要让一小批真实用户试用同时提前想好收集什么反馈。我个人会在上线前准备一个问题列表比如用户在哪里卡住是否有人不愿意用哪个环节大家问得最多有没有出现我们完全没预料到的用法这些问题比功能点列表更有价值。6.4 第四步用反馈决定去留两周后根据真实反馈做一次“去留判断”如果用户基本能用、愿意继续用可以考虑进入下一轮迭代。如果用户不愿意用先别急着加功能先弄清楚是场景不存在还是方案不够好。如果完全没人用果断砍掉或大幅调整不要因为“代码已经写了”而继续投入。这个判断逻辑看起来很残忍但它恰恰是 Getting Real 的核心真实反馈比计划更重要放弃错误的假设比坚持完成更重要。7. 结语少做一点反而更容易接近真实我越来越觉得开发软件最困难的部分不是写代码不是架构设计也不是性能优化而是每一次“做判断”的时候都面对不确定性。我们无法预知用户会不会喜欢无法预知这个功能有没有价值无法预知市场会不会买账。Getting Real 提供了一条相对务实的路不要试图一次性消除所有不确定性而是用最小的成本、最短的周期、最直接的方式让真实反馈替你做决定。它不要求你做更多反而要求你少做一点。少做一点“我以为用户会需要”的功能少做一点“为了完整性而存在”的设计少做一点“证明团队在忙”的流程。然后把省下来的时间和精力投入到观察真实使用、修复关键问题、打磨核心体验上。如果你现在正被一个想法困住不知道该不该继续做或者该不该一口气把功能做全我的建议是先停下来做一个最小真实版本找人用一次。你会发现真实反馈给出的答案往往比团队内部的十次会议都更清楚。这条路不炫酷也不热闹但它能让你离“真实”近一点。这大概就是 Getting Real 在今天的价值。