6.2 问题解决与变更管理
无论计划做得多么周全，问题和变更请求都是躲不过去的事。最有可能成功的团队，是那些预期到会有干扰、并且有一套办法去吸收它的团队。
这一节我们给出一份在执行阶段处理问题和变更请求的实用框架。
项目里常见的问题
- 关键任务延期
- 交付物质量不佳，或者不符合需求
- 来自干系人的突发变更请求
- 团队成员离职或可用度下降
- 外部合作方或依赖项导致的延期
当谁来决定、决定怎么传达出去不清楚时，响应时间就会变慢——而这通常正是信任开始流失的地方。
问题解决的基本步骤
- 早期发现：在团队反馈、工具告警和状态会议里捕捉早期信号
- 影响评估：判断这个问题对进度、质量和团队结构造成的影响
- 制定应对方案：考虑临时绕过、修复、备选路径、推迟或取消
- 干系人对齐：和相关方清晰沟通，达成共识
- 执行与留痕：实施应对方案，跟踪结果，把变更记录下来
这套循环搭起来，就是一个成熟团队和一个被动救火团队之间的差别。
怎么处理变更请求
变更请求一来，从三个维度评估：
- 与目标的契合度：这个变更是不是真的服务于项目的核心目标？
- 影响范围：团队能不能在时间、金钱、产能上消化它？
- 审批路径：谁需要审批、谁需要被咨询？
提前定好分类规则：小变更可以一线直接处理，大变更必须走评审和审批。
结语：会调整的团队推动项目成功
问题和变更并不是失败的标志——它们是展现适应能力的机会。保持冷静、评估影响、达成共识，是优秀 PM 和有韧性的团队的特征。
在 AB 中是这样的
在 AB 里，Bug 或 Issue 类型的任务和交付工作并排存在——问题不会被放在一份没人更新的单独清单里。任务上的评论把对话保持在上下文里。变更历史标签页会自动记录每一次状态和范围的变化，所以当一个问题真的演变成一次范围变更时，你能看清它具体是什么时候发生的。再配上 MCP 服务器，AI 助手可以读取问题、把分析作为评论发出来，甚至把它拆解成子任务。
→ 接下来：6.3 项目汇报。