02-项目管理的逻辑

1.2 项目管理的逻辑

1.14 项目管理的目标

项目管理的目标是多层次的，PMBOK 定义其核心目标是在约束条件下交付符合要求的成果。

铁三角的互斥本质：便宜、好、快，只能选两个

               好（质量 Quality）
               /\
              /  \
             /    \
            /      \
           /   选   \
          /    二    \
         /          \
        /____________\
   便宜（成本 Cost）    快（进度 Schedule）

三选二的冷酷现实：

你的选择	你得到	你失去
好 + 快	高质量 × 短周期	贵（成本飙升）
好 + 便宜	高质量 × 低成本	等（时间拉长）
快 + 便宜	短周期 × 低成本	丑（质量崩塌）

古人云："慢工出细活"（好+便宜→等），"一分钱一分货"（好+快→贵），"便宜没好货"（快+便宜→丑）。铁三角的本质是三个变量不可能同时最优，项目经理的工作就是找到干系人能接受的平衡点。

铁三角的互斥机制：

• 质量 ← → 成本： 提高质量 → 需要更贵的材料/更资深的人 → 成本上升
• 质量 ← → 时间： 提高质量 → 需要更多测试/评审 → 时间拉长
• 时间 ← → 成本： 压缩工期 → 需要加班/加人/并行 → 成本上升

关键认知： 项目经理的核心能力，是在干系人博弈中找到各方都能接受的"最不坏"平衡点，而非追求某一维度的极致。

成本与时间（进度）的深层关系

直接成本与间接成本

成本类型	定义	示例
直接成本	可直接归属于项目的费用	开发人员工资、服务器采购、外包费用
间接成本	分摊到项目的管理费用	办公场地租金、水电费、行政人员分摊

时间对两类成本的影响：

• 直接成本随工期缩短而上升 ------ 赶工（Crashing）需要加人、加班费
• 间接成本随工期延长而上升 ------ 拖得越久，管理费摊销越多

微笑成本曲线：总成本的最优工期

成本
 ↑
 │          总成本
 │         /      \
 │        /        \      ← 总成本 = 直接成本 + 间接成本
 │       /  最优    \
 │      /   工期     \
 │     /              \
 │    /    间接成本     \
 │   /  (随工期递增)     \
 │  /                    \
 │ /______________________\
 │/     直接成本           \
 │    (随赶工递增)          \
 └─────────────────────────→ 工期
  最短工期 ←---------------→ 最慢工期

曲线解读：

区间	在做什么	成本表现	风险
过度赶工（左侧）	加班、加人、外包	直接成本急剧上升	质量崩、团队崩
最优工期（底部）	节奏正常	总成本最低	---
过度拖延（右侧）	效率低下、等待	间接成本持续堆积	士气低、机会丢失

☺ 微笑曲线的名字由来： 总成本曲线像一张微笑的嘴，最低点在中间。左边赶工贵，右边拖延贵，不赶不拖刚刚好。

项目预算的构成

项目预算
│
├── 直接成本
│   ├── 人力成本（内部+外部）
│   ├── 材料/设备采购
│   ├── 外包/分包合同
│   └── 差旅及其他直接费用
│
├── 间接成本（管理费分摊）
│
├── 应急储备（Contingency Reserve）
│   └── 应对已知-未知风险（由PM控制）
│
└── 管理储备（Management Reserve）
    └── 应对未知-未知风险（由管理层控制）

预算项	谁管	对应什么
直接+间接成本	项目经理	成本基准（Cost Baseline）
+ 应急储备	项目经理	项目预算（Project Budget）
+ 管理储备	发起人/管理层	总资金需求（Funding Requirements）

现代扩展：从铁三角到六边形约束

约束维度	含义
范围（Scope）	明确要做什么、不做什么
质量（Quality）	符合验收标准，满足预期
进度（Schedule）	时间节点、里程碑可控
预算（Budget）	资金资源、人力成本的限制
资源（Resources）	人力、设备、材料的可用性
风险（Risk）	不确定性对目标的潜在影响

总结： 项目管理的目标不是追求某一维度的极致，而是理解便宜/好/快的互斥规律，利用成本曲线找到最优工期，在多重约束中实现整体最优。

---

1.15 项目管理的高层次目标

跳出单个项目的铁三角约束，项目管理的高层次目标是实现四方满意：

         ┌──────────┐
         │ 战略满意  │
         │ Strategy │
         └─────┬────┘
               │
  ┌────────────┼────────────┐
  │            │            │
  ▼            ▼            ▼
┌──────┐  ┌──────┐   ┌──────┐
│干系人│  │ 成员 │   │ HSE │
│满意  │  │ 满意 │   │ 无害 │
└──────┘  └──────┘   └──────┘

一、战略满意（Strategy Satisfaction）

项目是战略落地的载体。每个项目必须回答：这个项目对组织的战略贡献是什么？

战略类型	对应项目目标
市场扩张	进入新市场、推出新产品线
成本领先	流程自动化、供应链优化
差异化	创新技术研发、用户体验提升
合规风控	满足监管要求、通过审计认证

项目即使按时按预算交付，如果没有为战略目标做出贡献，从战略视角看就是失败。

二、干系人满意（Stakeholder Satisfaction）

项目的成功最终由干系人定义。交付一个"完美"但干系人不认可的结果，依然是失败。

干系人管理的核心：

• 识别（Identify）： 找出所有受项目影响或影响项目的人
• 分析（Analyze）： 判断其权力/利益/影响力/参与意愿
• 争取（Engage）： 持续沟通，管理期望，化解阻力
• 平衡（Balance）： 不同干系人需求冲突时，以项目目标为基准权衡

不要让干系人"突然发现"一个结果。持续参与，不断对齐预期。

三、项目成员满意（Team Satisfaction）

团队是项目的第一生产力。一个项目可以交付成功，但如果核心成员心力交瘁、流失殆尽，组织长期受损。

成员满意的三个层次：

层次	内容	PM应该做的
基本层	合理工作量、安全环境、公平报酬	保护团队，拒绝不合理需求
成长层	技能提升、挑战性任务、职业发展	分配能锻炼人的工作，给予反馈
归属层	被认可、被尊重、有成就感	公开表扬，庆祝里程碑，建立团队文化

项目结束，成员说"我愿意再和这位PM做项目"------这是项目经理的最高荣誉。

四、HSE（健康 Health / 安全 Safety / 环境无害 Environment）

在工程、能源、建筑等行业，HSE 是高于一切目标的底线。

维度	含义	典型场景
健康（Health）	保护人员的身心健康	劳保防护、心理健康、合理工时
安全（Safety）	预防事故，零伤害	安全培训、风险预案、事故报告
环境（Environment）	最小化对环境的负面影响	废弃物处理、碳排放、生态修复

HSE 与铁三角的关系：

• HSE 不是 与成本/进度并列的目标------它是一条不归零的红线
• 在安全健康和环保面前，成本、进度、甚至范围都可以妥协
• 一场安全事故可以瞬间抹杀所有项目成果

四方满意的优先级

HSE 无害（底线，不可妥协）
    │
    ▼
战略满意（方向，不能偏）
    │
    ▼
干系人满意（结果，要交付）
    │
    ▼
成员满意（过程，要持续）

总结： 低层次目标是"把项目做完"（交付铁三角），高层次目标是"让四方都满意"------战略批准立项的人、使用成果的人、干活的人、以及我们赖以生存的环境。

---

1.16 企业的类型

不同类型的企业，其项目管理的重点和模式差异显著。

按行业分类

企业类型	典型项目	PM特点
建筑施工	厂房、住宅、基础设施	合同管理、进度严控、安全管理
IT/互联网	软件开发、系统实施	需求变更频繁、敏捷迭代、技术风险
制造业	新产品研发、产线改造	IPD集成开发、供应链协同、成本控制
咨询服务	管理咨询、IT咨询	范围定义模糊、客户期望管理、知识转移
能源/化工	油田开发、炼厂建设	合规要求高、HSE安全、大型EPC

按组织模式分类

组织类型	权力结构	项目经理角色
职能型	部门经理权力最大	项目协调员（Project Coordinator），无实权
弱矩阵	职能经理主导，项目经理协助	项目联络员，影响力有限
平衡矩阵	职能经理与项目经理共享权力	正式项目经理，与职能经理平级
强矩阵	项目经理主导，职能经理提供资源	项目经理有较高权威，类似部门经理
项目型	项目经理全权负责	项目经理权力最大，团队专职

不同企业类型的PM策略

• 初创企业： 流程极简，PM身兼多职，快速试错
• 成熟企业： 流程规范，PMO支撑，强调可预测性
• 跨国企业： 跨文化管理，时区协调，合规复杂

---

1.17 项目与运营的区别

项目的八大本质特征

┌─────────────────────────────────────────────┐
│                  项  目                     │
│                                             │
│  ┌─────────┐ ┌─────────┐ ┌───────────────┐ │
│  │ 独一无二 │ │ 有始有终 │ │ 一次成功机会   │ │
│  └─────────┘ └─────────┘ └───────────────┘ │
│  ┌─────────┐ ┌─────────┐ ┌───────────────┐ │
│  │全责不均衡│ │临时性组织│ │   效果导向     │ │
│  └─────────┘ └─────────┘ └───────────────┘ │
│  ┌─────────┐ ┌─────────┐                   │
│  │不确定性  │ │针对性计划│                   │
│  └─────────┘ └─────────┘                   │
└─────────────────────────────────────────────┘

#	项目特征	含义	运营对比
1	独一无二	每次交付的都是从未有过的成果	运营是重复性、标准化的
2	有始有终	明确开始和结束时间，目标达成即解散	运营持续不断，无终结点
3	一次成功机会	失败成本极高，没有"下次做好"的余地	运营可试错、优化、迭代
4	全责不均衡	项目经理对结果全权负责，但对团队无行政管理权	部门经理有完整权责匹配
5	临时性组织	团队为项目临时组建，结束即各归各位	运营团队是常设编制
6	效果导向	关注"是否达成目标"，而非"投入多少工时"	运营侧重效率（产出/投入比）
7	不确定性（风险）	需求变化、技术未知、环境波动并存	运营过程成熟、风险可控
8	针对性计划	每个项目量身定制计划，没有万能模板	运营有 SOP，复制即可

逐条详解

1. 独一无二

没有两个完全相同的项目。即使是"照搬上一期"，干系人变了、环境变了，它就是新项目。

2. 有始有终

项目章程签署是"生"，最终验收通过是"死"。两者的时差就是项目生命周期。

3. 一次成功机会

运营容许犯错------这批产品不合格，下批改进。项目没有"下批"：大桥塌了不能重盖，系统上线失败客户已流失。

4. 全责不均衡

这是 PM 最大的痛点：对结果负 100% 责任，但团队成员不归你管、预算要审批、资源要"借"。有责无权是常态，影响力代替职权是必修课。

5. 临时性组织

团队成员知道项目结束就会分开，这种"临时关系"既带来紧迫感，也带来凝聚力挑战。

6. 效果导向

运营问"做了多少"（效率），项目问"做到了没"（效果）。加班 100 小时但没交付，等于零。

7. 不确定性（风险）

项目天然在未知中前行。风险管理的本质不是消灭不确定性，而是与不确定性共存。

8. 针对性计划

每个项目需要专属计划。把上期计划改个标题直接用，是项目失败的首要原因之一。

项目 vs 运营速查表

维度	项目	运营
性质	独一无二，有始有终	重复标准，持续不断
容错率	一次机会，零容忍	可迭代改进
组织	临时团队	常设编制
成功标准	达成效果	维持效率
风险	高不确定性	低波动
计划	量身定制	SOP 复制

一句话区分： 项目是做一件从未做过的事 ，运营是做好一件一直在做的事。

---

1.18 项目经理与职能经理

项目经理（PM）和职能经理（FM）是组织中两种截然不同的管理角色。理解 PM 的独特定位，是掌握项目管理思维的关键。

项目经理的五大特征

维度	项目经理	解读
角色	帅才	不是专才，是指挥者------整合各专业力量，为整体胜利负责
知识结构	通才	什么都懂一点，不必精通每一项技术，但必须能判断对错
管理方式	目标管理	以结果为导向，围绕项目目标配置资源、推动决策
工作方法	整合的方法	将不同专业的产出拼接成完整交付物，让1+1>2
主要任务	计划·组织·协调·指导	四步闭环：定计划→组团队→拉通协作→把控方向

逐条详解

1. 角色：帅才

项目经理像军队的"帅"，不是特种兵。帅才的核心能力不是自己开枪，而是：

• 知道每一仗该打到什么程度
• 知道谁来打效果最好
• 知道什么时候该冲、什么时候该撤

职能经理是"连长"（管一个专业兵种），项目经理是"指挥官"（管一场战役）。

2. 知识结构：通才

        ┌───────────────┐
        │    项目管理    │
        │   核心知识    │
        └───────┬───────┘
                │
    ┌───────────┼───────────┐
    │           │           │
    ▼           ▼           ▼
  技术        业务        管理
(够判断)    (够理解)    (够执行)

PM 不需要比程序员更懂代码，但必须知道一个功能需要 3 天还是 30 天。不需要比财务更懂报表，但必须会看 ROI。

3. 管理方式：目标管理（MBO）

职能经理	项目经理
过程管理------确保流程规范、动作到位	目标管理------确保结果正确、价值交付
"按 SOP 执行"	"为达成目标，可以调整一切"
考核：效率（产出/投入）	考核：效果（达成/目标）

4. 工作方法：整合的方法

项目的交付物不是各专业产出拼起来的"拼盘"，而是深度整合后的"融合菜"：

分析师的 ──┐
设计稿   ──┤
开发的 ──┼──→ PM 整合 ──→ 完整交付物
测试报告 ──┤
运维文档 ──┘

整合的三个层次：

1. 过程整合： 打通各阶段衔接点，消灭等待
2. 知识整合： 汇总各领域信息，做出全局决策
3. 干系人整合： 平衡各方期望，对齐项目目标

5. 主要任务：计划·组织·协调·指导

任务	内容	关键动作
计划	制定项目管理计划	WBS、里程碑、资源估算
组织	组建项目团队	从资源池要人、明确角色职责
协调	拉通各方的沟通与冲突	开会、谈判、跟催、化解
指导	把控方向，防止跑偏	范围确认、变更控制、风险预警

项目经理 vs 职能经理 速查表

维度	项目经理（PM）	职能主管（FM）
角色	帅才（指挥官）	将才（连长）
知识	通才（广度）	专才（深度）
管理方式	目标管理	过程管理
工作方法	整合	专业化
权力来源	项目章程	组织职位
资源控制	临时借用，结束释放	长期拥有
考核标准	项目成功	部门效率

一句话： 职能经理管好一群人，项目经理管好一件事。

---

1.19 PMP新考纲

2021年 PMP 考试大纲（ECO，Exam Content Outline）进行了根本性改革：从五大过程组 （启动-规划-执行-监控-收尾）转向三大领域的新框架。

三大领域与占比

      人（People）         过程（Process）       商业环境（Business Environment）
        42%                   50%                        8%
   ┌──────────────┐    ┌──────────────┐        ┌──────────────┐
   │ 团队建设       │    │ 交付管理       │        │ 战略对齐       │
   │ 领导力         │    │ 计划与控制     │        │ 合规           │
   │ 冲突管理       │    │ 风险管理       │        │ 商业价值       │
   │ 沟通           │    │ 十大知识领域   │        │ 组织变革       │
   │ 虚拟团队       │    │ 敏捷/混合     │        │ 收益管理       │
   └──────────────┘    └──────────────┘        └──────────────┘

ECO 的结构：领域 → 任务 → 驱动因素

新考纲采用三层结构：

领域（Domain）
  └── 任务（Task）：PM 必须完成的工作
        └── 驱动因素（Enablers）：完成该任务的具体行为/知识

35 项任务分布：

领域	任务数	占比
人（People）	14 项	42%
过程（Process）	17 项	50%
商业环境（Business Environment）	4 项	8%
合计	35 项	100%

三大领域任务全景

领域一：人（People）--- 14 项任务

#	任务	关键驱动因素
1	管理冲突	识别冲突来源、选择解决策略
2	领导团队	设定愿景、激励、服务型领导
3	支持团队绩效	评估、反馈、成长计划
4	赋能团队成员和干系人	授权、赋予决策权
5	确保成员/干系人充分培训	技能差距分析、培训实施
6	建设团队	团队发展阶段、凝聚力打造
7	解决和消除阻碍和障碍	识别障碍、升级解决
8	谈判项目协议	范围、成本、进度谈判
9	与干系人协作	识别、分析、争取参与
10	建立共识	达成一致、对齐期望
11	参与并支持虚拟团队	远程协作工具、时区管理
12	定义团队基本规则	行为准则、沟通规范
13	指导干系人	教练式沟通、赋能
14	运用情商提升团队绩效	自我意识、同理心、关系管理

领域二：过程（Process）--- 17 项任务

#	任务	关键驱动因素
1	以交付商业价值所需的紧急程度执行项目	优先级排序、MVP定义
2	管理沟通	沟通计划、信息分发
3	评估和管理风险	识别、定性/定量分析、应对
4	让干系人参与	参与度评估、持续争取
5	规划并管理预算和资源	估算、预算编制、资源平衡
6	规划和管理进度计划	活动定义、排序、关键路径
7	规划和管理产品/交付物的质量	质量指标、质量保证
8	规划和管理范围	WBS、范围基准、变更控制
9	整合项目规划活动	项目管理计划汇总
10	管理项目变更	变更控制流程、CCB
11	规划和管理采购	自制/外购分析、合同管理
12	管理项目工件	文档配置管理
13	确定适当的项目方法/实践	预测型、敏捷、混合选择
14	制定项目治理结构	角色、决策权限、升级路径
15	管理项目问题	问题日志、跟踪关闭
16	确保知识转移，实现项目连续性	经验教训、交接文档
17	规划和管理项目/阶段收尾	验收、归档、解散团队

领域三：商业环境（Business Environment）--- 4 项任务

#	任务	关键驱动因素
1	规划和管理项目合规性	法律法规、行业标准
2	评估和交付项目收益和价值	商业论证、收益管理计划
3	评估和应对外部商业环境变化	市场、竞争、技术趋势
4	支持组织变革	变更管理、文化塑造

任务与驱动因素示例

以"管理冲突"（人领域-任务1）为例：

任务：管理冲突
  │
  ├── 驱动因素1：识别冲突的根源和阶段
  ├── 驱动因素2：分析冲突发生的背景
  ├── 驱动因素3：评估/推荐解决方案
  └── 驱动因素4：综合多方观点达成解决方案

考试时，题目不会直接问"冲突管理有几步"，而是给出一个场景：成员吵架、PM 如何介入，考察你能否识别这是在执行哪个驱动因素。

新 vs 旧：核心变化

维度	传统考纲（五大过程组）	新考纲（ECO三大领域）
框架	ITTO（输入-工具-输出）	任务 → 驱动因素
学习重点	记忆流程和公式	场景理解和决策判断
敏捷内容	少量涉及	贯穿50%题目
软技能	约10%	42%权重
商业思维	很少涉及	战略对齐+收益+合规
PM形象	计划执行者	价值创造者、变革推动者

一句话： 新考纲不再考"PMBOK 第几页写了什么"，而是考"在这个场景下，项目经理应该怎么做"。

---

1.20 什么是项目集管理

定义

根据 PMBOK，项目集（Program） 是一组相互关联且被协调管理的项目、子项目集和项目集活动，以便获得分别管理所无法获得的利益。

三个关键词：

关键词	含义
一组项目	不止一个，且相互独立可拆分
相互关联	项目之间有依赖关系或共享资源
共性	找到共同点，统一规划，避免各自为战

项目集管理的核心逻辑：找到共性 → 整合规划 → 1+1>2。

经典案例：地下管道与综合管廊

场景： 一条主干道，三个管线要施工------

  燃气公司项目：铺燃气管 → 挖开地面 → 回填 → 修路
  电信公司项目：铺光纤    → 挖开地面 → 回填 → 修路
  自来水公司项目：铺水管  → 挖开地面 → 回填 → 修路

各自为战的结果：

后果	影响
重复挖路	同一条路挖三次，分别找三家施工队
市民不便	封路三次，每次几个月，怨声载道
成本浪费	三次回填+修路，总投入远超一次性
资源冲突	三家抢工期、抢路段

项目集思维：政府综合管廊系统

       ┌──────────────────────────────────┐
       │       城市综合管廊项目集           │
       │     （Utility Tunnel Program）    │
       ├──────────────────────────────────┤
       │  ┌─────────┐ ┌─────────┐ ┌─────┐│
       │  │燃气项目  │ │光纤项目  │ │ 水项 ││
       │  │(子项目)  │ │(子项目)  │ │(子项目)│
       │  └─────────┘ └─────────┘ └─────┘│
       │              │                    │
       │       公共部分：一次开挖，共建管廊 │
       │       一次回填修复，统一维护       │
       └──────────────────────────────────┘

PPP 模式（Public-Private Partnership）融资：

政府牵头规划管廊（公共部分），燃气/通信/水务等企业各自承担自己的管线投资，共同委托一家项目管理公司统一施工、统一维护。政府在特许经营期（如25年）内向使用者收费偿还投资，到期后移交政府。

协同收益	量化效果
开挖次数	从 3+ 次 → 1 次
市民影响	从反复封路 → 一次性施工
总投资	减少约 30%-50%（共用土方、道路修复）
运维	统一巡检，管线间有空间余量便于未来扩容

项目集管理的核心任务

任务	管廊项目集中的体现
收益管理	衡量"一次开挖"节省的总成本
干系人争取	说服三家管线企业加入，协调政府审批
治理框架	谁牵头、谁出资、谁维护的规则
依赖管理	燃气管与电力管安全间距 ≥ 规范要求
资源优化	共用挖掘设备、施工队伍、道路修复

项目集 vs 项目 速查

维度	项目（Project）	项目集（Program）
范围	有明确边界	范围更广，关注整体收益
变更	严格控制	主动优化，追求收益最大化
成功标准	按计划交付	整体收益实现
管理重点	战术执行	战略统筹 + 协同收割
典型场景	铺一根燃气管	建一条综合管廊，铺三根管

一句话： 项目管理是"挖一条沟，铺一根管"，项目集管理是"挖一条沟，铺三根管，顺便把路修好"。找到共性，一次搞定。

---

1.21 什么是项目组合管理

定义

项目组合（Portfolio） 是为了实现战略目标而组合在一起管理的项目、项目集、子组合和运营工作。

与项目集的区别：项目集中的项目有依赖关系 ；项目组合中的项目未必关联，是战略驱动放在一起的。

         战略目标：成为综合能源服务商
                    │
    ┌───────────────┼───────────────┐
    ▼               ▼               ▼
┌──────┐      ┌──────┐        ┌──────┐
│ 风电  │      │ 光伏  │        │天然气 │
│项目集 │      │项目   │        │项目   │
└──────┘      └──────┘        └──────┘

（三个方向彼此无依赖，但统一服务于"综合能源"战略）

波士顿矩阵（BCG Matrix）与项目组合决策

波士顿矩阵源自战略管理，是项目组合决策的经典工具。它将项目按市场增长率 和相对市场份额分为四类：

市场增长率
   ↑
 高│  ★ 明星产品        ？问号产品
   │  (Star)            (Question Mark)
   │  高增长·高份额       高增长·低份额
   │  → 加大投入          → 选择性投入
   │
 低│  $ 现金牛           ✕ 瘦狗
   │  (Cash Cow)        (Dog)
   │  低增长·高份额       低增长·低份额
   │  → 收割利润          → ？？
   └───────────────────────→ 相对市场份额
      高                    低

四象限策略：

类型	特征	标准策略
明星（Star）	高增长 + 高份额	加大投入，巩固领先地位
现金牛（Cash Cow）	低增长 + 高份额	收割利润，供养明星和问号
问号（Question Mark）	高增长 + 低份额	选择性投入，赌对了变明星，赌错了变瘦狗
瘦狗（Dog）	低增长 + 低份额	理论上应撤退/收割

瘦狗的"中国式生存"

按照波士顿矩阵的教科书答案，瘦狗项目应该果断砍掉。但在实际企业经营中，瘦狗常常活着------因为：

现实原因	逻辑
不能让人闲着	团队没项目干，人就散了；养人比砍项目更贵
维持客户关系	做一个不赚钱的小项目，保住大客户的"入场券"
消化冗余产能	设备、厂房闲置也是成本，不如接瘦狗订单摊薄固定成本
锻炼新人	用不重要的项目练兵，培养团队

项目组合管理不是纯粹的投资优化，而是在资源约束和现实约束下做政治可行的最优选择。理想状态是砍掉所有瘦狗，但现实中确保现金流的前提下，瘦狗可能是保留产能的最优解。

修正后的组合策略：

类型	理论策略	务实策略
明星	加大投入	加大投入
现金牛	收割利润	收割利润 + 反哺其他
问号	选择性投入	小步快跑，快速验证
瘦狗	砍掉	能不砍就不砍（养活团队 > 账面亏损）

项目组合 vs 项目集 vs 项目

维度	项目	项目集	项目组合
放在一起的原因	---	项目之间有依赖	战略对齐
关注点	交付产出	协同收益	战略→资源最优配
变更	控制	主动调整	动态优胜劣汰
成功标准	达成三重约束	实现项目集收益	实现战略目标

项目组合管理的核心任务

任务	波士顿矩阵视角
战略对齐	砍掉不匹配战略的→确保组合总分最高
资源平衡	现金牛养明星和问号
风险管理	四类分布，不扎堆一个象限
价值评估	定期复盘：问号变明星了没？明星变现金牛了没？
治理决策	瘦狗该砍就砍------除非有养它的非财务理由

一句话： 项目组合管理就是拿着有限的钱，决定投哪些"马"，并持续盯着赛场，优则加注，劣则止损。

---

1.22 如何区分项目组合与项目集

实战案例辨析

腾讯：多个"吃鸡"手游------项目组合

腾讯同时运营《和平精英》《PUBG Mobile》《使命召唤手游》等多款射击游戏：

         战略：占据战术竞技品类全部细分市场
                    │
    ┌───────────────┼───────────────┐
    ▼               ▼               ▼
  和平精英       PUBG Mobile     CODM
 (国内端游还原)   (海外市场)     (IP改编)

• 三个项目彼此独立，没有技术依赖
• 放在一起管是为了抢占同一品类不同细分用户
• 一个项目失败，不影响另外两个
• 判断：项目组合

蚂蚁金服：支付+信用+理财------项目集

蚂蚁金服下的支付宝、芝麻信用、余额宝、花呗、借呗：

       蚂蚁金服生态项目集
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
  支付宝    芝麻信用   余额宝/花呗
 (支付)     (征信)     (理财/信贷)

  支付数据 ──→ 养信用分
  信用分   ──→ 决定花呗额度
  花呗还款记录 ──→ 反哺信用分

• 各产品之间深度互通，共享用户数据和信用体系
• 单独做任何一个都没有生态价值
• 判断：项目集（互通 = 相互联系才是项目集）

速判口诀： 互通互联 → 项目集；同品类竞争 → 项目组合。

四层管理体系综合对比表

维度	项目管理	项目集管理	项目组合管理	管理成熟度模型
理论	单项目管理	多项目协同	战略投资组合	OPM3 组织级成熟度
范围	一个产品/交付物	一组相互关联的项目	所有项目、项目集、运营	整个组织的PM能力
目的	目标管理（达成交付）	协同收益（1+1>2）	战略对齐（资源最优配）	能力提升（持续改进）
要点	质量、成本、进度	互通互联、依赖管理	选对项目、动态优化	标准化→可衡量→持续改进
标准	按时按预算按范围	整体收益实现	战略目标达成	OPM3四阶段：标准化、可衡量、可控制、持续改进

逐行解读

1. 项目管理（Project Management）

维度	解读
理论	管理一个独立项目，交付特定的产品/服务/成果
范围	例如：开发一台新手机
目的	目标管理------项目章程定义目标，PM 推动达成
要点	在质量、成本、进度的铁三角中找平衡
标准	按时交付、不超预算、质量达标

2. 项目集管理（Program Management）

维度	解读
理论	管理一组相互关联的项目，获取分别管理所无法获得的收益
范围	例如：蚂蚁金服的支付+信用+理财生态
目的	协同收益------让各项目之间产生1+1>2的效果
要点	管理项目间的依赖关系 和相互联系
标准	整体收益是否超过各项目独立执行之和

3. 项目组合管理（Portfolio Management）

维度	解读
理论	为实现战略目标而管理的一组项目/项目集/运营
范围	例如：腾讯的战术竞技品类产品矩阵
目的	战略对齐------在有限资源下，选最优项目组合
要点	持续评估每个项目的战略贡献 和投资回报
标准	组合的整体价值是否最大化了战略目标

4. 管理成熟度模型（OPM3）

维度	解读
理论	评估和提升组织项目管理能力的框架
范围	不是管项目，而是管"管项目的能力"
目的	让组织的 PM 实践从混乱到标准化再到持续改进
要点	逐步提升：标准化→可衡量→可控制→持续改进
标准	组织是否达到了目标成熟度等级

一张图理清四层关系

  OPM3（管能力）
    │ "你的组织PM水平是几级？"
    ▼
  项目组合（管选择）
    │ "这么多项目，先做哪个？不做哪个？"
    ▼
  项目集（管协同）
    │ "这几个项目有关系，怎么让它们互相借力？"
    ▼
  项目（管执行）
    │ "这个项目怎么按时、按预算、保质交付？"

微信案例对照

以微信这个超级应用来理解四层：

层级	微信中的体现
项目管理	开发"微信支付"功能
项目集管理	微信支付 + 小程序 + 企业微信 → 商业闭环（互通互联）
项目组合管理	微信 × QQ × 腾讯会议 × 企业微信 → 腾讯社交矩阵
OPM3	腾讯的PM体系是否足以支撑同时管理数百个微信系项目

一句话总结： 项目是战役，项目集是战区协同，项目组合是总参谋部排兵布阵，OPM3 是检验军队的整体战斗力。

---

1.23 案例：善良是一种选择

经营之神王永庆：让穷人用得起

台塑集团创始人王永庆被称为"经营之神"，他的核心信条朴素而坚定：

"只要老百姓需要的，我们就要用最便宜的价格做出来。"

王永庆的米店故事：

少年王永庆开米店，发现同行都是等客人上门。他做了一件"多余"的事：主动送货上门，顺便帮客人把米缸里的陈米倒出来、洗净米缸，再倒新米进去。 服务免费，却让顾客再也离不开他。

成本提高了，利润呢？薄了。但街坊全成了回头客。

王永庆哲学	项目管理启示
卖米顺便洗米缸	交付成果顺便帮客户解决关联问题
薄利但人人买得起	项目预算不是越低越好，但浪费一分钱都是罪
先做人，后做事	项目干系人管理的前提是信任
勤能补拙，俭以养德	资源永远有限，效率即是竞争力

贝佐斯：提醒客户重复购买

亚马逊的核心理念中有一条反直觉的战略：

"我们的目标不是让客户买一次，而是不断提醒客户：上次那个很好用，该复购了。"

贝佐斯的客户价值公式：

客户价值 = 产品体验 - 客户付出的成本（金钱+时间+精力）

提高客户价值的方法：
  方法A：降低价格（简单但有限）
  方法B：降低客户的非金钱成本（亚马逊的核心策略）
         → 一键下单（省时间）
         → 自动补货提醒（省精力）
         → 免费退货（降风险）

亚马逊研发"Dash按钮"------贴在洗衣机上的实体按钮，按一下就自动下单洗衣液。这不是增加销售渠道，而是把"为客户创造价值"做到极致：让你永远不用担心洗衣液用完。

"善良"的商业模式 vs "相反"的商业模式

维度	王永庆/贝佐斯（善良型）	共享充电宝（相反型）
盈利基础	帮客户省钱/省心 → 客户自愿复购	客户手机没电 → 不得不花钱
客户关系	希望客户越来越好	客户越窘迫，利润越高
定价逻辑	薄利多销，靠规模赚钱	从1元/小时涨到4-6元/小时
产品设计	质量越好，客户越离不开	归还点越少越远，超时费越高
长期结果	客户忠诚 → 复购 → 复利增长	客户被迫使用 → 一旦有替代即流失

共享充电宝的"反善良"逻辑：

• 前半小时 1 元 → 先用低价让你借
• 归还点故意稀疏 → 你找不到还的地方 → 超时费
• 忘还一天封顶 99 元 → 给你买个新的都用不了这么多钱
• 商业模式的核心：利用你的不便和焦虑赚钱

一个项目或产品的本质，可以通过一个问题辨别："你的成功是建立在客户成功之上，还是客户无奈之上？"

PMP 终极启示：善良是最高级的管理

对项目经理而言，善良不是软弱，而是一种战略能力：

善良的维度	PM 的实践
对团队善良	拒绝不合理需求，保护团队不被榨干
对客户善良	告诉客户不需要的功能，帮他省钱
对组织善良	建议砍掉注定失败的项目，避免更大浪费
对自己善良	接受不完美的交付，持续迭代而非自我折磨

亚马逊的"遗憾最小化框架"与项目决策：

贝佐斯做重大决策时问自己一个问题："我80岁时，会不会因为没做这件事而后悔？"

项目经理也可以用这个框架：

• 砍掉一个瘦狗项目，一年后会不会后悔？→ 不会
• 为一个离职骨干特批远程办公，一年后会不会后悔？→ 不会（反而庆幸）
• 因为赶进度牺牲质量，上线后出事故，一年后会不会后悔？→ 一定会

结语： 菩萨心肠，雷霆手段。善良不是无原则退让，而是在合规的框架内，用长期主义对抗短期诱惑。项目管理追求的不是一个"完美项目"，而是让所有参与项目的人和组织，因为经历过这个项目，而变得更好。

---

1.24 价值交付体系

PMBOK 第七版最大的变革：从**"交付成果"转向"交付价值"**。价值交付体系（Value Delivery System）将战略、项目组合、项目集、项目、运营串联成一个完整的价值创造链条。

从"可交付成果"到"价值"

传统观点：项目成功 = 按时、按预算、按范围交付

现代观点：项目成功 = 交付的成果为组织创造了预期价值

链条：投入 → 项目 → 可交付成果 → 成果 → 价值
示例：预算 → 开发 → APP上线    → 用户使用 → 收入增长

两类浪费：Ⅰ 型与 Ⅱ 型

精益思想将一切不创造价值的活动定义为浪费。理解两种浪费，是识别价值的第一步：

浪费类型	定义	特征	是否可消除
Ⅰ 型浪费	不创造价值但当前无法消除的活动	必要的"恶"，如合规审计、安全巡检	短期内不能消，只能减
Ⅱ 型浪费	不创造价值且可以消除的活动	等待、返工、过度文档、重复审批	必须立即消除

软件开发中的 Ⅱ 型浪费实例：

浪费	举例
等待	需求提了等3天评审，代码写好了等2天才有测试环境
缺陷	BUG修了没写测试，下个迭代又重现
过度加工	一个内部后台页面，做了12轮视觉设计评审
交接	开发写完扔给测试，测试看不懂又问一遍
未完成的工作	Sprint结束时做了80%的功能堆在"进行中"

核心认知： 砍掉 Ⅱ 型浪费是最快的价值提升手段------不增加一分钱投入，只消除无价值活动，产出即刻提升。

价值流映射（Value Stream Mapping）

价值流映射是从客户需求出发，画出价值从输入到输出的全链条，标注每个环节的处理时间 和等待时间：

典型的软件开发价值流：

需求 ──→ 评审 ──→ 开发 ──→ 联调 ──→ 测试 ──→ 部署 ──→ 上线
 │         │        │        │        │        │        │
 2天       3天      5天      2天      3天      1天     0.5天
                     │←──→│
                    总加工时间：16.5 天
                    总等待时间：可能 30+ 天

节点	增值时间	典型等待
需求分析	2天	等评审排期 3天
需求评审	半天	跨部门协调排期 3天
开发	5天	等接口/等联调环境 4天
联调	2天	等测试环境 3天
测试	3天	修BUG后等复测 2天
部署上线	1天	等运维审批/变更窗口 2天

价值流映射的核心作用：

把"等待"可视化。一旦团队看到真实流程图，自然会问：

• "评审为什么要等3天？能不能今天下午？"
• "测试环境为什么要等？不能提前搭好吗？"
• "运维审批为什么要手动？不能自动化吗？"

不是说开发要更快，而是等待要更少。 一个需求从提出到上线，真正的编码时间可能只占 20%，80% 的时间在流转和等待中消耗。价值流映射的目标就是压缩那 80%。

组织级价值交付体系：一条流水线

┌──────────────────────────────────────────────────┐
│                    战略 Strategy                   │
│           "3年内成为行业TOP3"                      │
└──────────────────────┬───────────────────────────┘
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
   ┌──────────┐  ┌──────────┐  ┌──────────┐
   │ 项目组合A │  │ 项目组合B │  │ 持续运营  │
   │ (创新增长)│  │ (效率提升)│  │ (维持运转)│
   └────┬─────┘  └────┬─────┘  └──────────┘
        │             │
   ┌────┴────┐   ┌────┴────┐
   │ 项目集   │   │ 项目    │
   │ (协同)  │   │ (单点)  │
   └────┬────┘   └────┬────┘
        │             │
        ▼             ▼
   ┌──────────┐  ┌──────────┐
   │ 可交付成果 │  │ 可交付成果 │
   └────┬─────┘  └────┬─────┘
        │             │
        ▼             ▼
   ┌──────────┐  ┌──────────┐
   │   成果    │  │   成果    │
   └────┬─────┘  └────┬─────┘
        │             │
        └──────┬──────┘
               ▼
        ┌────────────┐
        │    价值     │
        │ (商业成功)  │
        └────────────┘

各环节的角色分工：

环节	谁负责	核心问题
战略	高管层	"我们要去哪？"
项目组合	PMO / 组合经理	"该投哪些项目？不投哪些？"
项目集/项目	项目经理	"怎么把事做成？"
运营	业务部门	"怎么让成果持续产生价值？"
价值	全员	"到底帮公司赚到钱/省了钱没有？"

项目经理的角色转变

传统角色	现代价值交付角色
交付管理者	价值推动者
计划执行者	变革推动者
范围守护者	价值最大化者
盯进度、催交付	盯浪费、提流速

一句话： 项目结束不等于价值实现。项目经理要从"管项目"升级为"管价值流"------不仅看产出，更要看产出能否转化成组织和干系人的真实价值。

---

1.25 初识敏捷

敏捷宣言（Agile Manifesto）

2001年，17位软件专家在美国犹他州雪鸟滑雪场共同签署了改变软件行业走向的宣言。

四大价值观：

左边（更重视）	vs	右边（也重要，但优先级较低）
个体和互动	高于	过程和工具
可用的软件	高于	完备的文档
客户协作	高于	合同谈判
响应变化	高于	遵循计划

逐条解读：

价值观	不是否定右边	而是强调
个体和互动 > 流程和工具	流程有用	但好团队比好流程更能解决问题
可用的软件 > 完备的文档	文档需要	但可工作的功能比完美的文档更能验证价值
客户协作 > 合同谈判	合同要签	但持续合作比条款博弈更能达成目标
响应变化 > 遵循计划	计划要做	但适应变化比死守计划更能保证最终成功

敏捷的核心特征

• 迭代（Iterative）： 将大项目拆分为小周期（Sprint），每个周期2-4周
• 增量（Incremental）： 每次迭代交付一个"可工作的增量"
• 自适应（Adaptive）： 根据反馈调整方向，而非死守原始计划
• 协作（Collaborative）： 跨职能团队紧密在一起，面对面沟通

柴火困境：敏捷的终极隐喻

一个旅人在风雪中赶路，背着一捆柴和一桶水。

柴可以生火取暖，水可以解渴。

风雪越来越大，他走不动了。

他面临一个选择：扔柴还是倒水？

扔柴 → 能活到明天，但没有火取暖，可能冻死。

倒掉一半水 → 重量减半，带着柴赶到营地，生火取暖等天亮。

把水倒掉一半 = 用最小资源满足客户的刚需：

水 = 非核心需求（nice-to-have）
柴 = 核心需求（刚需，must-have）

倒掉一半水，带着柴赶路 = 砍掉非必要功能，用最少资源交付最核心的价值

对照敏捷四大价值观：

柴火困境	敏捷对应
柴 = 刚需	可用的软件（MVP，先做核心功能）
水 = 锦上添花	完备的文档 / 合同谈判（重要但不紧急）
倒掉一半水	砍范围 → 保质量 → 快速交付
赶到营地生火	快速交付可工作软件 → 获得反馈 → 迭代优化
不扔柴	个体和互动 → 团队才是生存的根本

敏捷的本质：不是更快地做所有事，而是尽早识别哪些是"水"（可以倒掉），哪些是"柴"（必须带着），用最少的资源把柴安全送到营地。

敏捷 vs 瀑布

维度	瀑布（Waterfall）	敏捷（Agile）
需求	前期固定	持续演进
交付	最后一次性	频繁增量
反馈	后期才获得	每个迭代后获得
计划	详细前期计划	滚动式规划
柴火逻辑	背着水和柴一起走，最后可能都带不到	先带着柴，水倒一半，到了再说

主流敏捷框架

框架	特点	一句话
Scrum	固定周期迭代（Sprint）	最普及的敏捷框架
看板（Kanban）	持续流，限制在制品	可视化+限制并行
极限编程（XP）	强调工程实践	结对编程+TDD
SAFe	规模化敏捷	大企业的Scrum

---

1.26 传统与敏捷的区别

传统预测型（瀑布）和敏捷不是简单的"老 vs 新"，而是两种底层逻辑的差异。

核心差异：六维对比

维度	传统（预测型）	敏捷
计划	计划是蓝图，尽量精确锁定	计划没什么大用，它只是一个假设，随时被修改
范围 vs 资源	范围固定，资源按需调配	资源恒定，范围可随时裁剪
目标导向	按合同交付，满足规格说明书	客户获得商业价值，持续可用就是成功
变更态度	变更需要审批，越少越好	任何时候的变更都可以接受，越多说明离正确越近
团队模式	明确分工，按流程执行	团队自由，释放个性，自组织
交付节奏	项目结束一次性交付	每个迭代交付可用增量

逐维深解

1. 计划：蓝图 vs 假设

传统	敏捷
计划是承诺------签了就要做到	计划是假设------先做一点看看对不对
需求分析→概要设计→详细设计→编码	Sprint规划→开发→评审→回顾→重新规划
变更 = 错误，要控制	变更 = 学习，要欢迎

敏捷的心态： 计划不断被修改不是失败，而是你在越来越清晰地靠近正确答案。

2. 范围 vs 资源：谁固定，谁可变

传统铁三角：        范围固定 ──→ 资源可变（加人/加班）
                    时间固定 ──→ 成本可变（加班费）

敏捷铁三角：        资源恒定 ──→ 范围可变（砍低优先级）
                    时间固定 ──→ 交付物可裁剪（MVP优先）

如果......	传统会......	敏捷会......
进度落后	加人、加班 → 成本增加	砍掉低优先级功能 → 保证按时
需求膨胀	走变更流程 → 延期	放下一个Sprint → 不影响当前

3. 目标：合同交付 vs 商业价值

传统	敏捷
成功 = 按规格说明书交付	成功 = 客户用上了、产生了价值
验收标准是文档	验收标准是客户满意度
"你让我做的我做了"	"这个功能真的解决了客户的问题"

4. 变更：敌人 vs 朋友

传统	敏捷
变更 = 灾难信号	变更 = 洞察信号
通过 CCB（变更控制委员会）层层审批	Sprint Review 当场讨论要不要纳入
变更代价随时间指数级增长	每个Sprint平等对待所有需求

传统怕变，敏捷怕不变。 三个月没一个变更请求，可能不是需求稳，而是客户已经放弃了。

5. 团队：执行者 vs 自组织

传统	敏捷
PM 分配任务，团队执行	团队自己领任务，自己评估工作量
角色固化（前端只写前端）	跨职能，T 型人才
流程管人	人管流程

释放个性： 敏捷团队的理想状态是------早上站会说完，各人就知道今天该干什么，不需要 PM 逐个安排。

一张图总结

传统路线：                     敏捷路线：
需求分析                        Sprint 1 ──→ 交付可用的增量
   │                              │
概要设计                        回顾+调整
   │                              │
详细设计                        Sprint 2 ──→ 交付更多增量
   │                              │
编码                           回顾+调整
   │                              │
测试                             │
   │                             ...
集成                              │
   │                        Sprint N ──→ 完整交付
部署
   │
交付（客户首次看到成果）

如何选择

适合传统	适合敏捷
建造大楼、桥梁	开发 APP、网站
医疗设备、航空软件	创业产品、新业务探索
需求极其明确、变更代价极高	需求不确定、市场变化快
客户想要"确定性报价"	客户想要"尽早看到东西"

没有最好的方法，只有最适合的方法。 但"计划没什么用处"这句话的真正含义是：在不确定性高的场景中，死守计划比没有计划更危险。

---

1.27 应用敏捷的好处

敏捷的核心：价值交付

敏捷的一切实践，归根结底指向一个目标：不断交付有价值的产品。

不是：把项目做完，交给客户
而是：每个迭代都交付可用的、有价值的增量

价值交付的滚动效应：

Sprint 1 ──→ 交付高价值功能 ──→ 客户用上了
  │
Sprint 2 ──→ 再交付一批功能 ──→ 价值持续累加
  │
Sprint 3 ──→ 客户反馈"上批功能不需要，改做这个"
  │                        ↓
  │               避免了浪费3个Sprint做无用功
  ...

传统项目： 做 100% 的功能 → 最后才发现 30% 没人用

敏捷： 先做 20% 最高价值 → 客户用上 → 决定下 20% 做什么

具体好处

对客户：更早、更准、更稳

价值时间线：
传统 ████████████████████▲（半年后第一次看到产品）
敏捷 ▲──▲──▲──▲──▲──▲──▲（每2周看到新进展）

好处	说明
更早获得价值	第2周就能用上一部分，不必等半年
更准的需求	用上了给反馈，下一个Sprint就调整
更低的风险	方向错了两周就能发现，而非半年后验收时

对团队：掌控感、节奏感、成长感

好处	说明
自组织的掌控感	团队自己领任务、估时、承诺，不是被分配
可持续的节奏	固定 Sprint，避免了项目的"前松后赶"
T 型成长	在跨职能团队中，前端学点后端，开发懂点测试

对组织：更快、更活、更省

好处	说明
更快上市	每 2 周一个版本，抢占市场窗口
更灵活转向	市场变了，下个 Sprint 就可以换方向
更省成本	不做没人用的功能，砍功能比加功能更有价值

数据说话

据 Standish Group CHAOS Report：

指标	传统瀑布	敏捷
项目成功率	~14%	~42%
失败率	~29%	~8%
挑战（超期超预算但完成）	~57%	~50%

敏捷不是银弹 ，但把成功率从 14% 提升到 42%，源于一个简单逻辑：不断交付、不断验证、不断调整 → 永远在做最需要做的事。

---

1.28 敏捷的十二条原则

敏捷宣言的四条价值观，由十二条原则支撑落地。原则不是教条，而是思维方式。

十二条原则一览

#	原则	一句话
1	客户满意	最高优先级是持续交付有价值的软件，让客户满意
2	拥抱变化	欢迎需求变更，即使在开发后期也坦然接受
3	短周期	频繁交付可工作的软件，两周到两个月，越短越好
4	相互合作	业务人员和开发人员必须每天一起工作
5	激发和信任	找有积极性的人，给环境给支持，然后信任他们
6	面对面	面对面交谈是最有效的沟通方式
7	可工作的软件	可工作的软件是衡量进度的首要标准
8	可持续开发	保持恒定节奏，不突击不熬命，长久作战
9	技术卓越	持续关注技术卓越和好的设计，越敏捷越要追求质量
10	简洁	尽最大可能不做不必要的事------简洁是艺术
11	自组织	自组织团队产生最好的架构、需求和设计
12	回顾总结	团队定期反思如何更有效，然后调整行为

分组记忆法

按 6 个关键词分组，每组 2 条：

客户组       ① 客户满意        ② 拥抱变化
节奏组       ③ 短周期          ④ 相互合作
人际组       ⑤ 激发和信任      ⑥ 面对面
交付组       ⑦ 可工作的软件    ⑧ 可持续开发
技术组       ⑨ 技术卓越        ⑩ 简洁
团队组       ⑪ 自组织          ⑫ 回顾总结

关键原则详解

原则 5：激发和信任

"围绕有积极性的人构建项目。给他们所需的环境和支持，信任他们能把工作做好。"

找对人 → 给好环境 → 信任他们。PM 不是警察，是园丁。

原则 7：可工作的软件 = 进度

"可工作的软件是衡量进度的首要标准。"

做了 80% 的"正在开发中" ≠ 80% 进度。只有能跑起来、可演示的功能才算交付。

原则 10：简洁的艺术

"简洁------最大限度不做不必要的事------至关重要。"

砍掉一个功能比新增一个功能更需要勇气。代码越少 BUG 越少。

原则 12：回顾总结

"团队定期反思如何变得更有效，然后调整行为。"

这就是 Scrum 回顾会（Retrospective）的来源。不是甩锅，而是找改进点------"下个 Sprint，我们哪一点可以做得更好？"

柴火困境对应十二条

回到 1.25 的柴火困境：

柴火行动	对应原则
带着柴（刚需）赶路	原则① 客户满意------交付核心价值
倒掉一半水	原则⑩ 简洁------不做不必要的事
赶到营地生火	原则③ 短周期------尽早交付可用软件
天亮后回去取水	原则② 拥抱变化------根据反馈调整
下次不再拎满桶水	原则⑫ 回顾总结------反思并改进

总结： 十二条原则不是十二条规定，而是十二条实践检验过的经验。理解为什么，比记住是什么更重要。

---

1.3 PMP 词频与图谱：三类题型破解

PMP 考试 180 道题（含 5 道测试题不计分），表面千变万化，实质只有三种题型。

三类题型一览

题型	占比	特点	核心能力
概念题	~15%	考定义、术语、流程步骤	记忆+理解
情景题	~75%	给一个项目场景，问 PM 该怎么做	判断+决策
计算题	~10%	EVM、关键路径、三点估算、沟通渠道	公式+推算

题型一：概念题

特征： 题干短，直接问"XX是什么"或"以下哪个属于XX"。

典型题目：
  "以下哪项是项目组合管理的主要目标？"
  "关键路径的特征是什么？"

出题人思路：

• 混淆相近概念（项目集 vs 项目组合，质量保证 vs 质量控制）
• 把一个术语的定义词换掉，变成干扰项

应对策略：

• 关键词区分法：记住每个术语的唯一特征词
• 不是死背定义，而是理解"为什么这个概念叫这个名字"

题型二：情景题（核心）

特征： 给一段 3-5 行的项目场景描述，问 PM 应该"首先做什么"或"下一步做什么"。

典型题目：
  "一个项目进度落后 2 周，项目经理发现原因是某个关键供应商
   延迟交货。项目经理首先应该做什么？
   A. 与供应商谈判加快交货
   B. 更新风险管理计划
   C. 分析对关键路径的影响
   D. 通知项目发起人"

出题人思路 = PMI 的逻辑链：

PMI 答题有一条铁律------先分析、再行动：

出题人的期望路径：
  发现问题 → 分析影响 → 查阅计划 → 评估方案 → 采取行动 → 沟通干系人

永远不要：
  发现问题 → 直接行动（跳过分析）
  发现问题 → 先汇报（PM 不是传话筒）

常见出题陷阱：

陷阱	例子	为什么错
跳步	出问题直接找发起人	应先分析、先尝试解决
越权	PM 直接批准范围变更	变更要走 CCB，PM 不能自己批
偏激	直接终止供应商合同	应先沟通、分析替代方案
甩锅	告诉客户这是供应商的错	PM 对整体结果负责

情景题黄金法则：

1. 先分析后行动 → 遇到问题，先分析影响，再查计划，最后行动
2. 按流程走 → 变更走 CCB、风险走风险管理流程、问题走问题日志
3. PM 是主角 → PM 能自己解决的，不要升级。先做 PM 职责范围内的事
4. 对人要软 → 涉及干系人冲突，先沟通理解，再决策
5. 选最完整的答案 → 如果有两个选项都对，选那个包含了更多正确步骤的

题型三：计算题

特征： 给出几个数字，用公式计算后选答案。

计算类型	核心公式	频次
挣值管理 EVM	CV/SV/CPI/SPI/EAC/ETC 等	高频
关键路径	正推 ES/EF，逆推 LS/LF，TF 计算	中频
三点估算	tE = (O+4M+P)/6	中频
沟通渠道	n×(n-1)/2	低频
决策树	EMV = 概率×影响，选大者	低频

出题人思路：

• 数值陷阱：不是算出来就选，要看方向（CV>0 好，CPI<1 坏）
• 单位陷阱：注意是"元"还是"万元"

以出题人的视角做题

备考最有效的思维转变：站在出题人角度读题。

拿到一道题，问自己三个问题：

出题人的问题	你的解题线索
这道题想考哪个知识点？	从题干关键词定位到 PMBOK 的具体过程/领域
这道题的陷阱在哪？	哪个选项是"看起来对但跳了步骤"的
PMI 希望 PM 怎么做？	按标准流程，不按个人经验

做题口诀：

字多不看 → 先看最后一句（问什么）
排除法   → 删掉明显错的（越权/跳步/甩锅）
二选一   → 选最符合 PMI 流程的，不选"听起来有道理"的
做完     → 不要改。第一直觉正确率最高

核心认知： PMP 考试不考"你怎么做"，考的是"PMI 认为你应该怎么做"。抛掉个人经验，穿上 PMBOK 的思维外套。

---

1.3.1 项目管理的价值与方法论

管理大师总结项目管理的十大核心价值，每一句古语恰好对应 PMBOK 的核心方法论：

#	古语	白话	对应 PMBOK 方法
1	未雨绸缪	还没下雨，先修屋顶	规划过程组 + 风险管理
2	防微杜渐	刚冒小火星就踩灭	监控过程组 + 纠正措施
3	资源集成	四面八方汇集一处	整合管理 + 采购管理
4	恰到好处	不少做也不多做	范围管理 + 质量管理
5	循规蹈矩	按规矩来，不乱搞	过程管理 + 治理制度
6	锲而不舍	刻一千刀也不停	目标管理 + 变更控制
7	积微成著	一点一点攒成大事	组织过程资产 + 经验教训
8	公开透明	不藏着掖着	沟通管理 + 干系人参与
9	同舟共济	坐一条船，谁也跑不了	诚信共赢 + 干系人合作
10	各司其职	各干各的，不乱跨界	授权 + 平等尊重

逐条详解

1. 未雨绸缪 → 规划 + 风险

天晴修屋顶，不是等漏了再补。

PM 实践	具体动作
规划过程组	项目启动即制定项目管理计划
风险管理	识别风险 → 定性定量分析 → 规划应对 → 储备应急金

大部分项目失败不是因为执行差，而是因为计划时忽略了那个"可能下雨"的风险。

2. 防微杜渐 → 监控 + 纠正

发现小火苗，马上踩灭，而不是等火烧起来。

PM 实践	具体动作
监控过程组	持续比照计划与实际的偏差
纠正措施	偏差一出现就纠正，不等到不可挽回

PMBOK 强调"持续监控"的核心原因：问题越早发现，修复成本越低。 1 块钱的问题在设计阶段发现，到运维阶段修复需要 100 块。

3. 资源集成 → 整合 + 采购

木料从深山运来，石料从河滩采来，工匠从各地请来------项目经理的手把所有资源编成一张网。

PM 实践	具体动作
整合管理	统一协调各知识领域、各过程组的输入输出
采购管理	外部资源通过合同机制纳入项目

项目经理不是专家，是"集成商"------把人对的东西放在对的位置，在对的时间发挥作用。

4. 恰到好处 → 范围 + 质量

做少了客户不满意，做多了浪费资源。

PM 实践	具体动作
范围管理	清晰定义范围边界，防止范围蔓延（Scope Creep）
质量管理	满足要求即可，避免"镀金"（Gold Plating）

PMBOK 严厉反对两件事：范围蔓延（客户塞需求）和镀金（团队自己加戏）。做到刚好，才是本事。

5. 循规蹈矩 → 过程 + 制度

一个团队可以靠英雄，十个团队必须靠流程。

PM 实践	具体动作
过程管理	标准化的启动-规划-执行-监控-收尾流程
治理制度	明确决策权限、升级路径、审批规则

有流程不等于官僚。好的流程是把最佳实践的路径固化，让新人也能沿着老手的脚印走。

6. 锲而不舍 → 目标 + 变更

刻一千刀，刀刀用力，最终刻穿金石。

PM 实践	具体动作
目标管理	章程确立项目目标，始终围绕目标前进
变更控制	变更是手段不是目的------变要让目标更好达成，而不是让目标漂移

方向不变，手段可调。项目最怕的不是变更，而是变来变去把目标弄丢了。

7. 积微成著 → 组织过程资产

每个项目留下一点东西，百年老店的竞争力由此堆积而成。

PM 实践	具体动作
经验教训登记册	每个项目记录什么做对了、什么做错了
组织过程资产（OPA）	模板、流程、知识库持续更新和复用

一个项目的终点，是下一个项目的起点。好的组织不让同样的错误犯两次。

8. 公开透明 → 沟通 + 参与

消息藏一天，猜疑长三尺。

PM 实践	具体动作
沟通管理	谁需要什么信息、什么时候、什么形式------计划好，执行好
干系人参与	让关键干系人持续知情、持续输入

坏消息不说不会消失，只会发酵。透明不是示弱，是建立信任最快的方式。

9. 同舟共济 → 诚信 + 共赢

船翻了，谁的点子好都没用。

PM 实践	具体动作
诚信	PM 的核心职业道德之一------不隐瞒、不欺骗
共赢思维	从"我的利益"转向"项目的利益"

PMBOK 强调"干系人"而非"客户"，正是因为项目的成功需要所有相关方的共同投入。一个心怀不满的干系人足以毁掉一个完美的交付。

10. 各司其职 → 授权 + 平等

PM 不是全能，是让每个人把自己那部分做到最好。

PM 实践	具体动作
授权	责任到人，权力跟责任走
平等尊重	每个角色对项目同等重要，没有高低贵贱

项目经理最忌讳两件事：事必躬亲（把自己累死）和甩手掌柜（项目失控）。好的授权是：任务交给你，权力给你，资源给你，我只问结果。

一张图总结

  项目管理的十大心法

  事前 ── 未雨绸缪（规划）
   │      防微杜渐（监控）
   │
  事中 ── 资源集成（整合）
   │      循规蹈矩（过程）
   │      恰到好处（范围/质量）
   │
  始终 ── 锲而不舍（目标）
   │      公开透明（沟通）
   │      同舟共济（诚信）
   │      各司其职（授权）
   │
  事后 ── 积微成著（沉淀）

一句记十条： 未雨绸缪防风险，防微杜渐盯偏差，资源集成编大网，恰到好处不镀金，循规蹈矩建流程，锲而不舍追目标，积微成著攒资产，公开透明赢信任，同舟共济求共赢，各司其职放对权。

---

本章高频考点清单

#	考点	一句话
1	铁三角	范围/时间/成本互锁，改一个必动其他
2	微笑成本曲线	变更越晚成本越高，前期投入发现问题的成本最低
3	项目 vs 项目集 vs 项目组合	项目=交付成果；项目集=协同收益；项目组合=战略对齐
4	波士顿矩阵	明星/金牛/问题/瘦狗------组合管理的核心工具
5	敏捷宣言	个体互动>流程工具；可工作软件>文档；客户协作>合同；响应变化>计划
6	传统 vs 敏捷	传统=全面计划→执行；敏捷=小步快跑→持续反馈
7	项目预算构成	成本基准(=活动估算+应急储备)+管理储备=项目预算
8	概念/情景/计算三类题	概念=死记；情景=判断；计算=EVM/沟通渠道/PERT/EMV

本章常见考试陷阱

陷阱	正解
范围可以随便改不影响预算 ×	铁三角互锁，改范围必影响时间和成本，必须走变更控制
敏捷没有计划 ×	敏捷有计划，只是渐进明细的滚动式规划
项目集 = 大项目 ×	项目集侧重收益协同，项目以大≠项目集
项目管理就是敏捷 ×	敏捷只是方法论之一，传统/混合都有适用范围

---