Getting Real 是我每隔几年都会翻一下的产品方法论。它最早来自 37signals 团队在做 Basecamp 过程中的实战总结到今天读仍然不过时。它最核心的主张不是“不写文档”而是“用真实可运行的产品替代猜测和空转”。把这句话想明白团队在立项阶段很多无休止的讨论都能少一大半。这套方法适合谁适合独立开发者、三五人的小团队、正在做内部工具的效率小组以及所有想做从 0 到 1 产品验证的人。它不适合强合规、强流程、多部门接口集成的项目下面我会专门留一节说边界。最值得关注的点是它把“做产品”从一个需要大量前置文档的大工程变成一个可以按周执行的闭环。你可以不用刻意导入什么敏捷概念就能在两周内获得一个真实使用的版本。下面按实际工作顺序拆一下怎么判断自己适不适合、怎样把概念落到工作流、以及最常出问题的环节。1. 先判断你适不适合 Getting Real别把“少做”理解成“偷懒”Getting Real 表面上会被误读为“少做需求、不写文档、快上快试”。这句话只对了一半。它真正反对的不是文档而是没有实物反馈的空转真正鼓励的不是“功能少”而是“核心功能足够真实”。1.1 它真正反对的是什么很多团队写需求文档并不是因为业务方要求交付文档而是因为大家习惯用文档来“假装思考”。文档写完了团队以为问题已经想清楚了但最关键的判断——用户到底会不会用、这个流程是不是真的方便——往往在文档阶段没有任何验证。Getting Real 给出的替代方案是尽早把想法变成一个能运行的界面、流程或者脚本把它拿给真实使用者看。哪怕这个版本丑、功能少、没有权限体系、没有好看的图表只要核心流程能走通它的沟通效率就远高于几十页描述。我自己的判断标准很简单如果方案讨论超过一周还没有任何可操作的东西出现那问题往往不在“讨论得不够”而在“根本没有真正的问题需要解决”。1.2 三个核心动作缩小范围每个版本只解决一个最痛的问题不做“完整平台”。尽早发布只要核心流程闭环就发布给真实用户哪怕还有一堆想做的功能没做。用真实反馈替代猜测看用户是否主动用、是否能独立完成核心操作、遇到卡点在哪里而不是听他们嘴上说“感觉不错”。这三个动作听起来简单实际执行时最大的阻力是团队习惯。大家总觉得“等后台完善一点再给用户看”结果一等就是几个月。等到真正拿出手时之前假设的场景可能已经变了或者用户早就用别的方式绕过了问题。1.3 什么团队适合什么团队要谨慎用下面这个表可以快速判断场景是否适合原因个人开发效率工具适合反馈直接迭代快三五人团队做 SaaS 新功能适合可以小步上线用户反馈及时公司内部数据工具适合业务方就在旁边能快速拿到真实反馈银行、医疗等强合规系统不适合变更流程和审计要求决定必须保留文档与评审硬件软件产品谨慎物理制造无法按周迭代原型成本高甲方合同驱动的外包项目不适合交付物和验收流程由合同约定如果你处在“不适合”这一栏不用强行套用 Getting Real。你可以借鉴“缩小范围”和“尽早验证”这两个原则但文档、评审、里程碑仍然要按照项目要求保留。这里要区分“少做”和“做半成品”。Getting Real 鼓励少做边缘功能但不鼓励把核心流程切一半就交付。核心路径必须能完整走通否则那不是迭代是事故。2. 把“不写文档”翻译成可执行的工作方法很多人问不写需求文档那怎么对齐不写方案文档那怎么做设计评审答案不是“什么都不写”而是“换一种更短、更接近真实的载体”。2.1 用一页纸范围清单代替长文档我一般会让团队先写一页纸内容包括四块这个版本解决哪个具体问题。谁是这个版本的使用者。核心流程是什么用 5 到 10 步说清楚。明确不做的事情。这四条写清楚就能替代大多数 PRD 的讨论功能。真正的逻辑漏洞在做的时候才会暴露所以文档里不需要把细节全写满而是先定边界再直接做。我在一个内部报表工具项目里试过这个做法。最开始按惯常流程产品先花两周写需求文档提到权限分级、审批流、消息通知、定时任务、可视化图表表格列了七张。后来改成先写一页纸范围清单只保留“数据导入、列表筛选、导出 Excel”团队第三天就开始开发两周后第一个版本已经给业务方在用。对比很明显不在文档阶段纠结核心问题反而更早暴露。2.2 需求怎么判断三条过滤条件拿到一个功能需求时问三个问题缺了它核心流程能不能跑完缺了它用户会不会觉得“这根本不是我要的东西”缺了它你能否验证这个产品到底有没有价值三个问题都回答“不影响”就砍掉或延后。三个问题里只要第一个是“不能”那它就是核心需求必须保留。这个过滤条件尤其适合内部工具。权限分级和审批流在很多内部系统中看起来是理所当然的功能但对一个“先让业务方能把数据导出”的第一版来说它们大概率能延后。真正值得优先做的是让用户完成主线动作。2.3 怎么避免“做半件事”变成“做半成品”“半件事”的意思是把一个大系统拆成一个小闭环。闭环的意思是从用户进入系统到拿到结果全程是通的。“半成品”的意思是闭环里缺了关键节点用户走到某一步就断了。判断是否闭环有一个很直接的方法找一个不是开发的人让他从零开始用看他能不能不向你提问就完成任务。如果能这就是一个真闭环如果中途需要你解释或者需要看文档那闭环还没完成。我见过一个团队做了一个数据导出工具导出流程本身是通的但只能在指定浏览器里用其他浏览器打开页面直接空白。开发人员自己只用测试浏览器所以没发现。真实用户一打开就卡死这个版本就等于没有闭环。开发团队把精力全放在后端逻辑上忽略了“用户怎么进入入口”这个最基础的问题。2.4 讨论时多画流程图少写描述文档另一个可以立刻上手的变化开需求讨论会时让大家在白板上画流程图而不是每人写一段文字。流程图能把角色、操作、异常分支都暴露出来。写文字时很容易用“用户提交申请后进入审批”这种话掩盖真实逻辑但画图时必须表达清楚提交按钮在哪个页面、数据落在哪张表、审批人怎么收到通知、拒绝之后用户看到什么。这一步做完80% 的逻辑分歧在动手前就解决了完全不需要写一份几十页的需求文档。3. 一个照着走的落地流程从想法到真实反馈Getting Real 不是一本书读完就有用的理论它需要变成流程。下面这个流程我实际在几个内部项目里用过拆成两周时间适合一个 3 到 8 人的小团队。3.1 第一步把大目标压缩成一个“会面问题”大目标往往是一个系统名比如“做一个考勤系统”“做一个客户管理平台”。这种目标没法直接开发因为边界太大。要把它压缩成一个“会面问题”用一句话说明谁在什么场景下遇到了什么困扰希望通过一个动作得到什么结果。比如不是“做一个考勤系统”。而是“让主管每天早上花 5 分钟就能知道今天谁还没打卡并一键提醒”。压缩之后开发范围自然变小。团队要做的就是一个打卡记录页、一个未打卡列表、一个提醒按钮。不会一上来就碰排班、请假、加班、工资联动这些魔鬼细节。3.2 第二步写出一页范围清单和验收标准范围清单我建议写成三组必须做核心路径缺少一个都无法闭环。暂缓做有明确价值但这个版本不做也不影响闭环。明确不做这个版本完全不碰避免有人误解功能边界。以考勤提醒为例必须做打卡记录导入、未打卡名单计算、一键提醒。暂缓做自动定时提醒、移动端适配、多部门权限。明确不做排班表、请假审批、工资计算、复杂报表。验收标准也要写清楚。比如“打开页面到看到未打卡名单的操作不超过 3 步”“提醒后对应人员在 30 分钟内有反馈状态”。验收标准不是文档负担而是判断“这个版本到底做完了没有”的唯一依据。3.3 第三步找 3 到 5 个真实使用者这一步决定整件事的成败。内部团队最容易犯的错误是自己人充当用户测试然后得到一堆“还不错”“挺好用”的反馈。真实使用者应该满足三个条件他真的有这个痛点而不是配合你表演。他会直接告诉你哪里不好用甚至脾气差一点更好。他不是你的下属或依赖你发工资的人避免身份影响反馈真实性。我之前经历的一个教训是找了一个配合度很高的同事当测试人员他嘴上说“没问题”但上线后从来没有主动用过。后来才发现他根本不觉得这个流程需要工具他都是在任务快结束时补填数据。真正有效的办法是找一个每天被这个流程困扰、经常抱怨的人。宁可找一个会提很多问题的人也不要找一个什么都点头的人。真实反馈质量决定了下一轮迭代方向是否正确。3.4 第四步上线后收集什么信号上线不等于结束。要收集的信号不是“有没有人夸我”而是是否有人在没人提醒的情况下主动使用。用户完成一次核心任务需要多久卡在哪一步。收到的反馈是“缺功能”多还是“不知道怎么用”多。这个工具是否改变了他原来的工作方式。这些信号可以做成一个简单的反馈表。不用做复杂的数据分析只要每天看登录记录、操作日志外加每周做一次半小时的面对面访谈就能比较准确地判断方向。3.5 两周计划示例时间做什么验证标准第 1 到 2 天定义核心问题、画流程图、定范围清单一页纸可以说明白第 3 到 6 天开发最小核心路径开发人员自己能完整走通第 7 到 9 天找真实使用者测试记录卡点至少 2 个非开发人员能独立完成任务第 10 到 11 天修复关键问题补充必要提示再次测试不再出现中断型问题第 12 到 14 天部署到真实使用环境采集反馈获得一周真实使用记录这个计划不是唯一标准但它能让你在较短周期内获得真实反馈。如果两周后还没有任何真实使用者用起来问题大概率不在开发速度而在需求定义和用户选择上。4. 落地时最常见的坑和排查顺序方法论落地时真正难的不是理解而是在遇到问题后知道先查哪里。4.1 做出来没人用先查这四件事很多团队遇到“做出来没人用”的第一反应是加功能、加推广、做培训。但按 Getting Real 的思路应该先按顺序排查需求本身是不是真的存在看用户在没有提醒、没有强制要求时是否主动打开。入口是不是太难找如果用户需要点三次才能进入他们很可能直接放弃。是不是技术上不可用比如权限缺失、数据不同步、加载太慢。是不是解决的根本不是用户最痛的问题工具做得很顺手但用户真正的痛点不在这。这个排查顺序很关键。我见过一个内部工具团队花了两周疯狂加图表功能结果后来发现用户根本打不开页面是登录权限没有配好。这类问题不先排查环境只顾增加功能只会拉长反馈周期。4.2 功能越加越多控制“顺手加一个”的心理当产品跑起来之后最危险的话是“顺便加一个”。后面的逻辑往往是“这个功能很简单的”“不就是加个字段吗”“今天就能做完”。控制方法是用前面的三条过滤条件再过滤一遍。如果缺了它核心流程还能跑用户也不会觉得这不是同一个工具那就不加。加功能之前还要先看数据现有功能有多少人在用。如果现有核心功能的使用率都不高加新功能只会增加混乱。另一个很实用的做法每加一个新功能就明确说出它会砍掉哪个旧负担。如果一个新功能只是“多出来”的东西没有让原有流程变简单那它大概率不是好功能。4.3 团队已经有了很重的文档习惯怎么转型如果公司流程要求你写需求文档、详细设计、测试用例不要试图一次性推翻。比较稳妥的做法是挑一个边界清晰、影响面小的新项目试点 Getting Real 流程。可以先不写几十页 PRD只写一页范围清单配一个可运行原型。其他人最担心的往往不是文档多少而是“你做事有没有章法”。当你把一个可运行的原型摆在面前并且能说清楚范围、验收标准和反馈记录时文档量自然会减少。这个过程不需要团队宣布“我们转型了”只需要在下一批内部工具或小型需求上持续使用慢慢形成习惯。等大家发现不靠长文档也能顺利上线时阻力会小很多。4.4 什么时候必须暂停或放弃这里不是说 Getting Real 永远正确。遇到以下情况就应该回到更重的流程强合规项目银行、医疗、军工、政务系统审计要求必须保留全过程文档。合同明确锁定交付物甲方要求提交完整需求说明书、设计文档、测试文档不能因为方法论而违背合同。多团队接口高度耦合如果 A 团队改了接口B、C、D 团队的系统都会受影响就不能任意缩短联调周期。硬件和线下流程物理制造无法按周迭代原型成本高需要更严格的前置规划。在这些场景里可以吸收 Getting Real 的“小步验证”思想但不要照搬流程。4.5 一个排查清单表现象优先检查什么怎么处理上线没人用需求真伪、入口、权限、数据加载先观察真实日志再决定是否加功能用户只用一次就不用了核心流程是否闭环、使用体验是否太繁琐找用户当面走一遍记录卡点反馈都是“还行”用户是不是“捧场型”测试者换真实使用者重新测试开发周期一直延长范围是不是在膨胀重新用三条条件做减法团队争论方案是否缺少可运行原型停止讨论让一方先做一个最小闭环文档写了但没人执行文档是否成为替代思考的工具换成“一页纸范围 原型演示”这个表不是万能答案但它能帮你在卡住的时候按优先级排查而不是靠感觉乱试。如果只是看概念你可能会觉得 Getting Real 就是“小团队创业、快速迭代”这八个字。真正用过一轮之后才会发现它最难的不是少做而是在一堆看似都要做的需求里准确挑出那个必须做的核心并且真的让它上线接受真实反馈。我的建议是不要急着把团队流程全部改成这套先找一个小工具或新功能跑一个完整周期用真实的反馈数据来判断这套方法到底适不适合你们。多数时候跑完一轮你就知道下一步该怎么调整了。
Getting Real实战：用真实产品替代文档，小团队快速验证的核心理念
Getting Real 是我每隔几年都会翻一下的产品方法论。它最早来自 37signals 团队在做 Basecamp 过程中的实战总结到今天读仍然不过时。它最核心的主张不是“不写文档”而是“用真实可运行的产品替代猜测和空转”。把这句话想明白团队在立项阶段很多无休止的讨论都能少一大半。这套方法适合谁适合独立开发者、三五人的小团队、正在做内部工具的效率小组以及所有想做从 0 到 1 产品验证的人。它不适合强合规、强流程、多部门接口集成的项目下面我会专门留一节说边界。最值得关注的点是它把“做产品”从一个需要大量前置文档的大工程变成一个可以按周执行的闭环。你可以不用刻意导入什么敏捷概念就能在两周内获得一个真实使用的版本。下面按实际工作顺序拆一下怎么判断自己适不适合、怎样把概念落到工作流、以及最常出问题的环节。1. 先判断你适不适合 Getting Real别把“少做”理解成“偷懒”Getting Real 表面上会被误读为“少做需求、不写文档、快上快试”。这句话只对了一半。它真正反对的不是文档而是没有实物反馈的空转真正鼓励的不是“功能少”而是“核心功能足够真实”。1.1 它真正反对的是什么很多团队写需求文档并不是因为业务方要求交付文档而是因为大家习惯用文档来“假装思考”。文档写完了团队以为问题已经想清楚了但最关键的判断——用户到底会不会用、这个流程是不是真的方便——往往在文档阶段没有任何验证。Getting Real 给出的替代方案是尽早把想法变成一个能运行的界面、流程或者脚本把它拿给真实使用者看。哪怕这个版本丑、功能少、没有权限体系、没有好看的图表只要核心流程能走通它的沟通效率就远高于几十页描述。我自己的判断标准很简单如果方案讨论超过一周还没有任何可操作的东西出现那问题往往不在“讨论得不够”而在“根本没有真正的问题需要解决”。1.2 三个核心动作缩小范围每个版本只解决一个最痛的问题不做“完整平台”。尽早发布只要核心流程闭环就发布给真实用户哪怕还有一堆想做的功能没做。用真实反馈替代猜测看用户是否主动用、是否能独立完成核心操作、遇到卡点在哪里而不是听他们嘴上说“感觉不错”。这三个动作听起来简单实际执行时最大的阻力是团队习惯。大家总觉得“等后台完善一点再给用户看”结果一等就是几个月。等到真正拿出手时之前假设的场景可能已经变了或者用户早就用别的方式绕过了问题。1.3 什么团队适合什么团队要谨慎用下面这个表可以快速判断场景是否适合原因个人开发效率工具适合反馈直接迭代快三五人团队做 SaaS 新功能适合可以小步上线用户反馈及时公司内部数据工具适合业务方就在旁边能快速拿到真实反馈银行、医疗等强合规系统不适合变更流程和审计要求决定必须保留文档与评审硬件软件产品谨慎物理制造无法按周迭代原型成本高甲方合同驱动的外包项目不适合交付物和验收流程由合同约定如果你处在“不适合”这一栏不用强行套用 Getting Real。你可以借鉴“缩小范围”和“尽早验证”这两个原则但文档、评审、里程碑仍然要按照项目要求保留。这里要区分“少做”和“做半成品”。Getting Real 鼓励少做边缘功能但不鼓励把核心流程切一半就交付。核心路径必须能完整走通否则那不是迭代是事故。2. 把“不写文档”翻译成可执行的工作方法很多人问不写需求文档那怎么对齐不写方案文档那怎么做设计评审答案不是“什么都不写”而是“换一种更短、更接近真实的载体”。2.1 用一页纸范围清单代替长文档我一般会让团队先写一页纸内容包括四块这个版本解决哪个具体问题。谁是这个版本的使用者。核心流程是什么用 5 到 10 步说清楚。明确不做的事情。这四条写清楚就能替代大多数 PRD 的讨论功能。真正的逻辑漏洞在做的时候才会暴露所以文档里不需要把细节全写满而是先定边界再直接做。我在一个内部报表工具项目里试过这个做法。最开始按惯常流程产品先花两周写需求文档提到权限分级、审批流、消息通知、定时任务、可视化图表表格列了七张。后来改成先写一页纸范围清单只保留“数据导入、列表筛选、导出 Excel”团队第三天就开始开发两周后第一个版本已经给业务方在用。对比很明显不在文档阶段纠结核心问题反而更早暴露。2.2 需求怎么判断三条过滤条件拿到一个功能需求时问三个问题缺了它核心流程能不能跑完缺了它用户会不会觉得“这根本不是我要的东西”缺了它你能否验证这个产品到底有没有价值三个问题都回答“不影响”就砍掉或延后。三个问题里只要第一个是“不能”那它就是核心需求必须保留。这个过滤条件尤其适合内部工具。权限分级和审批流在很多内部系统中看起来是理所当然的功能但对一个“先让业务方能把数据导出”的第一版来说它们大概率能延后。真正值得优先做的是让用户完成主线动作。2.3 怎么避免“做半件事”变成“做半成品”“半件事”的意思是把一个大系统拆成一个小闭环。闭环的意思是从用户进入系统到拿到结果全程是通的。“半成品”的意思是闭环里缺了关键节点用户走到某一步就断了。判断是否闭环有一个很直接的方法找一个不是开发的人让他从零开始用看他能不能不向你提问就完成任务。如果能这就是一个真闭环如果中途需要你解释或者需要看文档那闭环还没完成。我见过一个团队做了一个数据导出工具导出流程本身是通的但只能在指定浏览器里用其他浏览器打开页面直接空白。开发人员自己只用测试浏览器所以没发现。真实用户一打开就卡死这个版本就等于没有闭环。开发团队把精力全放在后端逻辑上忽略了“用户怎么进入入口”这个最基础的问题。2.4 讨论时多画流程图少写描述文档另一个可以立刻上手的变化开需求讨论会时让大家在白板上画流程图而不是每人写一段文字。流程图能把角色、操作、异常分支都暴露出来。写文字时很容易用“用户提交申请后进入审批”这种话掩盖真实逻辑但画图时必须表达清楚提交按钮在哪个页面、数据落在哪张表、审批人怎么收到通知、拒绝之后用户看到什么。这一步做完80% 的逻辑分歧在动手前就解决了完全不需要写一份几十页的需求文档。3. 一个照着走的落地流程从想法到真实反馈Getting Real 不是一本书读完就有用的理论它需要变成流程。下面这个流程我实际在几个内部项目里用过拆成两周时间适合一个 3 到 8 人的小团队。3.1 第一步把大目标压缩成一个“会面问题”大目标往往是一个系统名比如“做一个考勤系统”“做一个客户管理平台”。这种目标没法直接开发因为边界太大。要把它压缩成一个“会面问题”用一句话说明谁在什么场景下遇到了什么困扰希望通过一个动作得到什么结果。比如不是“做一个考勤系统”。而是“让主管每天早上花 5 分钟就能知道今天谁还没打卡并一键提醒”。压缩之后开发范围自然变小。团队要做的就是一个打卡记录页、一个未打卡列表、一个提醒按钮。不会一上来就碰排班、请假、加班、工资联动这些魔鬼细节。3.2 第二步写出一页范围清单和验收标准范围清单我建议写成三组必须做核心路径缺少一个都无法闭环。暂缓做有明确价值但这个版本不做也不影响闭环。明确不做这个版本完全不碰避免有人误解功能边界。以考勤提醒为例必须做打卡记录导入、未打卡名单计算、一键提醒。暂缓做自动定时提醒、移动端适配、多部门权限。明确不做排班表、请假审批、工资计算、复杂报表。验收标准也要写清楚。比如“打开页面到看到未打卡名单的操作不超过 3 步”“提醒后对应人员在 30 分钟内有反馈状态”。验收标准不是文档负担而是判断“这个版本到底做完了没有”的唯一依据。3.3 第三步找 3 到 5 个真实使用者这一步决定整件事的成败。内部团队最容易犯的错误是自己人充当用户测试然后得到一堆“还不错”“挺好用”的反馈。真实使用者应该满足三个条件他真的有这个痛点而不是配合你表演。他会直接告诉你哪里不好用甚至脾气差一点更好。他不是你的下属或依赖你发工资的人避免身份影响反馈真实性。我之前经历的一个教训是找了一个配合度很高的同事当测试人员他嘴上说“没问题”但上线后从来没有主动用过。后来才发现他根本不觉得这个流程需要工具他都是在任务快结束时补填数据。真正有效的办法是找一个每天被这个流程困扰、经常抱怨的人。宁可找一个会提很多问题的人也不要找一个什么都点头的人。真实反馈质量决定了下一轮迭代方向是否正确。3.4 第四步上线后收集什么信号上线不等于结束。要收集的信号不是“有没有人夸我”而是是否有人在没人提醒的情况下主动使用。用户完成一次核心任务需要多久卡在哪一步。收到的反馈是“缺功能”多还是“不知道怎么用”多。这个工具是否改变了他原来的工作方式。这些信号可以做成一个简单的反馈表。不用做复杂的数据分析只要每天看登录记录、操作日志外加每周做一次半小时的面对面访谈就能比较准确地判断方向。3.5 两周计划示例时间做什么验证标准第 1 到 2 天定义核心问题、画流程图、定范围清单一页纸可以说明白第 3 到 6 天开发最小核心路径开发人员自己能完整走通第 7 到 9 天找真实使用者测试记录卡点至少 2 个非开发人员能独立完成任务第 10 到 11 天修复关键问题补充必要提示再次测试不再出现中断型问题第 12 到 14 天部署到真实使用环境采集反馈获得一周真实使用记录这个计划不是唯一标准但它能让你在较短周期内获得真实反馈。如果两周后还没有任何真实使用者用起来问题大概率不在开发速度而在需求定义和用户选择上。4. 落地时最常见的坑和排查顺序方法论落地时真正难的不是理解而是在遇到问题后知道先查哪里。4.1 做出来没人用先查这四件事很多团队遇到“做出来没人用”的第一反应是加功能、加推广、做培训。但按 Getting Real 的思路应该先按顺序排查需求本身是不是真的存在看用户在没有提醒、没有强制要求时是否主动打开。入口是不是太难找如果用户需要点三次才能进入他们很可能直接放弃。是不是技术上不可用比如权限缺失、数据不同步、加载太慢。是不是解决的根本不是用户最痛的问题工具做得很顺手但用户真正的痛点不在这。这个排查顺序很关键。我见过一个内部工具团队花了两周疯狂加图表功能结果后来发现用户根本打不开页面是登录权限没有配好。这类问题不先排查环境只顾增加功能只会拉长反馈周期。4.2 功能越加越多控制“顺手加一个”的心理当产品跑起来之后最危险的话是“顺便加一个”。后面的逻辑往往是“这个功能很简单的”“不就是加个字段吗”“今天就能做完”。控制方法是用前面的三条过滤条件再过滤一遍。如果缺了它核心流程还能跑用户也不会觉得这不是同一个工具那就不加。加功能之前还要先看数据现有功能有多少人在用。如果现有核心功能的使用率都不高加新功能只会增加混乱。另一个很实用的做法每加一个新功能就明确说出它会砍掉哪个旧负担。如果一个新功能只是“多出来”的东西没有让原有流程变简单那它大概率不是好功能。4.3 团队已经有了很重的文档习惯怎么转型如果公司流程要求你写需求文档、详细设计、测试用例不要试图一次性推翻。比较稳妥的做法是挑一个边界清晰、影响面小的新项目试点 Getting Real 流程。可以先不写几十页 PRD只写一页范围清单配一个可运行原型。其他人最担心的往往不是文档多少而是“你做事有没有章法”。当你把一个可运行的原型摆在面前并且能说清楚范围、验收标准和反馈记录时文档量自然会减少。这个过程不需要团队宣布“我们转型了”只需要在下一批内部工具或小型需求上持续使用慢慢形成习惯。等大家发现不靠长文档也能顺利上线时阻力会小很多。4.4 什么时候必须暂停或放弃这里不是说 Getting Real 永远正确。遇到以下情况就应该回到更重的流程强合规项目银行、医疗、军工、政务系统审计要求必须保留全过程文档。合同明确锁定交付物甲方要求提交完整需求说明书、设计文档、测试文档不能因为方法论而违背合同。多团队接口高度耦合如果 A 团队改了接口B、C、D 团队的系统都会受影响就不能任意缩短联调周期。硬件和线下流程物理制造无法按周迭代原型成本高需要更严格的前置规划。在这些场景里可以吸收 Getting Real 的“小步验证”思想但不要照搬流程。4.5 一个排查清单表现象优先检查什么怎么处理上线没人用需求真伪、入口、权限、数据加载先观察真实日志再决定是否加功能用户只用一次就不用了核心流程是否闭环、使用体验是否太繁琐找用户当面走一遍记录卡点反馈都是“还行”用户是不是“捧场型”测试者换真实使用者重新测试开发周期一直延长范围是不是在膨胀重新用三条条件做减法团队争论方案是否缺少可运行原型停止讨论让一方先做一个最小闭环文档写了但没人执行文档是否成为替代思考的工具换成“一页纸范围 原型演示”这个表不是万能答案但它能帮你在卡住的时候按优先级排查而不是靠感觉乱试。如果只是看概念你可能会觉得 Getting Real 就是“小团队创业、快速迭代”这八个字。真正用过一轮之后才会发现它最难的不是少做而是在一堆看似都要做的需求里准确挑出那个必须做的核心并且真的让它上线接受真实反馈。我的建议是不要急着把团队流程全部改成这套先找一个小工具或新功能跑一个完整周期用真实的反馈数据来判断这套方法到底适不适合你们。多数时候跑完一轮你就知道下一步该怎么调整了。