[返回企业 AI 落地实践]() 落地指南FDE 交付词元映射2026-10-23 # FDE 团队开发前如何摸清真实业务流程？ 面向企业内FDE交付团队与业务侧对接负责人，解决开发前置调研中常遇到的看不到真实操作、抓不准判断依据、调研结果无法匹配实际业务需求的问题，覆盖从现场观察到结论校验的全环节可落地实操方法。 ![放大镜对准一组业务单据与连接它们的流程线]() ## 本文回答 - 交付团队如何观察业务人员的真实操作？ - 如何发现流程中的外部资料和判断依据？ - 调研结论怎样让业务人员确认和纠正？ 面向企业内FDE交付团队与业务侧对接负责人，解决开发前置调研中常遇到的看不到真实操作、抓不准判断依据、调研结果无法匹配实际业务需求的问题，覆盖从现场观察到结论校验的全环节可落地实操方法。 下文引用的公开资料仅代表对应机构的实践做法，其余内容为项目实施建议，具体适用范围需由项目参与方共同约定。 ## 调研启动前的基础准备 执行角色为FDE团队指定的调研负责人，联合业务侧接口人共同推进，所需输入为业务部门初步需求说明与组织内部权限管理规则。Nielsen Norman Group的实地研究建议开展前确认已取得所需研究许可，避免因权限问题中断调研或引发合规风险[10]()。对应到FDE的工作模式，PagerDuty官方工程博客提到其FDE进入产品领域时会先学习贡献权限的分区图，业务调研阶段也需先明确可观察的业务环节、可记录的信息范围，划定清晰的调研边界[8]()。团队需提前准备统一的观察记录模板，模板包含场景描述、操作步骤、异常情况三个模块，方便后续整理归档。观察时段建议提前与业务侧约定，选在业务量适中的时间。太空闲时看不到完整流程，太繁忙时又容易干扰正常业务。若遇到权限无法覆盖的环节，及时调整调研范围，不强行介入未授权场景。 ## 自然情境下的流程观察方法 执行角色为FDE团队的调研人员，建议两人一组配合，一人专注观察，一人负责记录。输入为已确认的观察范围与业务岗位的日常排班信息。观察需遵循不干扰正常工作的原则，Nielsen Norman Group将观察不受打断的自然行为列为直接观察的核心目标，避免因提前通知或刻意引导导致业务人员操作变形[10]()。观察过程中不要随意提问，等业务人员完成当前操作后再提出疑问，避免打断操作节奏。需关注业务人员的完整操作链路，包括系统切换、临时调整、停顿犹豫的节点，不要仅记录正式制度中列明的步骤。还要记录业务人员之间的协作交互，比如跨岗位的信息传递方式、交接的内容，这些都是正式流程中容易遗漏的部分。对于重复出现的操作，要多观察几次，确认是常态操作还是偶然情况，避免把个案当成通用流程。PagerDuty官方工程博客称其FDE团队会尽早介入需求信号评估可行性和业务影响，调研阶段越早介入，越能捕捉到业务常态下的真实操作[8]()。若观察当天遇到业务紧急事项，需主动改期，不占用业务人员的处理时间。观察结束后形成分岗位的操作记录，每条记录对应具体的业务场景，不使用抽象的流程术语。 ## 隐性判断依据的挖掘与梳理 执行角色为FDE调研人员，与对应岗位的业务人员开展一对一情境访谈，访谈尽量在工作岗位旁进行，结合实时操作提问。输入为前期观察记录中标记的决策节点与疑问点。Nielsen Norman Group建议情境访谈时留意用户正在使用的外部资源，很多业务判断的依据来自两类资料，一类是正式制度文件，另一类是散落的临时文档、岗位传承的表格、外部政策文件甚至桌面便签[9]()。访谈时可以请业务人员演示一次完整的决策过程，边操作边讲解参考的资料和判断的理由，比单纯口述更准确。需针对每个决策节点询问参考依据，记录资料的存放位置、更新频率与适用场景，同时梳理判断的内在逻辑，理解资料如何支撑具体决策。Nielsen Norman Group将用户活动的内在结构列为情境访谈的重要理解内容，避免只记录资料名称而忽略使用逻辑[9]()。还要区分长期有效的依据和临时生效的依据，对阶段性的政策要求或临时规则，要标记有效期限，避免后续开发时误用。对于需要外部系统查询的数据，要记录查询路径和权限要求，明确这些数据是否可以通过API获取，为后续技术方案提供参考。若业务人员无法清晰表述判断依据，可邀请该岗位的资深人员共同梳理，不凭调研人员的主观推断填充内容。最终形成流程判断依据清单，与操作步骤逐一对应。 ## 调研结论的校验与对齐机制 执行角色为FDE调研负责人，联合业务侧各岗位代表与业务主管共同参与校验。输入为整理完成的操作记录、判断依据清单与流程初稿。校验采用走查的方式开展，不要直接发送文档让业务人员自行核对。Nielsen Norman Group建议让用户确认或纠正研究者的理解，调研人员需逐环节描述观察到的操作与判断逻辑，由业务人员当场指出偏差或补充细节[9]()。走查时可以搭配场景模拟的方式，设定几个常见的业务场景，让业务人员判断流程描述是否符合实际处理逻辑。校验过程中需按岗位拆分确认环节，让不同岗位的人员分别核对自己负责的流程段，避免跨岗位的认知偏差。对于有争议的环节，可以当场请资深业务人员演示实际操作，及时修正流程文档。若不同岗位人员对同一流程的描述存在差异，需提交业务主管明确统一的标准，FDE团队不自行裁定业务规则。PagerDuty官方工程博客提到嵌入产品团队的工程师会学习对方的协作规范和编码标准，FDE团队在调研阶段同步熟悉业务侧的沟通与决策规则，能提升结论校验的效率，减少反复沟通的成本[8]()。校验完成后，要把修改后的文档同步给所有参与校验的人员，留足缓冲时间供大家补充意见。最终形成经双方确认的业务流程文档，作为后续开发的基础依据。 ## 调研完成后的核对清单 调研结束后可对照以下条目逐一核对，确认调研成果的有效性与可用性 - 确认所有观察环节均已取得对应权限 - 确认每个操作节点都匹配对应的判断依据 - 确认各岗位代表已核对并认可自身负责的流程段 - 确认业务主管已协调统一不同岗位的认知分歧 - 确认最终流程文档已由业务侧接口人签字确认 - 确认未记录任何超出授权范围的敏感信息 ## 参考来源 - [PagerDuty · From Embedded to Everywhere: How Forward Deployed Engineering Was Born at PagerDuty]() - [Nielsen Norman Group · Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context]() - [Nielsen Norman Group · Field Studies]() ## 继续阅读指南 [全部指南]() - [!\[图片\]() ### 嵌入式交付团队如何演示试点并收集业务反馈？ 面向嵌入式交付团队的业务与交付负责人，本文聚焦AI及软件项目试点演示中常见的脱离实际业务、反馈零散难落地等问题，提供可落地的演示组织与反馈处理方法，支撑试点高效迭代。 阅读指南]() - [!\[图片\]() ### 嵌入式交付团队如何处理业务需求变更？ 本文面向嵌入式交付团队的业务负责人与交付主管，针对项目推进中业务需求中途增减、范围临时调整等常见协作痛点，给出需求登记、影响评估及计划重排确认的具体可操作方法。 阅读指南]() - [!\[图片\]() ### 嵌入式交付团队如何把试点交给客户运营？ 本文面向嵌入式交付团队与客户运营负责人，聚焦AI试点从交付阶段转入客户自主运营的衔接环节，梳理责任划分、材料准备与接管验证的实操方法，降低移交后的运营断层与协作摩擦风险。 阅读指南]()