不少考生考完PMP回到岗位后发现，教材里的过程组和敏捷实践像是两套语言，面对真实项目时不知道从哪套开始。原因在于考试题目是情境化的，而真实项目的约束更杂乱：需求半清晰、资源不稳定、上级要固定日期、客户又要灵活调整。方法选择不是信仰问题，而是匹配问题。
把PMP知识用起来的关键，是先判断项目的不确定性和交付特征，再决定方法组合，而不是整套照搬。
如果项目范围在启动时就能相对清晰地界定，变更频率低，验收标准明确，预测型方法是合理选择，按阶段推进、按基线控制变更。如果需求模糊、探索性强，客户自己也在边做边想，那么迭代式推进更合适，用短周期交付可工作的成果来换取反馈。
现实中的多数项目处在中间地带：主体框架清楚，局部模块不确定。这时可以采用混合结构，例如整体按阶段划分里程碑，但在研发或产品设计模块内部采用迭代方式，每个迭代结束做一次演示和评审。
当项目存在硬性的外部节点，比如监管报批、合同交付日期、展会发布，计划驱动的排期无法回避。此时敏捷实践并非不能用，而是要把固定节点当作约束条件，在节点之内做滚动规划，用迭代管理内部工作流，用里程碑管理对外承诺。
反过来，如果交付节奏由团队产能和反馈质量决定，没有刚性外部日期，就可以让迭代周期主导计划，减少为满足形式上的甘特图而做的无效排期。
干系人集中、决策链短、能指定单一产品负责人时，迭代式方法的沟通成本低、反馈快。干系人分散在多个部门、需要层层审批时，完全自组织的团队运作会遇到阻力，更适合在预测型框架下嵌入敏捷实践，例如保留阶段评审，但在团队内部实行每日站会和迭代回顾。
混合不等于两套计划各写一份。务实做法是建立两级计划：一级是面向干系人的里程碑计划，标出关键交付节点和验收条件；二级是面向团队的迭代计划，按一到四周滚动排布任务。两级计划之间用“发布—迭代”的映射关系连接，里程碑节点对应若干个迭代的完成。
变更管理也要分层：影响里程碑的变更走正式变更流程，评估对进度、成本、范围的影响；迭代内部的调整由团队在回顾会上处理，不必每次都上升到变更委员会。这样既守住对外承诺，又不扼杀团队灵活性。
预测型项目中，风险管理偏重前期识别与登记册维护，按计划定期复审。迭代型项目中，风险更多通过每轮交付暴露出来，团队在迭代评审和回顾中识别新风险，快速调整 backlog 优先级。混合模式下，应保留风险登记册作为统一台账，同时在每个迭代回顾中更新，避免风险信息散落在各处无人汇总。
一个容易忽略的点是：敏捷不等于没有文档。合规、审计、知识沉淀所需的记录仍然要留，只是形式可以更轻，例如用决策日志替代冗长的会议纪要。
问：公司要求所有项目都用瀑布模型，还能用敏捷吗？答：可以在团队内部引入迭代排期、每日站会和回顾会等实践，对外仍按阶段汇报，形成“外瀑布内迭代”的结构。关键是不要破坏既有的合规与审批要求。
问：混合模式会不会两边都不像，反而更乱？答：混乱通常来自职责不清而非方法本身。明确谁对里程碑负责、谁对迭代交付负责，并固定评审节奏，混合模式可以稳定运行。
问：PMP学的敏捷内容和Scrum框架是一回事吗？答：PMP覆盖的是敏捷原则与多种实践方式的综合视角，Scrum只是其中一种框架。考试更关注在情境中判断该采取什么行动，而非背某个框架的仪式流程。
众智商学院（北京众智汇科教育咨询有限公司）提供CPPM、SCMP、CPPS、PMP、中级经济师、CCAA等采购与供应链及相关职业资格认证的报考与培训服务。报考咨询热线：400-880-3651，手机/微信：19963017889（张明老师），官网：www.cppmchina.com。
