尾声
尾声
老兵带走什么,又该放下什么
企业数字化老兵进入 FDE 时代,哪些经验仍是资产,哪些项目惯性必须放下?尾声回到责任、判断与长期主义。
打开全书目录
- 序章 · 第四次听见“这次不一样”
- 第 1 章 · 先把发生过的事记下来:数据库与 ERP
- 第 2 章 · 企业第一次想看见自己:数据仓库与 BI
- 第 3 章 · 从一张报表到一套能力:大数据与数据中台
- 第 4 章 · 报表做完了,为什么没人行动
- 第 5 章 · 三百页需求文档,为什么仍然不是需求
- 第 6 章 · 定制化的诱惑,项目制的账
- 第 7 章 · 当软件开始采取行动
- 第 8 章 · 不是新名字,而是旧角色在前线汇合
- 第 9 章 · 真正改变的是交付契约
- 第 10 章 · 从表和指标,到对象、状态与动作
- 第 11 章 · 从数据治理,到行动治理
- 第 12 章 · 中国式 FDE:既要打桩,也要装修
- 尾声 · 老兵带走什么,又该放下什么
写到最后,FDE 这个缩写反倒没那么重要了。
它可能继续成为一种职位,也可能被解决方案架构师、交付工程师、AI 产品经理或一支跨职能小队吸收。公司会换名字,岗位会换边界,今天热门的工具也会很快过时。
留下来的,是一个越来越难回避的问题:做企业数字化的人,责任到底停在哪里?
如果停在数据入库,报表有没有人用不归你管;如果停在系统上线,流程是否改变不归你管;如果停在模型输出,后面的动作是否安全也不归你管。
每一道边界都有现实理由。没有人能对企业经营的全部结果负责。
可边界切得太干净,客户拿到的就会是一串各自成功、合起来没用的交付物。
老兵可以带走的东西
经历过数据库、ERP、数据仓库、BI 和数据平台的人,不必因为不会背最新模型参数而焦虑。
旧经验里有几样东西很难速成。
第一,是对口径的警觉。
同一个收入、客户、库存或完成状态,在不同部门嘴里可能不是同一件事。老兵见过数字对得上、含义却错了,也见过一场会议花掉两小时,只为确认报表里的“客户数”究竟怎么算。
第二,是对例外的尊重。
流程图总是比现场干净。真正的企业靠补单、特批、线下确认和老师傅判断维持运转。例外不一定都合理,却不能因为模型看不见就假装不存在。
第三,是生产意识。
演示成功和每天稳定运行之间,隔着权限、并发、脏数据、上下游故障、用户习惯和责任追踪。踩过这些坑的人,知道“能跑”只是开始。
第四,是对组织惯性的耐心。
技术可以一周升级,岗位分工、考核方式和部门利益不会。很多项目不是没有正确答案,而是没人有权把答案变成动作。
还有一句已经付过学费的常识:上线不等于成功。
这些东西不会因为 AI 出现而贬值。相反,软件开始采取行动以后,口径、例外、生产和组织的代价都变大了。
也有些东西不该再带着
经验会保护人,也会困住人。
第一件该放下的,是技术完整性高于业务价值。
平台架构很漂亮、模型很统一、治理制度很全面,不代表一个具体问题已经解决。如果最小范围的部署还没有证明有人愿意用,就不该用未来的宏大收益替今天的成本辩护。
第二件,是先建大平台,再等业务来用。
共性能力当然重要,但共性不是会议里设计出来的。它要经过几个真实场景反复碰撞,才知道哪些真的相同。
第三件,是把需求文档当作业务本身。
文档记录的是某些人在某个时刻能够说清楚的部分。没有跟着实际工作走一遍,就不知道那些“看情况”里藏着什么判断。
第四件,是把验收当作责任终点。
合同需要终点,团队也需要结项。可对产品和职业判断来说,用户是否采用、工作是否改变、经验是否沉淀,仍然要被看见。
最后还要放下一种资格感:做了很多年数据,才配谈真正的 FDE。
旧经验提供的是一张坑位图,不是一张入场券。资历不能替代现场理解,更不能替代结果。
刚上路的人不欠一段历史
没有亲手做过 ERP 实施,也不妨碍一个年轻工程师成为优秀的 FDE。
新工具让原型变得很快。过去需要几周搭起来的界面和流程,现在几天甚至几小时就能看见。这是一种真实优势:想法可以更早接受用户检验。
但快也会制造错觉。
能从文档生成应用,不等于理解了业务;能让 Agent 调用工具,不等于知道它该拥有什么权限;能在演示中完成任务,不等于它在生产环境里值得信任。
年轻人的功课不是补齐一部技术编年史,而是学会问那些旧问题:数据从哪来,词语由谁定义,例外怎么处理,动作影响谁,失败能否撤回,价值由什么证明。
没踩过旧坑不是缺点。不知道坑在哪里,才容易把速度用错方向。
不必再等下一次“这次不一样”
序章里,我们从几次熟悉的承诺出发。
ERP 希望把业务写进统一流程,BI 希望让企业看见自己,数据平台希望把分散能力沉淀和复用。它们都解决了真实问题,也都留下了未完成的部分。
AI 确实带来了一道断裂。过去的软件更多记录和展示,今天的软件开始用不完整的信息生成判断、调用工具并影响现实。这让行动、风险和责任同时进入交付中心。
可这并没有取消旧问题。
对象仍然要定义,数据仍然会脏,组织仍然有边界,用户仍然可能不用,商业价值仍然需要计算。模型能力越强,绕开这些问题的诱惑越大,出错后的代价也越高。
因此,FDE 不值得被神化成英雄角色。
它更像一个信号:企业软件的交付边界正在往前走。有人必须站在技术、业务和现场之间,把问题定义、原型、生产、采用与反馈接起来;也必须在不值得做、不能自动做的时候停下来。
这项工作不会由一个人包办。业务负责人要承担业务判断,安全与合规人员要守住边界,产品团队要吸收共性,管理者要改变激励。FDE 所能做的,是让这些原本分散的责任不再轻易掉进交接缝隙。
走过三十年,我们已经很会让企业“看见”。下一程难的,是让看见之后发生变化,又不假装变化没有代价。
FDE 不是数据人的下一份工作,而是企业数字化终于被迫为“从看见问题到解决问题”承担完整责任的那个时刻。
尾声资料
- OpenAI:Forward Deployed Engineer 职位说明
- Palantir:Forward Deployed Software Engineer 的工作现场
- NIST:AI Risk Management Framework
写作说明:尾声总结全书判断,不以作者资历作为观点成立的证据。
本页与 GitHub 上的章节 Markdown 同步。欢迎提交勘误。