# 1. 讲一次多团队依赖中关键路径上的失败经历 A 关键路径依赖失败是对方团队的责任，与己无关 B 关键路径依赖应提前识别、建立预警机制、预留缓冲并准备备选方案 ✓ 正确答案 C 关键路径依赖失败只能靠事后补救，无法预防 D 只要依赖方答应了，就无需担心延迟
# 2. 讲一次你主导接口治理、解决跨团队冲突的过程 A 接口冲突源于双方都不讲理，无法改善 B 跨团队接口冲突应靠上级裁决，与管理机制无关 C 接口治理就是让一方完全服从另一方 D 应通过立契约、定责任、建变更机制与契约测试来治理接口，化解冲突 ✓ 正确答案
# 3. 跨团队依赖中 SLA / 责任矩阵的建立 A SLA 与责任矩阵是形式主义，实际依赖靠人情沟通 B 应用 SLA 界定交付与响应标准、用责任矩阵（如 RACI）划定权责，并使各方认可 ✓ 正确答案 C 责任矩阵越复杂越好，才能覆盖所有情况 D SLA 应单方面强加给依赖方，节省沟通
# 4. 你如何在关键路径上加冗余 / 监控 / Review A 应在关键路径叠加冗余、监控与 Review，并按风险影响决定投入强度 ✓ 正确答案 B 关键路径的 Review 会拖慢进度，应省略 C 关键路径只需关注进度，无需额外保障 D 冗余越多越好，永远安全
# 5. 讲一次跨团队因"谁负责"扯皮的解决经历 A 职责不清的扯皮应判给先提问题的一方 B 应先行止血、依据事实厘清职责、用责任矩阵固化并建立兜底机制 ✓ 正确答案 C 责任矩阵只在项目启动时有效，之后无需维护 D "谁负责"扯皮应靠两边自行协商，管理者不介入
# 6. 你会如何在影响扩大前升级并保护下游验证时间 A 下游验证时间可随意挤占，只要功能能上线 B 应尽早带着清晰信息升级，并把下游验证时间作为不可压缩的刚性底线 ✓ 正确答案 C 发生延迟时应优先压缩验证时间，抢回进度 D 依赖出问题时应先等确认，避免误报
# 7. 你如何识别"关键依赖"——哪些团队 / 服务的失败会级联到你的项目 A 所有依赖都应同等对待，避免遗漏 B 越重要的团队越关键，应一律重点保障 C 应以"级联影响能力"为判据，结合依赖图与关键路径识别真正关键依赖 ✓ 正确答案 D 关键依赖只需靠直觉判断，无需分析
# 8. 讲一次你处理跨团队依赖失效（延迟 / 返工）的具体应对与升级路径 A 应按照内部应对、对方沟通、升级仲裁的分级路径处置，并以证据和方案推进 ✓ 正确答案 B 依赖失效应静默处理，避免影响团队士气 C 升级路径会显得能力不足，应尽量自己扛 D 依赖失效应立即升级到管理层，越快越好
# 9. 你如何在项目早期和依赖方建立"对齐机制"避免后续翻车 A 应在项目早期与依赖方对齐目标、契约、节奏、责任与风险，固化为正式机制 ✓ 正确答案 B 对齐机制只需口头约定，无需书面固化 C 依赖对齐应在出问题时再临时沟通，节省早期精力 D 早期对齐是形式主义，对后期无帮助
# 10. 请说明你如何用"依赖图 + risk register"管理跨 N 团队的复杂项目 A 依赖图与风险登记册二选一即可 B 应结合依赖图看清依赖结构、风险登记册跟踪应对，并配合固定节奏评审 ✓ 正确答案 C 风险登记册只在项目结束才用 D 跨 N 团队项目靠管理者记性好，无需工具
# 11. 讲一次你通过"提前并行 + mock 服务"减少对外部团队 block 的经历 A mock 服务与真实接口无需一致，能跑通即可 B 应通过契约先行、mock 服务与契约测试实现并行开发，并在真实接口就绪后做切换验证 ✓ 正确答案 C 外部依赖未就绪就只能等待，无法并行 D 并行开发只会增加返工，应尽量避免
# 12. 你如何处理"承诺失效"——依赖方最终没能按时交付的对策是什么 A 承诺失效无法预防，只能等对方补救 B 依赖方承诺不可靠时，应加倍依赖它并祈祷 C 依赖方承诺失效是对方违约，追责即可 D 应通过预案降级、控制影响、沟通升级与事后机制补强来应对承诺失效 ✓ 正确答案
# 13. 跨团队依赖的管理中如何用契约、进度跟踪与风险登记管理跨团队依赖？ A 契约与风险登记会拖慢协作，应省略 B 跨团队依赖管理靠日常沟通即可，无需文档工具 C 三大支柱中只需关注进度跟踪 D 应用契约立标准、进度跟踪看现状、风险登记管前瞻，三者闭环管理依赖 ✓ 正确答案
# 14. 依赖失效的应对中依赖方违约时如何按预案降级或绕过并控制影响范围？ A 依赖方违约时只能让整个项目延期，无法控制 B 违约影响无法控制，只能等对方补救 C 应预先准备降级/绕过预案，违约时立即启用并隔离影响、控制范围 ✓ 正确答案 D 预案会浪费前期精力，违约时临时应对即可
# 15. 遗留系统改造中改造前如何评估现状、设计增量步骤并控制风险？ A 遗留系统改造应一次性重写，一步到位最彻底 B 应评估现状、采用增量式改造，并以可回滚、测试与灰度控制风险 ✓ 正确答案 C 改造只需关注功能上线，无需评估旧系统 D 增量式改造会拖慢进度，应尽量大改
# 16. 重写与重构的抉择中判断该重写还是重构时用什么框架评估成本、风险与收益？ A 重构永远优于重写，任何情况都不应重写 B 重写一定优于重构，因为新系统更好 C 应用成本、风险、收益框架结合业务关键度与债的严重度理性决策，警惕重写冲动 ✓ 正确答案 D 旧系统看起来难看就应重写，一步到位
# 17. 依赖管理的沟通与升级中依赖风险升级时如何向双方管理层沟通并推动解决？ A 升级到管理层时只需陈述事实，无需给方案 B 依赖风险应尽量内部消化，避免升级到管理层 C 应结论先行、用事实数据说明、讲清诉求并给选项，推动管理层决策落地 ✓ 正确答案 D 依赖风险升级就是把对方"告"到管理层，证明对方错
# 18. 改造的度量中遗留系统改造后如何量化收益（稳定性、交付速度）与成本？ A 改造只算成本，收益无法衡量 B 改造收益靠感觉判断，无需数据 C 应建立改造前后基线，用稳定性、交付速度等指标量化收益并对照成本算 ROI ✓ 正确答案 D 改造收益只能定性描述，无法量化
