第 2 章 解决正确的问题
本章导读：FDE 最大的浪费不是写出有 bug 的代码，而是漂亮地解决了一个错误的问题。本章讲怎么在进场早期把问题找对：进场第一周怎么做、怎么分辨真问题与伪问题、怎么用一份问题定义文档把共识钉死、怎么把模糊的"提升效率"翻译成可测量的成功标准。本章的产出物（问题定义文档）是后续所有章节的地基。
2.1 进场第一周怎么过
第一周的目标只有一个：建立对客户业务的"地面真相"认知，而不是接受转述版本。 客户给你的背景材料、招标文件、高层访谈，都是二手的；二手信息经过了过滤和美化，直接在上面设计方案，等于在别人画的地图上开车。
第一周的三条动作：
动作一：跟着数据走一遍完整流程。 选一个典型业务对象（一张采购单、一笔理赔、一批原料），从它进入系统开始，跟着它走到流程结束。看它在哪些系统间跳转、在哪里被人工停下来处理、在哪里丢失或重复。流程中的每一次"人肉搬运"，都是潜在的问题点。这个动作胜过十次会议，因为你看到的是实际发生的事，不是 PowerPoint 上的理想流程。
动作二：找三类人各聊一次。 同一个组织对同一个问题的描述是分裂的，你至少要听到三个层面：
- 一线操作员（库管员、客服坐席、财务专员）：他们知道流程真实长什么样、哪些环节是纯痛苦的重复劳动。和他们聊要放下笔记本，用"带我看看你平时怎么干这活"开场。
- 中层管理者（部门经理、主管）：他们知道量化数据（多少人花多少时间在什么上）、知道流程为什么变成今天这样、知道哪些改动推得动。
- 高层（VP 及以上）：他们知道战略优先级和预算逻辑，知道这次采购要向谁证明什么。
三层数据对不上号的地方，就是组织的真实约束所在，也常常是项目后面会翻车的地方。
动作三：先画现状，再谈未来。 第一周结束时，你应该能画出客户现状的两张图：一张业务流程图（数据怎么流、谁在哪里做什么决策），一张系统架构图（有哪些系统、数据存在哪、怎么打通）。画不出来就说明第一周还没完成，先别急着谈方案。把这两张图拿给客户的中层确认，他们纠错的过程会暴露大量你不知道的信息。
2.2 真问题与伪问题
不是客户提出的所有问题都值得解决。伪问题会消耗你几周的时间，最后产出一个没人用的功能。分辨的依据不是问题描述本身，而是它背后的行为证据。
伪问题的典型信号：
- 只有高层说，中层和一线都不提。 高管说"我们要做智能预测"，但一线没人抱怨预测不准，那这多半是汇报素材而不是业务刚需。
- 说问题的人自己不用改任何东西。 如果解决这个问题的收益落在 A 部门，但需要 B 部门改变工作方式，而 B 不在项目里，这事推不动。
- 无法说出当前的量化基线。 问"这个流程现在花多少人力、多少时间、错误率多少"，如果没人答得上来，说明没人真正被它困扰，或没人认真测过它。
- 它其实是一个更深层问题的症状。 "报表慢"的深层问题可能是数据口径混乱，直接优化报表等于给漏水的屋顶刷漆。
真问题的典型信号：
- 存在大规模的重复人工劳动：人工搬运数据、人工核对、人工汇总。这类问题的收益最容易量化，也最容易被一线欢迎（因为减负的是他们自己）。
- 问题已经在造成可见损失：错发、超期、超额、罚款、客诉。有账可查。
- 有人已经用 Excel 和脚本在土法解决。土法方案是真需求的铁证，说明痛点大到有人愿意下班后自己写脚本。
- 客户愿意为它改变流程。真问题面前，客户愿意调整自己的组织，这是最硬的判据。
实践中多数"问题清单"里真伪混杂。处理方式不是争论，是回到基线数据：把每个候选问题折算成"每周多少人时、多少金额"写下来，立刻见分晓。 折算不出来，就先存疑。
2.3 问题定义文档：把共识钉死
问题找对之后，必须落成文字并让客户签字画押式地确认。口头共识会在三周后变成"我们当时不是这么说的"。问题定义文档不是形式主义，它是你在后面几个月里对抗需求漂移、范围膨胀的唯一锚点。
模板如下，一页到两页为宜，超过两页说明你还没想清楚：
markdown
# 问题定义：[一句话命名，如"门店退货单人工审核积压"]
## 背景
客户是谁，什么业务场景，现状流程如何运转（附流程图）。
## 现状与量化基线
当前这个问题消耗的资源 / 造成的损失，写清数据来源。
例：退货单平均审核 3.2 天，积压峰值 800 单/周，需 4 名专职审核（数据来源：客户 ERP 工单表 2026 年 1-6 月）。
## 目标（可测量）
上线后 X 个月内，[指标] 从 [基线] 改善到 [目标值]。
例：审核时长降到 1 天以内，单人处理能力提升 3 倍。
## 边界与不做什么
明确列出本项目不解决什么。这一节最重要。
例：不改变退货政策本身，不处理商品质量鉴定环节，不覆盖 B2B 大客户退货。
## 成功标准与验收方式
谁来判定、看什么数据、什么时间点验收。
## 依赖与约束
需要客户提供的数据/接口/人员配合，已知的技术与合规约束。两个使用要领：
第一，"不做什么"必须由客户确认。 范围模糊是 FDE 项目最常见的事故源。"不做什么"写得越具体，后面越好活。
第二，量化基线必须写数据来源。 客户拍脑袋给的数字不可靠，定不下来就花半天和客户一起拉数据。这个半天会在后面节省你几周的扯皮。
2.4 把"提升效率"翻译成可测量
客户高管的语言是"提升效率、降本增效、数字化"，你的语言必须是可测量的指标。翻译的通用方法是把模糊目标拆成 对象 × 动作 × 度量 三要素：
- "提升退货审核效率" → 对象 ：退货审核员；动作 ：处理一张退货单；度量：单均处理时长、单人日均处理量、积压单量。
- "让数据更准" → 对象 ：经营日报；动作 ：出具月度报表；度量：口径冲突条目数、报表出具提前天数、人工核对工时。
拆完后和客户逐个确认三件事：这个数字现在能不能拿到（拿不到就先补埋点或对账脚本）、谁来认这个数（最好双方共同认可一套数据）、多久看一次。拿不到基线的指标不是目标，是愿望。
最后给目标值留出诚实的空间。不要为了赢单拍一个激进数字然后指望现场奇迹；定一个"有证据支撑的保守值 + 一个理想值"，并在问题定义文档里写明目标值的推导依据。第 5 章会看到，这些当初写下的数字，就是续约谈判桌上你的全部弹药。
2.5 伪问题的处理：转化而非拒绝
识别出伪问题之后，怎么对提出它的高层说"不"？直接否定是下策：你会失去提出者的支持，而他往往是给你开门的人。上策是把伪问题转化为真问题，三种方法：
方法一：成本换算。 把伪问题按 2.2 的四问折算一遍，把"没有基线、没人抱怨、收益归属不清"的证据摆成一张中性的事实表，交给提出者。多数伪问题在数字面前自动降级。注意姿态：你是来帮忙把需求做实的，不是来证伪他的判断的，措辞上把"这个不划算"换成"我把账算了一下，您看这个口径对不对"。
方法二：找症状背后的真病。 高管提出的问题常常是他在报表上看到的症状（报表慢、预测不准、客户流失），顺着症状往下挖一层（第 2.2 节的信号四），用真问题替换伪问题，并把替换的逻辑讲给原提出者听。他提出的题目被你做成了真项目，功劳仍然是他的。
方法三：最小实验。 实在无法说服也无法证伪时，安排一个一周内能完成的低成本探针（拉一份历史数据、做一次小样本回测、蹲点观察一天），让事实替你说话。探针的结果无论正反，都推进了问题定义。
转化失败的情形也要正视：如果客户高层坚持伪问题且不容讨论，这本身是一个重要的客户情报，它说明项目的真实决策逻辑不是业务价值，此时要做的是降低投入承诺、保护自己的资源，并把风险如实同步给公司。不是每个客户都值得你全力以赴，这也是判断力的一部分。
案例框：一个伪问题是怎么被识破的
（示例案例，复合虚构）
某区域连锁药房邀请 FDE 团队进场，高层提出的题目是"用 AI 预测各门店销量"。按此立项，预计三个月。
FDE 进场第一周跟数据走流程时发现：门店店长的真实工作流是每周自己预估销量下单，估不准的部分靠调拨救；而调拨响应慢的根源是区域仓的拣货排班表格陈旧。对店长访谈，八成店长说销量预估"差不多就行"，真正的痛点是"补货申请提交后三四天才到货"。
把候选问题折算成人时与损失：销量预估不准造成的滞销与缺货损失，店长自己已经用经验消化了七八成，残余可改善空间有限；而补货响应每慢一天，门店需要多备三天安全库存，占压现金可观，且这是区域仓运营团队自己天天抱怨的事。
FDE 把两组数据摆到客户高层面前，项目从"AI 销量预测"改题为"补货响应时效优化"。三个月后时效从 4 天降到 1.5 天，门店安全库存下降，项目续约。事后复盘：如果按原始题目硬做，交付一个预测模型，预测得再准也改善不了补货链路，项目大概率在验收时被质疑价值。
这个案例里起作用的不是高明的技术，是 2.1 的两条动作：跟数据走一遍流程，找一线聊。伪问题的破绽都藏在一线的行为里。
本章工具
- 第一周动作清单：跟一条数据走完全流程；访谈一线、中层、高层各至少一人；画出业务流程图与系统架构图并请客户确认。
- 真伪问题四问：谁在抱怨（一线还是只有高层）？谁需要改变行为？基线数字是多少？是不是更深层问题的症状？
- 问题定义文档模板：见 2.3 节，务必包含"不做什么"与基线数据来源。
- 目标翻译三要素：对象 × 动作 × 度量，然后确认数据可获得性、认定人、查看频率。
本章要点
- 第一周建立地面真相：跟数据走流程、访谈三层人物、画出两张现状图，画不出来不谈方案。
- 分辨真伪问题靠行为证据，不靠问题描述；土法解决与可量化基线是真问题的铁证。
- 问题定义文档一至两页，"不做什么"与数据来源两节必须由客户确认。
- 目标必须翻译成对象 × 动作 × 度量，基线拿不到的指标只是愿望。
- 对伪问题转化而非拒绝：成本换算、找症状背后的真病、最小实验；强硬坚持伪问题本身是重要的客户情报。
- 当场写下的量化基线，是几个月后续约谈判的全部弹药。