为什么 90 天必须刻意设计
普通工程师的入职只有一层：适应新公司的代码库和同事。FDE 的入职有两层：一边熟悉自家的产品和组织，一边还要适应所负责客户的系统与人。两个陌生环境叠在一起，如果不带计划走进去，三个月过去，你会发现自己在哪一边都没扎下根。
所以第一个季度应该被设计，而不是被动漂过。下面这套 90 天框架并非照搬某家公司的制度，而是从 FDE 职位结构中归纳出来的构建。骨架分三段：第一个月摸清，第二个月独立接单，第三个月主导任务。把每个月的目标固定成一句话，每周的清单自然就长出来了。
铺在底下的原理是信任账户。在客户现场，FDE 的话语权不来自头衔，而来自攒下的信任；而信任不是靠一次大成果，而是靠守住小承诺的重复来累积的。设计这 90 天的目的不是华丽登场，而是让这个账户开户即不透支。反过来，第一个月留下的坏印象，会在余下的整个任期里持续计息。下面清单里的每一项，归根到底都是往这个账户里存钱的动作。
第一个月 — 摸清环境、产品和人
第一个月的目标不是成果，而是地图。这张地图画得多准，决定后两个月能跑多快。
- 第 1 周 — 权限总盘点。VPN、SSO、代码仓库、工单系统、进入客户环境的通道，一个账号一个账号地确认，把不能用的列成清单去申请。只靠文档把自家产品从零装一遍——你被卡住的地方，就是客户被卡住的地方。
- 第 2 周 — 客户环境的技术地图。亲手把客户的系统架构画成图，读一遍部署路径和最近三份故障记录。画不出来的部分就是你的问题清单。
- 第 3 周 — 人的地图。分清客户那边谁拍板、谁真正在用产品、谁会成为帮你的内部支持者，同时整理自家这边的升级路径。这个阶段参加会议以旁听为主。
- 第 4 周 — 工单影子学习。从头到尾观察前辈处理工单的全过程，把现存的运行手册编成目录，用客户的缩写和行话编一本术语表。
第一个月的陷阱是心急。为了尽快露一手而跳过画地图，第二个月抢出来的速度会在第三个月变成事故还回来。
第二个月 — 独立处理工单
第二个月的目标是给信任账户存入第一笔钱。完整性比规模重要。
- 第 5、6 周 — 独立接低风险工单。完整记录处理过程，在主管抄送在场的前提下亲自负责客户沟通。约定的时间点有没有发出中间进展，比解决得快不快更重要。
- 第 7、8 周 — 把工单难度上调一档，以副手身份参与故障响应。从处理过的工单里挑一个，写一份防复发提案。这份文档常常就是你的第一个速赢。
这个月的陷阱是贪快。信任来自沟通的规律性，而不是解决的速度。提前预告过的延迟不会消耗信任；毫无音讯之后突然送达的完成报告，反而留下不安。
第三个月 — 主导一个任务
第三个月的目标是把一件小事从头到尾主导一遍。
- 第 9、10 周 — 挑一个两周体量的项目来主导，比如一次集成或一次迁移。开工前把成功标准写成文档，与客户达成一致。没有标准文档就开工的项目，做完了也说不清算不算做完。
- 第 11、12 周 — 执行，然后留下复盘。独立主持一次客户例会，并把自己入职时被卡住的地方改进到入职文档里。下一个人的 90 天缩短多少，就是你的贡献。
90 天结束时应该看得见的东西
三个月的节点上问自己三个问题，入职的成败就显形了。第一，能不能不看任何资料，把所负责客户的系统架构图画出来？第二，能不能讲清那家客户的干系人地图——谁拍板，谁在用？第三，故障报告进来时，头 30 分钟做什么，心里是否已经有数？
哪怕只有一个答案还模糊，也只需挑出那个领域，退回第一个月的画地图环节即可。入职适应是回路不是直线，找到薄弱段落倒带重来，本身就是正常轨道。第三个月的目标不是变得完美，而是变成一个确切知道自己缺口在哪里的人。
三个都有答案，入职就完成了。如果第三个答案还模糊，下一篇讲的正是这件事：故障诊断的分步手册。
亲手练习
这 90 天的手感，可以先在模拟里过一遍。
- FDE 工程师养成 RPG — 从低等级起步、逐步换取访问权限和信任的结构，就是入职第一个月的缩影。
- FDE 课程路线图 — 把第一个月要画的地图中的技术项，先用清单预检一遍。
FDE 完全指南系列