1. 题目与使用场景
面试官想知道你能否在人员变动、轮岗或项目切换时，把“个人掌握”变成“团队可持续”。题目中的“还没准备好”可以是接任者经验不足，也可以是时间窗口很短；重点不是证明自己不可替代，而是让责任安全地转移。
2. 面试官考察点
- 是否先界定责任边界、不可接受的风险和交接完成标准。
- 是否把隐性知识转成文档、演练、监控或检查清单。
- 是否给接任者真实决策权，同时保留短期支持和升级路径。
- 是否用结果指标证明交接有效，而非只说“开了几次会”。
Amazon 的 Ownership 原则强调对长期结果负责；Google SRE 的事故材料把明确的交接对象和知识转移视为降低压力、保持指挥链清晰的机制。回答应体现这两点。
3. 回答前需要澄清的问题
- 交接的是服务、项目、客户关系还是值班职责？持续多久？
- “还没准备好”具体表现是什么：缺少领域知识、权限、信心，还是时间不足？
- 哪些错误会造成用户影响、合规问题或数据损失？
- 交接后由谁最终负责，何时算完成？
4. 30 秒回答框架
用“背景—风险—设计—验证—结果”五句回答：
团队需要在两周内把支付对账服务交给新同事。对方没有处理过月末结算，我先列出高风险操作和升级联系人，随后用一份运行手册、一次故障演练和一周双人值班完成渐进式交接。第一轮月末结算由对方主导、我只在预设阈值触发时介入；结果是交接后连续三次结算无逾期，值班告警也按时关闭。
5. 分步骤深入解答
第一步：定义责任与完成条件
画出输入、决策、输出、依赖和升级路径。把“能独立负责”写成可观察条件，例如能完成一次演练、能解释关键告警、能在规定时间内完成回滚。GitHub 的 CODEOWNERS 机制说明，责任边界应落在明确的文件或团队范围上，而不是只存在于口头约定。
第二步：按风险拆分知识
把知识分为三类：高频且可逆的日常操作、低频但高损失的操作、需要跨团队协调的例外。对第一类用清单和示例；对第二类安排桌面演练和双人审批；对第三类写清联系人、决策权限与升级时限。不要把所有背景一次性倾倒给接任者。
第三步：采用渐进式放权
先由接任者观察，再由其执行、你旁观，最后由其独立处理。每个阶段设退出条件，例如两次无提示完成、一次故障演练通过、关键指标保持在阈值内。支持窗口应有截止日期，否则责任会长期悬置在原负责人身上。
第四步：验证交接后的系统状态
检查的不只是接任者是否“感觉有把握”，还包括结果指标：故障响应时间、未关闭告警、回滚成功率、客户升级数量或交付准时率。交接后一段观察期内保留审计记录，确认问题被发现、归因并修正。
6. 高质量示范回答
我负责一个每天处理账单导出的作业，原本由我单独值班。公司安排我在十天后转到新项目，接任同事熟悉业务但没有处理过失败重跑。我的风险判断是：重复扣款和错过财务截止时间不能接受，普通格式错误可以在当天修复。
>
我先把责任拆成日常执行、失败重跑、供应商沟通和最终升级四块，给每块写完成条件与联系人；再把过去三次故障整理成运行手册，并用脱敏数据做一次失败重跑演练。前三天我示范，接下来四天由同事操作、我旁观，最后三天由同事主导值班。我只在重复扣款风险或超过十五分钟未恢复时介入。
>
交接完成的标准是同事独立通过演练、能解释所有关键告警，并在两次真实运行中按时关闭异常。转移后的三次结算都按时完成，没有重复扣款；我把观察期内的两个小问题补进手册后正式撤出。这个过程让我意识到，责任交接的产物是可验证的工作系统，不是一次知识分享会议。
7. 常见错误
- 只讲培训时长，不讲风险、权限和完成标准。
- 为了显示负责而不放权，导致接任者无法形成判断能力。
- 把所有异常都留给自己，造成隐形单点故障。
- 只报告“没有事故”，却没有说明观察期、指标或如何发现问题。
- 把接任者描述成“不够好”，忽略了流程和文档本身的责任。
8. 追问及应对
追问一：如果接任者坚持说自己还没准备好怎么办？
把担忧转成具体场景，让对方选择先演练哪一类风险；必要时缩小权限和范围，但保持明确的放权时间表。
追问二：交接期间出了事故，责任算谁的？
按事先写明的阶段责任和升级规则处理。复盘关注信号、决策和机制缺口，不把责任归因简化为个人能力。
追问三：什么时候可以完全退出？
当接任者满足预设能力条件，关键指标在观察期内稳定，且团队知道新的唯一负责人和升级路径时退出，并保留短期可联系但非默认值班的安排。