【摘要】
客户递过来的需求清单，从来不是按价值排序的，是按嗓门和疼痛感排序的。你按清单顺序做，一定先做最吵的那条，而不是最该做的那条。
分级要做两次判断，而且必须分开做：第一次判该不该做，第二次排先做哪个。混在一起做，结论一定是"都能做，都很重要"，然后项目在第四个月失控。
【核心要点】
- 分级不是排序。先筛掉不该做的，再排剩下的，顺序反了会做一堆不该做的功能
- 最危险的象限不是"做不了"，是"能做但不该做"——技术上没难度，所以没人拦，做完全是人家的锅
- Fab 里有五类典型的不该做：替 PE 判工艺、替生产按 Hold、绕过 MES 直连设备、万能报表平台、固化人力搬运
- 排序用两个维度：阻塞度 × 复用度，而不是客户嗓门
- 说"不做"要三选一：换层（不是我的职责）、换期（V2，条件是什么）、换价（定制单报价）
- 分级表必须作为合同附件，它是后续所有变更管理的基线
---
一、两次判断，分开做
| 正当（该做） | 不正当（不该做） | |
|---|---|---|
| 可行 | 第一批做 | 最危险区：能做，所以没人拦 |
| 不可行 | 改造方案或分期 | 明确拒绝 |
FDE 最容易踩的是右上角。左下角（不可行但正当）反而好办：客户认，你给替代路径，双方都体面。
右上角的问题在于技术难度会掩盖责任问题。一个"系统自动判定这批要不要报废"的需求，工程师第一反应是"能做，读 defect map 加规则引擎就行"，没人问"判错了谁赔"。等真判错一批，责任就落在系统上，也就是落在你身上。
二、Fab 里最常见的五类"能做但不该做"
1. 把 PE 的工艺判定写成系统规则。 客户说"按这个规则自动判 OK/NG"。可以做，但结论必须停在"建议"，最终判定权归人。系统只输出证据链：哪片、哪个参数、偏离多少、历史同条件良率如何。
2. 替生产执行 Hold 决策。 Hold 是生产权限，动的是在制品和交期。系统能做的上限是：检测到条件成立 → 生成 Hold 建议单 → 推给有权限的人确认。直接落 Hold 的需求，一律转成"建议 + 一键确认"。
3. 绕过 MES 直连设备写数据。 客户 IT 有时会说"我们直接连 EAP 改状态更快"。这条不能接。MES 是单一事实源，绕过它写数据，等于亲手制造账实不符，出了问题追溯链断在你这里。
4. 万能报表平台。 "能不能做个我们自己配报表的工具"。这句话的需求边界是无限的，而维护成本随字段组合指数增长。正确转化：固定 10 张高频看板 + 一个受限的自助查询（只开放已建模的维度）。
5. 把人力搬运固化进系统。 客户某个人每天手工导表合并，希望你做个功能替他导。先问一句：这个动作本身合理吗？很多"自动化需求"实质是把一个本该取消的流程固化成代码，做完了流程还在，只是更快地错。
这五类的共同点：技术上都不难，所以没人喊停；做完之后责任转移到系统，而系统是你交付的。
三、排序：阻塞度 × 复用度
筛完剩下的，才轮到排序。
| 高复用 | 低复用 | |
|---|---|---|
| 高阻塞（不做，后面全部卡住） | 第一批，最高优先 | 做，但按项目定制计价 |
| 低阻塞 | 进产品 backlog，排版本 | 拒绝或挂起 |
"高阻塞"的判据很实在：这条不做，其他需求能不能验收？数据模型、主数据、权限体系、消息通道这类东西永远是高阻塞——它们不产生演示效果，但缺了什么都跑不起来。这也是为什么 FDE 要有能力把客户从"我要看板"拉回"先把 Recipe 主数据补全"。
"低复用"不等于不做，而是不该用产品价卖。客户独有的报表口径、独有的一条审批流，做，但要单列报价。这一条还有个副作用：很多需求一报价就消失了——说明它本来就不痛。
四、一个 20 条需求的分级结果（节选）
| # | 需求 | 分级 | 理由 | 期次 |
|---|---|---|---|---|
| 1 | CD 异常自动告警 | 做 | 高阻塞（后续所有分析依赖采集链路）+ 高复用 | V1 |
| 2 | Recipe 版本主数据补全 | 做 | 判据的前置条件，不做则 1 号需求判据全错 | V1 |
| 3 | 自动判定批次报废 | 不该做 | 责任边界：判定权归 PE，系统只出建议 | 拒绝 |
| 4 | 系统自动 Hold Lot | 不该做 | Hold 是生产权限，转为建议单 + 一键确认 | V1 降级 |
| 5 | 大屏 | 不该做 | 不改变行为，只改变谁来看 | V2 |
| 6 | 客户专有良率周报格式 | 做，定制计价 | 低复用，纯项目定制 | V1 附加 |
| 7 | 自助报表配置器 | 不该做 | 边界无限，维护成本不可控 | 拒绝，给固定 10 张看板 |
| 8 | 历史三年数据回灌 | 挂起 | 卡在数据权限与清洗口径，解锁条件：客户 IT 开放归档库 | 待定 |
八条里，进 V1 的四条、降级一条、拒绝三条。这个比例是正常的。一份 20 条的需求清单，能进 V1 的通常就是 4–6 条。
注意第 2 条：它没有任何演示效果，客户也不会主动提，但它是第 1 条能不能成立的前提。FDE 的价值有很大一部分体现在这种"把隐性前置条件翻到台面上"的动作上。
五、把"不做"讲成客户能接受的话
拒绝是技术活。三种话术，按场景选：
换层——不是我不做，是它不属于这一层。 "自动 Hold 这个动作得由 MES 落，我们从 EAP 侧直接发，追溯链会断在中间。我们的做法是检出即生成建议单，MES 那边一键确认，链路是完整的。"
换期——不是不做，是排在后面，条件是明确的。 "大屏 V1 不做。原因是它不影响 PE 的判断，而 V1 的验收指标是'早上 1.5 小时的活压到 10 分钟'。V2 的前提是异常清单稳定跑满一个月、误报率降到 10 条/天以下，那时候上大屏才有东西可展示。"
换价——可以做，但它属于定制。 "这个周报格式是你们独有的口径，可以做，属于定制开发，我单列报价给你。"这句话说完，客户的真实需求强度立刻就显形了。
三套话术的共同点：先给理由，再给替代，最后给条件。只说"这个做不了"，客户听到的是"你不想做"；给完替代和条件，客户听到的是"你想清楚了"。
六、分级表要进合同附件
分级结论不要只存在会议纪要里。做成一张表，作为合同附件，字段至少六个：编号、描述、分级（做/降级/挂起/不做）、理由、归属期次、计价方式。
它的三个作用：
- 变更管理的基线。 后面客户加需求，对着这张表说"这条当时定的是 V2"，比争论"你上次不是答应了吗"有效得多。
- 季度复盘的依据。 哪些"不做"后来变成了"必须做"，说明当时的判断标准有问题，要修。
- 内部对齐的工具。 销售看这张表知道能承诺什么，研发看这张表知道范围在哪。FDE 最怕的是销售在客户面前答应了表外的东西。
七、可复用点
- 分级先判该不该做，再排先做哪个。顺序反了，项目会在第四个月失控。
- 最危险的是"能做但不该做"——技术难度会掩盖责任问题，没人拦，做完锅是你的。
- 系统只出建议和证据链，判定权和 Hold 权留在人手里。这条是 Fab 里最硬的一条边界。
- 排序看阻塞度 × 复用度。高阻塞低演示效果的需求（主数据、权限、采集链路）要主动往前放。
- 拒绝要给三样东西：理由、替代方案、解锁条件。只给理由等于树敌。
下一篇讲需求文档：Fab 场景下的 PRD 该写到什么颗粒度。写细了客户不看，写粗了开发全靠猜，分界线在"状态机、异常分支、字段级约束"这三样上。