接了一个烂摊子，FDE先看哪里

公司通知你，下周一去客户现场，接手上一任 FDE 留下的项目。你的第一反应是什么？本文分享一个方法，帮你在第一周快速搞清楚项目状况。

———— / BEGIN / ————

公司通知你下周一去客户现场，接手上一任 FDE 留下的项目。

前任走得很突然，没留交接文档，连代码仓库账号都不知道密码。客户那边的技术负责人第一句话："你们的人走了，系统每天晚上 8 点就挂，你什么时候能修好？"

系统为什么会挂？客户改过哪些代码？还有哪些坑没踩？

做 FDE 这几年，接过不少这样的项目，前任留下的十有八九都是坑。不是技术问题，而是信息缺失、责任不清、客户不满意。

接手项目的第一周，先看三个地方，就能摸清楚项目底细。

一、确认过往资料：三看

接手项目的第一件事不是改代码，而是确认过往资料。

看配置文件

配置文件是项目的身份证，告诉你这个系统长什么样。

先看配置文件，确认版本号、环境变量、依赖服务、密钥有没有问题。很多时候，系统跑不起来就是因为配置文件里的密钥过期了，或者指向了客户的内网地址。

举个例子，有次接手项目，第一天就发现配置文件里有 3 个问题：数据库密钥过期、Redis 地址指向测试环境、Python 依赖版本和生产环境不一致。这三个问题不先解决，后面什么都做不了。

配置文件的关键是先让系统跑起来。跑不起来，你什么都看不到；跑起来了，才能看到真正的问题。

看客户修改记录

客户修改记录是项目的病历本，告诉你这个系统经历过什么。

去客户的代码仓库，看 git log，重点看最近 3 个月的提交记录。看看客户改过哪些文件、为什么改、改完之后有没有问题。再搜一下代码里的 TODO、FIXME、HACK 这些关键词，很多坑都藏在这些注释里。

举个例子，看 git log 发现客户在 2 个月前改过一个数据同步模块，注释里写"临时方案，后续优化"。去看那个模块的代码，发现客户把异步改成了同步，导致高峰期数据库连接数暴涨，这就是系统每天晚上 8 点挂的原因。

如果前任 FDE 还在，能联系上就问一句："客户改过哪些东西，为什么改？"前任的回答能帮你省掉 80% 的踩坑时间。

看未完成工单

未完成工单是项目的体检报告，告诉你这个系统还有哪些已知问题。

去工单系统，看看哪些工单还没关闭，重点看那些状态是"已临时规避"的工单。这些工单的问题没解决，只是用临时方案绕过去了，随时可能复发。

还要看那些状态是"已关闭"但客户评价不满意的工单。这些工单可能前任 FDE 为了 KPI 强行关了，但客户心里有怨气，你接手之后客户可能会翻旧账。

接手项目的第一周，给客户发一封交接确认邮件，列出你看到的所有未完成工单，让客户确认哪些是高优先级。这封邮件既是工作记录，也是保护自己的证据。

二、检查业务流程：核心检查点

确认完资料，接下来是检查业务流程，找出系统的卡点。

分四层检查：系统、数据、业务、运维。

系统层

系统层看 4 个点：版本、环境变量、依赖服务、密钥。

版本号对不对？环境变量有没有遗漏？依赖服务（Redis、消息队列、第三方 API）能不能连上？密钥有没有过期？

很多项目的问题出在环境变量上，前任 FDE 在本地改了环境变量，但没同步到生产环境，导致你接手之后系统跑不起来。

数据层

数据层看 3 个点：数据源、权限、备份。

数据从哪里来？是客户的数据库，还是第三方 API？权限够不够？能不能读、能不能写？备份策略是什么？多久备份一次？备份存在哪里？

举个例子，有次接手项目，发现客户的数据库只给了只读权限，但系统里有个功能需要写入。前任 FDE 用了一个临时方案，把数据先写到本地文件，再手动导入数据库。这个方案能用，但维护成本高，而且容易出错。

业务层

业务层看 3 个点：客户特殊逻辑、SLA、升级路径。

客户有没有特殊的业务逻辑？和标准产品有什么区别？SLA 是什么？客户要求系统可用性是多少？响应时间是多少？升级路径是什么？客户的系统能不能平滑升级到新版本？

举个例子，有次接手项目，客户的 SLA 要求是 99.9% 可用性，但前任 FDE 没做高可用方案，系统是单机部署。我花了 2 周时间优化准确率，客户却说"我不关心准确率，我关心系统别挂"。

运维层

运维层看 2 个点：监控告警、应急预案。

监控系统有没有？告警规则对不对？告警接收人是谁？应急预案有没有？系统挂了怎么办？

举个例子，有次接手项目，监控告警的接收人还是前任 FDE 的手机号，系统挂了半天客户才发现。我接手之后第一件事就是把告警接收人改成自己的手机号，然后写了一份应急预案，告诉客户系统挂了怎么快速恢复。

三、准备行动方案：第一周怎么做

确认完资料、检查完业务流程，接下来是准备行动方案。

第一周的目标不是解决所有问题，而是识别风险、排定优先级、和客户对齐预期。

D1-D2：先让系统跑起来

第一天和第二天，目标是先让系统跑起来。

不管前任留下多少坑，先让系统跑起来。系统跑不起来，你什么都看不到；系统跑起来了，才能看到真正的问题。

这两天不要急着改代码，先把配置文件、环境变量、依赖服务、密钥全部确认一遍。如果系统还是跑不起来，就去找客户要账号、要权限、要文档。

D3-D4：识别遗留问题

第三天和第四天，目标是识别遗留问题。

用前面说的三看原则和四层检查点，把系统的问题全部列出来。然后按严重度和紧急度排序，分成 P0、P1、P2、P3。

严重度 紧急度 优先级 处理方式

P0

立即修复

P1

排期修复

P2

降级处理

P3

记录观察

P0 问题立即修复，比如系统每天晚上 8 点挂，这种问题不能拖。P1 问题排期修复，比如客户要求的新功能。P2 问题降级处理，比如某个不常用的功能报错。P3 问题记录观察，比如代码里的 TODO 注释。

D5：和客户对齐

第五天，目标是和客户对齐。

给客户发一封邮件，列出你这一周看到的所有问题、优先级排序、修复计划。然后约客户开个会，当面确认优先级、交付时间、责任边界。

和客户对齐的时候，有几句话术很管用：

• "我接手之后，先把系统跑起来了，现在能正常运行。"（先报告好消息）

• "我看了一下之前的工单和代码，发现有几个遗留问题，我已经排好优先级了。"（展示你做了什么）

• "系统每天晚上 8 点挂的问题，我已经找到原因了，这周五能修好。"（承诺具体时间）

• "有些问题需要你们配合，比如数据库权限、环境变量，能不能帮我协调一下？"（明确需要客户配合的地方）

• "我会每周给你发一封进度邮件，有问题随时联系我。"（建立沟通机制）

和客户对齐的时候，千万别说前任 FDE 的不是。你可以说"之前的方案有些地方需要优化"，但不要说"前任做得不对"。客户可能会问你"前任为什么这么做"，你就说"我还在了解情况"。

总结

接手 FDE 项目不是从零开始，是风险识别。

前任留下的项目，十有八九都是坑。但只要方法对，第一周就能摸清楚项目底细。

接手项目的第一周，目标不是解决所有问题，而是让客户看到你在做事、你有计划、你靠谱。

本文来自作者：王钊