第 5 章 · 三百页需求文档，为什么仍然不是需求

需求调研最容易出现的一句话是：

“我们现在就是手工做，你照这个流程自动化就行。”

听上去很清楚。

真坐到操作人员旁边，事情会变成另一副样子。

他先打开系统查订单，又翻到共享盘找上个月的表，看到某种客户名就去聊天记录里搜一句旧通知。遇到金额对不上，他不会立刻报错，而是凭经验判断可能是哪一类历史问题。实在拿不准，再问隔壁那位干了八年的同事。

你问，这一步为什么这样处理？

他说，一直都这样。

你再问，什么情况下不能这样？

他想了一会儿，说，那要看情况。

项目的入口，往往就藏在“看情况”三个字里。

人会做，不代表人能讲清楚

很多工作是熟练以后才做得快。

熟练的代价是，操作者不再逐步意识到自己在判断什么。他看到一个字段、一个客户名或一句备注，脑子里已经完成了分类。让他当场把规则完整说出来，反而很难。

这不是用户不配合，也不是业务人员逻辑差。

一个人每天处理几十次例外，很多知识会变成手感。系统文档只记录正常流程，例外留在人的记忆里。新人学不会时，老师傅带着做几次；等新人也变成老师傅，规则还是没有写下来。

会议室里的需求访谈，最容易拿到的是“应该怎么做”。

现场能看到的，才是“实际怎么做”。

两者不一样，不一定是谁在撒谎。正式流程代表组织希望工作如何发生，现场动作代表人在时间、数据和权限都不完美时如何把事情办完。

FDE 若只听前一种，就会做出一套演示很顺、上线就卡的系统。

需求在传递中会换几次样子

老板说，希望提高回款效率。

业务负责人把它翻译成应收账款预警。

IT 部门再翻译成一个看板和消息提醒。

供应商拿到的需求，变成若干字段、页面和接口。

每一层翻译都没有明显错误，最后交付的东西却可能离老板最初关心的问题很远。

老板要的是钱早点回来，业务负责人想到的是哪些账逾期，IT 想到的是如何展示，供应商负责的是按时上线。至于提醒以后谁催、客户为什么不付、争议怎么处理，并没有自然落到任何一方。

需求文档可以写得很厚，因为页面、字段、权限和流程都能展开。最难写的那一页却经常缺席：

什么结果发生，才算这个问题被解决？

如果没有这一页，文档越完整，越可能让团队高效地交付一个方向不明的东西。

先看一整天，再谈要做什么

FDE 方法里有一种很朴素的做法：先跟着真实用户工作。

不急着问他想要什么功能，先看一天怎么过。什么任务最耗时，哪些步骤反复切系统，哪里需要等别人回复，什么异常必须请老师傅出手，哪些规则嘴上说得简单，一碰真实数据就例外百出。

Palantir 对前线部署工程师的描述强调，他们嵌入客户环境，用现有平台解决客户问题，还要处理生产故障、部署修复并与客户和产品团队协调。这里的“前线”不是地理位置，而是离工作发生的地方足够近。

近到可以看到需求文档里没有的部分。

这与传统业务分析并非完全不同。优秀的实施顾问、流程顾问和系统分析师早就在这样做。FDE 没有发明现场观察，它只是让这件旧工作在 AI 时代重新变得不能省。

原因很简单：过去漏掉一条例外，可能由操作人员手工补救；现在若让 Agent 自动处理，漏掉的例外会被批量执行。

不要把坏流程自动化得更快

现场观察还有一个容易被忽略的作用：判断这项工作是否值得自动化。

客户说每天要把 A 系统的数据复制到 B 系统，团队最直接的反应是做一个机器人。可继续问下去，可能发现 B 系统里的字段根本没人使用，只是五年前某次检查留下的要求。

把复制动作自动化，当然能省时间。

更好的答案可能是删掉它。

企业里的流程会像旧代码一样积累。制度改过，表格没删；系统换过，审批还保留；某次事故加了一道检查，三年后没人记得它防什么。

FDE 如果按用户现有动作逐步复刻，很容易把历史包袱做成更快、更贵的新系统。

所以现场不是只看“人怎么干”，还要追问：

这一步在防什么风险？
如果不做，会发生什么？
谁使用它的结果？
有没有更靠前的地方可以消掉问题？
这是稳定规则，还是某个人的临时习惯？

有些答案适合写进系统，有些应该先推动业务改流程。

原型不是为了让客户点头

需求很难一次说清，原型因此有价值。

但原型有两种用法。

一种是证明技术能做。准备一批干净数据，跑出漂亮结果，客户看完说“就是这个”。这种原型适合展示方向，却很容易把项目送进概念验证坟墓：大家都认可，没人知道下一步怎样进入真实工作。

另一种原型是逼问题暴露。

用接近真实的脏数据，让用户亲手操作；把正常流程和最麻烦的例外一起放进去；事先约定一个业务指标和裁判。原型做完以后，团队不只知道模型能不能跑，还知道哪里需要人工、哪些权限不能放、什么错误无法接受。

Palantir 公开的 AIP 工作流也会明确提醒：示例使用的是假设数据，要部署成真实业务流程，必须换成组织自己的数据。这句看似普通的话，恰好划出了演示和生产之间那条线。

原型的价值不是让客户更快点头，而是让双方更早发现自己原来没想清楚。

需求不是一句话，是一组选择

写到这里，再回头看那句“照现有流程自动化就行”，就会发现它什么都没决定。

哪些步骤保持不变，哪些应该删除？正常情况自动做，例外由谁接手？速度、准确率和风险怎么取舍？系统给建议，还是可以直接执行？如果业务规则改变，由谁更新？

每一个答案都在决定产品长什么样，也在决定责任落到谁身上。

FDE 的价值，不是比别人更会“挖需求”。这个词听上去像需求早就埋在那里，只等聪明人把它挖出来。

现实更像共同建造。客户带来业务经验，工程师带来技术边界，双方通过现场、数据和原型，一起决定什么问题值得解决，以及怎样才算解决。

这也意味着，并非所有客户说出的需求都应该接。

可一旦开始拒绝需求，另一个矛盾就来了：供应商靠项目和人天挣钱，客户愿意为定制付费。大家都知道定制太多会拖垮产品，眼前的合同却是真金白银。

下一章，我们来算这笔账。

本章资料

场景说明：本章操作员、回款与系统搬运场景为复合示例；不将其表述为作者在某个具体客户处的亲历。