# 1. 迭代中途产品经理频繁变更需求，如何用变更成本可视化推动决策而不是硬扛或全接？ A 硬扛，全接 B 用变更成本可视化（返工/延期/影响）推动合理决策 ✓ 正确答案 C 拒绝所有变更 D 默默接受，不反馈
# 2. 需求方只给"竞品有我们也要有"的理由时，如何引导澄清真实用户问题？ A 追问竞品功能解决的用户问题与自身业务目标，引导价值分析 ✓ 正确答案 B 接受，直接照做 C 直接拒绝 D 完全看不起竞品
# 4. 如何建立需求变更的正式流程（变更申请→影响评估→审批→排期），避免口头变更？ A 不需要流程，口头即可 B 流程越复杂越好 C 只做书面申请，不评估 D 建立申请→评估→审批→排期流程，口头变更不生效 ✓ 正确答案
# 5. 跨团队需求冲突（两个 PM 争抢同一开发资源），如何推动优先级仲裁而不伤关系？ A 自己拍板谁先做 B 谁催得紧先做谁 C 躲开，不处理 D 用客观标准评估，请高层仲裁，保持中立沟通 ✓ 正确答案
# 6. 需求变更使原验收标准失效时，如何牵头与产品、QA 重定验收标准与测试范围，而不是被动接新需求？ A 牵头产品/QA 重定验收标准与测试范围，三方确认 ✓ 正确答案 B 被动接收新需求，沿用旧验收 C 让 QA 自己定 D 不更新验收标准
# 7. 如何用"迭代内变更预算"管理变更频率，既守住交付承诺又不让需求方觉得你在抗拒变化？ A 不设预算，来者不拒 B 设定迭代预算，预算内接受、预算外严格评审或延后 ✓ 正确答案 C 完全拒绝变更 D 预算根据需求方喜好调整
# 8. 上线前一天发现需求理解偏差且修正影响大时，如何评估与沟通上线、延期、缩减范围三种选项？ A 客观评估上线/延期/缩减范围三选项的代价与风险，共同决策 ✓ 正确答案 B 直接延期 C 硬着头皮上线 D 隐瞒偏差
# 9. 如何区分"合理的需求演进"与"需求蔓延（scope creep）"？判断标准是什么？ A 所有变更都是蔓延 B 是否偏离核心目标、是否影响排期、是否有价值论证 ✓ 正确答案 C 所有变更都是演进 D 看需求方心情
# 12. 需求方绕过你直接向 leader 提出变更时，你如何与 leader 对齐并重新确立变更入口，又不让需求方难堪？ A 指责需求方绕过 B 不管了 C 顺着需求方绕过 D 与 leader 对齐统一变更入口，请需求方同步信息，不伤面子 ✓ 正确答案
# 13. 需求方口头承诺"现在先做、损失下个版本补"，你如何把承诺书面化并跟踪兑现？ A 相信口头承诺，不做记录 B 书面化承诺并跟踪兑现，确保下个版本补偿 ✓ 正确答案 C 拒绝现在先做 D 只做，不追补偿
# 15. 需求变更后的回归测试范围如何与 QA 协商确定？如何避免"改了 A 忘了测 B"？ A 只测变更的模块 B 全量回归 C 让 QA 自己猜 D 用影响依赖分析找出受影响模块，形成三方确认的回归清单 ✓ 正确答案
# 19. 变更被驳回后需求方坚持时，你如何设计“复议”路径（补充数据、二次评审）而不形成对抗？ A 驳回后彻底关闭 B 设计补充数据+二次评审的复议路径，有条件和时限 ✓ 正确答案 C 让需求方无限申诉 D 直接同意
# 20. 如何用 feature flag 或灰度控制高风险变更的上线节奏，并向产品说明其代价与回滚路径？ A 直接全量上线 B 只做 flag，不沟通 C 用 flag/灰度控制，向产品说明代价与回滚路径 ✓ 正确答案 D 隐藏回滚路径
