项目管理与交付面试题
模拟真实面试场景，训练对项目规划、敏捷、风险、质量、复盘的思考与表达。
一、基础题
1. 项目管理的五大过程组是什么？基础
2. Scrum 中的三个角色是什么？各自职责是什么？基础
3. 什么是 OKR？请举例说明。基础
4. 什么是 Kanban？和 Scrum 有什么主要区别？基础
5. 什么是 WBS？分解的原则是什么？基础
二、进阶题
6. 项目进度落后时，你会怎么做？进阶
7. 如何管理需求变更？进阶
8. 如何做项目估算？你觉得哪种方法最靠谱？进阶
9. 如何进行风险管理？请用一个实际项目举例。进阶
10. 如何保证前端项目的交付质量？进阶
参考答案要点：
- 明确 DoD（Definition of Done）：包括代码评审、测试、性能基准等。
- 建立质量门禁：CI 检查、自动化测试、Code Review。
- 设定性能预算：关键指标的超时告警。
- 灰度发布：小范围验证后全量。
- 数据反馈：通过埋点和监控持续观察质量。
评分维度：
- 流程保障（30%）
- 自动化建设（25%）
- 质量标准（25%）
- 持续改进（20%）
常见错误：
- 把质量等同于"测试"，认为 QA 应该对所有质量问题负责。
- 只看上线前的质量，不看线上运行后的质量。
- 质量门禁形同虚设（比如 CI 失败也能合并代码）。
扩展追问：
- 当业务压力要求降低质量标准时，你能做的最低的妥协底线是什么？
- 什么是"好"的 Code Review？如何让 Code Review 不流于形式？
三、高级题
11. 如何在资源有限的情况下保证项目质量？深入
参考答案要点：
- 优先保障关键路径和核心功能质量。
- 建立自动化测试和质量门禁。
- 用风险驱动测试，重点覆盖高风险场景。
- 引入代码评审和结对编程。
- 设定性能预算和安全基线。
- 灰度发布，逐步放量。
评分维度：
- 优先级判断（25%）
- 自动化与门禁（25%）
- 风险驱动（20%）
- 过程改进（15%）
- 发布策略（15%）
常见错误：
- 在压力下完全放弃质量控制，承诺"上线后再补"。
- 平均分配测试资源，没有根据风险区分优先级。
- 削减自动化投入，认为"手动测试也能凑合"。
扩展追问：
- 你如何在项目初期就让团队关注质量，而不是等到测试阶段才发现问题？
- "上线后再补"这个承诺在你的经验中兑现率如何？
12. 你如何进行项目复盘？有什么要求？深入
参考答案要点：
- 回顾目标和关键结果。
- 对比实际结果，找出差异。
- 分析成功和失败的原因，用 5 Whys 深入追根。
- 提取可复用的经验和教训。
- 制定改进行动项并跟进。
- 沉淀为团队知识库或 SOP。
评分维度：
- 结构完整（20%）
- 根因分析（25%）
- 经验沉淀（25%）
- 行动跟进（20%）
- 安全氛围（10%）
常见错误：
- 复盘变成了追责大会，大家不敢说真话。
- 改进措施"一定要加强XX"之类的空话，没有可执行性。
- 复盘记录写完了但从不回头跟踪。
- 复盘频率太低（一年一次）或太高（每个故事都复盘）。
扩展追问：
- 你有过"问题反复出现"的经历吗？说明复盘出了什么问题？
- 如果团队拒绝参加复盘，说"浪费时间"，你怎么处理？
13. 如何协调前/后端之间的依赖关系？深入
参考答案要点：
- 契约优先：前后端先约定接口规范（OpenAPI / GraphQL Schema），并行开发。
- Mock 先行：前端使用 Mock Server，不依赖后端开发完成才联调。
- 尽早联调：不要等到双方都开发完，尽早开始端到端集成。
- 契约测试：用 Contract Test 确保双方对接口理解一致。
- 定期同步站会：暴露依赖阻塞。
- RACI 清晰：接口规范谁负责定义、谁负责实现、谁负责验收。
评分维度：
- 流程机制（30%）
- 工具方法（25%）
- 沟通协同（25%）
- 风险防范（20%）
常见错误：
- 后端的 API 设计完全由后端决定，前端被动接收。
- 前端等待后端开发完成才开始联调（串行依赖）。
- 接口文档写完了不更新，联调时才发现对不上。
扩展追问：
- 如果你的团队用 GraphQL，前后端依赖管理有什么不同？
- 当后端说"这部分会改"你们先不要联调，你怎么应对？
14. 前端项目如何做 Sprint Planning？深入
参考答案要点：
- 容量确认：统计团队可用人天（扣除假期、会议）。
- Backlog 梳理：PO 讲解故事，团队澄清细节。
- 估算：用 Planning Poker 或团队熟悉的方式估算故事点。
- 承诺：根据历史 Velocity 选择本次 Sprint 可以完成的故事。
- 依赖对齐：确认前后端依赖、设计资源是否到位。
- DoD 确认：明确本次 Sprint 的完成标准。
评分维度：
- 流程完整（25%）
- 容量管理（20%）
- 依赖处理（20%）
- 承诺机制（20%）
- 前端特殊性（15%）
常见错误：
- Planning 会议上才开始看需求（应该先 Backlog Refinement）。
- 靠"感觉"而不是 Velocity 做承诺。
- 前端专属依赖（设计稿、接口、浏览器兼容）未考虑。
扩展追问：
- 如果你的团队 Velocity 波动很大，你怎么处理 Sprint Planning？
- 前端开发中如何处理"设计师还在改稿"这种情况？
15. 如何将 OKR 落地到前端团队的日常工作中？深入
参考答案要点：
- 季度 OKR 设定：从公司/部门 OKR 分解出团队 OKR，全员参与讨论。
- OKR 公开透明：挂在团队看板上，每次站会引用。
- 月度 OKR 检查：每月检查 KR 进度，必要时调整。
- Sprint 层面对齐：每个 Sprint 的 Backlog 中至少有一个任务是驱动某条 KR 的。
- OKR 不是绩效考核：明确 OKR 是方向指引，不是评价工具。
- 足够激进：O 要有挑战性，70% 完成率是好的。
评分维度：
- 层级分解（25%）
- 日常融入（25%）
- 与 Sprint 结合（20%）
- OKR 文化理解（15%）
- 实际案例（15%）
常见错误：
- OKR 变成"目标管理"的下发工具，团队被动接受。
- OKR 设定后没有日常跟踪，到季度末才发现偏了。
- 把 OKR 达成率直接与绩效挂钩，导致团队不敢设激进的 O。
- OKR 和日常任务脱节，两个世界互不干扰。
扩展追问：
- 如果 OKR 和紧急的线上问题冲突了，你怎么取舍？
- 你怎么判断团队是在"做 OKR"还是在"写 OKR"？
标签：#project-management #agile #scrum #kanban #okr #风险 #面试题 #estimation
最后更新：2026-06-25