五大过程组和十大知识领域怎么对应？

项目管理五大过程组十大领域，并不是两套需要死记的清单。过程组回答“现在处于哪个管理阶段”，知识领域回答“这个阶段要管什么对象”，两者交叉，才落到具体过程。

这套矩阵由 PMI 在《PMBOK 指南》第六版（2017）中系统化，共 5 个过程组、10 个知识领域、49 个过程。第七版转向原则和绩效域，2025 年发布的第八版继续沿这一方向调整。本文讨论经典矩阵；如果组织按新版体系管理，可把它当作检查清单，而不是唯一流程。

下面先拆两个维度，再用矩阵看对应关系，按五个过程组说明输入、动作和产出物，并指出两个高发返工环节。

先把两个维度分开：过程组管节奏，知识领域管对象

五大过程组：从立项到收尾的五类管理动作

启动、规划、执行、监控、收尾。它们不是五个割裂的阶段，而是五类管理动作；在迭代项目里，每个迭代都可能重复规划、执行和监控。

十大知识领域：项目要管好的十类对象

• 整合管理：统筹目标、计划、变更与收尾，贯穿五个过程组。
• 范围管理：明确做什么、不做什么，控制范围蔓延。
• 进度管理：拆活动、排顺序、估工期、定计划。
• 成本管理：估算成本、制定预算、控制支出。
• 质量管理：定标准、做保证、查结果。
• 资源管理：解决谁来做、够不够、如何协作。
• 沟通管理：确定谁需要什么信息、何时给、怎么给。
• 风险管理：识别不确定性，分析影响，准备应对。
• 采购管理：决定外部买什么，管理合同与供应商。
• 相关方管理：识别受影响和能影响项目的人，管理参与。

49 个过程：两个维度的交叉点

每个过程都有输入、工具与技术、输出。过程组是纵轴，知识领域是横轴，交叉点就是具体过程。49 个过程不是 49 道必须逐条执行的工序，PMBOK 本身强调裁剪。

五大过程组和十大知识领域怎么对应：一张矩阵看懂

先看总量：启动 2 个、规划 24 个、执行 10 个、监控 12 个、收尾 1 个，合计 49 个。下表按知识领域分行、按过程组分列，单元格是过程数量。

收尾过程组只有整合管理的 1 个过程，即结束项目或阶段，所以没有单列。除整合管理外，每行相加就是该领域的过程总数；整合管理再加这 1 个收尾过程，合计 7 个。

横看：一个知识领域的全生命周期

范围管理在规划阶段有 4 个过程，从规划范围、收集需求、定义范围到创建 WBS；在监控阶段有确认范围和控制范围 2 个过程。风险管理更分散：5 个在规划，1 个在执行，1 个在监控。横看能看清一个领域从“怎么定”到“怎么控”的路径。

纵看：一个过程组要处理哪些领域

规划过程组覆盖全部 10 个知识领域，24 个过程接近总数的一半；监控过程组也覆盖 10 个领域，执行过程组覆盖 7 个，启动只涉及整合与相关方，收尾只涉及整合。纵看能判断当前阶段的工作面。

看贯穿：哪条线不能只放在一个阶段

整合管理是唯一在五个过程组都有过程的领域；相关方管理从启动延伸到监控；范围、进度、成本、质量、资源、沟通、风险、采购在收尾阶段没有独立过程，收尾统一落在整合管理的“结束项目或阶段”。矩阵的价值不是背熟 49 个名字，而是快速定位现在要管什么、该产出什么。

按五个过程组走一遍：输入、动作、产出物

下表把五个过程组的共同动作压缩成一行，具体项目还要按规模和风险裁剪。

五组动作不是一次性串行：执行和监控通常并行，规划会随着信息增加而滚动更新。

项目范围与目标怎么定

目标先写进项目章程：要解决什么问题、交付什么成果、成功标准是什么、谁批准。范围再往下拆：收集需求，写范围说明书，明确产品范围、项目范围、验收标准和除外责任，再用 WBS 拆到可估算、可分配的程度。验收标准如果无法用测试、演示或检查来验证，就说明范围还没定清。

计划、执行、监控怎么衔接

计划段的核心是定基准：范围基准、进度基准、成本基准，加上质量、资源、沟通、风险、采购和相关方参与等子计划。执行段按基准产出可交付物，同时收集工作绩效数据。监控段拿实际数据对比基准，发现偏差后先分析原因，再决定是否变更；变更必须走整体变更控制，评估对范围、进度、成本、质量和风险的影响，批准后才能更新计划。

三段的连接点是数据和变更：执行产生数据，监控判断数据，变更把判断转成新的计划。

两个高发返工环节，以及怎么规避

范围与需求没定清：后面反复返工

常见表现是需求散落在聊天记录和表格里，开发按理解做，测试按旧文档验，验收时才发现双方说的不是同一个东西。规避方法不复杂：需求有统一入口和责任人；每条需求能追溯到来源和验收标准；WBS 覆盖全部交付物；范围说明书写明除外责任；范围变更进入统一通道。

变更控制失效：范围蔓延推高进度和成本

另一类返工来自“先做了再说”。口头变更没有记录，基线随时被覆盖，最后进度和成本一起失控。做法是：先有基线，再有变更；变更申请写清原因和影响；由有权限的人审批；批准后同步更新计划、基准和相关文档；拒绝的变更也要留痕。如果一项变更说不清会影响哪些交付物、工期和成本，就不应该直接进入执行。

把矩阵落到工具里：禅道如何承载五个过程组

矩阵落到工具，不是把 49 个过程做成 49 个菜单，而是让输入、产出和变更记录连起来。以多项目并行的中大型研发组织为例，禅道用项目集、项目、产品、执行四个核心管理结构组织工作，把需求、任务、Bug、用例和文档放在同一组关联数据里。

启动与规划：立项、目标、计划、基线

立项时把项目目标、范围、里程碑和责任人落到项目对象；规划时用项目计划和迭代计划安排阶段与交付节奏，结合预计工时、资源日历和评审节点形成可跟踪的计划。需求与设计文档评审通过后可锁定基线，后续修改走变更申请、影响评估和审批。

执行、监控与收尾：让记录可追溯

执行阶段，需求、任务、Bug、用例和文档相互关联，产品、开发、测试围绕同一组数据协作，看板或 Scrum 迭代承接日常推进。监控阶段用基线、变更记录、工时投入、进度和 Bug 分布看偏差，问题、风险、机会可以单独建账并明确责任人。收尾阶段完成验收和移交，把文档、测试报告和变更历史留在平台里，供下一个项目复用。工具能提供记录和追溯，项目目标是否达成、资源如何取舍，仍要由团队判断。想了解项目管理全流程的承载方式，可以查看禅道项目管理解决方案。

常见问题

49 个过程必须全部执行吗？

不必。PMBOK 强调按项目规模、复杂度和风险裁剪。小项目可以合并规划文件、简化审批；高风险、跨组织的项目则需要更完整的基准和变更记录。判断标准不是做了几个过程，而是关键风险有没有被覆盖。

敏捷项目还能用这张矩阵吗？

可以，但用法不同。敏捷把规划、执行、监控压缩到短迭代里重复发生；矩阵可以用来检查一个迭代是否漏掉范围确认、风险应对或相关方沟通，而不是要求补齐全部文档。

第六版、第七版、第八版该按哪个版本学？

看用途。考试按当前考试大纲和指定教材；组织内落地，先确认大家用的是哪一版框架。第六版的矩阵适合做过程检查表，第七版和第八版的原则、绩效域适合做目标和价值判断，两者不必互相替代。

回到开头的问题：五大过程组和十大知识领域不是一一对应，而是同一项目的两个维度。过程组给节奏，知识领域给对象，49 个过程是交叉点。这套项目管理五大过程组十大领域的框架，价值不在背熟名词，而在项目例会上能快速定位：现在在哪个过程组，要管哪个知识领域，应该产出什么。