周一:客户现场启动会
FDE 的周一上午基本在客户现场开 kickoff 会议。9 点到场,会议室里有客户的业务负责人、IT 总监、数据团队 leader、合规官、还有 1-2 个最终用户。会议目的是把”我们要做什么”重新对齐一次:上次会议的销售讲的是产品故事,这次会议 FDE 要把故事拆成可执行的 12 周计划。
上午剩下的时间用来写会议纪要、确认数据源清单、约下周的接入会议。中午和客户业务方吃工作餐,顺便问一些”上次没问到”的问题——比如”这个部门老大真实的想法是什么”、”IT 那边有没有反对者”。这些信息 PPT 上不会有,但决定项目能不能成。
周二到周四:写代码 + 调环境
典型的 FDE 一周有 3 天在写代码。代码不是产品的核心代码,而是客户定制层:把客户的数据源接入、调整 UI 文案为客户业务术语、写部署脚本对接客户 CI/CD。
写代码之外,大量时间在”调环境”:客户的 IAM 怎么配、网络代理怎么绕、Kafka topic 在哪个 vlan 里。FDE 经常需要学一个新工具(客户的某个内部系统)才能继续工作,学习能力比任何特定技能都重要。
周五:汇报 + 内部同步
周五分两部分:上午给客户写周报,总结本周进展、下周计划、风险点;下午开内部会,和产品经理过客户反馈、和销售过商业进展、和客户成功过续约信号。
FDE 的周五下午是”信息汇聚点”——客户的所有信号在 FDE 这里汇总,所以内部团队对 FDE 的周报依赖度很高。一份写得好的周报能让销售提前半年预知续约,写得差的周报让产品误判需求优先级。
不典型的一天:oncall
客户上线后,FDE 通常要承担前 3 个月的 oncall。Oncall 不是简单看监控:
- 客户的监控体系可能和你们不一样,需要自己适配告警。
- 客户的运维流程可能要求走工单,凌晨 3 点的故障要按 ITIL 流程填表。
- 客户的 oncall 工程师可能根本不懂这套系统,你要手把手教他们怎么响应。
这是 FDE 最被低估的部分。一个 FDE 的”产出”看起来是写代码、做演示,真正决定客户留存的是上线头三个月怎么和客户一起扛过故障。
不典型的一天:客户政治
在大客户场景,政治消耗的时间不亚于写代码。常见场景:
- IT 部门和业务部门意见不一致,FDE 被夹在中间。
- 合规官突然要求加一道数据脱敏,FDE 要重新设计架构。
- 客户的中层管理者借项目刷存在感,FDE 要应付突然增加的需求。
这些场景没写在 JD 里,但 FDE 一周会遇到 2-3 次。处理客户政治没有标准答案,但有几条经验:
- 永远书面化:口头承诺都不可靠,所有决策发邮件,抄送关键 stakeholder。
- 找真正的 sponsor:不是出钱的人,是项目成败对他影响最大的人。
- 不要绕开 IT:IT 是最容易被忽视但最有否决权的部门,提前 4 周对齐。
FDE 一周的时间分配
成熟的 FDE 一周时间分布大致是:
- 30% 客户现场(开会、演示、oncall)
- 30% 写代码(集成、定制、调试)
- 20% 跨团队沟通(销售、产品、客户内部)
- 10% 出差和通勤
- 10% 自我提升(学客户业务、读新文档、写内部 wiki)
如果你的 FDE 一周有 60% 在写代码,说明要么项目太技术、要么客户太自助,可能不需要 FDE;如果一周有 60% 在开会,说明要么项目太政治化、要么 FDE 没有自主权,需要重新对齐。
FDE 的”反直觉”经验
- 出差不是负担:FDE 平均出差 30-50%,但好的 FDE 反而喜欢——线下建立的信任是线上 10 倍。
- 写代码不是核心能力:写代码的比重随经验上升而下降,L7 FDE 一周可能只写 5 小时代码,其余都在”让项目顺利推进”。
- 客户投诉是好事:敢当面抱怨的客户是最可能续约的;沉默的客户才是危险信号。
