运营FDE手记③：基金公司已有IT，为什么还要讨论FDE

运营FDE手记 · 03

一个渠道催着上线产品，销售说费用折扣已经确认，运营拿到的材料却没有写清适用范围和结束日期，根据模糊的邮件表述，确定了产品清单，并根据邮件日期确定了生效。IT按照收到的参数申请完成配置，结果最后实际使用的时候，又发现与最新约定不一致，只好退回修改。每个人都推进了自己的任务，但实际上仍然反复返工。

基金公司已有IT，为什么还要讨论FDE？

很多人会把FDE归到IT或者运营或者单独设置一个团队，就结束了。实质上，本质设置FDE需要解决的，是有人把业务问题的调查、工具实现和实际使用持续接在一起。IT是团队或职能的称呼，FDE在这里首先是一种工作方式，两者并不冲突，也不完全重叠。

如果现有团队已经直接参与需求形成、完成工程实现，并持续跟进使用效果，就未必需要另设岗位。若工程人员总在需求传递几轮后才介入，上线后又无人继续改进，就有必要检验这种协作能否调整。

运营人员也可以参与承担这项工作：查清材料与处理依据，提出可验证的要求，与工程人员一起试用和修正工具。具体怎样配合，要看业务复杂度和已有能力。

以下仍用渠道折扣上线作示意，看一次参数变更怎样从「已经沟通过」走到「实际生效正确」，以及FDE式参与在哪一步能够产生价值。

先判断返工是怎样产生的

先复盘一项近期上线任务的各个节点，等待协议、内部审批、设置参数和重新测试分别用了多少时间，每次退回是缺材料、含义不一致，还是实现错误。不同原因不能都归到“沟通不够”。

如果规则已明确，只是系统功能不足或者新功能开发排期不足，应处理IT资源与优先级；如果常常是协议审批或者协议流程的不匹配，那就是销售或者产品的相关责任人推进。增加一个FDE的人，并不能解决这些问题。

在这个例子中，值得改进的是同一项折扣设置的参数，经过多次转述后，关键信息才逐步补齐。运营说的“按XXX执行”，还不能直接成为系统参数。甚至会因为流程判断的问题，误增加了新的信息。工程人员若能更早参与核查，就有机会在配置前发现缺项。

因此，试点要改变一个具体安排，就是让负责实现的人参加材料核对，并跟到首轮实际使用。给他业务接触和修改工具的时间，再观察是否减少了澄清与返工。

从一句折扣约定核对到实际参数

从刚刚说的具体例子来看，渠道说「折扣已经确认」，后台运营需要的却是渠道和产品标识、费项、适用对象、折扣含义、起止条件及有效依据。合规则需要关注合同签署时间、系统参数生效时间，以及相关材料记录、系统操作记录的匹配性。

以折扣结束日期变更为例，新要求可能已经进入销售部门的文件，原参数却没有更新。相关审批流程已经完成，但公告还没有披露。过去由于每个部门的工作触发条件比较固定（或者更加随机），比如有的部门会认为必须进行公告后才能进行后续执行，而有的部门会认为，只要经过了审批，相关的说明就可以生效。

这种流程环节的衔接存在不确定性和不一致性。过往尤其在任务紧急时，很容易造成疏漏，导致后续内控审查不合规。

一个具体的改进是，将协议或确认记录、参数申请、实际设置和测试结果关联到同一项任务，不同工作流可以对齐。

FDE可以参与确定这些关联，再实现数据读取、差异检查和处理界面。AI帮助提取要求，整理流程过程中的 Gap，并对Gap的可接受性生成不同方案，例如，与法规进行比较，列出可接受的、符合内控合规要求的、连贯的流程，完成流程的串联。

这种交付超过维护一张进度表，但也不意味着包办所有工作。业务决定由谁作出，系统改动由谁负责，上线条件由谁确认，仍然需要在实现之前说清楚。

基金公司怎样分工

职责问题……这项工作由谁承担

这里新增的工作量，不止是把任务催到完成，还包括阅读业务材料、做出检查工具、验证结果并处理试用反馈。它可以由具备业务理解的工程人员承担，也可以由运营与工程人员共同完成。

项目经理可以协调目标、依赖和进度；承担FDE工作的人员还需要把检查逻辑实际做出来，并根据使用问题修改实现。

在AI的帮助下，项目经理和FDE一个人可以兼任，但要明确哪些工程工作由谁完成，以及未来实际使用和推进的角色。

运营的优势是理解材料、例外和业务后果，工程人员的优势是把要求变成可运行、可测试的工具。双方一起核查一次真实任务，比把一份更长的需求文档交给下一部门，更容易暴露尚未说清的条件。

围绕这项试点，可以沿用现有部门职责，只把具体交付和确认责任说明白：

参与方

需要负责的内容

渠道及相关业务负责人

确认商业要求、依据和适用范围，处理业务争议

FDE或应用工程人员

梳理关联，完成实现、测试并跟进使用问题

参数及系统负责人

按确认要求配置，反馈实际值，支持系统变更

IT平台与信息安全人员

提供运行和访问支持，明确模型、数据及日志要求

用一次完整上线培养能力

IT人员参与这类工作，需要从业务结果反问条件：用户为什么检查这个日期，错了会影响哪笔业务？运营人员则要学习把判断写成输入、处理和预期结果，并用正常情况与反例一起验证。

AI可以协助整理材料和编写代码，但团队仍需要能够理解、测试和维护实现的人。工具生成成功之后，还要有人解释检查为何成立，出了问题怎样定位和修改。

可以先由一位熟悉业务的运营人员与一位应用工程人员配对，完成从材料核对到首轮使用的全过程。试点结束后，留下对照表、检查程序、已确认规则和维护安排，供下一次上线继续使用。

是否值得继续

试点需要明确投入时间，以及哪些原任务因此调整。业务负责人确定优先级，IT负责人安排实现与运行支持；跨部门冲突要有协调人，不能让参与者在原工作量之外无限接需求。

评价时，比较澄清次数、返工原因、上线后参数差异及维护耗时。样本少时先记录事实，不急着宣称效率提高多少。

其实很多的优化场景是，少了几轮传话，却新增大量人工维护，这个在企业数据化的时候非常常见，通过设置专岗承担综合性兜底工作，这也不是一个理想的状态。

理想的状态还是让原有节点能够有更清晰的边界和流程，通过确定共用的数据访问、权限、测试和发布支持，让下一项业务改进不必重新解决这些基础问题。哪些条件由业务确认、哪些工具可以复用，则在具体项目中逐步积累。

已有IT的基金公司，仍然值得讨论FDE，因为参与业务和负责实现之间可能存在断点。

先用一次上线证明这种持续参与有用，再决定把能力留在现有岗位、形成固定搭档，还是设置专门角色。岗位名称应跟随已经验证的工作需要。

作者：栗加

每个视角都是拼凑世界真相的碎片，听真诚的行业观察者讲述独特的故事。我们有深耕行业的资深顾问，连续跨界探索的未来创业者，专注细节的产品匠人，和许多志同道合的你们，如果你有想要分享的故事或者感想，可以留言或者邮件联系（AiysJY@outlook.com），也欢迎点分享给需要的朋友们，记得点一下在看和星标，期待共同在这个行业的宏大叙事中，留下一句诗。：）