现场项目最危险的偏差,往往不是技术实现出了故障,而是团队从一开始就接受了未经验证的问题描述。FDE 进场后需要沿着真实数据和业务流程建立事实基础,再通过一线、中层与高层的交叉访谈识别约束,最终把问题、边界、基线和验收标准落成可确认的文档。
本章导读:FDE 最大的浪费不是写出有 bug 的代码,而是漂亮地解决了一个错误的问题。本章讲怎么在进场早期把问题找对:进场第一周怎么做、怎么分辨真问题与伪问题、怎么用一份问题定义文档把共识钉死、怎么把模糊的"提升效率"翻译成可测量的成功标准。本章的产出物(问题定义文档)是后续所有章节的地基。

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