PMP 入门与实战：从项目经理角色认知到沟通方法

Wed, 09 Aug 2017 10:00:00 +0800

PMP 入门与实战：从项目经理角色认知到沟通方法

我在华为电软核担任项目经理，这是我给新人培训材料的总结。项目管理不是把活派出去就完事，而是在有限的时间、预算、资源约束下，带领团队把事儿做成。这篇文章结合 PMP 体系与一线交付经验，帮你用最快的速度建立 PM 的角色认知和实战感。

一、PM 不是高级打杂，而是项目的总导演

很多新人第一次做 PM 时会有错觉：PM 就是催进度、拉会议、写周报的“高级打杂”。但真正的 PM 是项目的总导演——你对最终交付结果负责，而不是只负责传话。

1.1 项目经理的四个角色

结合 PM 角色认知模型，项目经理要同时承担四个责任：

flowchart TB
    PM([项目经理 PM])
    D[项目按要求交付责任者]
    T[团队建设责任者]
    O[组织能力建设责任者]
    B[项目经营责任者]

    PM --> D
    PM --> T
    PM --> O
    PM --> B

    D --> D1[启动 / 计划 / 执行 / 监控 / 验收 / 关闭]
    T --> T1[核心团队运作 / 人员能力提升 / 组织氛围]
    O --> O1[流程方法 / 工具建设 / 过程资产积累]
    B --> B1[收入管理 / 成本控制 / 业务拓展]

简单记忆：

角色	关键词	日常表现
交付责任者	按期、按质、按预算	盯进度、管风险、控变更、搞验收
团队建设者	人心、能力、氛围	布阵点兵、辅导下属、解决冲突
组织能力建设者	流程、方法、资产	沉淀模板、优化流程、分享经验
经营责任者	赚钱、省钱、控成本	成本评估、收入确认、变更报价

1.2 从个人贡献者到团队绩效达成者

PM 是一次“转身”：以前你关注“我干得怎么样”，现在你要关注“我们团队干得怎么样”。

flowchart LR
    A[独立贡献者<br/>个人绩效] -->|转身| B[项目经理<br/>团队绩效]
    B --> C[关注事]
    B --> D[关注人]
    C --> C1[计划 / 进度 / 质量 / 风险]
    D --> D1[沟通 / 激励 / 培养 / 冲突]

新人自检三问：

我是谁？（我在这个项目里的核心职责是什么）
我的优势劣势？（我擅长技术、沟通还是流程）
我的工作方式？（我习惯先发制人还是被动响应）

二、PMP 核心原理：五大过程组

PMP 把项目管理抽象成 49 个过程，归入 5 大过程组 和 10 大知识领域。新人不用背 49 个过程，先理解 5 大过程组的逻辑。

2.1 五大过程组循环

flowchart LR
    A[启动<br/>Initiating] --> B[规划<br/>Planning]
    B --> C[执行<br/>Executing]
    C --> D[监控<br/>Monitoring & Controlling]
    D --> E[收尾<br/>Closing]
    D --> B
    D --> C
    E --> A

    style A fill:#e0f2fe
    style B fill:#dcfce7
    style C fill:#fef9c3
    style D fill:#fee2e2
    style E fill:#f3e8ff

过程组	核心问题	关键输出
启动	为什么要做？值不值得做？	项目章程、干系人登记册
规划	怎么做？谁来做？什么时候做完？	项目管理计划、WBS、进度基准、成本基准
执行	按计划推进，协调资源与人	可交付成果、变更请求
监控	偏差多少？要不要纠偏？	工作绩效报告、变更请求、纠正措施
收尾	做完了吗？经验留下了吗？	验收报告、经验教训、项目关闭

注意：五大过程组不是严格的“阶段”，它们会重叠、反复、交叉。比如监控贯穿始终，规划也可能在执行中重新发生。

2.2 十大知识领域一句话版

flowchart TB
    subgraph KA[十大知识领域]
        direction LR
        A1[整合管理] --> A2[范围管理]
        A2 --> A3[进度管理]
        A3 --> A4[成本管理]
        A4 --> A5[质量管理]
        A5 --> A6[资源管理]
        A6 --> A7[沟通管理]
        A7 --> A8[风险管理]
        A8 --> A9[采购管理]
        A9 --> A10[干系人管理]
    end

知识领域	核心问题	新人重点
整合管理	怎么把零散的事串成整体？	写计划、做变更、开阶段评审
范围管理	到底做什么？不做什么？	WBS、需求澄清、范围变更控制
进度管理	什么时候做完？	里程碑、甘特图、关键路径
成本管理	要花多少钱？能不能省？	估算、预算、挣值分析
质量管理	做成什么样才算好？	验收标准、测试计划、质量回溯
资源管理	需要谁？怎么激励？	团队组建、责任分配矩阵 RAM
沟通管理	跟谁说什么？怎么说？	沟通计划、例会、周报、话术
风险管理	什么可能搞砸？怎么应对？	风险登记册、应急预案
采购管理	哪些东西要外购？	SOW、合同、供应商管理
干系人管理	谁在意这个项目？怎么管理期望？	干系人登记册、参与策略

三、项目铁三角与新六边形

3.1 传统铁三角

flowchart LR
    A[范围 Scope] --- B[进度 Schedule]
    B --- C[成本 Cost]
    C --- A

3.2 PMP 更完整的六边形制约

现代项目管理认为，项目受多个因素共同制约：

flowchart TB
    Q[质量 Quality]
    S[范围 Scope]
    C[成本 Cost]
    T[进度 Time/Schedule]
    R[风险 Risk]
    RE[资源 Resources]

    Q --- S
    S --- C
    C --- T
    T --- R
    R --- RE
    RE --- Q

新人最常踩的坑：客户说“加个小功能，不影响进度和成本”。你要意识到：范围变了，进度、成本、质量、风险几乎都会变，只是影响大小不同。PM 的职责是把这些影响量化出来，让决策者做知情选择。

四、项目规划：把大目标拆成可执行的小任务

规划阶段是 PM 最需要下功夫的阶段。规划不好，执行再努力也白搭。

4.1 计划分级：不同人看不同粒度

级别	名称	用途	读者
0 级	里程碑计划	只显示关键节点	公司管理层、项目集经理
1 级	职能领域计划	各职能主要工作	项目经理、核心团队
2 级	专项详细计划	开发/测试/采购等展开	模块负责人
3 级	个人执行计划	任务到天/人	项目成员

4.2 WBS：工作分解结构

WBS 是项目规划的骨架。核心原则：

100% 原则：所有项目工作都要被分解，不能遗漏。
4-6 层原则：一般 4 层左右，别超过 6 层。
80 工时原则：最底层任务一般不超过 80 小时（约 2 周）。
滚动式规划：近期详细，远期粗略。
干系人参与：让相关人一起拆，不要 PM 一个人拍脑袋。

flowchart TD
    A[OTT 平台交付项目] --> B[需求与设计]
    A --> C[平台部署]
    A --> D[终端开发]
    A --> E[内容对接]
    A --> F[测试验收]
    A --> G[项目关闭]

    B --> B1[需求澄清会]
    B --> B2[方案设计]
    B --> B3[SOW 确认]

    C --> C1[云资源开通]
    C --> C2[流媒体部署]
    C --> C3[CDN 配置]

    D --> D1[Android STB]
    D --> D2[iOS Mobile]
    D --> D3[SmartTV]
    D --> D4[PC Web]

    E --> E1[直播源接入]
    E --> E2[VOD 内容上传]
    E --> E3[DRM 对接]

    F --> F1[E2E 测试]
    F --> F2[客户验收]
    F --> F3[问题整改]

    G --> G1[交付件归档]
    G --> G2[转维培训]
    G --> G3[项目总结]

4.3 甘特图、里程碑、燃尽图

甘特图：横轴时间，纵轴任务，直观显示“谁什么时候做什么”。
里程碑：项目中的关键节点，通常零工期，用来标志阶段完成。
燃尽图：敏捷项目常用，显示剩余工作量随时间下降的趋势。

gantt
    title 示例：OTT 项目关键里程碑
    dateFormat  YYYY-MM-DD
    section 启动与规划
    项目启动会           :a1, 2015-08-01, 7d
    SOW 确认             :milestone, after a1, 0d
    详细计划基线         :milestone, 2015-08-15, 0d
    section 执行
    平台部署             :2015-08-16, 14d
    终端开发             :2015-08-20, 20d
    内容对接             :2015-09-01, 10d
    section 验收
    E2E 测试             :2015-09-11, 10d
    客户验收             :milestone, 2015-09-25, 0d
    项目关闭             :2015-09-26, 5d

五、项目执行与监控：PDCA 循环

执行与监控不是“盯人”，而是计划 → 实施 → 反馈 → 调整的循环。

flowchart TD
    P[Plan 计划] --> D[Do 执行]
    D --> C[Check 检查]
    C --> A[Act 调整]
    A --> P

    P -.->|基线| M[范围/进度/成本基准]
    C -.->|度量| D1[进度偏差<br/>成本偏差<br/>质量指标]
    A -.->|措施| D2[纠正 / 预防 / 缺陷补救]

监控阶段 PM 要回答的三个问题：

我们现在在哪？（实际进度、成本、质量）
我们离计划多远？（偏差）
我们要怎么做？（纠正措施、变更、上报）

六、沟通管理：PM 70% 时间都在沟通

PMP 认为沟通管理是项目成败的关键。PM 不是传声筒，而是信息的过滤器、翻译器和加速器。

6.1 沟通管理四步法

flowchart LR
    A[识别干系人] --> B[制定沟通计划]
    B --> C[执行沟通]
    C --> D[问题闭环]
    D --> A

6.2 干系人识别与分类

干系人就是对项目有影响或被项目影响的人。常见分类：

flowchart TB
    subgraph S[干系人四象限]
        direction LR
        A[高权力<br/>高利益] --- B[高权力<br/>低利益]
        C[低权力<br/>高利益] --- D[低权力<br/>低利益]
    end

    A --> A1[重点管理<br/>客户老板 / 项目发起人]
    B --> B1[令其满意<br/>职能部门领导]
    C --> C1[随时告知<br/>终端用户 / 运营人员]
    D --> D1[花最小精力监督<br/>外围支持人员]

6.3 沟通方式选择

场景	推荐方式	原因
复杂问题、有冲突	面对面 / 视频会议	能看到表情、即时反馈
需要留痕、正式确认	邮件 / 会议纪要	可追溯、可签字
日常进度同步	即时消息 / 日报	快速、轻量
跨部门协调	项目例会 / RACI 表	明确责任、统一节奏

6.4 高频沟通话术模板

场景 1：需求不明确，需要客户确认

“王总，关于 XX 功能，目前我们理解有两种实现方式：方案 A 是……，优点是……，缺点是……；方案 B 是……，优点是……，缺点是……。从项目范围和时间来看，我建议采用方案 A，您看是否可以确认？如果选 B，可能需要增加 3 天并调整后续测试计划。”

要点：给选项、讲影响、让客户做选择题而不是开放题。

场景 2：进度Delay，需要同步客户

“李经理，想和您同步一个情况：受第三方接口延迟影响，模块 X 预计比原计划晚 2 天。我们已经采取了以下措施：1. 协调对方优先级；2. 并行启动模块 Y 测试；3. 准备临时方案。目前整体里程碑仍可控，我们会每天同步进展。这是详细的影响评估，您看是否需要召开专项会议？”

要点：先说事实、再说影响、最后给措施和选项。

场景 3：客户提出范围变更

“张总，这个需求我们收到了。我先记录下来，明天下午 5 点前给您一份变更影响评估，包括：对进度、成本、质量、风险的影响，以及推荐方案。评估完成后我们再一起决策是否纳入本期交付。”

要点：不直接拒绝也不直接答应，用“评估 → 决策 → 实施”的流程争取时间。

场景 4：团队内部冲突

“你们两边的顾虑我都理解了：开发担心改动引发回归，测试希望尽早覆盖边界。我们的共同目标是按期高质量交付。这样，我们先用 15 分钟把边界场景列出来，评估改动范围，如果可控就本周内完成；如果范围大，就走变更流程。现在我们一起写一下场景清单。”

要点：点出共同目标、把冲突转化为任务、给明确截止时间。

场景 5：推动不愿配合的职能部门

“刘经理，这个任务在咱们项目计划里是模块 X 的前置依赖，目前距离截止时间还有 3 天。如果这边不能按期提供，会导致下游 5 个人停工，整体里程碑风险会上升到高。您看能否协调资源优先处理？如果需要我向上汇报协调，我也可以同步项目发起人。”

要点：讲清楚依赖关系、量化影响、给对方台阶也保留升级路径。

七、变更管理：拥抱变化，拒绝侥幸

变更是项目常态，但 PM 不能当“传话筒”，必须建立变更控制机制。

7.1 变更管理五步流程

flowchart TD
    A[变更识别] --> B[变更澄清]
    B --> C[变更分析]
    C --> D[变更决策]
    D --> E[变更实施与跟踪]
    E --> F[基线更新]

    A -->|任何人提出| A1[记录变更请求]
    B -->|聚焦价值| B1[明确变更内容和原因]
    C -->|四原则三标准| C1[范围/进度/成本/质量影响]
    D -->|CCB/客户| D1[批准/拒绝/暂缓]
    E -->|责任人| E1[执行并验证]

变更分析四原则：影响范围、进度、成本、质量都要评估。

变更决策三标准：必须做？值得做？现在做？

7.2 变更管理话术

阶段	话术
识别	“收到，我先记录为变更请求 CR-001，稍后统一评估。”
澄清	“为了准确评估，能否确认一下：这个功能的使用场景是什么？必须在哪个版本上线？”
分析	“这个变更会影响 3 个模块，预计增加 5 人天，测试周期延长 2 天，风险等级为中。”
决策	“基于影响评估，建议本期不做，放到二期；如果必须做，需要追加预算并调整验收时间。”
实施	“变更已批准，这是更新后的计划和责任人，请大家按新基线执行。”

八、风险管理：提前把坏事想清楚

风险不是等问题发生了再处理，而是提前识别、评估、应对、监控。

8.1 风险管理四步法

flowchart LR
    A[风险识别] --> B[风险评估]
    B --> C[风险应对]
    C --> D[风险监控]
    D --> A

    A -.->|工具| A1[头脑风暴 / 检查表 / 经验教训]
    B -.->|维度| B1[概率 × 影响]<br/>高/中/低
    C -.->|策略| C1[规避 / 转移 / 减轻 / 接受]
    D -.->|动作| D1[跟踪 / 更新 / 触发应急]

8.2 风险应对策略

策略	含义	例子
规避	不做或换方式，彻底消除风险	不用未经验证的新技术
转移	把风险后果转给第三方	买保险、签固定总价合同
减轻	降低概率或影响	增加测试、提前采购关键设备
接受	不采取措施，准备应急储备	预留缓冲时间或预算

8.3 风险登记册模板

风险 ID	风险描述	概率	影响	等级	应对措施	责任人	状态
R01	第三方接口延迟	中	高	高	提前 2 周启动对接，准备 mock	张三	跟踪
R02	核心人员离职	低	高	中	建立备份机制，文档化	李四	跟踪
R03	客户需求频繁变更	高	中	高	固化 SOW，严格变更流程	PM	跟踪

8.4 风险沟通话术

“我们在风险评审中发现，第三方 DRM 对接存在延期可能。当前概率评估为中等，但一旦发生会影响整个验收。我们的应对措施是：本周内完成技术预研，并准备一套降级方案。责任人是我，下次周会同步进展。”

九、项目验收与关闭

项目不是上线就结束了，验收和关闭同样重要。

9.1 验收流程

flowchart TD
    A[完成全部交付件] --> B[配置审核]
    B --> C[入口条件审核]
    C --> D[提交验收申请]
    D --> E[客户组建验收组]
    E --> F[正式验收测试]
    F --> G{是否通过?}
    G -->|是| H[签署验收报告]
    G -->|否| I[问题整改]
    I --> F
    H --> J[项目关闭 / 转维]

9.2 验收前 PM 自检清单

合同 / SOW 约定的交付件是否全部完成？
测试报告、用户手册、运维文档是否归档？
已知缺陷是否有客户书面确认？
验收申请是否正式发出？
验收标准和测试用例是否与客户对齐？

9.3 项目关闭三件套

验收报告：客户签字，确认交付完成。
经验教训：好的坏的都记下来，下次不再踩坑。
转维交接：让运维/运营团队能接手。

十、案例复盘：为什么 A项目能成，Transvision项目不行

10.1 A项目：成功交付的关键

范围清晰：直播/DVR/catchup + 付费/预付费模式 + launcher/广告/getsapp。
计划可控：首期 3 个月 12 天，二期 3 个月，节奏稳定。
沟通及时：与客户保持良好及时的沟通。
风险质量进度都管住了：最终客户满意度高，用户增长迅速。

启示：项目成功 = 清晰范围 + 可控计划 + 有效沟通 + 风险管理。

10.2 Transvision项目：为什么不可交付

需求边界不清：全终端、双 DRM、多支付、广告、CP Dashboard、用户割接、时移、ABR……堆在一起。
成本无法核算：套餐定价与 XXX公司成本核算难以达成明确结论。
商业可行性存疑：POC 持续近一年，成本约 5000 美金，最终被拒。

启示：PM 要敢于在早期说“这个项目不可交付”——不是消极，而是对组织负责。项目经营责任者的角色要求 PM 评估商业可行性，而不仅是执行。

十一、给 PM 新人的三条成长建议

1. 先建立“流程感”，再追求“灵活性”

新人常犯的错误是觉得流程麻烦、想快速跳过。但流程是保护你的：变更流程保护你不被客户随意改需求，风险流程保护你不被突发问题打懵。先把流程跑熟，再谈灵活裁剪。

2. 把“人”当成项目最重要的风险

进度延期、需求变更、技术问题，归根到底都是人的问题。PM 70% 的时间要花在沟通上：对齐期望、解决冲突、激励团队、管理客户。

3. 练习“结构化表达”

PM 的话术不是油滑，而是结构化：

结论先行
给数据和事实
讲影响和选项
明确下一步和责任人

十二、总结：一张图看懂 PM 的核心工作

flowchart TB
    A[项目目标] --> B[范围管理]
    B --> C[WBS 分解]
    C --> D[进度/成本/质量计划]
    D --> E[执行 + 监控]
    E --> F[沟通 / 风险 / 变更]
    F --> G{验收通过?}
    G -->|是| H[项目关闭]
    G -->|否| I[整改 / 变更]
    I --> E

    style A fill:#e0f2fe
    style H fill:#dcfce7
    style I fill:#fee2e2

PM 的核心能力可以概括为三句话：

把事情做对：理解需求、拆清范围、管好进度成本质量。
把人对齐：识别干系人、制定沟通策略、化解冲突。
把风险控住：提前识别、量化影响、准备预案。

如果你刚转 PM，别急着背 49 个过程。先把这篇文章里的角色认知、五大过程组、WBS、沟通、变更、风险管理跑起来，你就已经比大多数新人走得更稳了。

参考：本文部分内容结合《XXX PM 角色认知》培训材料与 PMBOK 第七版/第六版项目管理知识体系整理，融入一线 OTT 项目交付经验。

沟通管理 on 方糖猫Blog

PMP 入门与实战：从项目经理角色认知到沟通方法

PMP 入门与实战：从项目经理角色认知到沟通方法

一、PM 不是高级打杂，而是项目的总导演

1.1 项目经理的四个角色

1.2 从个人贡献者到团队绩效达成者

二、PMP 核心原理：五大过程组

2.1 五大过程组循环

2.2 十大知识领域一句话版

三、项目铁三角与新六边形

3.1 传统铁三角

3.2 PMP 更完整的六边形制约

四、项目规划：把大目标拆成可执行的小任务

4.1 计划分级：不同人看不同粒度

4.2 WBS：工作分解结构

4.3 甘特图、里程碑、燃尽图

五、项目执行与监控：PDCA 循环

六、沟通管理：PM 70% 时间都在沟通

6.1 沟通管理四步法

6.2 干系人识别与分类

6.3 沟通方式选择

6.4 高频沟通话术模板

场景 1：需求不明确，需要客户确认

场景 2：进度Delay，需要同步客户

场景 3：客户提出范围变更

场景 4：团队内部冲突

场景 5：推动不愿配合的职能部门

七、变更管理：拥抱变化，拒绝侥幸

7.1 变更管理五步流程

7.2 变更管理话术

八、风险管理：提前把坏事想清楚

8.1 风险管理四步法

8.2 风险应对策略

8.3 风险登记册模板

8.4 风险沟通话术

九、项目验收与关闭

9.1 验收流程

9.2 验收前 PM 自检清单

9.3 项目关闭三件套

十、案例复盘：为什么 A项目 能成，Transvision项目 不行

10.1 A项目：成功交付的关键

10.2 Transvision项目：为什么不可交付

十一、给 PM 新人的三条成长建议

1. 先建立“流程感”，再追求“灵活性”

2. 把“人”当成项目最重要的风险

3. 练习“结构化表达”

十二、总结：一张图看懂 PM 的核心工作

十、案例复盘：为什么 A项目能成，Transvision项目不行