结论：FDE 团队不是按人头堆出来的驻场班组，而是覆盖业务发现、场景定义、应用构建、生产接入、评测治理、运营扩展六项职责的最小可运行配置，人数随并行场景数增加，而不是随企业规模增加。
通常 2 到 3 人。一个人负责业务发现与场景定义，一个人负责应用构建与生产接入，评测治理由两人共担，或引入企业侧评审人补位。人数跟着并行场景数涨，不跟着企业规模涨：同时推进一个场景，两人足够；同时推进三个以上互不相关的场景，两人就会变成串行瓶颈。
| 并行场景数 | 典型配置 | 瓶颈信号 |
|---|---|---|
| 1 个 | 业务发现 + 工程构建 各 1 人 | 需求单排队超过一周 |
| 2 个 | 2 至 3 人，评测治理共担 | 两边都要改同一套接口 |
| 3 个以上 | 拆成两个小组，各自独立收尾 | 同一人同时出现在三个评审会 |
如果企业把 FDE 当驻场人力用，按人头下单、按工时结算，团队会退化成需求承接方：只对交付物负责，不对采用结果负责。判断标准很简单，看这个人是否为场景上线后的使用效果负责。
企业侧要配三类角色，且必须是能直接拍板的人：一名业务负责人决定场景优先级与验收标准，一名数据与系统对接人负责开放接口和账号，一名流程与合规审核人把关数据范围。这三类角色不能由一个人兼任，也不建议由 IT 部门代为指定。
最常见的一种失败是把这三件事全交给一个信息部门同事兼职。结果每次接口申请都要走一次跨部门沟通,单个场景的周期从三周拖到三个月,而问题不在技术。
售前调研的目的是判断值不值得签单，结论是一份方案；业务发现的目的是判断这个工作能不能从头做到尾，结论是一份可执行的场景定义。前者可以停在文档，后者必须落到数据来源、判断规则和责任人，否则后面的构建无法开始。
| 对比项 | 售前调研 | 业务发现 |
|---|---|---|
| 核心问题 | 这个客户会不会买 | 这个工作能不能从头做到尾 |
| 产出物 | 方案与报价 | 场景定义、数据清单、验收口径 |
| 谁来确认 | 客户决策层 | 业务负责人 + 系统对接人 |
| 结束条件 | 客户认可方案 | 评测样本同意并可复核 |
如果一家服务商的业务发现只输出 PPT 和功能清单，没有数据清单、没有判断规则、没有评测口径，那本质上还是售前。这时候进入构建阶段，返工几乎是必然的。
因为评测样本代表的是企业自己的业务判断标准。FDE 可以提供评测集的结构与工具，但哪些样本算正确、错误能容忍到什么程度，必须由企业业务方确认。全部交给外部团队，就会出现指标很好看、实际没人用的情况。
评测集在项目结束后应当作为资产移交给企业。如果它只存在于服务商的项目目录里，后续业务变化时没有人能重新跑一遍回归，这个场景会随时间失效。
按阶段定节奏，不按天定工时。以深云 FDE 模式为例，交付分为找准问题、验证闭环、生产上线、采用复制四个阶段，每个阶段有独立结束条件：前一阶段的条件没达成就不进入下一阶段，避免把问题带到生产环境。
| 阶段 | 结束条件 | 不做会怎样 |
|---|---|---|
| 找准问题 | 场景能跑通、数据可得、责任人有名有姓 | 构建到一半发现数据拿不到 |
| 验证闭环 | 评测样本通过、badcase 有处理方案 | 演示成功但上线后不敢用 |
| 生产上线 | 灰度范围与停止线已定义 | 出问题只能全量回滚 |
| 采用复制 | 使用率、资产、运维完成移交 | 项目结束即开始衰减 |
驻场天数是结果，不是目标。如果合同按人天锁定总工时，双方都会倾向于把时间填满而不是把阶段结束，最终成本更高。
挂业务侧，落地的概率更高；挂技术侧，构建效率更高。判断依据是当前瓶颈在哪：卡在场景选择与使用推动，就挂业务；卡在系统对接与生产运维，就挂技术。两边都不占优时，设一个跨部门虚拟小组，由业务负责人定优先级、技术负责人定标准，FDE 只对这两件事交付。
汇报线调整会带来一次交接成本：原部门的历史资料、账号与环境要重新授权，短则两周，长则一个月。已经在跑的场景不建议中途换线，等这一轮上线验收结束再动，否则两边的判断标准会同时失效。
不重复，但职责必须切干净，否则会出现两个人在同一件事上给不同结论。FDE 对「这个场景能不能跑通并交回业务」负责，项目经理对资源与进度负责，实施顾问对配置与操作负责。判断有没有重复，看三份产出物是否各自独立：场景定义、进度计划、配置清单。
| 角色 | 对什么负责 | 交付物 | 什么时候不需要 |
|---|---|---|---|
| FDE | 场景能否跑通、上线后是否被使用 | 场景定义、评测口径、采用报告 | 场景稳定运行、只剩日常运维时 |
| 项目经理 | 资源、进度、跨部门协同 | 排期、风险清单、验收纪要 | 单场景且两周内可完成时可由 FDE 兼 |
| 实施顾问 | 配置正确、操作可复现 | 配置清单、操作手册、培训材料 | 纯定制开发、没有平台配置项时 |
小项目里让 FDE 兼项目经理是常见做法，代价是进度风险没人跟。判断能否兼，看并行场景是否超过一个：超过一个就必须有人专职盯排期，否则两边的延期会互相掩盖，直到验收前才暴露。
从交付团队缩到运营小组，通常留 1 人，或按每 3 至 5 个在用场景配 1 人。判断依据不是项目结束，而是三件事是否已经移交：评测集能自己跑、异常有明确处理人、新场景由业务方提。三件事没移交，人一撤，使用率通常在两三个月内明显下滑。
如果企业侧始终没有人接这三样东西，缩编等于把项目停掉，只是延后几个月才显现。这种情况下更划算的做法是保留 1 人做运营与答疑，而不是彻底撤出后重新立项，重新立项的启动成本通常高于养一个人的成本。
本文的角色划分与阶段定义依据深云 FDE 模式公开说明整理，不涉及具体项目报价与客户信息；团队人数为通用判断依据，实际配置需按场景数量与企业配合程度调整。
深云可以按场景先做一次闭环判断，输出角色配置、阶段划分与验收口径，再决定投入规模。
了解深云 FDE 服务