这篇解决 FDE 在项目前期最常见的一场拉锯：客户什么都要，而你只能先做一部分。
核心做法是把「全都要」拆成带价值、频率、成本标注的场景清单，再用四象限逼出一个有理由的「不做」。最容易被误用的是打分环节：分数必须是客户签认的，工程师代打的分数在砍范围时会被一句「我们没说过这个不重要」全部推翻。
相比泛泛的优先级方法论，这篇强调三份书面产物——场景登记表、范围基线、需求池——并针对国内现场「会上点头、会后不落纸」的现实，补上变更闸门和漂移回看两个机制。
读完就做一件事：把手上项目里悬着的诉求逐条填进一张场景登记表，发给对接人书面确认。
—— FDEChina编辑部 · 实战派
客户说「这些功能我们全都要」的时候，直接答应会把项目拖死，直接拒绝会丢掉信任。范围界定的本质不是砍需求，而是把一坨模糊的「全都要」变成一张有排序、有结论、有书面确认的清单。这篇给出八个编号步骤，从场景拆解到范围漂移回看，每步包含做什么、产出物和常见坑。范围界定做得越早，后面每一步的返工越少。它假设你已经完成了需求发现，手里有一批原始诉求待整理；如果客户的预期本身就失衡，先读期望管理再回来做排序。
步骤一：把「全都要」翻译成一张场景清单
做什么：把启动会、需求文档、群聊、邮件里出现的所有诉求逐条拆出来，改写成「谁在什么情况下做什么、怎么算做成了」的格式。一条诉求只写一个场景，宁可先拆细再合并，不要把三件事揉成一句「提升运营效率」。判断拆得够不够细的一个经验法则是：每条场景都能独立回答「做没做成」，如果一条记录要靠补充解释才能判断，就说明还混着多件事。每条记录提出人、提出渠道和原始表述——原始表述是后续出现争议时唯一可信的凭证。
产出物：场景登记表，字段至少含编号、场景描述、提出人、提出渠道、原始诉求原文。
常见坑：只记录客户高层在会上说的诉求，漏掉一线操作者在私下沟通里提的真问题；后者往往频率更高、更具体。
步骤二：给每条场景标业务价值与使用频率
做什么：和客户方对接人一起，对每条场景回答三个问题：谁在用、多久用一次、用完之后省了什么或多赚了什么。价值与频率各按高、中、低打分，理由用客户自己的话记在旁边。注意两类场景的排序逻辑不同：频率低但单次价值极高（比如季度审计取数）和频率高但单次价值低（比如日报草稿），不能放在同一把尺下直接比；前者看它撬动的决策重量，后者看它节省的累计工时。打分过程尽量控制在一次会内完成，拖成多轮打分会让客户失去耐心，最后退回「都挺重要」的原点。
产出物：带价值分、频率分和理由列的场景清单。
常见坑：工程师替客户打分。你的判断可以作为建议，但签字的分数必须是客户给的，否则后面砍范围时对方一句「我们没说过这个不重要」就能推翻全部排序。
步骤三：标注技术可行性与数据就绪度
做什么：逐条检查三件事：输入数据是否存在、质量如何、能否合法拿到；依赖的系统有没有开放接口、要找谁开权限；这条场景失败时有没有人工兜底。可行性与价值分开评估，不要因为「这个难做」就在价值上压低它——难做但值得的事应该落在「后做」象限，而不是被悄悄丢掉。
产出物：清单上新增数据就绪度、外部依赖、兜底方式三列。
常见坑：把演示环境的数据质量当成生产环境的数据质量。在客户现场用真实数据跑通一次抽取，比十页评估文档更能暴露就绪度问题。
步骤四：估算每条场景的工作量与隐性成本
做什么：按人日粗估每条场景的实现量，同时把隐性成本列出来：数据清洗、边界情况处理、上线后的误报处理与日常维护。给区间不给点值，区间宽度本身反映不确定度——越不熟的领域区间越宽，这个信息对客户同样有价值。
产出物：清单增加工作量列，外加一页估算说明，写清口径、假设，以及哪些成本没算进去。
常见坑：只报首次实现成本，不算维护成本。AI 类场景的维护成本（坏例修复、提示词调整、模型升级后的回归验证）常常不低于首次实现，可以参照评测基线建设的做法，提前把回归成本计入估算。
步骤五：画价值-成本矩阵，把场景分成四类
做什么：以价值为纵轴、成本为横轴把所有场景落位，得出四类：先做（高价值、低成本，通常是首期验证的主体）、后做（高价值、高成本，写进路线图并约定启动条件）、再议（低价值、低成本，交给客户自己决定）、不做（低价值、高成本，明确说出不做及其理由）。四象限的意义不是画图好看，而是把「不做」变成一个有理由的正式结论，而不是悬而未决的暧昧。落位时容忍争议、记录争议：个别场景客户坚持认为价值高，就按客户的判断移位，并在旁边注明这是客户判断——排序可以商量，账要算得清楚。
产出物：四象限图，每条场景落位并标注处置结论。
常见坑：沟通时刻意隐掉「不做」那一类。没说出口的需求不会消失，只会在验收时换一个名字回来。
步骤六：与客户对齐排序并书面确认
做什么：开一次范围对齐会，带着矩阵和你的建议排序去，让客户做选择题（先做 A 还是 B）而不是问答题（你们觉得该做啥）。会上逐条过「不做」和「后做」的理由，允许客户调整个别结论，但每处调整都要当场记录调整理由；会上改掉的每一个结论，都要在纪要里能查到是谁基于什么改的。会后二十四小时内发确认邮件，写清本期做什么、明确不做什么、后做类按什么条件启动。
产出物：对齐会纪要、确认邮件、更新后的范围基线文档。
常见坑：会上点头、会后不落纸。国内客户现场尤其常见「会上都懂、回去各说各话」，书面确认不是不信任，是替双方省掉三个月后的回忆分歧。
步骤七：设置范围变更闸门
做什么：与客户约定：所有新出现的诉求统一进需求池，按步骤二到五的同一套流程重评重排，每周固定时间评审一次。现场被当面问到「这个能不能顺便加一下」时，标准答案只有一句「已记录，下次评审给你结论」，不当场答应也不当场拒绝。这句话要提前和对接人打好招呼，让它成为流程而不是你个人的态度，否则每次都会被当成一次新的拒绝。
产出物：对客户可见的需求池、每周一次的变更评审记录。
常见坑：为了维护关系当场答应「小需求」。范围失控从来不是一次大妥协造成的，而是二十次「就这一次」攒出来的；闸门的节奏感比闸门的严格度更重要。
步骤八：用里程碑回看范围漂移
做什么：每个里程碑结束时，把实际交付范围与范围基线对比，统计新增、删除、变更各多少条，把漂移量写进周报让双方都看见。漂移本身不是坏事，失控的漂移才是；让漂移可见，客户才会和你一起管理它，而不是默认加需求是免费的。
产出物：范围漂移记录，随里程碑评审一起过。
常见坑：只顾向前跑不回看，漂移累积到验收阶段才暴露，那时任何解释听起来都像推卸责任。
小结
这八步的核心是三份书面产物：场景登记表、范围基线、需求池。范围界定做得好不好，不看会上聊得多愉快，看三个月后双方能不能拿出同一份文件。它向上承接项目生命周期中的范围确认环节，向下为PoC 验收清单提供验收边界的依据；如果项目里有多个干系人在拉扯优先级，把四象限对齐会和确认邮件的机制，与期望管理里的干系人分层配合使用。