题目重点：发现团队performance下降时，如何用交付、质量、依赖与负担证据定位并改善。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 以本人真实职责和经历作答，区分直属管理、技术带领与peer协作，不冒称绩效或招聘决策权。
- 案例中人数、周期、结果和证据来源按真实情况填写；练习情境只示范结构，不能冒充履历。
解题路线
- 先固定performance口径与基线，不把commit数量或story point作为不同团队可直接比较的产出。
- 检查scope/人员/事故/oncall/依赖/返工/需求变化，分解流动时间和等待时间；成员个体问题与系统瓶颈分开。
- 与团队共同验证主要假设，选择一两项改善，如减少在制任务、明确验收、修反复故障、安排focus时间；为新做法设试验窗口。
- 结果看价值交付、质量、可预测性和团队负担，解释同时发生的其他变化，避免简单归功于新流程。
手动走一遍
练习情境：交付周期变长，日志显示大部分时间等外部review而非写代码。改依赖协议和提前设计review比要求每人多完成ticket更贴近根因。
规模与取舍
规模按真实负责人数、跨团队范围、周期和风险说明；先约90秒主线，再按追问给决策、行动与证据。管理结果常有延迟和多重因素，不把组织整体变化全部归因于单人。
易错点与追问
容易失分的边界
- 只加更多会议可能加剧实际瓶颈。
- 绩效下降默认归罪成员态度，忽略需求和依赖。
继续深挖
- 如何判断新流程有作用？同口径观察等待/返工，并听团队实际负担。
- 短期提升吞吐但质量下降怎么办？预设guardrail与持续观察。
