前端负责人的三次危机时刻

上周面了一个前端负责人的岗位，面试官问了三个场景题，挺有意思的，记录一下我的回答思路。

第一个问题：接口文档写错字段，同一个错误反复犯

面试官问我，如果有个后端接口文档字段写错了，提醒过还继续犯，怎么办。

我的第一反应是，这种事情靠提醒是没用的。人的记忆力是最不可靠的东西，你今天跟他讲一遍，他回去写十个接口，能记住两个就不错了。所以得从流程和工具上想办法。

我之前的做法是拉着他一起做两件事。第一，后端必须维护一份TypeScript的类型定义文件，前端直接从这个文件里导入类型。这样他字段写错了，前端的代码编译阶段就会报错，根本留不到联调的时候才发现。第二，在axios的拦截器里加一层校验，开发环境下如果返回的数据结构和声明的类型对不上，控制台直接打一个特别醒目的红色警告。让错误第一时间暴露出来，而不是藏在一堆日志里。

如果这些手段都用上了还是继续犯，那就不是能力问题了，是态度或者习惯问题。这时候我会在项目群里直接@他，把报错截图贴出来，说这个字段和约定不符，流程先阻塞，等确认了再继续。语气要平，对事不对人，但要让所有人都看到这件事的成本。

其实管理的本质不是让一个人变好，而是让一个人即使犯错也不会造成太大的伤害。工具兜底比谈心管用。

第二个问题：演示前一天测试环境崩了，运维联系不上

这个问题比较现实，几乎每个团队都遇到过。面试官想知道的是你作为负责人，怎么对内对外交代。

我的策略是内外有别，对外绝对不能提环境坏了这种话，对内要带着方案去汇报而不是带着问题去抱怨。

具体来说，第一步是立刻自救。环境崩了不代表什么都做不了，我至少有两个备选方案。一个是把测试环境的接口地址写死到本地hosts里，前端跑本地环境直连后端服务，只要数据库还活着就能跑。另一个是拿一个之前打包好的稳定版本，配合Mock数据跑一个静态页面，核心业务流程能走通就行。

有了这两个方案之后，再去找PM。我要说的是环境确实出了点状况，但我已经准备好了本地代理环境或者静态Demo，核心功能全部走得通，只是动态数据操作受限。然后请PM帮我判断一下，明天甲方是不是必须看到增删改查的实时效果，如果是，需要他帮忙协调资源解决网络问题，如果不是，我手里的方案完全够用。

面对甲方的时候，话术要换个说法。我会说为了保证演示流畅，我们特意搭建了一个高保真的演示专线环境，所有界面和交互逻辑都是真实版本，大家可以先聚焦业务流程和设计效果。至于环境坏了这种信息，甲方不需要知道，他们只需要看到东西是好的。

第三个问题：演示过程中出了一个错误

这个问题考的是临场应变。演示中出了岔子，最忌讳的是当场道歉、慌乱解释或者甩锅给网络。

我的做法是分三步走。错误发生的那一刻，立刻打断操作，微笑着把话题接过来。如果错误只是弹了个窗但页面还在，就说这是我们特意在演示环境里设置的边界值校验，用来展示系统对异常数据的拦截能力，不影响主流程，我们继续看下一个环节。如果直接卡死白屏了，就说演示数据预埋出了点非预期冲突，为了不耽误大家时间，我们跳过这个细节，先过完整体业务流程，会后我把完整操作录屏发到群里，确保闭环。

演示结束合上电脑的时候，主动提一句刚才那个小波动我们已经记录下来了，是演示数据构造时的边界遗漏，正式上线前会全覆盖测试。然后把话题迅速拉回到业务确认上，问大家整体流程是否符合预期。

事后跟PM汇报，不能只说Bug改完了。我会承认是我对演示环境的冒烟测试没做到位，但同时也提一个改进方案，比如以后演示前一个小时强制跑一遍核心路径的检查脚本，给演示环境打一个只读镜像包，彻底杜绝数据被篡改的风险。把一个个人失误转化成流程升级的契机，PM反而会觉得你有担当。

一点体会

这三个问题其实都在考察一件事：出了问题之后，你是只想着把眼前这关过了，还是能从一次事故里提炼出规则，让整个团队以后不再踩同一个坑。

前者是执行者的思维，后者才是负责人的思维。面试官想看的无非是这一点。