项目管理的五大过程组是 PMP 考试的核心框架，贯穿整个项目生命周期。本章将深入解析每个过程组的特点、包含的过程、关键输出以及相互之间的逻辑关系。对于技术背景的学习者，理解这些过程组就像理解软件开发中的 SDLC（软件开发生命周期）阶段，每个阶段都有明确的目标、活动和交付物。
启动 → 规划 → 执行 → 监控 → 收尾
↑ ↓ ↓ ↓ ↓
└───────────────────────────────┘
(迭代与反馈循环)
启动过程组是定义新项目或现有项目新阶段的一组过程。其核心目的是获得授权，正式开始项目或阶段。对于程序员来说，这就像在开始编码前的需求确认和项目立项阶段——确保我们在做正确的事。
启动过程组的关键目标：
启动过程组仅包含 2个过程（需要牢记）：
| 过程名称 | 所属知识领域 | 主要输出 |
|---|---|---|
| 制定项目章程 | 整合管理 | 项目章程、假设日志 |
| 识别相关方 | 相关方管理 | 相关方登记册、相关方参与计划 |
过程间关系：
商业文件 → 制定项目章程 → 项目章程
↓
识别相关方 → 相关方登记册
项目章程是整个项目的”宪法”，一旦签署，项目正式存在。包含内容：
记录所有已识别相关方的信息：
启动阶段的相关方参与度通常最高，因为：
相关方影响力与成本关系：
影响力 ↘ 成本 ↗
高 |＼ ／| 高
| ＼ ／ |
| ＼ ／ |
| ＼ ／ |
低 |________＼／_______| 低
启动 规划 执行 收尾
高频考点提示：
规划过程组是项目管理中最复杂、包含过程最多的过程组，共有 24个过程（占49个过程的近50%）。其目的是制定项目管理计划和项目文件，用于指导项目执行。类比软件开发，这相当于系统设计和架构阶段——在开始编码前详细规划系统架构、数据库设计、接口定义等。
核心特征：
按知识领域分布的24个规划过程：
| 知识领域 | 过程数量 | 关键过程 |
|---|---|---|
| 整合管理 | 1 | 制定项目管理计划 |
| 范围管理 | 4 | 规划范围管理、收集需求、定义范围、创建WBS |
| 进度管理 | 6 | 规划进度管理、定义活动、排列活动顺序、估算活动持续时间、制定进度计划 |
| 成本管理 | 3 | 规划成本管理、估算成本、制定预算 |
| 质量管理 | 1 | 规划质量管理 |
| 资源管理 | 2 | 规划资源管理、估算活动资源 |
| 沟通管理 | 1 | 规划沟通管理 |
| 风险管理 | 5 | 规划风险管理、识别风险、定性风险分析、定量风险分析、规划风险应对 |
| 采购管理 | 1 | 规划采购管理 |
| 相关方管理 | 1 | 规划相关方参与 |
规划过程的逻辑顺序（简化版）：
制定项目管理计划
↓
收集需求 → 定义范围 → 创建WBS
↓
定义活动 → 排列活动顺序
↓
估算资源 → 估算持续时间 → 制定进度计划
↓
估算成本 → 制定预算
↓
确定基准
渐进明细是规划过程组的核心理念，体现在：
滚动式规划（Rolling Wave Planning）：
示例：软件项目的渐进明细
初始阶段： [用户管理模块] [订单模块] [支付模块]
↓
第一次细化： [用户注册][用户登录][权限管理] [订单创建]...
↓
第二次细化： [邮箱注册][手机注册][第三方登录]...
三大基准是项目绩效测量的基础：
组成 = 范围说明书 + WBS + WBS词典
绩效测量基准（PMB）：
PMB = 范围基准 + 进度基准 + 成本基准
规划不是线性的，而是迭代和循环的：
触发重新规划的情况：
敏捷项目中的规划：
规划耗时参考：
传统项目：规划时间 ≈ 20-40% 项目总时间
敏捷项目：每个迭代规划 ≈ 5-10% 迭代时间
执行过程组是完成项目管理计划中确定的工作以满足项目需求的一组过程。这是项目消耗资源最多、产生可交付成果的阶段。对程序员而言，这就是实际编码、测试、集成的阶段——将设计转化为可工作的软件。
执行过程组的核心活动：
资源消耗特点：
资源消耗曲线：
100% | ╱─╲
75% | ╱ ╲
50% | ╱ ╲
25% | ╱ ╲
0% |___╱______________╲___
启动 规划 执行 监控 收尾
执行过程组包含 10个过程：
| 知识领域 | 过程名称 | 关键活动 |
|---|---|---|
| 整合管理 | 指导与管理项目工作 | 执行计划、产生可交付成果 |
| 整合管理 | 管理项目知识 | 利用现有知识、创造新知识 |
| 质量管理 | 管理质量 | 将质量要求转化为行动（QA） |
| 资源管理 | 获取资源 | 获得团队成员、设备、材料 |
| 资源管理 | 建设团队 | 提升能力、促进协作 |
| 资源管理 | 管理团队 | 跟踪绩效、解决冲突 |
| 沟通管理 | 管理沟通 | 确保信息流动 |
| 风险管理 | 实施风险应对 | 执行风险应对计划 |
| 采购管理 | 实施采购 | 获取卖方应答、选择卖方 |
| 相关方管理 | 管理相关方参与 | 满足期望、解决问题 |
过程间的协同关系：
指导与管理项目工作（总协调）
↓
获取资源 → 建设团队 → 管理团队
↓
管理质量（过程改进）
↓
管理沟通 + 管理相关方参与
↓
产生可交付成果
执行过程是变更请求的主要来源：
变更请求类型：
变更流程：
发现问题/机会 → 提出变更请求 → 变更控制委员会(CCB)审批
↓
更新计划 ← 批准
↓
执行变更 → 验证变更
管理项目知识是PMBOK第6版新增的过程，反映了知识管理的重要性：
显性知识 vs 隐性知识：
知识管理工具：
知识管理矩阵：
显性知识 隐性知识
分享： 知识库/Wiki 师徒制/结对编程
获取： 文档学习 观察/实践
创造： 经验总结 头脑风暴
应用： 检查单/模板 专家判断
敏捷中的知识管理：
管理质量（QA）vs 控制质量（QC）：
| 对比维度 | 管理质量(QA) | 控制质量(QC) |
|---|---|---|
| 所属过程组 | 执行 | 监控 |
| 关注点 | 过程 | 可交付成果 |
| 目的 | 过程改进 | 验证可交付成果 |
| 性质 | 预防性 | 检查性 |
| 责任人 | 质量保证部门 | 项目团队 |
质量保证活动示例：
持续改进循环（PDCA）：
Plan（规划）→ Do（执行）
↑ ↓
Act（改进）← Check（检查）
监控过程组是唯一贯穿项目始终的过程组，从项目启动到收尾都在进行。它就像软件开发中的持续集成/持续监控（CI/CD）——不断检查项目健康状态，及时发现偏差并采取措施。
监控过程组的独特性：
监控的层次：
项目层面监控
├── 过程监控（各过程组的执行情况）
├── 绩效监控（进度、成本、质量、范围）
└── 风险监控（风险状态、新风险识别）
监控过程组包含 12个过程：
| 知识领域 | 过程名称 | 监控重点 |
|---|---|---|
| 整合管理 | 监控项目工作 | 整体绩效 |
| 整合管理 | 实施整体变更控制 | 所有变更请求 |
| 范围管理 | 确认范围 | 可交付成果验收 |
| 范围管理 | 控制范围 | 范围蔓延 |
| 进度管理 | 控制进度 | 进度绩效 |
| 成本管理 | 控制成本 | 成本绩效 |
| 质量管理 | 控制质量 | 产品质量 |
| 资源管理 | 控制资源 | 资源使用率 |
| 沟通管理 | 监督沟通 | 沟通有效性 |
| 风险管理 | 监督风险 | 风险状态 |
| 采购管理 | 控制采购 | 合同绩效 |
| 相关方管理 | 监督相关方参与 | 参与度水平 |
挣值管理（EVM）核心指标：
基础值：
绩效指标：
进度偏差：SV = EV - PV （负值表示落后）
成本偏差：CV = EV - AC （负值表示超支）
进度绩效：SPI = EV / PV （<1 表示落后）
成本绩效：CPI = EV / AC （<1 表示超支）
完工估算（EAC）公式：
典型情况：EAC = BAC / CPI
非典型情况：EAC = AC + (BAC - EV)
考虑SPI：EAC = AC + (BAC - EV) / (CPI × SPI)
整体变更控制流程：
变更请求提出 → 影响分析 → CCB评审 → 批准/拒绝
↓ ↓
记录变更 执行变更
↓
验证变更 → 更新文档
变更控制委员会（CCB）：
配置管理：
四种变更类型对比：
| 类型 | 时机 | 目的 | 示例 |
|---|---|---|---|
| 纠正措施 | 偏差发生后 | 回到基准 | 加班赶进度 |
| 预防措施 | 风险识别后 | 避免偏差 | 增加测试覆盖 |
| 缺陷补救 | 缺陷发现后 | 修复缺陷 | 修复bug |
| 更新 | 持续 | 反映现状 | 更新风险登记册 |
趋势分析技术：
收尾过程组包含 2个过程，负责正式结束项目或阶段的所有活动。这就像软件发布后的部署、文档整理和项目总结——确保所有工作都已完成，经验得到总结。
两个收尾过程：
收尾类型对比：
| 对比维度 | 行政收尾 | 合同收尾 |
|---|---|---|
| 范围 | 整个项目或阶段 | 特定合同 |
| 时机 | 项目结束时 | 每个合同完成时 |
| 次数 | 一次 | 多次（每个合同） |
| 负责人 | 项目经理 | 采购经理 |
| 重点 | 内部流程 | 外部关系 |
重要原则：即使项目提前终止，也必须执行收尾过程。
经验教训（Lessons Learned）是组织过程资产的重要组成部分：
经验教训收集时机：
经验教训登记册内容：
情况描述 → 问题根因 → 采取措施 → 效果评估 → 改进建议
知识转化路径：
个人经验 → 项目经验教训 → 组织过程资产 → 最佳实践
回顾会议 知识库更新 标准化
资源释放顺序：
团队解散活动：
移交清单：
验收标准确认：
验收标准（规划时定义）→ 可交付成果（执行时产生）
↓ ↓
验收测试 ← 质量控制（监控时检验）
↓
正式验收（收尾时签字）
项目档案包含：
| 类别 | 具体内容 |
|---|---|
| 项目管理文件 | 章程、管理计划、基准 |
| 项目文档 | 需求文档、设计文档、测试报告 |
| 变更记录 | 变更请求、CCB决议、变更日志 |
| 风险记录 | 风险登记册、风险应对结果 |
| 合同文件 | 合同、采购文档、发票 |
| 沟通记录 | 会议纪要、邮件、报告 |
档案管理原则：
过程组不是离散的、一次性的事件，而是在整个项目期间重叠发生的活动：
活动水平
^
| 启动
| /\ 规划
| / \ /\ 执行
|/ \ / \ /\ 收尾
| X \ / \ /\
| / \ \/ \ / \
| / \ /\ \/ \
| / \ / \ /\ \
| / X \ / \ \
| / / \ \/ \ \
|/_______/___\___/______\_____\___> 时间
监控（贯穿始终）
重叠特征：
过程组间的反馈循环：
启动 → 规划 → 执行 → 收尾
↑ ↑ ↑ ↑
└──────┴──────┴──────┘
监控反馈
典型反馈场景：
预测型生命周期：
启动(5%) → 规划(25%) → 执行(55%) → 监控(10%) → 收尾(5%)
特点：
迭代型生命周期：
迭代1: 启动→规划→执行→监控→评审
迭代2: 规划→执行→监控→评审
...
迭代N: 规划→执行→监控→收尾
特点：
敏捷生命周期：
Sprint 0: 启动（产品愿景、初始待办事项）
↓
Sprint N: Sprint规划 → 每日站会 → Sprint评审 → 回顾
↓
发布: 收尾（部署、文档、总结）
混合型生命周期：
Prompt 示例：
"请帮我创建一个PMP五大过程组的知识图谱，包括：
1. 每个过程组包含的过程（49个过程）
2. 过程间的输入输出关系
3. 关键可交付成果流向
4. 标注哪些是关键路径上的过程"
AI 练习提示词模板：
"基于以下场景生成5道PMP过程组相关题目：
- 场景：一个为期12个月的软件开发项目
- 重点：过程组的选择和顺序
- 难度：中等
- 包含：情景判断和计算题"
使用 AI 生成记忆口诀：
| 传统过程组 | 敏捷实践 |
|---|---|
| 启动 | 产品愿景、团队章程 |
| 规划 | Sprint规划、待办事项梳理 |
| 执行 | Sprint执行、每日站会 |
| 监控 | 燃尽图、Sprint评审 |
| 收尾 | 回顾会议、发布 |
过程组 vs 项目阶段 ❌ 错误：先完成所有规划，再开始执行 ✅ 正确：过程组在项目中迭代和重叠
项目章程的制定者 ❌ 错误：项目经理制定项目章程 ✅ 正确：发起人或PMO制定，项目经理协助
变更批准权限 ❌ 错误：项目经理可以批准所有变更 ✅ 正确：超出权限的变更需要CCB批准
监控过程组的时机 ❌ 错误：在执行完成后才开始监控 ✅ 正确：监控贯穿项目始终
EVM计算错误 ❌ 错误：EAC = BAC - AC ✅ 正确：EAC = BAC/CPI（典型情况）