第三章 需求定义与 SOW
3.2 用例优先级与需求取舍
承前：北极星指标定下来之后，问题从"衡量什么"变成了"先做什么"。青禾优选的启动会上，白板上一口气列出了 14 个候选用例——从会员召回、智能客服、选品建议到门店排班预测，每个部门都往里塞了自己最疼的事。但第一期交付的资源只够做 2 个。这一节讲 FDE 的核心决策工具：用例优先级表，以及怎么用"做/延后/放弃"三档把 14 个砍到 2 个，并且让被砍掉的人心服口服。
3.2.1 为什么客户给的用例清单不能照单全收
客户列需求清单的方式通常是"痛点脑暴"：把所有疼的地方都写上。这份清单的真实含义不是"这些都要做"，而是"这些地方都疼"。照单全收的下场是教科书级的灾难：范围蔓延（scope creep）、里程碑集体延期、每个用例都做得半吊子，最后验收时每个部门都说"我们要的那个没做好"。
FDE 的职责恰恰是替客户做减法。这需要勇气，也需要方法。方法就是优先级表，勇气来自一个事实：客户高管自己也不想要一个什么都做但什么都做不好的项目。你在需求会上说"第一期我们只做两件事，做深做透"，只要逻辑站得住，发起人通常是感激的——他正需要一个专业方替他挡住各个部门的伸手。
3.2.2 四个评分维度
我们对每个候选用例打分，维度只有四个，每个 1-5 分：
| 维度 | 含义 | 打分问的问题 |
|---|---|---|
| 业务价值 | 对北极星指标的杠杆 | 做好了，复购率能动多少？谁最在乎？ |
| 技术可行性 | 以现有底座 + 客户数据能不能做 | 数据存在吗？干净吗？API 有吗？ |
| 交付成本 | 到可验收状态要多少人天 | 要接几个系统？要多少场对齐会？ |
| 风险 | 失败概率和失败的政治后果 | 试点失败会不会连累整个项目？ |
前三个维度决定了"值不值"，第四个维度决定了"输了赔不赔得起"。很多评分表只看前三项，忽略第四项，这在政治复杂的企业里是要吃大亏的。
四个维度合成总分的常见方式是：优先分 = 业务价值 × 可行性 ÷（成本 × 风险系数）。乘法关系是有讲究的：价值再高，可行性为零就是零分；成本再低，价值为零也是零分。风险作为除数，一个 5 分风险能把整个用例拖进"延后"档。
3.2.3 三档处置：做、延后、放弃
打完分不是排个序就完事，而是分三档，每档的沟通话术完全不同：
做（第一期）：通常 1-2 个。选择标准不是总分最高，而是总分高的里面最能构成完整链路的那个。注意"链路完整"比"分数高"重要：一个从数据接入、Agent 编排、人工审核到效果回测的全链路用例，哪怕分数略低，也优于两个断片式的高分用例——因为它能验证整个交付模式，为第二期铺路。
延后（第二期及以后）：明确写进 SOW 的"范围外但已规划"清单。这一档的关键是给出触发条件而不是模糊承诺："当 X 系统的数据接入完成后启动"、"当第一期指标基线建立后启动"。有触发条件的延后是规划，没有触发条件的延后是缓兵之计，客户感觉得出来。
放弃（不做）：要给出结构化理由。放弃不是贬低，而是"以当前条件不值得投入"。把理由写清楚（价值低/数据不存在/成本畸高/风险不可承受），半年后条件变化时还能重新评估。
3.2.4 沙盘：14 个候选用例的取舍现场
青禾优选的需求工作坊上，优先级表大致长这样（节选）：
用例 价值 可行性 成本 风险 处置
─────────────────────────────────────────────────────────
沉睡会员自动召回（试点门店群） 5 4 3 2 做
会员问答机器人（App 内） 4 4 2 2 做
导购话术助手 3 3 3 3 延后
智能选品建议 4 2 5 4 延后（数据不齐）
门店排班预测 2 2 4 3 放弃（价值低）
全渠道会员标签统一治理 5 2 5 3 拆为W4-W5数据工作
...两个现场冲突值得展开：
冲突一：智能选品是副总裁的心头好，但可行性只有 2。 选品需要商品动销、库存周转、竞品价格三类数据，青禾的库存数据只有老 WMS 一套，格式是 2015 年的自定义导出。FDE 的处理不是硬顶"做不了"，而是拆解：选品建议延后，但把"库存数据诊断"拆成第 4 周的数据工作，如果诊断结论支持，第二期排期。副总裁保住了面子，项目保住了范围。
冲突二：运营经理想把自己团队的"报表自动化"塞进第一期。 这个用例价值只有 3，但它其实是运营在争取"减工作量"承诺的落点。处理方式是把它合并进召回用例：召回 Agent 的看板天然覆盖运营 80% 的手工报表需求，作为附属交付物写进验收标准，单独列用例就砍掉了。
这就是需求取舍的实质：优先级表是武器，但用它的目的是重新组织各方的利益，而不是宣布胜负。 每一次"砍"都伴随一次利益的重构——延后给触发条件、放弃给理由、合并给替代载体。
3.2.5 把取舍结果钉进 SOW
取舍结果必须以书面形式固化，否则第一次周会就会复活。固化清单包括：
- 范围内用例：写业务目标、覆盖范围（哪些门店/人群/渠道）、明确的验收标准；
- 范围外清单：逐条列名，注明"明确不在本 SOW 范围内"，并注明处置档位与触发条件；
- 假设与依赖：本期用例成立的前提（如"试点门店 POS 数据可实时同步"），前提破裂时的处理路径。
第 3 项最常被忽略，也最常救命。青禾的召回用例依赖"试点门店的会员手机号可合规触达"——这条写进假设，后来某门店的会员授权数据不全，触发假设破裂条款，范围按时收缩，而不是无限扯皮。
3.2.6 一个快速评分工作坊的实操流程
优先级表听起来简单，但现场带着客户打分是有技巧的——打分环节失控的常见形态是：某个部门负责人坚持给自家用例的价值打 5 分，别人不好意思反对，表格最后变成政治分。一个经过验证的工作坊流程是这样的：
第一步，独立打分（15 分钟）：每个干系人先不讨论、各自给全部候选用例的价值分打分。独立打分的意义是让每方的真实立场先落纸，避免被会议现场的强势者带偏。
第二步，差异曝光（10 分钟）：把所有人的分数投到屏幕上，只找分歧最大的用例讨论。青禾的"智能选品"价值分从 2 到 5 都有——这个 3 分的分歧本身就是信息：副总裁看的是战略价值，运营看的是执行痛苦。分歧讨论对齐的不是分数，是各方脑中的"价值"定义。
第三步，FDE 主导技术项（成本/可行性/风险不打分，FDE 给数）：这三个维度是专业判断，不适合民主。数据存不存在、要接几个系统、失败的政治后果——这些数字由乙方团队评估后直接给出，并给出依据。客户参与技术项讨论只会让"可行性"变成"愿望性"。
第四步，现场出三档结论，会后 24 小时内书面确认。趁记忆新鲜，把表格和处置结论发全体与会者，欢迎 48 小时内书面异议，过期视为认可。这条流程纪律是"沉默共识"的制度化——下次有人翻案时，你有会议纪要和确认邮件双保险。
整个工作坊两小时结束。两个小时换来第一期范围的政治合法性，是整个 W3 性价比最高的两小时。
最后提一个反直觉的经验：评分表的真正产出不是分数，是分数背后的对话。 价值 3 分和 4 分谁高谁低不重要；讨论"为什么是 3 分"时暴露出来的信息——比如选品建议其实在赌下一季的品类战略——才是决定取舍的真正依据。表格是手段，对齐是目的，别把手段当目的交付给客户。
3.2.7 要点总结
- 客户的需求清单是痛点清单，不是承诺清单；FDE 的职责是替客户做减法，第一期只做 1-2 个能跑通完整链路的用例。
- 四维评分：业务价值、技术可行性、交付成本、风险；风险维度决定"输了赔不赔得起"，不可省略。
- 三档处置各有纪律：做=链路完整优先；延后=必须带触发条件；放弃=必须带结构化理由。
- 每一次砍需求都要伴随一次利益重构（触发条件、替代载体、拆解方案），优先级表是重组利益的工具，不是宣判书。
- 取舍结果通过范围外清单和假设依赖条款钉进 SOW，防止需求在周会上复活。
3.2.8 延伸：AI 项目特有的取舍维度
传统软件的需求取舍方法论（RICE、MoSCoW、Kano 模型都可用）在 AI 项目上要做两个修正：
修正一：可行性不再是二元判断。 传统功能"能做/不能做"很清楚；AI 用例的可行性是一个光谱——"召回文案生成"可行性 5 分，"完全自动化的无人值守触达"可行性 2 分，中间隔着的是准确率门槛、兜底设计和责任分配问题。所以 AI 用例的可行性评分实质是**"自动化等级"的选择**：全人工（AI 只建议）、人审放行、低风险自动 + 高风险人审、全自动。第一期选哪个等级，比"做不做"这个用例本身更影响成败。青禾第一期选"人审放行"，第二期视评估结果升到"低风险自动"——等级随信任升级，这比一步到位的幻想稳妥得多。
修正二：风险维度里要加"模型风险"。 模型会出错（幻觉、偏见、提示注入）是常态而非事故。评分时问的不再是"会不会失败"而是"失败了错误如何被发现、被兜住"。一个错了会被人审拦住的用例，风险 2 分；一个错了直接触达百万会员的用例，风险 5 分。这条修正的推论是：先用"人审放行"等级把高风险用例的风险分降下来，再谈做不做——很多"争议太大做不了"的用例，换个人审等级就从放弃档回到延后档了。
参考资料
- Statement of Work (SOW): Definition, Process & Free Templates — Institute of Project Management — SOW 中的范围界定与范围外（exclusions）写法，取舍结果固化的参照。
- 什么是工作说明书 (SOW)？ — SAP — SOW 要素概述：范围、时间表、交付物与验收，范围蔓延是头号失败原因。
- OpenAI launches the OpenAI Deployment Company — OpenAI — OpenAI 对 FDE 交付模式的官方描述：诊断后"选择少量优先工作流"（a small number of priority workflows），正是本节的"做减法"。
- The AI Was the Easy Part: What is a Forward Deployed Engineer for Supply Chain? — Samir Saci — 真实交付中"定义先于算法"的完整案例，取舍与对齐占了大半工作量。