需求发现与问题定义
给刚拿到一个模糊的「我们要搞 AI」、需要在两周内把它变成一份可以签字的方案的人。这一页给可直接用的访谈提纲、场景筛选清单、干系人地图、问题陈述模板和范围切割方法。
本页小目录（约八千字，可跳读；带实物的是第五、七、十、十二、十三节）： 一 为什么值钱｜二 整体流程｜三 场景海选｜四 伪需求过滤｜五 访谈提纲｜六 JTBD｜七 流程走查与例外清单｜八 干系人地图｜九 从表面到真问题｜十 问题陈述模板｜十一 范围切割｜十二 一页立项书 / SoW｜十三 过关检查清单｜十四 常见误区
一、这一步为什么值钱
企业 AI 项目最常见的失败不是做不出来，是做出来了没人用；没人用的根因多数发生在这一步——问题选错了，或者问题被翻译得走了样。
被广泛引用的失败率数字要连同争议一起写清楚。MIT Media Lab 的 Project NANDA 在 2025 年 7 月发布《The GenAI Divide: State of AI in Business 2025》，报告称「95% 的组织获得的回报为零」「只有 5% 的整合式试点在提取数百万美元的价值」，方法是 52 家组织的结构化访谈、153 位高管问卷、以及对 300 多个公开披露 AI 项目的系统性回顾。[1] 它不是同行评审研究，样本也非随机抽样，且原话是「5% 的整合式试点在提取价值」——传成「95% 的项目失败」时含义已被简化。可以用来说明方向，不适合当精确统计。
两个更可验证的旁证：Palantir 的 AIP Bootcamp 把真实业务问题与真实数据写成入场前提，官方原话是「Bootcamp 不是抽象的学习，也不是用预先做好的应用；它让参与者今天就处理他们真实的用例」[2]；多个 FDE 培训项目把「需求发现与 scoping」单列为模块，Interview Kickstart 给了它整整一周，核心问法是「show me how you do this today」。[3]
一句话总结这一步的目标：把「我们要搞 AI」变成一段业务方看完会说「对，就是这个」的问题陈述，加上一个划死了边界的范围。
二、整体流程
三、场景海选：先铺开，再收敛
标准的错误做法是：开一个会，各部门报三个场景，管理层挑三个立项。各部门报上来的三个，不是他们最痛的三个，是最好写进 PPT 的三个。 真正痛的活因为琐碎、难说清、说出来显得本部门管理不善，全都不会出现在那张表上。
正确的顺序是相反的：先海量铺开，再收敛。
3.1 五个采集源（别只用第一个）
| 源 | 怎么采 | 能采到什么 |
|---|---|---|
| 1. 决策者睡不着觉的事 | 45 分钟访谈，只问「今年哪三件事你最担心」「上个月哪件事让你在会上发过火」 | 高价值，但数据通常最难拿 |
| 2. 工单 / 客服 / 报销 / 审批系统里的高频重复 | 导出近 6 个月记录按主题聚类，出「出现次数 × 平均处理时长」排行 | 真实、可量化、无人提及。最被低估的一个源 |
| 3. 一线的「变通」 | 走三个部门各问三个人：「这个流程里，你私底下有没有一套自己的干法？」 | 流程图上不存在的真实工作，含金量最高 |
| 4. 报表 / 数据资产的闲置处 | 找数据部门要「哪些报表做了但没人看」的清单 | 数据已在系统里，只差一个用法，可行性最高 |
| 5. 已经自发在用 AI 的地方 | 看内部社区、看谁在自掏腰包买账号 | 已被验证「有人愿意用」 |
必须走够五个源。 只走第 1 个，你会得到一堆战略级的、数据拿不到的题；只走第 2 个，你会得到一堆琐碎的、算不出钱的题。
3.2 场景卡：七格，两分钟填完
铺的时候不要填详细，填不出来的格子写「不知道」。
| 格 | 内容 | 填写要求 |
|---|---|---|
| 1 | 场景一句话 | 动词开头，业务语言。「把 X 从 A 变成 B」 |
| 2 | 谁在痛 | 必须是人名或具体岗位。写「公司」「部门」的一律作废 |
| 3 | 频次 | 一天 / 一周 / 一月发生多少次 |
| 4 | 现在怎么干的 | 一句话，包含工具名（Excel、微信、某系统） |
| 5 | 一次要多久 | 分钟或小时。不知道就写「不知道」 |
| 6 | 数据在哪 | 系统名 / 表名 / 或「在人脑子里」/ 或「不知道」 |
| 7 | 错了会怎样 | 这一格决定后面 Eval 的严格程度 |
四、伪需求过滤器：四问一票否决
铺完之后先做减法。每个场景 30 秒，通常能砍掉六成以上。
第一问：有没有一个具体的人在为这个问题痛？ 场景卡第 2 格写不出人名或具体岗位的，全部出局。这一条对应亚马逊 Working Backwards 五个客户问题里的第一问「客户是谁」[4]，在企业内部场景里要加严——因为最常见的伪需求形态就是「公司层面痛」（降本增效、提升效率、数字化转型）。落不到具体的人，就没有任何一个人愿意每周花两小时配合你。
第二问：他愿意为这个问题付出真实成本吗？ 判别方法：直接问「这事如果要你每周花两个小时陪我，你干不干」。答「当然可以，你随时找我」的是客套；答「周三下午我有空，但周四要交报表」的是真的。
第三问：哪个数字会变？这个数字多久能测到基线？ 借自 Douglas Hubbard《How to Measure Anything》的澄清链：值得在乎的东西必然可被观察，可观察就必然表现为某个量，有量就能测；他还有一个更狠的前置问题——这个测量支持的是哪一个具体决策？[5] 在交付语境下要更硬：不只要能测，还要在开工前测得到基线——结束时手上没有可复测的基线，汇报就只能靠形容词。
第四问：出错的代价是什么？ 场景卡第 7 格。这一格不是用来砍场景的，是用来给场景分级的：
- 错了没事（重发一次、人工改一下）→ Eval 可以松，可以先上；
- 错了要赔钱 → Eval 要严，必须有人工复核环节；
- 错了会伤人 / 停产 / 违规 → 第一个项目不碰。 不是因为它不值钱，是因为你还没有信用去承担第一次事故。
三类高危信号（看到就绕开）
- 无主之地：跨三个部门以上，且没有一个人对最终结果负责。技术难度通常不高，组织难度是地狱级。
- 只许看不给碰：数据方说「你可以看看，但不能拿走、不能落地、不能写回」。只读的系统不改变任何人的动作，做完必然零采纳。
- 宇宙级需求：「做一个能回答公司所有问题的助手」。这类需求的实质是提需求的人自己也不知道要什么。
2×2：只选一个
- 横轴：数据可得性（数据在哪、拿得到吗、脏不脏、看门人是谁）
- 纵轴：业务价值
只选右上角的一个。选两个等于选零个。
麦肯锡在《Rewired》里的原版可行性维度包含「数据、技术、变革管理复杂度」三样。[6] 在 AI 交付语境下把横轴收窄成纯数据可得性，理由是：模型是买的、云是现成的，技术复杂度往往不是瓶颈，真正卡人的是数据在别的部门手里、看门人不配合。
顶住左上角。 价值最高、数据拿不到的那个，大概率是决策者最兴奋的那个。顶住的话术有三个机关——承认他对（不否定价值判断）、给出具体的时间代价（「光把数据拿齐大概六到八周」，不是「比较难」）、把它变成有日程的下一仗（不是拒绝，是排期）：
「您说的这个我完全同意，价值最大的就是它。我摸了一下底，它要的数据现在分散在 A 系统和 B 部门的手工台账里，光把数据拿齐大概要六到八周。所以我想这么办：我把它列成第二个项目，现在就开始走数据准备，同时先用四周打 C 这个场景——C 的数据下周就能到手，四周能出一个真数字。拿着 C 的结果，我们再去要 A 和 B 的数据，会好要得多。」
五、访谈：Mom Test 与它的中文修正
5.1 三条规则
Rob Fitzpatrick 的《The Mom Test》，书名的意思是：好的问题应该好到「即使对方是你妈、即使她一心想哄你开心，问出来的答案依然是有效信息」。三条规则：谈他们的生活，不谈你的点子；问过去的具体事，不问未来的泛泛意见；少说，多听。[7]
底层论断只有一句：人会出于礼貌而撒谎。 三条机理：人们不知道自己要什么（一线主管说「我要个大屏看板」，真实问题可能是他每周一被问数问得下不来台）；人们对未来的自己过度乐观（「如果有这个工具你会用吗」的兑现率低到可以忽略）；恭维是社交润滑剂，不是数据（访谈结束你觉得「聊得特别好」，往往正是危险信号）。
在中文语境里第三条要再加重一档：中文职场的客套密度高于英文语境，「挺好的」「可以考虑」「有价值」这类词的信息量接近于零。
5.2 好问题十个（进场前背下来）
- 带我走一遍你昨天的工作，从上班到下班。
- 上一次（出质量事故 / 排班冲突 / 对账对不上）是什么时候？给我讲讲当时的过程。
- 那次最后花了多少人、多长时间收尾？
- 这个数从哪来的？你怎么拿到的？
- 这事现在谁在管？出了问题第一个电话打给谁？
- 你们试过什么办法解决它？为什么后来不用了？
- 如果这个问题继续不解决，会怎么样？
- 整个流程里，最让你烦的一步是哪步？
- 这套 Excel / 系统是谁做的？他还在吗？
- 除了你，还有谁被这个问题坑得最惨？能引荐我聊聊吗？
5.3 坏问题十个（全部禁用）
| 别问 | 为什么 |
|---|---|
| 你觉得我们这个方案怎么样？ | 乞讨恭维 |
| 如果有一个 AI 能自动排班，你会用吗？ | 未来式假设，答案永远是「会」 |
| 你们最大的痛点是什么？ | 太抽象，得到排练过的官方答案 |
| 你们想要什么功能？ | 把设计外包给用户 |
| 你们是不是经常遇到数据不准的问题？ | 诱导性提问 |
| 我们用了最新的大模型，你们感兴趣吗？ | 推销 |
| 你觉得这个行业未来会怎么发展？ | 聊得很爽，无关 |
| 领导，您对数字化转型有什么规划？ | 引出 PPT 语言 |
| 所以你的意思是这个方案可行，对吧？ | 逼对方给承诺 |
| 这个需求优先级高不高？ | 所有需求的答案都是「高」 |
5.4 三类对象，分开成册
面对的不是一个「客户」，是一张有利益冲突的关系网。同一句话对一线是求教，对数据看门人是冒犯。
A. 一线操作者（目标：真实流程 + 隐性判断）
- 开场：「我不是来看你们工作的，我是来学的。这个活我完全不懂，你今天正常干，我在旁边跟着。」
- 主问：「上周这个活你是怎么干的？走给我看一遍。」
- 挖例外：「一般是这样，但是如果……什么情况下会不一样？」
- 挖判断：「你刚才怎么知道要选这个的？」
- 挖变通：「有没有什么活，系统里不好办，你自己有一套办法的？」（这句要在建立信任之后再问，太早问会被理解成查违规）
- 收尾：「我明天还来，你有什么要我带的？」（下次还能来，比这次问到什么更重要）
B. 部门负责人（目标：决策权与承诺）
- 开场：「我想先跟您对一下这件事该怎么算成功。」
- 主问：「如果这件事做成了，您手上哪个数字会变？」
- 挖约束：「这件事做成了，您这边会不会有人不高兴？」（能问出来的都是宝贵信息，问不出来说明信任还不够）
- 挖历史：「以前有没有人试过？后来怎么样了？」
- 要承诺：「我需要每周两小时您或者您指的人陪我，验收会您需要在场。这个能定下来吗？」（要具体的时间，不要「支持」这个词）
C. 数据看门人（目标：数据与口径）——顺序不能换：先给地位，再挖坑，再给交换，最后要日期。
- 「这几张表的口径，全公司还有谁懂？」（先给地位，别先要数据）
- 「哪个字段我要是直接用了，会踩坑？」
- 「这张表 20XX 年之前和之后，算法有变过吗？」
- 「口径文档我写好之后署您的名，可以吗？」
- 「数据进来之后是只读副本，有行级权限和审计日志，比现在散在各人电脑上要安全。您看这么设计够不够，还差什么？」
- 「那我们定 X 月 X 日之前拿到第一批切片，可以吗？」（一定要落到日期）
5.5 真承诺 vs 假承诺
访谈的产出不该是「感觉聊得不错」，而是对方付出了真实成本，只有三种形态：
- 时间：「下周三我把数据组的人约来开会。」
- 声誉：「我把你引荐给我们分管副总。」
- 预算 / 资源：「这期给你留一块。」
「我们内部讨论一下」「这个方向很有价值」都是礼貌的拒绝。更具体的检验标准：肯不肯给你真实数据切片、肯不肯让你见一线用户。 这两样都不肯给的「高度支持」，支持是假的。
5.6 三条访谈纪律
- 不带 demo。 demo 一掏出来，对方就从「讲述自己的问题」切换成「评价你的产品」，你再也听不到真话。
- 每次只带三个必须搞清的问题进场。 清单太长会让你急着赶进度，失去追问的耐心——追问才是访谈的全部价值。
- 说话不超过 30%。 超过了这场访谈就废了。
六、JTBD：从「要什么」转到「在完成什么任务」
最常被引用的一手出处是 Clayton Christensen 等人 2016 年 9 月发表于《哈佛商业评论》的《Know Your Customers' "Jobs to Be Done"》[8]；Christensen Institute 的表述是「人们不是简单地购买或挑选产品与服务；他们把它们拉进自己的生活里，以取得进展」。[9]
在企业交付里 JTBD 最实用的不是理论，是 Bob Moesta 那套沿时间线倒着还原的访谈法的迁移：原版还原「哪一串多米诺骨牌倒下才导致他做出了这个购买决定」，在交付现场改成还原「哪一串信号让他做出了这个判断」。[10] 具体动作叫案例复盘：
不要问「你一般怎么判断」。拿三张真实的单子放在桌上——一张典型的、一张边界的、一张他当年判错过的——逐张问：「这张你当时怎么处理的？为什么？」
人对抽象问题的回答是编的，对具体案例的回答是真的。 这三张单子同时是 Context 工程里的判断卡和 Eval 评估集里的边界样本。相关路线还有 Tony Ulwick 的 Outcome-Driven Innovation。[11]
七、流程走查：跟着走一遍，而不是问需求
访谈能拿到「他说的」，走查能拿到「他做的」。两者的差值就是真实约束所在。
7.1 方法出处
- 现地现物（genchi genbutsu）：丰田的做法，官方表述是「最佳实践是去到问题存在的那个地点或流程」。[12] 顺带澄清一个常见混淆：精益社区常说的 "gemba walk" 不是丰田自己用的词，Lean Enterprise Institute 明确写道「丰田不使用 'gemba walk' 这个说法」。[13][14]
- Contextual Inquiry 的师徒模型：Beyer 与 Holtzblatt《Contextual Design》四原则之一是 master/apprentice——把自己放在学徒而不是提问者的位置；另外三条是到现场看真实工作、当场把观察翻译成含义让对方确认、带着明确焦点观察。[15]
7.2 看什么（按信息价值排序）
- 变通。他有没有在系统之外干活？私人 Excel、微信群、纸条、脑子里的一套顺序。变通是流程文档和现实之间的差值，这个差值就是你的机会。
- 等待。他一天里有多少时间在等——等审批、等回消息、等系统跑完。等待是最容易量化的痛。
- 返工。哪一步他做了两遍以上。
- 询问。他一天里问了几次人、问的谁、问的什么。每一次「他去问人」，都是一次没有被系统承载的知识调用。
- 手。他的手在干什么——戴手套、扶设备、拿着单子、同时开六个窗口。这一条决定了交互形态（比如「必须能语音输入」这类结论就是从看手看出来的）。
7.3 记什么（三条纪律）
- 记原话，不记结论。 「客户需要自动化」没用；「他说上个月为了对一笔差异单加了三个通宵」有用。
- 记时间戳。 每个动作花了多久——后面算账全靠这些数。
- 记例外。 每次他说「一般是……但是如果……」，后半句立刻单独记一行。「但是如果」后面的内容，是走查这一步的全部价值。
7.4 产出物：例外清单
| 流程步骤 | 文档上怎么写 | 实际怎么干 | 例外触发条件 | 例外怎么处理 | 谁定的这个规矩 | 出错过吗 |
|---|---|---|---|---|---|---|
| 退货单审核 | 系统自动校验金额 | 超过 5000 元人工复核 | 金额 > 5000 或客户等级 = VIP | 转主管，主管看客户历史 | 2023 年一次投诉之后王主管定的 | 有，去年漏了一单 |
这张表少于 10 行，说明你没跟够。 任何跑了三年以上的业务流程，例外都不会少于 10 条。
八、干系人地图
8.1 五种人，名字写出来
| 角色 | 定义 | 你要拿到什么 | 不搞定的后果 |
|---|---|---|---|
| 拍板人 | 有权说「这个流程可以改」的那个人 | 每周固定时间 + 验收当天到场 | 「大家都同意，但没人拍板改流程」 |
| 掏钱的 | 预算归谁 | 知道他的考核指标是什么 | 汇报时他会问你不想被问的问题 |
| 天天用的 | 一线用户 | 至少 3 个人愿意当第一批试用 | 上线后周活个位数 |
| 被动了奶酪的 | 这件事做成之后谁的价值感或权力被削弱 | 提前知道他是谁 | 他不会正面反对，他会在你需要配合的每一个环节慢半拍 |
| 数据看门人 | 那张表只有他懂口径 | 数据 + 口径解释 | 项目在第二周停摆 |
学术上常被引用的分类工具是 Mendelow 的 power-interest grid，按「权力大小」和「关心程度」两维把干系人分成四类分别处理[16]（原始论文年份在文献里有 1981 与 1991 两说，【待核实】）；PMI 也有公开的干系人管理策略说明。[17]
8.2 决策权：D 必须唯一
决策权分配可以只借 Bain RAPID 框架的一条：D（Decide）必须唯一[18]（原版五个角色对一个单场景项目是过度设计）。
但企业内部有一个常见变形：技术方案的 D 是 IT、流程变更的 D 是业务、上线授权的 D 是老板，三个人互相等。 所以不要只写一个 D，按决策类型写三个：技术方案谁定、流程变更谁定、上线授权谁定。三个格子填不满，别往下走。
8.3 「被动了奶酪的」那个人怎么找
三个信号，见到任意一个就记下来：他现在的价值来自信息不对称（「只有他知道那个表怎么算」，系统一旦把它变成公开的，他就从「不可或缺」变成「一个岗位」）；这件事会让他的考核数字变难看（比如隐藏的返工次数第一次被统计出来）；他管的人会变少。
找到之后不要绕开他。三种处理按优先级：署名（让他成为规则的定义者，写进系统和汇报里）、减负（先做一件让他自己轻松的事，哪怕和主线无关）、退路（如果他的活确实要被替代，提前和他的领导谈他的下一个位置——这件事不该由你来谈，但必须由你来提）。
8.4 尸体考古
每个场景进场先问一句：
「这事以前有没有人试过用系统解决？后来怎么样了？」
如果有，去把那个项目挖出来：谁做的、什么时候没的、当时一线怎么说的。上一个失败系统的死因就是你的雷区图，而且一线对你的第一句评价大概率就是「上次那个也是这么说的」——你得知道「上次那个」是什么才接得住。
九、从表面问题到真问题
9.1 5 Whys，但每一层必须附现场证据
5 Whys 出自丰田，由丰田佐吉提出雏形、大野耐一在《Toyota Production System》里系统化并称之为丰田科学方法的基础。[19] 它在会议室里最常见的失败是五层全靠想——一口气推完，推出一个听起来很深刻的结论。加一条硬约束就能救：
每一层的答案后面，必须附一个你在现场看到或听到的事实（带人名或时间）。附不上的那一层，停下来，回现场。
| 层 | 问 | 答 | 现场证据 |
|---|---|---|---|
| 1 | 为什么退货单要 3 天？ | 因为要等主管复核 | 8/12 跟班，王工提交后 2 天 11 小时才被复核 |
| 2 | 为什么复核要这么久？ | 主管每天下午才批一次 | 李主管说「我一天就下午三点集中批」 |
| 3 | 为什么集中批？ | 因为要一张张翻客户历史 | 现场看他批一单平均 6 分钟，其中 4 分钟在查历史 |
| 4 | 为什么要查客户历史？ | 因为 2023 年出过一次大额错退 | 王主管原话：「那次赔了 8 万，从那以后我全看。」 |
| 5 | 为什么不能自动查？ | 客户历史在 CRM，退货单在 ERP，两边不通 | 数据地图上两系统客户 ID 不一致 |
读一下第 5 层的答案，再读一遍第 1 层的问题。表面问题是「审核慢」，真问题是「主管为了防一次 8 万元的错误，每单花 4 分钟做人工关联查询」。两者指向完全不同的方案：解表面问题会做一个催办提醒（主管更烦，速度没变）；解真问题是把 CRM 的客户历史摘要自动贴到退货单上（单笔从 6 分钟降到 1 分钟，而且主管的风险感没有降低）。
9.2 三个「差值信号」
真问题往往藏在差值里。回顾材料，找这三个：
| 差值 | 在哪找 | 它意味着什么 |
|---|---|---|
| 说的 vs 做的 | 访谈记录 vs 走查笔记 | 说的是他认为应该的样子，做的是真实约束。差值处 = 真实约束 |
| 高层说的 vs 一线说的 | 部门负责人访谈 vs 一线访谈 | 高层给战略叙事，一线给工作现场。差值处 = 机会 |
| 系统里的 vs 人脑里的 | 数据地图 vs 判断卡 | 系统承载不了的判断。差值处 = 这个项目的价值所在 |
三个差值一个都写不出来，说明你还没挖到真问题，只做了信息收集。
9.3 一条附带纪律：打架的数字比漂亮的数字有信息量
同一件事出现两个不同口径时，不要选一个信，去把它们的分母问出来。这通常会牵出一条口径冲突，也可能直接否掉你打算用的基线指标。口径治理的做法见 Context 工程。
十、问题陈述：格式与验收
格式固定，不超过 150 字：
谁（具体人 / 岗位）在什么时候（触发条件），因为什么约束（真实原因，不是表面原因），不得不做什么（当前的应对），代价是多少（时间 / 金钱 / 风险），一年发生多少次。
示例：
退货主管李某在每天下午集中审核时，因为客户历史在 CRM、退货单在 ERP、两系统客户 ID 不通，不得不对每一单人工翻查客户历史，单笔复核 6 分钟里有 4 分钟花在查询上，全年约 1.4 万单，折合约 930 小时。这个做法始于 2023 年一次 8 万元错退事故，任何方案都不能降低他对这类错误的防御能力。
最后那句话是这段陈述里最重要的一句——它写出了这个方案的不可违反约束，而这一句通常只有真正下过现场的人写得出来。
验收这一步只有一个动作：把这段话念给业务方听。
- 他说「对，就是这个」——过关。
- 他说「差不多吧」——没过关。
- 他说「还有一种情况你没说到」——没过关，但这是好消息。把那种情况问清楚，改完再念一遍。
十一、范围切割：缩范围，不缩价值
11.1 一条判据
可以把场景切窄——只做一个部门、一类单据、一条产线——但切下来的这一刀必须端到端打穿：从真实数据进，到一线用户的屏幕，到业务指标的变化。禁止「横切一层」的阉割版（只做个数据看板、只做个聊天问答），那种东西演示效果好、业务价值为零。
判断标准只有一句：做完之后，有没有一个具体的人，他每天的某个动作因此变了？
11.2 固定时间、可变范围
方法上的一手出处是 Basecamp 的《Shape Up》里的 Appetite（先定愿意花多少时间，再把方案锤进这个时间）、Circuit Breaker（周期内没交付的项目默认取消而不是默认延期）、Scope Hammering（为在固定时间盒内完成而强力削减范围）三个概念[20]，术语原文与在交付流水线里的位置见 交付生命周期。
它们在企业交付里的价值只有一句：期限是纪律工具——它逼你砍需求、逼对方配合、逼双方在「完美」和「能用」之间选能用。
11.3 「不做」清单比「做」重要
范围写法的正反对照：
| 差 | 好 |
|---|---|
| 覆盖客服全流程 | 做：华东区、退货类、文字工单。不做：语音工单、其他大区、退货以外的工单类型、不做自动回复只做分类与排序 |
「不做」那几条是你在第 12 天顶住「能不能顺便加个 X」时唯一的依据。至少写三条。
标准话术：「这个记进第二期清单。这四周我们先把说好的这个数字打下来。」
十二、一页立项书 / SoW：六格
无论是内部立项还是外部合同，这六格是最小集合：
- 问题——用业务语言，禁行话。
- 目标业务指标——只能有一个，且必须是现在就能测到基线的数字。
- 范围——做什么 / 不做什么，「不做」至少三条。
- 数据清单——每一项写责任人 + 到手日期。
- 节奏——死线，具体到日期。
- 需要对方给的三样东西——能拍板的业务负责人、能解释数据的人、第一天用真实数据的授权。
写法对照
| 差 | 好 | |
|---|---|---|
| 项目名 | AI 智能客服提效项目 | 把华东区退货单的处理时间从 3 天压到 1 天 |
| 目标指标 | 提升客服响应效率，改善客户满意度 | 首次响应时间中位数从 4.2 小时降到 1 小时以内（基线取 2026 年 7 月全量工单） |
行话黑名单：赋能、抓手、闭环、智能化升级。出现一个，这份立项书的可信度掉一半。这条纪律继承自亚马逊 PR/FAQ 的「禁行话、禁内部缩写」约束。[4]
为什么指标只能写一个：多指标等于没指标。结项那天你会挑对自己有利的那个讲，对方也知道你会这么干。一个指标才构成一个赌局，赌局才有信用。
第 6 格那三样东西的出处
这三样对应 Palantir AIP Bootcamp 的客户准备做法：合作伙伴公布的准备清单要求确认参与人角色（业务负责人、用户、相关 IT 干系人）、在营前一到两周提供基于工作流的静态数据切片、预先讨论用例范围、并在数据共享后与数据所有者开一次 30 分钟的会。[2][21] 把出处说出来是有用的，尤其当你没有品牌势能、只能借势的时候。
签字这个动作的真实功能
签字与其说是审批，不如说是一次测试：不肯在这张纸上签字的人，也不会给你后面几站需要的支持。 反复推说「先做起来看看再说」的，当场把三样东西再要一遍——要不到，应该重新考虑场景。
签字时还有一句话必须当面讲：
「这四周结束，可能的结论有三个：扩大、调整、停止。停止也是一个正常结论，我会把为什么不该做写清楚给您。这样我这四周才敢用真数据、真死线干活。」
十三、这一步的过关检查
- [ ] 场景铺够，五个采集源都走过
- [ ] 四问过滤跑完，每个被砍的场景写明砍的理由（这份被砍清单是下一个项目的原料）
- [ ] 2×2 画出来，只圈了一个
- [ ] 顶住了左上角那个，并已把它写进下一仗清单
- [ ] 现场走查至少 2 到 3 个整天，例外清单 ≥ 10 行
- [ ] 三类对象各访谈过，笔记里有原话和时间戳
- [ ] 干系人地图五种人名字写出来，三类决策的 D 分别是谁写清楚了
- [ ] 「被动了奶酪的」那个人找到了，且已想好用哪种方式处理
- [ ] 前任项目死因查过了（有就写，没有写「查过，没有」）
- [ ] 5 Whys 做完，每一层都附了带人名或时间的现场证据
- [ ] 三个差值至少写得出两个
- [ ] 问题陈述念给业务方听，他说「对，就是这个」
- [ ] 范围切完，「不做」写了至少三条
- [ ] 一页立项书 / SoW 六格填满，指标只有一个
- [ ] 三样东西全部到位（人名 + 日期，不是口头承诺）
- [ ] 对方签字了，且当面听过「停止也是一个正常结论」
十四、常见误区
- 「先做个 demo 给他们看看」。 demo 会把访谈变成产品评价会。它的位置在 造与 MVD，不在这一步。
- 「需求文档写得越细越好」。 没有原话、没有时间戳、没有例外的详细需求文档，只是把假设写长了。
- 「找对接人聊就够了」。 对接人给你的是被翻译过一次的问题。三类对象都要见，尤其是会被动了奶酪的那个人。
- 「先把范围定大一点好谈价钱」。 范围大等于死线软，死线软等于没有交付。
- 「业务方说数据没问题，那就开始吧」。 口头承诺的成本为零。数据切片没有实际到手之前，不要开始建。
延伸阅读
- Context 工程 — 访谈和走查拿到的材料怎么变成模型能用的形态
- Eval 设计 — 场景卡第 7 格「错了会怎样」如何决定评估的严格程度
- 交付生命周期 — 这一步在整条流水线里的位置与典型耗时
- 造与 MVD — 范围切割之后怎么造
- 05 · 前 30 天、05 · 干系人与数据获取 — 这一步的现场做法与常见障碍
- 03 角色与能力 — 这一步需要的能力在能力模型里的位置
- Rob Fitzpatrick, The Mom Test — 一百多页，是这一整页里投入产出比最高的一本
- Basecamp, Shape Up — 全书免费在线，范围管理部分值得逐章读
来源
- MIT NANDA（Project NANDA, MIT Media Lab）, "The GenAI Divide: State of AI in Business 2025", 2025-07. 项目页 https://www.media.mit.edu/groups/nanda/overview/（官方 PDF 直链会重定向至该概览页，报告全文本次经第三方镜像核对，【原始 PDF 待核实】）
- Palantir, "Deploying Full Spectrum AI in Days: How AIP Bootcamps Work", Palantir Blog, 2023-10-12. https://blog.palantir.com/deploying-full-spectrum-ai-in-days-how-aip-bootcamps-work-21829ec8d560
- Interview Kickstart, "Forward Deployed Engineering" 课程大纲（W13 Customer Discovery & Scoping），抓取日期 2026-09-01. https://interviewkickstart.com/courses/forward-deployed-engineering
- Colin Bryar & Bill Carr, Working Backwards（2021）；Working Backwards / PR-FAQ 流程公开说明. https://workingbackwards.com/concepts/working-backwards-pr-faq-process/
- Douglas W. Hubbard, How to Measure Anything: Finding the Value of "Intangibles" in Business, Wiley, 2007（澄清链）。
- Eric Lamarre, Kate Smaje, Rodney Zemmel, Rewired, Wiley, 2023；配套公开文章 https://www.mckinsey.com/capabilities/quantumblack/our-insights/reimagining-your-business-for-ai
- Rob Fitzpatrick, The Mom Test, 2013. 官方站点 https://momtestbook.com（三条规则为书内表述，官网页面未逐字呈现，【原文页码待核实】）
- Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan, "Know Your Customers' 'Jobs to Be Done'", Harvard Business Review, 2016 年 9 月刊. https://hbr.org/2016/09/know-your-customers-jobs-to-be-done
- Clayton Christensen Institute, "Jobs to Be Done". https://www.christenseninstitute.org/theory/jobs-to-be-done/
- Bob Moesta, Demand-Side Sales 101, 2020；jobstobedone.org. https://jobstobedone.org/
- Tony Ulwick / Strategyn, "Outcome-Driven Innovation". https://strategyn.com/lp/outcome-driven-innovation/
- Toyota (UK) Magazine, "What is Genchi Genbutsu?". https://mag.toyota.co.uk/genchi-genbutsu/
- Lean Enterprise Institute, "Gemba Walk"（Lean Lexicon）. https://www.lean.org/lexicon-terms/gemba-walk/
- Lean Enterprise Institute, "Gemba, workplace, genchi genbutsu, go-and-see… What's the difference?". https://www.lean.org/the-lean-post/articles/gemba-workplace-genchi-genbutsu-go-and-see-whats-the-difference/
- Hugh Beyer & Karen Holtzblatt, Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann, 1998（第二版 2014）。方法综述公开 PDF：http://iihm.imag.fr/coutrix/ens/M2-MoSIG-HiL/1stAssignment/ContextualInquiry/holtzblatt.pdf
- Aubrey Mendelow, "Environmental Scanning: The Impact of the Stakeholder Concept", ICIS 会议论文（power-interest grid 的原始出处；文献中对年份有 1981 与 1991 两种引用，【年份待核实】）
- Project Management Institute, "Planning effective stakeholder management strategies". https://www.pmi.org/learning/library/planning-effective-stakeholder-management-strategies-development-6058
- Paul Rogers & Marcia Blenko, "Who Has the D? How Clear Decision Roles Enhance Organizational Performance", Harvard Business Review, 2006-01. https://hbr.org/2006/01/who-has-the-d-how-clear-decision-roles-enhance-organizational-performance
- Lean Enterprise Institute, "5 Whys"（Lean Lexicon）https://www.lean.org/lexicon-terms/5-whys/；原始出处为 Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, 1978（英文版 1988）
- Ryan Singer / Basecamp, Shape Up, 术语表. https://basecamp.com/shapeup/4.5-appendix-06；"Decide When to Stop" 章 https://basecamp.com/shapeup/3.5-chapter-14
- PVM（Palantir 合作伙伴）, "Palantir Platform Bootcamp Guide"（公布的客户准备四步与三阶段议程，属合作伙伴公开文档，非 Palantir 官方原文）. https://blog.pvmit.com/pvm-blog/palantir-platform-bootcamp-guide