关键开发人员离职了，leader 不想招人以节省成本，你如何看待并推动？
关键人离职而不招人，短期省成本，但会使团队出现单点、交付延期、质量下降，长期风险更高。我会量化影响：关键模块无人维护、知识断层、交付周期拉长、潜在客户损失，用数据说明"不招人"的隐性成本大于招聘成本。同时提出低成本替代方案：先内部调配、临时补位、外包或兼职过渡，再分阶段推进正式招聘。推动 leader 评估"失去关键能力"的长期风险，平衡短期成本与连续性。
关键在"用数据把隐性成本显性化"，同时提供过渡方案，而非单纯反对 leader 决策。
关键人离职前的风险预警与挽留尝试如何开展？
预警：关注关键人的离职信号（满意度下滑、绩效波动、频繁请假、沟通减少），通过定期 1:1 了解诉求。挽留：了解离职原因（薪酬、成长、家庭、团队），针对性回应——提供成长机会、调整职责、争取薪酬、改善工作条件；同时坦诚沟通对公司的影响与可能的调整。挽留不成则及时转入交接，避免被动。预警与挽留都基于真诚沟通与对个人诉求的把握。
预警靠"信号识别+1:1 沟通"，挽留靠"针对诉求的对策"，挽留不成即转交接。
交接窗口期的并行工作（shadowing）如何设计？
交接窗口期设计 shadowing：①明确交接范围与目标，列出关键模块、文档、账号、依赖；②安排接替人与离职人结对，逐项讲解并实操；③并行期让接替人独立处理任务、离职人在旁把关，逐步过渡；④交接后设答疑期（1-2 周），离职人可远程答疑。关键是把"知道"转成"能独立做"，用演示、任务、答疑验证。控制交接节奏，避免一次性倾倒。
shadowing 的核心是"由讲转做、由辅导转独立"，并行期逐步放权并设答疑期。
关键开发人员离职了，leader 说"不能有 bus factor"，你如何看待并推动？
leader 意识到"不能有 bus factor"是积极的，但缺人风险仍在。我会推动：①交接期充分知识转移（文档、演示、结对）；②建立知识共享机制，让接替人系统掌握关键模块；③评估代码所有权，推动多人掌握关键代码、减少单点；④设定交接验收标准，验证接替人独立能力。同时推动后续人才机制（备份、轮岗、文档化），把"不能有 bus factor"从口号落到机制。
把 leader 的"意识"转化为"机制"，通过交接、共享、备份落实低单点。
关键人离职后出现知识断层，应急方案是什么？
知识断层应急方案：①盘点接管范围，评估受影响模块与风险；②借助离职前交接文档、代码注释、设计文档快速恢复；③联系离职人短期内答疑（若协议允许）；④临时调整团队分工、集中资源处理关键事项，必要时外包或临时补充；⑤建立知识库与文档，防止再次断层。应急时优先保障核心业务，再逐步补齐知识储备。
应急按"盘点→恢复→支援→补库"推进，先保障核心业务，再长期补知识。
团队文档库被批评"无 changelog"，你如何看待并推动变更记录？
changelog 是变更追踪与知识沉淀的关键，缺失会导致版本混乱、排查困难。我会推动：①建立变更记录规范（格式、必填项：变更内容、原因、影响、人、时间）；②在发布流程中强制要求更新 changelog，纳入代码评审/发布检查；③用工具（如版本管理、自动生成）降低记录成本；④示例示范并讲师培训，让团队形成习惯。同时说明 changelog 对排障、审计、协作的价值。
推动靠"规范+流程入口+工具降成本+示范"，让变更记录成为发布的一部分。
团队文档库被批评"无 owner"，你如何看待并推动责任归属？
文档无 owner 会导致无人维护、内容陈旧、责任不清。我会推动：①为每个文档/模块指定 owner，明确维护与更新责任；②建立文档 RACI 或责任矩阵，明确负责、参与、知会；③定期 review 文档质量，owner 遗漏则追责；④在入职、交接、发布流程中绑定文档更新责任。owner 制让文档"有人管、有人更新、有人负责"。
推动靠"owner 指定+责任矩阵+review 追责"，把文档维护绑入流程。
团队文档库过时（3 年没更新），你如何看待并推动更新？
3 年未更新的文档已失真，误导新人、引发事故。我会：①盘点文档，评估哪些仍有效、哪些过时、哪些已废弃；②建立"更新优先"清单，优先更新与核心业务、新人 onboarding 相关的文档；③与 owner 分工，分批更新，剔除失效内容；④建立更新机制（定期 review、发布时更新、owner 负责），防止再度过时。先清理再更新，落地机制。
处理过时文档是"先盘点评估、再分批更新、后建机制"，避免一次性大改。
关键人员离职的知识转移，文档、交接与结对如何开展？
知识转移结合文档、交接、结对三方式：①文档——沉淀设计决策、架构、接口、问题记录，形成可查知识库；②交接——列出系统清单，逐项讲解并答疑；③结对——接替人与离职人结对实操，在真实任务中掌握。三者结合：先文档把显性知识留下，再交接理清全貌，最后结对验证独立性。用验收标准检验转移效果。
三种方式互补，文档留显性、交接理脉络、结对验能力，组合实施最有效。
离职交接的清单，包括文档、账号与依赖如何制定？
离职交接清单应覆盖：①文档——设计文档、架构、接口、部署、运维手册、FAQ；②账号——代码仓库、云平台、CI/CD、数据库、供应商等权限账号与密码移交；③依赖——第三方服务、外部联系人、遗留依赖项；④任务——进行中的任务、待办、风险；⑤代码——未提交改动、分支、构建方式。清单逐项核对并签字确认，避免遗漏关键项。
交接清单覆盖"文档+账号+依赖+任务+代码"，逐项核对签字防遗漏。
离职交接如何定义"交接完成"的验收标准（文档、演示、答疑期），避免"看似交接实则没有"？
定义验收标准：①文档——交接清单逐项核对，文档齐全、可读、可操作；②演示——接替人当众演示关键模块运行与操作，证明已理解；③答疑期——离职后保留 1-2 周答疑期，接替人能独立处理问题；④独立任务——接替人独立完成一个真实任务并通过评审。以"接替人能否独立工作"为真正验收，而非"交接方是否讲完"，避免"看似交接实则没有"。
验收以"接替人独立能力"为核心，用文档核对、演示、答疑、独立任务四重验证。
关键人离职前如何组织"知识萃取"（设计决策访谈、常见问题梳理），把脑子里的东西留下来？
知识萃取是"把隐性知识显性化"。做法：①设计决策访谈——围绕关键模块询问"为什么这样设计、有哪些权衡、踩过哪些坑"，记录决策背景；②常见问题梳理——整理关键人常被问的问题、解决方案与排查路径；③复盘/结对——在其解决问题时与之结对，记录思路；④沉淀文档——将访谈与梳理结果整理成可读文档，标注场景与决策。目标是让"经验"变成"知识"。
知识萃取靠"访谈+问题梳理+结对观察+文档沉淀"，把脑内经验显性化。
替补到岗前，如何做优先级降级与需求沟通？
替补到岗前，团队能力下降，应做优先级降级：①与业务方/PM 对齐当前交付能力，说明缺员影响；②重新排序需求，砍掉/推迟非关键项，保障核心业务；③明确中期交付承诺与延期风险，让相关方知情；④安排临时支援或过渡方案。需求沟通关键在"透明+期望管理"，用数据说明影响，共同决策优先级，避免承诺无法兑现。
优先级降级是"能力评估+需求重排+透明沟通"，聚焦核心业务并管理期望。
bus factor 的降低，代码所有权与文档化如何理解？
bus factor 指"团队失去某成员后项目停滞的风险系数"。降低手段：①代码所有权——从"单人独占"改为"多人共同掌握"，用代码评审、结对、轮岗让多人熟悉关键代码；②文档化——沉淀架构、决策、接口、运维文档，减少对个人记忆的依赖；③结对与备份——为关键模块设置第二负责人。核心是"知识与能力分散化"，避免单点依赖。
降低 bus factor 靠"所有权共享+文档化+备份"，让关键能力不再集中于一人。
离职期的工作交接，清单与验证如何开展？
交接先定清单：按文档、账号、依赖、任务、代码逐项列明，明确交接人、接替人、时间。验证：逐项核实（账号能登录、文档可用、代码可构建），接替人演示关键操作，设置答疑期验证独立能力。交接完成以"接替人可独立工作"为标志，而非清单画勾。清单与验证结合，确保交接真实有效，避免形式化。
"清单逐项核对 + 独立能力验证"双保险，防止交接流于形式。
团队连续性的机制，轮岗与备份如何理解？
连续性机制：①轮岗——让成员周期性接触不同模块，拓宽知识面，避免单点；②备份——为关键模块/角色设置第二负责人，明确 backup；③结对——常态结对使知识分散；④文档与知识库——沉淀可复用知识。轮岗与备份让团队"不依赖某个人"，即使关键人离开也能快速补位。机制上应定期评估知识分布，识别并消除单点。
轮岗与备份把"个人能力"转化为"团队能力"，关键在于识别并消除单点。
知识转移的验证，交接后的抽查与陪跑如何开展？
交接后的验证：①抽查——定期抽查接替人对关键模块的理解，能否解释设计与处理问题；②陪跑——在接替人独立上手初期，设专人陪跑支持，及时纠偏；③事后复盘——通过真实任务表现评估独立性；④答疑期——保留前任答疑通道。验证目的是确认"知识已真正转移"，而非"交接过程结束"。陪跑与抽查结合，及时补漏。
验证靠"抽查理解+陪跑支持+真实任务复盘"，确保知识真正落地。
