06 过程：概述

06 过程：概述

4.1 定义：五大过程组（IPECC）

什么是过程组

过程组（Process Group） 不是项目阶段，而是项目管理活动的逻辑分组。五大过程组贯穿项目的每个阶段（如设计阶段有自己的启动-规划-执行-监控-收尾）。

     I           P           E           M&C          C
  启动         规划         执行        监控         收尾
Initiating   Planning    Executing   Monitoring   Closing
                                     &
                                    Controlling

五大过程组速览

过程组	英文	核心问题	主要产出
启动	Initiating	这个项目值得做吗？谁来做？	项目章程、干系人登记册
规划	Planning	怎么把这事做成？	项目管理计划、三大基准
执行	Executing	怎么按计划干活？	交付物、团队绩效
监控	M&C	还在正轨上吗？	绩效报告、变更请求
收尾	Closing	怎么正式结束？	最终交付验收、经验教训

五个过程组不是五个阶段

  错误理解（线性的）：
  启动 → 规划 → 执行 → 监控 → 收尾

  正确理解（重叠的）：
  启动 ────────────
       规划 ────────────
            执行 ────────────
                 监控 ────────────
                      收尾 ────

• 监控贯穿项目始终（从启动到收尾每一刻都在监控）
• 规划在前半段密集，但执行中随时可能回到规划（变更需要重新规划）
• 大型项目的多个阶段不是串行的：设计阶段和施工阶段可能局部重叠

49 个过程在各过程组的分布

知识领域	启动	规划	执行	监控	收尾	合计
整合	1	1	2	2	1	7
范围	0	4	0	2	0	6
进度	0	5	0	1	0	6
成本	0	3	0	1	0	4
质量	0	1	1	1	0	3
资源	0	2	3	1	0	6
沟通	0	1	1	1	0	3
风险	0	5	1	1	0	7
采购	0	1	1	1	0	3
干系人	1	1	1	1	0	4
合计	2	24	10	12	1	49

醒目的数字： 规划占了 24 个过程（近一半），印证"规划是项目管理的灵魂"。执行 10 个，监控 12 个------说明 PDCA 中 Check & Act 的比重和执行相当，甚至略多。

过程组与知识领域的交叉

         启动 │ 规划 │ 执行 │ 监控 │ 收尾
  整合    ●  │  ●  │  ●  │  ●  │  ●    ← 唯一贯穿全部五个
  范围       │ ●●  │     │ ●●  │
  进度       │ ●●●●●│     │  ●  │
  成本       │ ●●  │     │  ●  │
  质量       │  ●  │  ●  │  ●  │
  资源       │ ●●  │ ●●● │  ●  │
  沟通       │  ●  │  ●  │  ●  │
  风险       │ ●●● │  ●  │  ●  │
  采购       │  ●  │  ●  │  ●  │
  干系人  ●  │  ●  │  ●  │  ●  │

整合管理 是唯一横跨全部五个过程组的知识领域------启动(制定章程)、规划(制定计划)、执行(指导与管理)、监控(监控项目+实施变更)、收尾(结束项目)。

IPECC 与裁剪

不是每个项目都需要走完 49 个过程。裁剪的原则：

项目规模	过程组保留度
微型（1-3人/1月）	启动(章程邮件) + 简单规划 + 执行 + 收尾、监控简化
小型（3-10人/3月）	保留核心 20-25 个过程
中型（10-50人/6-12月）	标准裁剪，30-35 个过程
大型（50+人/1年+）	接近完整的 49 个过程

一句话： IPECC 五步，是项目管理最底层的操作系统。启动定方向，规划定路线，执行踩油门，监控看仪表盘，收尾熄火入库。

---

五大过程组的相互作用

过程组不是孤立的------它们之间有持续的信息流和控制流。

                  ┌──────────────────────────┐
                  │       监控与控制          │
                  │    (贯穿全生命周期)        │
                  └───────────┬──────────────┘
                              │
        绩效数据 ─────────→ 对比基准 ──→ 偏差 ──→ 变更请求
                              │                       │
                              ▼                       ▼
  ┌──────┐    ┌──────┐    ┌──────┐              ┌──────┐
  │ 启动  │───→│ 规划  │───→│ 执行  │              │ 收尾  │
  │      │    │      │    │      │              │      │
  │ 章程  │    │ 计划  │    │ 交付物 │              │ 归档  │
  │      │    │ 基准  │    │ 数据   │              │ 移交  │
  └──────┘    └──────┘    └──┬───┘              └──────┘
                  ▲          │                      ▲
                  │          │                      │
                  └──────────┼──────────────────────┘
                             │
                       变更请求触发重新规划

关键交互场景：

交互	说明	例子
启动 → 规划	章程是规划的输入	章程定义了项目目标和关键干系人，规划基于它展开
执行 → 监控	执行产生工作绩效数据，监控分析数据	开发完成 3 个功能 → 监控对照进度基准 → 发现慢 1 天
监控 → 规划	偏差超出阈值，触发变更和重新规划	SPI=0.7 → 发起变更 → 调整进度基准
监控 → 执行	批准的变更请求回到执行层落实	CCB 批准了加功能 → 开发团队纳入下一个 Sprint
执行 → 收尾	交付完成 → 移交 → 关闭	所有验收通过 → 合同收尾 + 行政收尾

循环的本质： IPECC 是一个不断旋转的飞轮。每一圈的输出都变成下一圈的输入，每一次监控都在修正航向。

---

项目阶段 vs 过程组

这是 PMP 考试最常见的混淆点之一。

维度	项目阶段（Phase）	过程组（Process Group）
定义	项目生命周期的时间分段	项目管理活动的逻辑分组
问什么问题	"现在处于项目的哪个时间段？"	"现在在做哪一类管理活动？"
关系	串行或局部重叠	贯穿每个阶段
依赖	阶段之间有先后依赖	过程组之间有逻辑交互
例子	设计阶段 → 施工阶段 → 测试阶段	每个阶段内部都有 I→P→E→M→C

  一个三阶段项目的过程组分布：

        设计阶段              施工阶段              测试阶段
    I P E M C            I P E M C            I P E M C
    ├─┼─┼─┼─┤            ├─┼─┼─┼─┤            ├─┼─┼─┼─┤

  每个阶段 = 一个独立的 IPECC 微循环

对比	阶段	过程组
阶段性交付物	设计阶段结束 → 设计图纸	规划过程组结束 → 项目管理计划
关口/审批	阶段关口（Phase Gate）：设计评审通过才能进入施工	没有"规划关口"，规划完直接进入执行
重复性	一个阶段走完一次	过程组在各个阶段不断重复

考试陷阱：

❌ "项目进入执行过程组后就不再规划了"
✅ 执行过程组中，变更可能随时触发回到规划

❌ "规划过程组在项目开始时就全部完成"
✅ 滚动式规划：近期的详细规划，远期的粗粒度规划

❌ "每个阶段有自己独立的过程组"
✅ 对！但各个阶段的输出会累积传递。设计阶段的交付物是施工阶段的输入。

一句话： 阶段是时间轴上的大块头（设计→开发→测试），过程组是每一块内部的微型管理循环（I-P-E-C-C）。一个项目有 3 个阶段，就等于有 3 轮 IPECC。

---

4.2 太极 49 与裁剪

什么是"太极 49"

PMBOK 第六版的 49 个过程，被 PM 圈戏称为"太极 49"------因为它们像太极拳，看似柔和，实则环环相扣、借力打力。49 个过程不是 49 个独立的招式，而是一个相互平衡的动态系统。

       规划为主（24 个）             执行为主（11 个）
       ┌────────────────┐       ┌────────────────┐
       │ 范围·进度·成本  │       │ 资源·沟通·采购  │
       │ 风险·质量·干系人 │  ←→  │ 干系人·质量    │
       └───────┬────────┘       └───────┬────────┘
               │                       │
       ┌───────┴───────────┬───────────┴───────┐
       │                   │                   │
       ▼                   ▼                   ▼
   启动（2）           监控（12）           收尾（1）
   定方向              维持平衡              善后归位

太极 49 的阴阳哲学：

阳面（向外、主动）	阴面（向内、约束）
执行过程组（做）	监控过程组（看）
多、快（进度激进）	好、省（质量+成本保守）
变更推动（客户要加功能）	变更控制（范围不能漫无边界）
干系人争取（拉更多人参与）	干系人管理（太多人参与会乱）

太极的真谛： 不是 49 个过程全部打一遍，而是在过程中根据实际情况借力打力------进度压紧了就放松质量？不行，质量的反作用力会让你付出更多代价。

裁剪的对象

裁剪不是"不做"，是"有意识地选择做到什么程度"。

裁剪对象	可以怎么裁	例子
过程数量	去掉不适用的过程	纯内部项目跳过采购管理全部 3 个过程
过程的严格度	同一个过程做到不同颗粒度	微型项目：风险管理 = 一张 Excel；大型项目：完整的风险登记册+定量分析
输入/工具/技术	选择最合适的工具	沟通可以用 Slack 而非正式报告；估算可以用类比而非自下而上
生命周期	选预测型/敏捷/混合	需求明确→瀑布；需求模糊→敏捷；核心模块瀑布+外围敏捷
开发方法	同一项目内不同模块用不同方法	底层架构用瀑布（稳定），上层应用用敏捷（灵活）
管理计划/文件	合并或简化文档	把沟通管理计划和干系人参与计划合并

裁剪考虑的因素

因素类别	具体要问的问题
项目特征	规模多大？多复杂？多紧急？需求稳定吗？
团队特征	团队有多大？在一个地方还是分散？经验丰富吗？
组织特征	公司文化是鼓励创新还是求稳？PMO 要求多严？
行业特征	强监管吗？（医疗、金融）变更代价高吗？（建筑）
干系人特征	客户想深度参与还是只想要结果？发起人偏好什么沟通方式？
技术特征	技术成熟吗？有历史数据可以参考吗？
风险水平	高风险 → 风险管理过程要加严；低风险 → 可简化
合规要求	有法律/审计要求吗？需要保留哪些审计证据？

裁剪决策矩阵示例：

如果......	那么......
项目只有 3 个人、1 个月	砍掉 70% 的过程，只保留启动+简单规划+执行+收尾
客户要求每两周看到进展	选敏捷，用 Sprint 节奏，弱化瀑布式阶段关口
行业监管严格（金融核心系统）	风险管理+变更控制不能简化，反而要强化
团队分布 3 个国家	沟通管理过程要加重，必须有时区协调机制
技术方案不确定	选滚动式规划，近期详细、远期粗粒度

一句话： 太极 49 不是让你背下 49 个过程，而是理解 49 个过程之间的平衡关系，然后根据项目环境，精准选出需要的那几招，做到恰到好处。

---

4.3 什么是 Scrum

Scrum 是敏捷世界里最广泛使用的框架。它不是方法论，是轻量级框架------只定义了必须的规则，具体做法留给团队。

Scrum 的核心记忆：3355

    ┌──────────┐
    │  3355    │
    └────┬─────┘
         │
  ┌──────┼──────┐
  │      │      │
  ▼      ▼      ▼
3 角色  3 工件  5 事件  5 价值观
Roles Artifacts Events Values

3 个角色

角色	职责	不是
产品负责人 PO	定义做什么、排优先级、对产品价值负责	不是"需求传话筒"
Scrum Master	确保 Scrum 被正确理解和执行，移除障碍，教练	不是"项目经理"
开发团队	每个 Sprint 交付可工作的产品增量	3-9 人，跨职能、自组织

关键三者关系： PO 管"做什么"，SM 管"Scrum 有没有做对"，开发团队管"怎么做"。

3 个工件（Artifacts）

工件	内容	谁维护
产品待办列表（Product Backlog）	所有需求的有序列表，唯一的优先级来源	PO
Sprint 待办列表（Sprint Backlog）	当前 Sprint 要完成的需求 + 交付计划	开发团队
产品增量（Increment）	Sprint 结束时交付的可用成果，必须符合"完成定义"	开发团队

5 个事件（Events）

事件	时长	目的
Sprint	1-4 周（固定）	一个完整的交付周期，包含以下 4 个会 + 开发工作
Sprint 计划会	≤ 8 小时（4 周 Sprint）	PO 讲优先级，团队选能做多少 → 产出 Sprint Backlog
每日站会	15 分钟	昨天做了什么？今天做什么？有什么障碍？
Sprint 评审会	≤ 4 小时（4 周 Sprint）	给干系人演示增量，收集反馈，调整 Product Backlog
Sprint 回顾会	≤ 3 小时（4 周 Sprint）	团队内部反思：哪里好？哪里要改？下次 Sprint 做什么改进？

Sprint 是容器，4 个会在容器内发生。Sprint 的长度一旦确定，整个项目期间不变。

5 个价值观

价值观	表现
承诺（Commitment）	团队承诺 Sprint 目标，而不是承诺每个任务都完成
专注（Focus）	Sprint 期间只做 Sprint Backlog 里的事，不接收外加需求
开放（Openness）	好消息坏消息都公开，障碍不藏着
尊重（Respect）	每个角色不可或缺，PO 和开发互相尊重
勇气（Courage）	敢于说"完不成"、敢于砍功能、敢于承认错误

Scrum 工作流程

  Product Backlog              Daily Scrum
  (PO 维护，持续排序)             (每天 15 分钟)
         │                          │
         ▼                          ▼
  ┌──────────────────────────────────────────────┐
  │              Sprint (1-4 周)                  │
  │                                              │
  │  ┌────────────┐              ┌────────────┐  │
  │  │ Sprint     │   开发工作    │ Sprint     │  │
  │  │ 计划会     │──────────────→│ 评审会     │  │
  │  │ (选需求)   │   ←────────── │ (演示增量) │  │
  │  └────────────┘   Sprint     └────────────┘  │
  │                   Backlog           │        │
  │                                     ▼        │
  │                              ┌────────────┐  │
  │                              │ Sprint     │  │
  │                              │ 回顾会     │  │
  │                              │ (改进过程) │  │
  │                              └────────────┘  │
  └──────────────────────────────────────────────┘
         │                          │
         ▼                          ▼
    Sprint 交付增量            下一个 Sprint

精髓： Scrum 的精髓不是 3355 的数字，而是固定节奏的迭代------每周/每两周交付一个可用增量→获取反馈→调整方向→继续交付。用节奏感对抗不确定性。

IPECC 视角看 Scrum

IPECC	在 Scrum 中的对应
I 启动	项目愿景、初始 Product Backlog
P 规划	Sprint 计划会（滚动式规划）
E 执行	Sprint 开发 + 每日站会
M 监控	Sprint 评审（看产品）+每日站会（看进度）+燃尽图
C 收尾	每个 Sprint 都交付增量 = 每个 Sprint 都是一次小收尾

Scrum 没有消灭 IPECC，而是把 IPECC 压缩到了一个 Sprint 里，加速运转。

---

4.4 敏捷中冲突与迭代回顾

快速决策与共识方法

大拇指投票法（Thumb Voting）

最简单的团队决策工具，3 秒钟完成一轮表决。

手势	含义	团队行动
👍 拇指向上	同意，支持	---
👎 拇指向下	不同意，反对	必须说出反对理由和替代方案
✊ 拇指横放	中立，可接受但不热切	选择性发言

只要有一个 👎，就必须停下讨论，直到解决反对意见或共识达成。

五指拳投票法（Fist of Five）

升级版共识工具，从 0 到 5 表达支持程度。

手势	含义
✊ 0 指（握拳）	完全反对，要否决
☝️ 1 指	有严重疑虑，需要重点讨论
✌️ 2 指	有些疑虑，但可以听大家的
🤟 3 指	可以接受，不阻止
🖖 4 指	支持，认为是个好主意
🖐️ 5 指	全力支持，愿意带头推动

使用规则：

• 如果全队 ≥ 3 指 → 通过
• 如果任何人 ≤ 2 指 → 停下来听他讲

价值： 不是所有人都要 5 分，而是没有人是完全反对（0-1 分）。尊重少数意见，但不被少数绑架。

Sprint 回顾会

回顾会 ≠ 吐槽大会

❌ 回顾会的错误用法	✅ 回顾会的正确用法
抱怨"那个需求太烦了"	分析"为什么那个需求开发效率低？是PO 没写清楚还是我们没问清楚？"
把责任推给外部	聚焦自己能改变的事
列了一大堆改进点不执行	最多选 1-2 个改进，纳入下个 Sprint

回顾会的标准节奏

  ① 设定基调（2 分钟）
     "今天是安全空间，对事不对人，只找改进点"
  
  ② 收集数据（10 分钟）
     每个人在便利贴上写：好 / 不好 / 困惑
  
  ③ 生成洞察（10 分钟）
     归类 → 找共性 → "为什么这个问题反复出现？"
  
  ④ 决定改进（5 分钟）
     最多选 1-2 个改进，指定谁来做，下个 Sprint 检验
  
  ⑤ 关闭（3 分钟）
     回顾今天的回顾会本身好不好，感谢参与者

回顾方法 SSCC

SSCC 是四个维度的简洁回顾框架：

  S - Start（开始做）
      我们应该开始做什么来提升？

  S - Stop（停止做）
      哪些事在浪费我们的时间和精力？立刻停。

  C - Continue（继续做）
      什么做得很好？继续保持，不要丢掉。

  C - Change（改变做）
      什么要做但可以做得更好？怎么改？

维度	例子
Start	"开始把每日站会从 Slack 文字版改成视频面对面"
Stop	"停止把未完成的代码带到下一个 Sprint"
Continue	"继续做代码审查，它确实减少了 BUG"
Change	"变更不是不做，而是 Sprint 中途不接新需求，排到下一个"

SSCC 操作法

  每人 4 张便利贴，分别写 S / S / C / C
      ↓
  贴在白板上的对应区域
      ↓
  SM 引导讨论：合并同类项 → 选出 Top 1-2 付诸行动
      ↓
  下个 Sprint 回顾会先检查：上一次的改进做到了没？

SSCC 的精髓： 回顾会的产出不是一大张便利贴，是下个 Sprint 要做的一件具体改变。不做改变的回顾会 = 集体浪费时间。

冲突在敏捷中的处理

冲突场景	化解工具
PO 和开发对需求优先级争执	五指拳投票法：谁的理由说服更多人？
团队对技术方案有分歧	设定 Spike（限时实验）：2 天内各试一个方案，拿数据说话
站会上某人每次都滔滔不绝	SM 私下提醒："15 分钟是所有人的时间，不是一个人的"
回顾会上有人攻击个人	SM 立刻打断："对事不对人，说行为不说人"

敏捷处理冲突的原则： 不回避、不对人、用数据、定规则、限时间。

---

4.5 持续改进与 PDCA

PDCA：持续改进的底层引擎

PDCA（戴明环）是质量管理和过程改进的元模型。项目管理中，它不是某个阶段要做的事，而是每个过程都在运转的底层循环。

        ┌──────────┐
        │  Plan    │  计划：确定目标 + 制定行动方案
        │   计     │
        └────┬─────┘
             │
    ┌────────┼────────┐
    │        ▼        │
    │  ┌──────────┐   │
    │  │   Do     │   │  执行：按计划行动，记录过程数据
    │  │   做     │   │
    │  └────┬─────┘   │
    │       │         │
    │       ▼         │
    │  ┌──────────┐   │
    │  │  Check   │   │  检查：对比计划 vs 实际，分析偏差
    │  │   查     │   │
    │  └────┬─────┘   │
    │       │         │
    │       ▼         │
    │  ┌──────────┐   │
    └─→│   Act    │   │  改进：标准化成功经验，修正偏差根因
       │   改     │───┘
       └──────────┘

PDCA 在项目中的每一环

阶段	项目中的对应动作	频率
P - 计划	制定管理计划、定义 WBS、估算、风险应对	项目启动 + 每阶段
D - 执行	执行计划、生产交付物、记录工作绩效数据	每天
C - 检查	偏差分析、EVM、质量审计、风险审计	每周期/里程碑
A - 改进	变更请求、纠正措施、预防措施、更新经验教训	发现偏差时立即

PDCA 在不同层级的体现

层级	PDCA 体现	频率
每日	站会 → 发现障碍 → 当天清除	每天
每个 Sprint	Sprint 计划→开发→评审→回顾	1-4 周
每个阶段	阶段规划→执行→阶段评审→调整下阶段	数月
整个项目	启动→规划→执行→监控→收尾	一次

PDCA 不是大循环转一圈，是大循环套小循环------日循环套在 Sprint 循环里，Sprint 循环套在阶段循环里，阶段循环套在项目循环里。

PDCA 与问题解决

步骤	工具
P - 找到问题根因	5Why、鱼骨图、帕累托分析
P - 制定改进方案	头脑风暴、基准对照
D - 试点执行	选一个 Sprint / 一个模块先试
C - 验证效果	前后指标对比（缺陷率、交付速度）
A - 固化或调整	效果好→纳入标准流程；效果差→回到 P

一句话： PDCA 不是学完就放下的理论，是每一次发现偏差、每一个 Sprint 回顾、每一个里程碑评审时都在运行的肌肉记忆。计划-执行-检查-改进，缺一环就叫半途而废。

---

注：SPCA vs PDCA

在 2.15 中介绍了 SPCA（Sense-Plan-Check-Act），强调在计划之前先感知问题本质。SPCA 是 PDCA 的增强版------避免在错误的方向上做完美的计划。二者关系：

  SPCA = Sense → PDCA
          (感知)  (完整循环)

在过程管理的语境中，PDCA 是标准化用语，但在实际应用中，建议先 S 再 PDCA------想清楚再动手。

---

4.6 质量管理的水平与发展

质量管理的五个阶段

  成熟度
    ↑
    │                         ★ TQM（全面质量管理）
    │                         │  "质量是所有人的事"
    │                         │
    │              ★ DFX（面向 X 的设计）
    │              │  "把质量设计进去，不是检测出来"
    │              │
    │      ★ QA（质量保证）
    │      │  "按流程做，质量就自然好"
    │      │
    │  ★ QC（质量控制）
    │  │  "做完了检查，不合格返工"
    │  │
    │★ 用户发现
    │  "用户投诉了才知道有问题"
    └──────────────────────────────────────→ 时间

零级：用户发现

产品上线/交付后，由用户在使用中发现缺陷。

特征	后果
全过程没有任何质量活动	每一次返工的成本是设计和制造阶段的 10-100 倍
"做完了看看能不能用"	客户满意度最低，但修复代价最高

一级：QC（质量控制）

做完之后检查，不合格的挑出来返工或扔掉。

手段	局限
测试、检查、抽样	只能发现缺陷，不能防止缺陷
质量 = 测试团队的事	缺陷已经发生，修复只是止损

QC 的核心逻辑： 质量是检验出来的。

二级：QA（质量保证）

不靠最终检查，而是靠过程的规范性来保障质量。

手段	价值
质量审计、过程审查	检查你是不是按流程做的
标准化流程、模板、检查单	如果过程是对的，结果大概率也是对的

QA 的核心逻辑： 质量是过程保证出来的。

维度	QC	QA
关注	产品	过程
时机	事后	事中+事前
谁做	测试/QC 团队	质量保证团队/审计
问什么	"产品合格吗？"	"过程规范吗？"

三级：DFX（Design for X）

把质量、测试、制造、维护、可靠性等要求，在设计阶段就融入产品。

DFX 子类	含义	例子
DFT（Test）	设计时预留测试接口	芯片留测试引脚
DFM（Manufacturing）	设计时考虑制造可行性	减少零件数量、降低装配难度
DFR（Reliability）	设计时考虑可靠性	冗余设计、降额使用
DFS（Serviceability）	设计时考虑可维护性	模块化、热插拔

DFX 的核心逻辑： 质量是设计出来的。设计阶段花 1 块钱能解决的事，到制造阶段要 10 块，到用户手里要 100 块。

四级：TQM（全面质量管理）

质量不只是质量部门的事，是全组织、全流程、全员的事。

TQM 核心要素	含义
全员参与	CEO 到一线员工，每个人都对质量负责
全过程覆盖	从市场调研到售后服务的完整价值链
持续改进	PDCA 永不停歇
以客户为中心	质量的定义由客户说了算，不是规格书说了算
数据驱动	用统计方法而非经验判断

TQM 的核心逻辑： 质量是一种组织文化，不是一套管理工具。

五个阶段的投入产出比

阶段	1 块钱投入	返工成本
DFX（设计阶段）	预防缺陷	1×
QA（过程控制）	发现过程偏差	10×
QC（成品检查）	发现产品缺陷	100×
用户发现	0	1000×

一图胜千言： 质量管理的进化，就是一个不断把质量活动向左移动的过程------从用户端移到工厂端、从工厂移到设计端、从设计端移到文化端。移动得越左，代价越小。

---

4.7 质量保证 QA 与质量控制 QC

QA 和 QC 是 PMP 考试的高频混淆概念，一字之差，逻辑截然不同。

核心差异速查表

维度	QA（质量保证）	QC（质量控制）
过程组	执行	监控与控制
对象	过程（Process）	结果（Result / Product）
目标	合规------确保过程符合标准	合格------确保产品符合要求
问题	"我们做事的方式对吗？"	"我们做出来的东西对吗？"
性质	预防性（事前+事中）	检测性（事后）
工具技术	质量审计、过程分析、根本原因分析	检查、测试、抽样、控制图
谁做	质量审计员、QA 团队	测试人员、检查员
产出	变更请求、过程改进建议	合格的交付物、缺陷报告

过程组关键区分

        启动        规划          执行          监控         收尾
         │           │            │            │            │
    ───────────── 质量规划  ──── QA ──────── QC ──────── 最终验收
                   (规划)      (执行)       (监控)       (收尾)
                     │           │            │
                 定标准      保证按标准做   检查达标没

• QA 在执行过程组：一边做一边审计过程是否合规，及时提出改进
• QC 在监控与控制过程组：做完产出后，对照标准检查是否合格

工具技术对照

QA 工具（管过程）	QC 工具（管结果）
质量审计：有人来看你的过程是否按标准执行	检查/测试：用方法测量产品是否达标
过程分析：看流程哪里可以优化	控制图：看产出是否在受控范围内
根本原因分析：为什么过程出了问题	帕累托图：哪些缺陷类型占比最高
亲和图/流程图：梳理和优化流程	统计抽样：用样本推断整体质量

案例区分法

场景：一个软件开发项目

情节	是 QA 还是 QC？
审计员抽查：你们的代码审查环节真的在做吗？有记录吗？	QA------在查过程是否合规
测试人员跑了一轮回归测试，发现 3 个 BUG	QC------在查产品是否合格
PM 发现最近 Sprint 的缺陷密度在上升，召集回顾会分析原因	QA------分析过程，找改进点
测试团队用自动化脚本跑了 500 条用例，生成测试报告	QC------检验产出
PM 建议：把代码审查从"建议"改成"必须"，不审查不准合并	QA------改进过程

一句话区分

角色	做什么
QA	"你做对了吗 ？我来看你的过程合不合规。"
QC	"你做对了吗 ？我来查你的结果合不合格。"

经典考题陷阱： 题目说"项目经理发现项目的缺陷率在上升"，问 PM 应该做什么。答案是 QA（分析过程找根因），不是 QC（加大测试力度）------因为测试只能发现更多缺陷，不能阻止缺陷产生。

---

4.8 面向 X 的设计（DFX）

什么是 DFX

DFX（Design for X）是在产品设计阶段就提前考虑到下游所有环节的需求------制造、装配、测试、物流、维护、成本、环境------把这些约束融入设计，而非事后补救。

  传统方式：
  设计 → 制造 → 装配 → 发现问题 → 回头改设计（3 个月后）
  
  DFX 方式：
  设计时就把制造/装配/测试/物流/维护的要求全考虑进去

DFX 常见类型

DFX 类型	含义	核心问题
DFM（Manufacturing）	面向制造的设计	"这个设计在工厂能造出来吗？"
DFA（Assembly）	面向装配的设计	"组装步骤能不能再少几步？"
DFT（Test）	面向测试的设计	"设计时留测试点了吗？出厂怎么测？"
DFR（Reliability）	面向可靠性的设计	"用 5 年会不会坏？最弱的点在哪儿？"
DFL（Logistics）	面向物流的设计	"能装进标准集装箱吗？能堆叠吗？"
DFS（Serviceability）	面向可维护性的设计	"坏了怎么修？能只换坏的部分吗？"
DFC（Cost）	面向成本的设计	"这个零件能不能用更便宜的材料？"
DFE（Environment）	面向环境的设计	"能回收吗？能拆解吗？材料环保吗？"

经典案例：宜家（IKEA）

宜家是 DFX 的极致典范------从设计图的第一笔开始，就已经决定了物流成本、组装体验和终端零售价。

    传统家具厂                    宜家
   ┌──────────┐               ┌──────────┐
   │ 设计好看   │               │ 设计时想好：│
   │ 做出来送   │               │ 怎么平板包装  │
   │ 到家组装   │               │ 怎么自组装    │
   │ 能装就装   │               │ 怎么装进车尾  │
   │ 不行退货   │               │ 怎么最省运费  │
   └──────────┘               └──────────┘
   运输：一辆卡车 20 套        运输：一辆卡车 200 套
   组装：靠师傅                组装：靠客户自己
   价格：贵                    价格：便宜

DFX 维度	宜家的做法	带来的价值
DFL（物流）	平板包装，扁平纸箱	运费降低 80%，一辆卡车装 10 倍货物
DFA（装配）	统一用内六角扳手，不用螺丝刀/锤子	用户自己装，不用请师傅，说明书不用文字
DFC（成本）	用刨花板而非实木，表面贴皮	材料成本省 60%，但外观不输实木
DFM（制造）	全球统一零件规格，跨产品线共用五金件	采购量大→议价权→成本再降
DFE（环境）	可拆解、可回收材料	符合欧盟环保标准，ESG 加分

宜家 DFX 的终极心法： 客户自己搬回家、自己组装、自己乐在其中------把成本最高的环节（运输体积、组装人工）通过设计转移到客户身上，同时让客户觉得这是"DIY 乐趣"。

宜家对项目管理的启发

宜家逻辑	项目管理启示
"设计前就想好怎么运"	WBS 分解前就想好怎么集成、怎么交付
"所有产品用同一种螺丝"	统一团队的模板、工具链、代码规范------降低切换成本
"说明书不用文字，只用图"	对客户的文档要极简可视化------干系人不想读报告，想看仪表盘
"平板包装省运费"	降低非增值成本（等待、交接、返工）→ 提升项目整体效率

一句话： DFX 的精髓------不是在造出问题后去解决问题，而是在设计阶段就让问题根本没机会发生。

---

4.9 TQM 与朱兰

什么是 TQM

TQM（Total Quality Management） 是质量的最高境界------质量不是某个部门的事，是全组织的事。

TQM 的三个"全"

        ┌──────────────────────────────┐
        │            TQM               │
        │                              │
        │   全员        全过程          │
        │  (All People)  (All Process)  │
        │   人人有责      端到端覆盖     │
        │                              │
        │         全方位                │
        │      (All Dimensions)         │
        │   全组织 × 多方法             │
        └──────────────────────────────┘

全员（All People）

含义	做法
从 CEO 到一线操作工，每个人都对质量负责	不是质量部的人去"检查"质量，而是每个人在自己的岗位上"做出"质量
质量 = 本职工作的固有部分	质量培训覆盖全员，不是只培训质检员

质量不是"别人的事"。 程序员写出 BUG，测试截住了，BUG 已经发生了。

全过程（All Process）

含义	做法
从市场调研→设计→采购→制造→交付→售后服务，全价值链覆盖	每个环节定义质量标准、每个交接点定义准入准出条件
过程的质量决定了产品的质量	上一个环节的输出不合格 = 下一个环节的灾难

不再靠"最后检查"保质量，而是靠"每个环节对下一个环节负责"。

全方位（All Dimensions）

含义	做法
全组织： 研发、生产、销售、财务、人事------所有部门都纳入质量管理体系	人力资源管"招对人"、采购管"买对料"、财务管"质量成本"
多方法： 不只用一种质量工具，而是统计方法+管理方法+技术方法全套组合	PDCA + 六西格玛 + 精益 + DFX + 质量审计 + 控制图

朱兰：质量管理的建筑师

约瑟夫·朱兰（Joseph M. Juran），与戴明并列质量管理双峰。他的核心贡献：

朱兰质量三部曲（Juran Trilogy）

    质量计划          质量控制          质量改进
  (Quality          (Quality          (Quality
   Planning)         Control)          Improvement)

   定标准             守标准             提标准
   "质量该是什么样？"   "达标了吗？"        "能不能更好？"

阶段	动作	比喻
质量计划	识别客户、定义需求、制定质量目标、设计达标过程	建房子打地基
质量控制	测量实际绩效、对比标准、找偏差、纠正	住房子日常维护
质量改进	识别改进机会、建立改进项目、突破到更高水平	装修升级

朱兰的关键理念

理念	内容
80/20 法则（帕累托原理）	80% 的质量问题来自 20% 的原因------抓住关键少数
适用性定义	质量 = 适用性（Fitness for Use），不是"越高越好"，是"刚好满足客户需要"
质量螺旋	质量不是一次性项目，是不断向上的螺旋上升过程
上层参与	质量的突破必须从管理层开始，不能只靠基层改善

朱兰 vs 戴明

维度	朱兰	戴明
核心贡献	质量三部曲 + 帕累托	PDCA 环 + 14 条原则
质量定义	适用性（客户说了算）	低成本的一致性（统计控制）
方法	项目管理式突破改进	统计过程控制
强调	管理层的规划和突破	全系统的持续改进

TQM 对 PM 的要求

维度	PM 该做什么
全员	让每个团队成员知道自己对哪个质量指标有影响
全过程	评审每个阶段的准入准出标准，把 QA 和 QC 嵌入流程
全方位	不只盯测试，还要关注需求评审质量、代码审查质量、文档质量
持续改进	每个 Sprint 回顾会，必问一句：哪个质量指标能提 10%？

一句话： TQM 不是一种管理技术，是一种管理信仰------质量不是检测出来的，是每一个人在做每一件事的过程中自然流淌出来的。

---

4.23 沟通技巧和方式

沟通漏斗

沟通最大的敌人，不是"没说话"，而是"你以为说明白了"。

  你想说的       100%
       │          ▼
  你实际说的      80%     ← 表达能力
       │          ▼
  对方听到的      60%     ← 注意力、环境噪音
       │          ▼
  对方理解的      40%     ← 背景知识、认知偏差
       │          ▼
  对方记住的      20%     ← 记忆衰减

  从 100% → 20%：每次沟通，80% 的信息在传输途中丢了

五大沟通技巧

1. 简化语言

坏做法	好做法
"根据项目管理信息系统导出的工作绩效数据进行挣值偏差分析"	"我们现在超预算了 15%，比计划慢了 1 周"
对客户说 API/分布式/微服务/容器化	对客户说"这个功能明天上线，操作和旧版一样"

原则： 说对方听得懂的话。对 CFO 说钱，对 CTO 说技术，对用户说体验。

2. 视觉辅助

工具	替代什么
甘特图	"进度正常"三个字换成一条绿线
燃尽图	"还剩一半工作量"换成一根往下走的线
气泡图	"风险矩阵"换成一目了然的红黄绿球
仪表盘	长篇周报换成一张红黄绿灯页面

一图胜千言。人对图形的处理速度是文字的 60,000 倍。

3. 积极倾听

技巧	做法	为什么有效
复述	"所以你的意思是......对吗？"	确认自己没理解歪
提问	"你说的慢，具体是指哪一步慢？"	把模糊变具体
不打断	让对方把话说完	打断 = 传递"你的话不重要"
回应非语言	点头、眼神接触、"嗯"	表示在跟随

4. 有效反馈

坏反馈	好反馈
"这个文档写得不好"	"第三章缺了接口说明，而且格式对不齐。建议加上接口列表，用 Markdown 表格。"
只批评不肯定	先肯定（"思路很清晰"）→ 再具体指出改进点 → 最后鼓励

SBI 反馈模型：

  S - Situation（情境）：什么时候发生的事？
  B - Behavior（行为）：对方具体做了什么？
  I - Impact（影响）：这个行为带来了什么后果？

  例子："昨天站会上（S），你打断了小王三次（B），
        之后小王就没再发言了，我们可能错过了一个重要问题（I）。"

5. 情绪控制

当对方......	PM 应该......
发火	不反击，先说"我理解你的感受"，等对方情绪降温再讲道理
沉默	不是"学会了吗点头"，而是"你怎么看？哪里还不太清楚？"
抵触	不说"你必须做"，说"如果这个不做，对项目会有三个影响......你的意见呢？"

沟通的情绪铁律： 情绪上来时，智商下去。先处理情绪，再处理问题。

三种沟通方式

交互式沟通（Interactive）

特征	适用场景
双向、实时、有来有回	解决冲突、需求讨论、脑暴、一对一面谈
成本最高，但信息最准确	所有需要达成共识的场合

面对面 > 视频 > 电话 > 文字。

推式（Push）

特征	适用场景
发送方主动推送，接收方被动接收	周报、邮件通知、干系人报告
无法确保对方读了/理解了	信息分发，不是共识形成

"我发了邮件" ≠ "对方看了" ≠ "对方懂了" ≠ "对方会行动"。

拉式（Pull）

特征	适用场景
信息放在公共空间，需要的人自己来取	项目文档、维基、知识库、看板
成本最低，但依赖对方主动	大量信息的长期存放和按需获取

三方式组合策略

沟通目标	推荐方式
需要共识和决策	交互式（开会/视频）
通知、报告、同步状态	推式（邮件/周报）
存档、查阅、参考	拉式（共享盘/维基/看板）

一句话： 沟通不是把自己想说的说完，是确保对方理解了你需要他理解的内容。漏斗不会消失，只能靠技巧（简化/可视化/倾听/反馈/控制情绪）和方式（交互/推/拉）一层一层捞回来。

---

4.24 十大知识领域 1------项目整合管理

整合管理是什么

整合管理不是"管某一件事"，而是管所有事之间的接口。其他 9 个知识领域各自管好自己，整合管理让它们统一到同一个目标下。

       范围  进度  成本  质量  资源  沟通  风险  采购  干系人
         │    │    │    │    │    │    │    │    │
         └────┴────┴────┴────┴────┴────┴────┴────┘
                            │
                       整 合 管 理
                   (把所有领域编成一张网)
                            │
                       项 目 成 功

整合管理 =	说明
唯一的知识领域	横跨全部 5 个过程组
PM 的核心职责	其他领域可以委派，整合不能------PM 是项目的总集成师
7 个过程	制定项目章程→制定项目管理计划→指导与管理项目工作→管理项目知识→监控项目工作→实施整体变更控制→结束项目或阶段

整合的四大层次

层次	整合什么	例子
过程整合	各知识领域的过程相互衔接	范围变更 → 自动触发成本重估 + 进度重排
信息整合	分散的数据汇总为全局视图	进度数据 + 成本数据 → 挣值分析
干系人整合	各方的需求和期望综合平衡	技术要先进性，采购要便宜 → PM 找平衡点
交付整合	分块交付的产出拼成完整成果	前端+后端+测试 → 可用的系统

发展趋势

趋势	含义	对 PM 的影响
自动化整合	CI/CD、DevOps 让技术整合自动化	PM 从盯技术集成转向盯业务集成
混合方法	不再纯瀑布或纯敏捷，而是灵活组合	PM 要能裁剪，能把不同节奏的过程组平滑衔接
知识管理成为显学	PMBOK6→7：新增"管理项目知识"过程	知识沉淀和复用 = 整合管理的重要产出
端到端价值流	不只管项目内的整合，还要看项目到运营的衔接	PM 的目光要从"交付验收"延伸到"价值实现"
AI 辅助决策	数据分析辅助偏差检测和变更影响评估	PM 从"算数据"转向"用数据决策"

敏捷场景中的整合管理

敏捷没有消灭整合，只是换了一种形式：

传统整合	敏捷中的整合
专业整合团队做集成测试	CI/CD 流水线自动化集成，每次提交都集成
阶段末做整体协调	每日站会微整合------谁被阻塞了？依赖解了没？
变更控制委员会 CCB 审批	PO + 团队在 Sprint 评审中当场决策
厚重的项目管理计划	轻量的产品待办列表 + 冲刺待办列表 + DoD
PM 一个人做整合	整个 Scrum Team 共同参与------PO 管需求整合，SM 管过程整合，Dev 管技术整合

敏捷整合的精髓：

不是： PM 拿着一份大计划，每周对齐一次
而是： 团队每天站会对齐，每次提交集成，
      Sprint 评审时验证整体，回顾时改进整合方式

整合从"定期的行政动作"变成"持续的工程实践"

一句话： 整合管理是所有知识领域的"胶水"。范围、进度、成本、质量......每个领域做到极致，如果没有整合，就像各个器官都健康但没有神经系统------动不起来。项目经理的终极价值，就是做项目的神经系统。

---

4.25 项目章程

章程是什么

三句话定义	含义
项目发起人发布的	不是 PM 自封的，不是团队讨论出来的------必须是发起人签署
正式批准项目成立	章程签发 = 项目诞生。没有章程 = 项目不存在
授权项目经理动用组织资源	PM 的权力来自章程，不是来自职位

章程三要素：

  章程 = 诞生证 + 授权书 + 通行证

  诞生证：项目正式存在了
  授权书：PM 有权力花钱、要人、调动资源
  通行证：拿着章程去找职能经理要人，对方不能以"不知道这个项目"为由拒绝

章程包含什么内容

必须包含的要素	说明
项目目的	我们为什么要做这个项目？
高层级需求	不需要详细，但要说清楚要什么
整体项目风险	影响最大的 3-5 个风险是什么
关键干系人名单	谁对这个项目至关重要
可测量的项目目标	不能含糊------"降低成本"不行，"年运营成本降低 15%"行
退出标准	什么情况下应该中止项目
项目经理任命	谁是 PM，有文本记录
发起人签名	没有签字的章程 = 废纸

章程里没有的东西（考试陷阱）：

❌ 章程里没有	这些在哪
详细 WBS	项目管理计划（规划过程组）
具体进度计划	项目管理计划
详细风险清单	风险登记册（项目文件）
具体团队成员	资源管理计划
具体预算科目	成本基准

什么是项目管理计划

章程告诉所有人"项目是什么"，管理计划告诉所有人"怎么把这个项目做成"。

项目管理计划包含	不是......
15 个子管理计划 + 3 大基准 + 变更/配置管理计划	不是项目进度表（它在基准里，是计划的一部分）
"我们怎么做"的规则和标准	不是日记（日记是项目文件，记录实际发生）

章程 → 管理计划 → 项目文件的推导链：

  章程（发起人）
    │ "做个 APP，目标 6 个月上线，预算 200 万，PM 是小李"
    ▼
  项目管理计划（PM 编制，发起人批准）
    │ "怎么管范围（需求变更走 CCB），怎么管进度（甘特图+周报），怎么管质量......"
    ▼
  项目文件（PM 持续维护）
    │ 风险登记册、问题日志、WBS 词典、实际进度数据......

维度	章程	项目管理计划	项目文件
谁批准	发起人	发起人/高层	PM
何时创建	启动	规划	全生命周期
可变更性	极少变	走 CCB	PM 随时更新
考法	章程里没有详细计划！	计划里没有具体风险条目！	文件里全是数据！

一句话： 章程说"做什么，谁来做"，计划说"怎么做"，文件记录"做成什么样了"。三者层层递进，内容绝不重叠。

---

本章高频考点清单

#	考点	一句话
1	五大过程组	启动→规划→执行→监控→收尾，49过程分布：2/24/10/12/1
2	过程组 ≠ 阶段	过程组是管理维度，阶段是时间维度，每个阶段可含所有过程组
3	Scrum 3355	3角色(PO/SM/DevTeam)+3工件(PBI/SBI/增量)+5事件(Sprint/计划/站会/评审/回顾)+5价值观
4	PDCA Scrum版	Sprint计划§→执行(D)→站会©→回顾(A)
5	QA vs QC	QA=管过程预防(8.2)；QC=查结果检测(8.3)
6	DFX	面向X的设计：面向制造/装配/测试/拆卸/环境......让全生命周期最优化
7	TQM 朱兰三部曲	质量规划→质量控制→质量改进
8	沟通漏斗	心里想的100%→说出来的80%→听到的60%→理解的40%→记住的20%
9	整合四大层次	过程整合→信息整合→干系人整合→交付整合
10	章程三要素	做什么(What) + 谁来做(Who/PM) + 高层级需求/风险/里程碑

本章常见考试陷阱

陷阱	正解
过程组=项目阶段 ×	过程组是逻辑分组，每个阶段可能包含所有过程组
Scrum不是项目管理 ×	Scrum 是敏捷框架，可用于管理复杂项目
DFX 只是设计阶段的事 ×	DFX 影响全生命周期：采购、制造、测试、运维
沟通问题=多发信息 ×	沟通漏斗说明发送≠收到≠理解，关键是有效而非数量