new
This commit is contained in:
@@ -0,0 +1,90 @@
|
||||
### 1 个人概述
|
||||
#### 1.1 个人背景
|
||||
奶爸，白天上班，备考时间不稳定。学习时间集中在每天的23点到凌晨2点。
|
||||
1. 23点开始看回放，整理笔记。
|
||||
2. 23点开始刷题，有时为了刷完一套题，可能奋斗到后半夜2点。
|
||||
|
||||
#### 1.2 信心不足
|
||||
|
||||
清晖老师说备考刷题达到126分能过，刷题成绩并没有给自己多少的信心，基本上是悬崖边。自然考场出来信心也是不足，一度安慰自己，过不了也没关系，想想考试费，下次不考了吧。结果3A了。
|
||||
|
||||
* 备考刷题成绩
|
||||
|
||||
> | 复习-1 | 复习-2 | 模拟-1 | 模拟-2 |
|
||||
> |:---:|:---:|:---:|:---:|
|
||||
> |117|128|132|115|
|
||||
|
||||
### 2 备考
|
||||
|
||||
#### 2.1 笔记篇
|
||||
在清晖最开始建班级群的时候，我自告奋勇成了班委，主要负责整理课常笔记，并发出来在班里分享。主要目标是有一个责任在身上，可以督促自己去梳理知识框架。避免学习过程中可能且必定出现的偷懒情绪。
|
||||
|
||||
##### 2.1.1 电子笔记工具
|
||||
大纲类笔记软件，主要是通过整理大纲，把PMP考试的知识结构梳理出来。
|
||||
|
||||
##### 2.1.2 笔记大纲
|
||||
PMBOK每一个知识领域的知识结构是比较简单的，如下图所示，基本上，都可以整理出类似的结构。
|
||||
![[Pasted image 20240716103736.png|400]]
|
||||
|
||||
#### 2.2 刷题篇
|
||||
##### 2.2.1 结合十五矩阵考点定位
|
||||
|
||||
前文强调了考点定位的重要性，个人在开始刷题经常会有定位错误的情况，整理了一个审题步骤，如下：
|
||||
|
||||
1. 判断问题描述场景是哪一个阶段
|
||||
2. 判断问题描述场景是哪一个知识领域
|
||||
3. 判断问题描述场景涉及到哪个工具
|
||||
4. 定位责任人
|
||||
1. 项目经理的职权范围在于项目管理
|
||||
2. 涉及到启动过程/商业战略等，可能需要找发起人
|
||||
|
||||
##### 2.2.2 模考总结样例
|
||||
在做完第一套模拟题之后，对了答案，二刷分数没什么改变，于是针对模拟题，做出如下总结：
|
||||
|
||||
> 1. 特别注意题目
|
||||
> 1. 23，团队自主决定 ☑️
|
||||
> 2. 35，回顾会的内容 ☑️
|
||||
> 3. 40，团队站会自主 ☑️
|
||||
> 2. 错题考点
|
||||
> - 最小交付物、原型法 1
|
||||
> - 培训需求评估 2
|
||||
> - 管理计划是程序文件，不涉具体具体知识领域的细节描述 1
|
||||
> - 干系人通过冲刺评审会，了解项目情况，并反馈意见 1
|
||||
> - 问题与风险的区别 1
|
||||
> - 干系人参与项目
|
||||
> - 计划，有助于项目成功 1
|
||||
> - 干系人参与展示会，有助于减少功能发布错误 1
|
||||
> - 干系人了解项目信息少，了解干系人期望，制定沟通管理计划 2
|
||||
> ...
|
||||
|
||||
##### 2.2.3 回到笔记
|
||||
1. 个人并没有再去做统计，哪一类知识点做的最多
|
||||
2. 模考中，出错的知识点，要么定位出错，要么知识点没掌握好
|
||||
3. 回到笔记，去找到老师标记的重点，读两遍，清晖老师要求的读重点，我就是在这一步完成的
|
||||
|
||||
### 3 总结
|
||||
|
||||
1. 不要钻牛角尖
|
||||
考试考的是对知识点的掌握，是规范里定义的最佳实践，不一定符合某些个人的实践经验，不要跟考试过不去、不要跟自己的时间过不去，来考PMP，钱都花了，请先接受PMBOK的思想。
|
||||
2. 班级讨论
|
||||
我所在的清晖班级群讨论非常积极，每日三题、模拟题错题讨论。个人在提问时关注的内容，和前文所述重点基本一致，答案虽然理解了，但题目的考点是哪些，如何做“十五矩阵考点定位”的。班班和上课老师分享的经验，可以很好的帮助我们快速掌握PMP考题的思路，同学们之间的讨论也经常会碰撞出一些火花。
|
||||
3. 定位题目的考点
|
||||
PMP考试大多数为场景描述题，在描述中，经常涉及多个过程组和知识领域，找到关键的提问句，定位考点。做题时不要纠结某个选项，把握题目的考点最重要，不能准确定位题目考点，知识点倒背如流又能如何。
|
||||
4. 重点知识学习
|
||||
以考试的角度来说，确实有些知识是不考的，不要浪费时间。
|
||||
老师课上说的重点知识，需要认真对待。
|
||||
另外，除开知识点以外，老师的经验更是重点，比如：敏捷题占比很大，多读讲义。
|
||||
1. 学习材料
|
||||
- 看书重不重要：和清晖老师建议略有不同，我没看过教材，这里说教材，指的是《PMBOK V6》《敏捷实践指南》《PMBOK V7》。
|
||||
- 讲义重不重要：跟课学习、整理知识时很重要，有了自己仔细整理的电子笔记后，就没用了。强调，这里说的是“仔细准备的电子笔记”。
|
||||
1. 敏捷
|
||||
对比一下PMBOK，敏捷只有薄薄一本，但是却占了近70道题。清晖有敏捷专项训练，一定要做。即便有些题考点是PMBOK的内容，但也可能拿敏捷的内容来迷惑你。
|
||||
6. 笔记
|
||||
在我个人备考过程中，笔记的整理占了比较大的时间，可以更好的把握PMP考试的知识点脉络。而在后面刷题的过程中，笔记对我的帮助也很大，学习过程是以笔记为核心展开的。
|
||||
7. 模考
|
||||
目标不是刷了多少套，也不是刷了多少分，重点在于，对应到老师课上提出的重点。思考一下
|
||||
1. 做模拟题的目标是啥？
|
||||
2. 二刷模拟题的意义是啥？
|
||||
3. 记笔记的意义是啥？
|
||||
8. 题目
|
||||
不论是清晖的模拟题，还是考场真题，中文题目真的都是机翻，这绝对存在影响理解题目的可能性。在备考过程中，题目表述不清楚的，不需要太较真，考试时，如果有英语基础，就去看一下原文。
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: 最终报告
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 最终报告是项目或阶段末尾时对这个工作周期的总结。
|
||||
externalLink: "[最终报告](https://my.supernotes.app/share/key+float+moral+maze/)"
|
||||
---
|
||||
|
||||
# 最终报告
|
||||
|
||||
它是4.7<font color="#ff0000">结束项目或阶段的输出文件</font>，用来<font color="#ff0000">总结项目的最终绩效</font>。项目最终的状态如何，都会体现在最终绩效报告当中。里面有：
|
||||
|
||||
1. 范围的目标：项目该干多少活才能算是达到了完工标准；
|
||||
2. 产品的目标：产品做到什么程度才算是合格；
|
||||
3. 成本的目标：项目原计划应该用多少钱，以及实际用了多少钱，还有你成本发生的偏差原因；
|
||||
4. 进度目标：花多长时间应该完工以及你实际花了多长时间。
|
||||
5. 那么还有最终产品服务或成果如何满足商业计划或者是业务需求。
|
||||
6. 以及在项目过程当中发生的风险、问题和解决方案。
|
||||
|
||||
与工作绩效数据的区分，
|
||||
1. 绩效信息和绩效报告体现的是<font color="#ff0000">某个时刻或某个阶段</font>的绩效状态
|
||||
2. 最终报告体现的是在<font color="#ff0000">阶段末或项目收尾</font>的时候的最终绩效状态。
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
---
|
||||
|
||||
title:: 范围管理计划与需求管理的计划
|
||||
abstract:: 管理计划都属于程序文件，他们是定义该如何管理范围和需求的。也就是说《项目范围说明书》、《需求文件》、《需求跟踪矩阵》是在这两个管理计划的控制下。
|
||||
externalLink:: [范围管理计划与需求管理的计划](https://my.supernotes.app/share/cable+february+cash+job/)
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: PMO-项目管理办公室
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: PMO项目管理办公室，项目管理的职能部门，统筹全部项目管理。根据职能的强弱，分为：支持型对项目的控制力最弱，控制型，控制力居中，指令型，对项目的控制力最强。
|
||||
---
|
||||
# PMO-项目管理办公室
|
||||
今天我们来介绍一个服务性的机构：项目管理办公室，英文缩写叫做PMO。PMO的作用是对与项目相关治理过程进行标准化，并促进资源方法论、工具和技术共享的一个组织部门。这句话什么意思呢？它的意思是说，项目管理办公室参与项目的治理，并且制定项目管理的标准、制定项目管理的流程，还能够把资源在多个项目之间进行共享，把好的方法论、好的工具和技术进行共享的一个部门。
|
||||
|
||||
那么，PMO根据企业的所需要，可以设置在不同的层级，比如企业层级、事业部层级和项目组层级。所以它的职责可大可小，根据PMO的一个权力大小，我们把PMO分为三种类型：支持型、控制型和指令型。
|
||||
|
||||
权力最小的叫做支持型，几乎没有什么权利担任的是一个顾问的角色，它可以给项目提供支持，可以提供项目管理的模板，一些最佳实践，可以给项目经理提供指导、辅导、培训和监督。
|
||||
|
||||
权力居中的是控制型，既可以给项目提供模板，提供最佳实践、提供培训、提供监督，也可以有一定的权利控制单个项目。
|
||||
权力最大的是指令型，直接管理项目，直接控制项目的一个交付，他对项目的结果负责任。
|
||||
|
||||
所以我们总结项目经理和PMO，它有什么样的差异呢？项目经理关注的是单个项目的目标，而PMO关注的是多个项目的目标，管理多个项目的变更；项目经理控制的是单个项目的资源，而PMO关注的是优化利用多个项目的资源；项目经理管理的是单个项目的制约因素，比如说项目的范围、进度成本质量风险等等，而PMO是站在企业的高度对多个项目的制约因素进行负责，它可以参与项目组合的管理。
|
||||
|
||||
# 内容提取
|
||||
PMO项目管理办公室，项目管理的职能部门，统筹全部项目管理。根据职能的强弱，分为：支持型对项目的控制力最弱，控制型，控制力居中，指令型，对项目的控制力最强。
|
||||
@@ -0,0 +1,34 @@
|
||||
### 敏捷三个支柱
|
||||
* 透明
|
||||
* 检视
|
||||
* 适应
|
||||
|
||||
### 敏捷三个角色
|
||||
1. 产品负责人
|
||||
|
||||
2. Scrum主管
|
||||
|
||||
|
||||
1. 开发团队
|
||||
|
||||
|
||||
|
||||
|
||||
### 敏捷架构3355
|
||||
|
||||
|
||||
### Scrum的3个工件
|
||||
|
||||
|
||||
### Scrum5个事件
|
||||
|
||||
|
||||
|
||||
### Scrum5个价值观
|
||||
|
||||
|
||||
### Scrum工作框架（PDCA）
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 事业环境因素&组织过程资产
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 事业环境因素的特性，不能改变，项目受其影响。组织过程资产，公司内部不断总结获得经验与知识。
|
||||
---
|
||||
|
||||
# 事业环境因素
|
||||
项目团队不能够控制但是会对项目造成影响限制的各种条件。它可能<font color="#ff0000">提高或限制项目的灵活性</font>，对项目造成<font color="#ff0000">消极或者是积极的影响</font>。
|
||||
|
||||
事业环境因素是外界因素，是项目不能够改变的。如组织文化、组织结构、设施、基础设施，比方说IT硬件，可用性，性能等等，还有一些信息技术软件，公司的项目管理软件，工作授权系统等等，以及员工的可用性，资源的可用性，员工的能力等等，这些也都是事业环境因素。比方说一家公司只可以和这家供应商合作，那么这种就是资源的可用性，你不能够改变又必须选择它，通通都叫做事业环境因素。
|
||||
|
||||
# 组织过程资产
|
||||
组织过程资产是在管理项目的过程中<font color="#ff0000">积累的知识和总结的经验教训以及遵循的流程政策</font>，它从哪来呢？它和事业环境因素不一样，它一定是<font color="#ff0000">公司内部不断总结获得的</font>。组织过程资产包括了两部分，<font color="#ff0000">流程与程序共享知识库</font>。
|
||||
1. 组织内部的流程与制度政策：比如说公司制定的各种标准、政策以及各种模板、合同模板、风险登记册模板，你可以对它进行各种参考，还有各种控制程序、变更控制程序、风险控制程序。比如说你的项目要进行变更了，变更按照什么流程来进行，风险要进行管控了，风险管控按照什么流程来进行？
|
||||
1. 组织内部的共享知识库。共享知识库，又叫组织知识库，它也是内部不断总结获得的。当我们做完每个项目的时候，需要总结经验教训，更新组织过程资产。当下一个项目启动的时候，需要参考组织过程资产，避免犯同样的错误。组织过程资产，你可以选择用或者是不用，但是事业环境因素，你不能够对它进行选择，必须面对。
|
||||
|
||||
# 内容提取
|
||||
1. 事业环境因素的特性，不能改变，项目受其影响。通常来做，发起一个项目要尽可能的避免事业环境因素的影响，就是因为其不可改变，不可抗拒性，反而言之，这种特性的因素，才将其归类为事业环境因素。
|
||||
1. 组织过程资产，来自组织内部的知识，要充分的利用，以给项目提供初始的、基础的支撑。公司的内部流程、标准和政策，是公司管理过程中总结的经验，他们可以被改变，只要有新的更好的经验产生。
|
||||
@@ -0,0 +1,6 @@
|
||||
### 五大过程组
|
||||
|
||||
### 十大知识领域
|
||||
|
||||
### 49个过程
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
PMbok定义了四种类型的变更请求：
|
||||
1. 纠正措施: 指现在你和原计划做的不一致。比如说进度落后了，但是还没有造成严重的后果，或者是产品的质量缺陷，只是和原计划有一些不一致。那么，现在你需要进行纠偏，让它回到原计划，与计划保持一致。进度落后了，我采取一定的措施让它回到原计划，回到原来的轨道，这个叫做纠正。
|
||||
2. 预防措施: 现在和原计划保持一致，没有偏差，但是你为了确保未来也不产生偏差，做了一定的措施，对未来做防范。
|
||||
3. 缺陷补救: 已经引起了严重的恶果，导致最终的产品有质量问题，这是一个缺陷，因此要进行补救。
|
||||
4. 更新: 它是针对受控文件或计划的变更。对一些重要的项目管理文件以及项目管理计划进行的一些修改叫做更新。
|
||||
|
||||
说明：
|
||||
1. 纠正措施和缺陷补救区别在于：纠正措施没有引起质量问题，没有引起缺陷，没有引起严重的后果。而缺陷补救是指一定是导致了质量缺陷、质量的问题、质量不一致。
|
||||
2. 纠正措施和预防措施它的区别在于：纠正措施是指现在已经产生了偏差，然后给它进行纠正。预防措施是指现在没有产生偏差，预防未来出现差错。
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
#### 商业文件包含哪些内容
|
||||
|
||||
1. 商业可行性论证
|
||||
2. 商业价值分析
|
||||
3. 收益管理计划
|
||||
@@ -0,0 +1,2 @@
|
||||
* 团队章程和基本规则有时是等同的。
|
||||
* 根据团队章程中定义的基本规则来明确团队成员和其他关系人应该采取什么行为引导关系人参与。
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
又称为鱼骨图、石川图。是追溯问题来源的一种方法。
|
||||
[[工具-石川图]]
|
||||
@@ -0,0 +1,2 @@
|
||||
用来确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
又称为鱼骨图、因果图。是追溯问题来源的一种方法。
|
||||
[[工具-因果图]]
|
||||
@@ -0,0 +1,4 @@
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
定生分析的三元素：概率、影响、紧迫性
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
* 有助于确定哪些风险对项目具有最大的潜在影响。
|
||||
* 典型表现形式是龙卷风图。
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
1. 直接成本：直接计入单个项目的钱，不由多个项目来进行分摊。
|
||||
1. 间接成本：不能直接计入单个项目的钱，需要多个项目来进行分摊。比方说有一件设备是三个项目共用的，那么它的租赁费就由三个项目来进行分摊，这部分钱就叫做间接成本。
|
||||
1. 固定成本：不随生产量或者是工作量的变化而发生变化。
|
||||
1. 可变成本：随着生产量和工作量的变化而发生变化。比如说员工的奖金，员工的加班工资等等。
|
||||
1. 机会成本：这是选择和放弃的一个概念，选择了a项目而放弃了b项目，那么b项目所带来的收益就是a项目的机会成本。比如说a项目可以赚到20万，b项目可能赚到30万，那么选择了项目a而放弃了项目b，那么项目a的机会成本就是项目b可能赚到的30万。
|
||||
1. 沉没成本：已经花掉的钱叫做沉没成本。从纯理性的角度，要不要投资一个项目，不应该考虑沉没成本，沉没成本是已经花掉的钱，它是过去的，过去花的钱不应该影响后续做决策，我们的决策是针对未来，而不是针对过去。
|
||||
|
||||
- 根据成本的承担方：直接成本、间接成本
|
||||
- 成本的确定度：固定成本、可变成本
|
||||
- 项目做与不做：机会成本、沉没成本
|
||||
@@ -0,0 +1,4 @@
|
||||
管理项目知识，指使用现有的知识来生成新的知识并且帮助组织学习的过程。知识管理最重要的是要管理显性知识和隐性知识。
|
||||
什么叫做显性知识呢？能够用语言、文字、图片、数字进行表达的，容易储存的、理解的、易于沟通的，这些都是显性知识。比如说，你去图书馆看书，你上网获取一些资料，你听了一个讲座，你获取到的都是显性知识。可以通过言传的方式来获取。
|
||||
什么叫做隐性知识呢？不容易表达的，难以传递的，难以理解的，只能通过自身的一些反思，思考一些心得体会，这个叫做隐性知识。比如你去听驾校学开车，怎么学开车呢？师傅会给你代教，他会告诉你一些规章制度，怎么开车的一些方法，技术。那你具体自己要怎么样学会开车，怎么把车开的好？是需要自己的勤加练习，对师傅说的话的一些反思和思考。还有你听了一次讲座，你能够接纳到的那些叫做显性知识，那这些知识你接纳到了之后。要通过自身的一些反思之后，你才能够学起来、用起来。那么，真正能够用得上学习上的总结出来的那些经验教训又叫做隐性知识。所以，在管理项目知识的时候，不仅仅要重视显性知识的收集，更加要重视隐性知识的收集。因为如果你不把这些隐性知识给收集起来，那么你的这些经验教训、心得体会可能就会流失了。
|
||||
好，我们今天的知识点就讲到这里，我们明天再见咯~
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: 组织结构
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 项目经理的权力从大到小排, 项目型 > 强矩阵型 > 平衡矩阵型 > 弱矩阵型 > 职能型，说的是一个企业里项目和职能的平衡关系，各有利弊，也不能说现在在考PMP，就认为项目优先就优于职能优先。
|
||||
---
|
||||
|
||||
# 组织结构
|
||||
|
||||
职能型、矩阵型、项目型。矩阵型又可以再细分为弱矩阵，平衡矩阵，强矩阵。
|
||||
* <font color="#ff0000">职能型</font>：传统的组织结构，每个部门都有职能经理。把员工按照专业来划分为部门，员工只要向自己的顶头上司、职能经理汇报工作。这种组织结构有清楚的上、下级的汇报关系，但是跨部门沟通非常的困难。
|
||||
* <font color="#ff0000">弱矩阵型</font>：项目经理的权力小于职能经理。出现了联络员、协调员来帮助跨部门间的沟通。
|
||||
* <font color="#ff0000">平衡矩阵型</font>：项目经理的权力几乎等于职能经理，他与职能经理共同掌握项目的预算。员工有两个老板：职能经理和项目经理，所以这种组织结构沟通很复杂，管理难度大。但是这种组织结构，人力资源的使用效率比较高，因为员工既参与了本职工作，又可以参与项目的工作。
|
||||
* <font color="#ff0000">强矩阵型</font>：项目经理的权力大于职能经理，他的顶头上司不再是职能经理，而是项目经理的经理。并且他一个人全盘掌握项目的预算，项目经理全职工作。而在职能型弱矩阵、平衡矩阵，项目经理是兼职的，但是到了强矩阵型组织，他是全职工作。
|
||||
* <font color="#ff0000">项目型</font>：项目经理最大程度的掌握了项目的团队，员工只需要向自己的顶头上司，项目经理进行汇报工作。所以，这种组织结构沟通容易。但是，在这种组织结构，员工缺乏事业的连续性和保障，资源配置重复，使用效率会比较低下。
|
||||
@@ -0,0 +1,4 @@
|
||||
|
||||
范围基准，它是项目的三大基准之一。是由经过批准的范围说明书，WBS和WBS词典三位一体构成，缺一不可。既然能成为基准，那么说明它是一个<font color="#ff0000">标准，不能随意的更改</font>。如果想要更改范围基准，需要走一个正式的变更控制程序，用来和实际的绩效做比较。
|
||||
|
||||
项目范围书是产品范围和项目范围的整体框架的描述，它描述了范围的边界。WBS是把可交付成果自上而下进行分解，用一个图的形式来进行展示。那么现在这个图如果比较模糊，看不懂的话，我们应该去看一份文字层面的描写，这个叫做<font color="#ff0000">WBS词典</font>。所以，<font color="#ff0000">WBS词典对WBS提供支持</font>。它里面会<font color="#ff0000">对WBS当中的每一个组件进行详细的描述</font>。这个组建的编码，这个组件要做哪些工作，它的假设条件和制约因素，以及谁负责来做这件事情，它的进度里程碑，相关的进度活动所需的资源以及质量要求，验收标准等等。都会详细的记录在WBS词典当中。所以通俗的来讲，WBS词典是做什么的呢？因为WBS它只是一个视图，如果看这个图没有看懂怎么办？那么出来一个WBS词典，用来对图进行补充和解释。所以说，范围基准里的范围说明书，WBS和WBS词典三者缺一不可，构成了一个完整的范围基准。
|
||||
@@ -0,0 +1,2 @@
|
||||
* 通过向专家访谈获得定量风险分析的输入
|
||||
* 鼓励访谈者提出诚实和无偏见的意见
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: 项目章程
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 项目章程的标志性意义，项目的正式立项。主要包含12项内容。
|
||||
---
|
||||
### 过程概述
|
||||
制定项目章程是启动过程组，项目整合管理领域范围的一个过程，这个过程的输出为项目章程，过程成功完成的标志是项目章程的批准。
|
||||
|
||||
|
||||
|
||||
### 过程的核心人员
|
||||
发起人在项目章程的制定过程中，起到拍版的作用，在这个阶段，项目可能牵扯到的干系人还不知道老板要做这么个事。
|
||||
发起人确定了项目章程，这些干系人才会识别出来，并且在计划阶段收到通知。
|
||||
|
||||
### 过程的意义
|
||||
一般是由项目的发起人发起，通过制定项目的章程，完成立项，确立项目的正式地位，并且还能够给项目经理进行授权，授权他在组织中使用资源。所以章程有时候又叫做项目批准书、立项书、立项报告等等。对主要可交付成果、里程碑以及每位干系人的角色和职责达成共识。
|
||||
### 过程的输入
|
||||
1. [[商业文件]]：提供商业可行性论证、收益管理计划。
|
||||
2. 协议
|
||||
3. [[事业环境因素与组织过程资产]]
|
||||
### 过程的输出
|
||||
#### 项目章程
|
||||
章程里面会包含12个内容，里面都是宏观的、大概的、一些方向性的内容：
|
||||
1. 项目的目的
|
||||
2. 可测量的项目的目标
|
||||
3. 高层次的需求（高层次的需求就是宏观的需求、大概的需求、不是很具体的一些需求）
|
||||
4. 高层级的项目描述边界
|
||||
5. 主要的可交付成果（它里面都是大概的一些边界，以及一些主要的可交付成果，并不是全部的可交付成果）
|
||||
6. 整体的项目风险（也是大概的一些风险）
|
||||
7. 总体的里程碑进度计划（大概的里程碑进度计划）
|
||||
8. 预先批准的财务资源（大概的预算）
|
||||
9. 关键的干系人的名单
|
||||
10. 项目的审批要求、项目的退出标准（在什么样的条件下才能够关闭项目，或者是取消项目，也会在章程里面写清楚）
|
||||
11. 项目经理的权责和职权
|
||||
12. 项目的发起人以及高级管理层的姓名也会写在章程当中。
|
||||
|
||||
|
||||
|
||||
|
||||
### 过程的工作方法
|
||||
1. [[工具-专家判断]]
|
||||
2. 数据收集
|
||||
1. [[工具：头脑风暴]]
|
||||
2. [[工具：焦点小组活动]]
|
||||
3. [[访谈]]
|
||||
3. 沟通
|
||||
1. [[技能：冲突管理]]
|
||||
2. [[技能：引导]]
|
||||
3. [[技能：会议管理]]
|
||||
4. [[工具：会议]]
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: 制定项目管理计划
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 规划阶段的工作，对项目进行过程中的方方面面，进行一个统一的规划，指导规范项目后续执行操作。
|
||||
---
|
||||
# 过程概述
|
||||
项目管理计划是一份<font color=red face="黑体">综合性的计划</font>，指导项目如何执行，如何监控，如何收尾，是项目的行动方案。
|
||||
它包含了三部分内容：
|
||||
|
||||
1. 十个子计划 -- 对应十大知识领域，与知识领域完全吻合。比方说范围管理知识领域对应了需求管理计划和范围管理计划，进度管理知识领域对应了进度管理计划，成本管理知识领域对应了成本管理计划，质量管理知识领域对应了质量管理计划，以及后面的资源、沟通、风险、干系人以及采购。
|
||||
2. 三大基准 -- 把范围、进度和成本三合一又成为了绩效测量基准。所以要看一个项目的绩效，一个项目的状态，不仅仅看范围、进度或成本，而是三合一。既然叫做基准，说明你不能随便的改。如果要改基准，需要走正式的变更管理流程才能对基准进行更改。
|
||||
3. 其他组件 -- 包含了变更管理计划，指导项目如何进行变更管理。配置管理计划指导项目如何进行配置管理。项目采用什么样的生命周期，迭代、预测还是适应型，那么还有开发方法，管理审查等等。
|
||||
|
||||
|
||||
|
||||
|
||||
# 提取与个人理解
|
||||
1. <font color=orange face="黑体">总的来说，PMP这书里的知识，并没有告诉我们具体该如何做，他只是解释说明了，或者说定义了，在一个项目中有哪些工作要做，这些工作的之间的依赖关系。稍微具体一点的，就是各种过程中的工具，比如会议，[[工具：头脑风暴|头脑风暴]]，但这些也只是稍微具体了一点，他依然没有，也没有办法去说明具体会要如何开，毕竟具体问题具体分析，项目经理不是人工智能，需要在具体项目中，有自己的分析，判断该如何去做。</font>
|
||||
2. <font color=orange face="黑体">而题目给出具体的场景，这个时候，就需要项目经理，将书里的显性知识，经过内化，以支撑自己的判断。</font>
|
||||
4. 结合十五矩阵来理解项目管理计划，在规划过程组，对项目过程中的各个领域进行计划，由于当前是在讨论整合领域，各项子计划内容，会在后面的对应领域章节去学习，这里只要了解，这个计划要包含哪些内容就好。即：
|
||||
1. 在项目章程得到批准后，标志着完成立项，即进入到项目规划阶段
|
||||
2. 计划与子计划，就是明确这个项目该如何管，范围如何管、进度如何管、成本、质量等等，这些都说明确了，就会对后面的项目执行过程起到规范与约束作用。
|
||||
3. 三大基准
|
||||
1. 范围基准，确定哪些做，哪些不做，边界在哪里。
|
||||
2. 进度，时间预算
|
||||
3. 成本，成本预算
|
||||
4. 其他组件
|
||||
1. 子计划与基准是核心知识领域，其他组件相当于是辅助项目核心管理内容的协助模块定义，对项目的运转起到<font color=red face="黑体">辅助作用</font>。
|
||||
2. 如变更管理，变更本身并不是项目交付产物的核心内容，但是项目过程很难不因此某些因素而发生变更，比如功能，有质量偏差。因此为了更好的处理变化，并且能跟踪，让项目有序的进行，就需要对变更进行管理，因此需要变更管理计划。
|
||||
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
项目是为<font color="#ff0000">创造独特的产品</font>，<font color="#ff0000">服务或成果</font>而进行的<font color="#ff0000">临时性的工作</font>。项目的最终目标是“创造有形或无形的可交付成果”。如：提供的服务、或者是掌握的知识、你发表的科学论文、研发出的成果，这些都可以叫做项目的可交付成果。
|
||||
|
||||
项目的三大特性：
|
||||
1. <font color="#ff0000">临时性</font>，创造完就终止
|
||||
2. <font color="#ff0000">独特性</font>，以往的产品、服务或成果因为某些因素而不能、无法重复使用。这个可交付物是独特的。因为项目的结果具有独特性，导致了项目的过程存在不确定性，因此项目要做好风险管理。
|
||||
3. <font color="#ff0000">渐进明细性</font>。渐进明细是指你掌握的信息越来越多，估算越来越具体，而不断的持续改进和细化你的项目管理计划。项目管理计划又叫做项目的行动方案。在项目的早期，你只掌握了一些项目粗略的信息，只能制定一些简单的项目管理计划，而随着你对项目了解的越来越多，信息越来越准确具体，不断的会去更新修改你的项目行动方案，导致项目管理计划不断的去更新、调整和计划。这个叫做项目的渐进明细性。
|
||||
|
||||
所以我们可以发现，不仅仅是工作当中，而生活当中的项目也无处不在。办公室装修可以是一个项目，举办婚礼可以是一个项目，哪怕在家炒一道菜，也可以把它当做项目来进行对待。这也是PMI给我们灌输的理念，一切皆项目，事事皆项目。
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: 开工会议
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 规划阶段的工作，对项目进行过程中的方方面面，进行一个统一的规划，指导规范项目后续执行操作。
|
||||
---
|
||||
|
||||
# 项目启动大会
|
||||
开工会议它的英文是Kick-off meeting。有时候中文翻译为开踢大会，开球大会，启动大会。就好比足球比赛开场之前，每位教练都会在更衣室对他的足球队员进行一个战略战术的宣布。
|
||||
|
||||
项目启动大会<font color="#ff0000">属于规划过程组</font>，标志着<font color="#ff0000">项目完成执行前的一切准备，计划工作，开始执行工作</font>。
|
||||
|
||||
启动大会与干系人：在完成管理计划之后，每个人的职责，角色，都通过启动大会宣布，所有人达成一个共识，因此，全部干系人都需要参加。
|
||||
在项目启动大会上面，项目经理会向项目团队展示项目管理计划，获得关键干系人对项目管理计划的正式认可。
|
||||
@@ -0,0 +1,2 @@
|
||||
### <font color=red face="黑体">项目周期的特征</font>（P19-4）
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
1. 范围
|
||||
2. 成本
|
||||
3. 时间
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 项目的周期
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 项目采用何种周期模型，取决于对于需求的明确程度，清晰明确的，可以早做计划，不清晰明确的，划分周期来做。
|
||||
---
|
||||
### 项目生命周期
|
||||
五种类型的生命周期：
|
||||
1. 预测型生命周期，也叫完全计划型。完全按照计划来做，整个项目的过程当中没有什么变更。它适用于你对你要交付的产品需求非常明确，你的项目中的计划、工作非常的熟悉，非常的了解。
|
||||
1. 迭代型生命周期。通过不断的循环活动来<font color="#ff0000">优化产品的功能</font>，每一轮迭代都要把产品的功能做到最优。
|
||||
1. 增量型生命周期。在特定的时间之内不断的<font color="#ff0000">增加产品的功能</font>，每一轮的迭代都在上一次的基础上面增加功能。
|
||||
1. 适应型生命周期，又叫做敏捷方法，相当于是<font color="#ff0000">迭代型和增量型的混合</font>。既要优化产品，又要增加功能。它适用于什么场景呢？你对你要交付的最终的产品和结果难以事先确定。在项目管理的过程当中经常有变化，需要应对快速变化的环境，相当于一边提需求一边交付。
|
||||
1. 混合型，相当于是预测型和适应型的混合。在管理项目的过程当中，对于确<font color="#ff0000">定性的需求用预测型</font>，<font color="#ff0000">不确定的那一部分用适应型</font>。比如说硬件部分的需求是比较确定的。那么就用预测型生命周期。软件部分不那么确定用适应型的生命周期。
|
||||
@@ -0,0 +1,14 @@
|
||||
### 项目集
|
||||
|
||||
项目集是一组<font color="#ff0000">相互关联且被协调管理的项目、子项目集和项目集活动</font>，以便获得分别管理所无法获得的利益。怎么解读它呢？它是一组有关联性，有依赖性的项目。放在一起管，好处最多，利益最大化。比如说有人来参加英语培训，完了之后考雅思考托福，这是一组项目集。培训是为了考试，而考试又依赖于培训。这样放在一起做可以使得利益最大化，称之为项目集管理。所以，项目集管理有两个关键词，第一<font color="#ff0000">关联性</font>，第二<font color="#ff0000">依赖关系</font>。所以项目集是多项目，但是多项目不一定是项目集，它有可能是项目组合。
|
||||
|
||||
### 项目组合
|
||||
|
||||
今天我们来解读项目组合管理。项目组合是指为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。项目组合当中的一组项目为了实现同一个共同目标而把它放在一起管。但是，这些项目不一定彼此间有依赖关系，或者是直接相连。可能没有关联性，也没有彼此依赖，只是为了实现同一个目标。它只关注谁的优先级更高，就把资源优先分配给谁。比如说在组合当中有三个项目：a，b，c。如果a的优先级更高，资源先给a，bc就没有那么多的资源。如果c的优先级最高，资源先给c，ab没有那么多的资源。公司的资源是有限的，去的了某一个项目，其他项目可能没有那么多的资源，所以他们彼此竞争。我们在公司企业当中，一定要想办法提高自己项目的优先级去获取更多的资源。
|
||||
|
||||
我们再总结一下什么是项目集管理。有一组项目有关联性，有依赖关系，这是项目集管理。如果有一组项目没有关联性，可能没有依赖关系，彼此还竞争资源，这是项目组合管理。那么项目集是多项目，但是多项目不一定是项目集，它有可能是项目组合。今天的知识点大家都学习到了嘛？欢迎大家提交答题后在评论区留言哦~
|
||||
|
||||
### 内容提取
|
||||
都是多项目，区别在于是否有相关性，依赖关系。
|
||||
1. 项目集：将项目关联在一起的因素是其关联性，互相间的依赖关系。
|
||||
2. 项目组合：将项目关联在一起的因素是组织的高层战略目标。
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: 项目经理的权力
|
||||
category: PMP备考
|
||||
subCategory: 每日打卡
|
||||
abstract: 项目经理的权力，是其使用某种管理手段或方式的依据。
|
||||
---
|
||||
### 项目经理的权力
|
||||
权力的来源，来自于<font color="#ff0000">职位</font>、<font color="#ff0000">人生</font>或者是<font color="#ff0000">人际互动</font>。项目经理的权力，是其使用某种管理手段或方式的依据。PMbok当中提到了14种权力，其中重要的五种：
|
||||
1. 专家权力，作为技术或者管理方面的专家而产生的权力，在项目经理具备对应的专业能力的情况下，为团队提供指导、指引，以使其提高，并完成工作。比如，医生对病人的权力，医生对于病人来说，它是医学方面的专家。
|
||||
1. 奖励权力，来自于项目经理的职位。如果下属表现优良，你可以对他进行奖励。
|
||||
1. 正式权力，也叫合法权力，来自于项目经理的职位。有权力做出某种决定，但是项目经理的正式权力往往是不足的，因为我们默认在矩阵组织当中工作，项目经理会受到职能经理的制约。
|
||||
1. 参照性权力，参照性权力又可以细分为两种，暗示权力以及威望或魅力。第一个暗示权力基于项目经理与职位较高者的关系。别人信任你、欣赏你，以你为榜样是因为你和高层的关系比较好；第二个威望或魅力，比如说你有漂亮的外貌，拥有人格的魅力，能够吸引到别人。
|
||||
1. 惩罚权力，如果下属表现的不好，项目经理对他进行处罚，扣工资、扣奖金等等。
|
||||
|
||||
那么，我们现在总结五种权力，专家权力，参照性权力来自于项目经理的个人。奖励权力，正式权力，惩罚权力来自于项目经理的职位。
|
||||
@@ -0,0 +1,62 @@
|
||||
### 1 概括
|
||||
#### 1.1 定义
|
||||
包括把<font color="#ff0000">组织的质量政策</font>应用于规划、管理、控制项目和产品质量要求，以满足干系人的目标各个过程。
|
||||
#### 1.2 目的
|
||||
需求管理是为了满足用户的显性需求，而质量管理是满足用户在显性需求下的隐性的、内在的需求。
|
||||
#### 1.3 质量标准约束范围
|
||||
* 可交付成果的质量标准
|
||||
* 项目管理过程的质量标准
|
||||
|
||||
### 2 子过程
|
||||
|
||||
|
||||
#### 2.1 规划质量管理（8.1）
|
||||
* 定义：<font color="#ff0000">识别项目及其可交付成果的质量要求和/或标准，并局面描述项目将如何证明符合质量要求和/或标准的过程。</font>
|
||||
* 作用：<font color="#ff0000">为整个项目中如何管理和核实质量提供指南和方向。</font>
|
||||
* 过程：
|
||||
|
||||
* 工具 - <font color="#ff0000">质量成本</font>
|
||||
* <font color="#ff0000">一致性与非一致性工作成本</font>，对比的是计划工作与实际工作。
|
||||
* 计划工作成本有预防成本、评估成本
|
||||
* 非计划工作成本有内部失败成本、外部失败成本
|
||||
* 输出
|
||||
* <font color="#ff0000">质量管理计划：项目管理子计划之一。描述将如何实施适用的政策、程序和指南以实现质量目标；也描述了项目团队为实现项目质量目标所需的活动和资源。</font>
|
||||
* <font color="#ff0000">质量测量指标：专用于描述项目或产品属性，以及控制质量过程将如何难符合程度。</font>
|
||||
|
||||
#### 2.2 管理质量（8.2）
|
||||
* 定义：<font color="#ff0000">把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程。</font>
|
||||
* 作用：<font color="#ff0000">提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因。</font>
|
||||
* 过程：
|
||||
|
||||
* 工具
|
||||
* [[工具-数据分析]]，可以简称为分析，区别在于分析的不同的目标数据。通过<font color="#ff0000">分析过程</font>找到由过程问题或因素，而产生的质量问题；<font color="#ff0000">分析根本原因</font>，即找到导致问题的根本原因。
|
||||
* [[工具-因果图]]，又称为鱼骨图、石川图。是<font color="#ff0000">追溯问题来源</font>的一种方法。
|
||||
* [[工具-直方图]]，
|
||||
* [[工具-散点图]]，线性回归方法。找到问题与X/Y因素的相关性。
|
||||
* [[工具-审计]], 在质量管理过程中，审计往往由外部团队开展，如审计部门、PMO或外部审计师，以客观判断质量表现。
|
||||
* [[工具-问题解决]]，属于经验总结知识库，即对可以标准化的问题制定长久、有效的、可参考的结构化的解决方案。
|
||||
* 输出
|
||||
* 质量报告
|
||||
* 测试与评估文件
|
||||
|
||||
#### 2.3 控制质量（8.3）
|
||||
* 定义：<font color="#ff0000">为评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。</font>
|
||||
* 作用：<font color="#ff0000">核实项目可将会成果和工作已经达到主要干系人的质量要求，可供最终验收。</font>
|
||||
* 过程：
|
||||
|
||||
* [[工具-帕累托图]], 用于识别造成大多数问题的少数<font color="#ff0000">重要原因</font>。
|
||||
* [[工具-控制图]], 确定一个过程是否稳定，或是否具有可预测的绩效。
|
||||
* [[工具-七点原则与失控]], 连续的七个点，未超出控制界限，但在均值同一侧，一个点超出控制界限
|
||||
|
||||
* [[工具-石川质量七工具]]
|
||||
> ```mermaid
|
||||
> graph LR
|
||||
> 发现问题-->寻找原因-->记录原因-->分析问题-->解决问题
|
||||
> ```
|
||||
|
||||
* [[工具-石川质量七工具]]
|
||||
|
||||
* 输出
|
||||
* <font color="#ff0000">质量控制测量结果</font>，对质量控制<font color="#ff0000">活动的结果</font>的书面记录
|
||||
* 核实的可交付成果，是确认范围过程的输入，以便项目外部正式验收。
|
||||
* 变更请求
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: 开班
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: 学习资料包括【预习】【预习练习】【正课】【正课练习】【考前】【冲刺练习】，PMP考试须知，考场, PMP证书通过标准、续期资讯。
|
||||
activeDate: 2024-03-16
|
||||
---
|
||||
|
||||
# 一、学习资源
|
||||
1. 正课直播课（14课）：
|
||||
1. 入口
|
||||
1. [PC-阔知学堂](https://www.qhclass.com)
|
||||
2. 知享学堂APP
|
||||
2. 学习时间表（14天，一周两课）
|
||||
1. 
|
||||
2. 
|
||||
3. 要求
|
||||
1. 跟上每一周的直播课，时间紧
|
||||
2. 第一阶段上课，第二阶段刷题
|
||||
3. 讲义为主
|
||||
3. 备考与练习：
|
||||
1. 关注微信公众号 清晖在线学堂-》清晖直播间-》tab4-》我的已购-》备考训练营
|
||||
2. 预习内容，重点看前三章，正课开始就可以放下
|
||||
1. 录播课（以正课为主）
|
||||
2. 预习串讲（以正课为主）
|
||||
3. 分章练习（预习阶段做）
|
||||
3. 正课练习：
|
||||
1. 单元测试（正课阶段做）
|
||||
4. 考前冲刺
|
||||
1. 敏捷题目、复习题目、课堂模拟，正课结束后，考前冲刺做
|
||||
2. 敏捷串讲（直播）、复习串讲（直播）、考试技巧、考前串讲
|
||||
5. 打卡小程序：每日打卡
|
||||
6. 群：每日三题
|
||||
|
||||
|
||||
# 二、考试安排
|
||||
1. 人/过程/环境，3A
|
||||
2. 纸笔/答题卡/230分钟9:00～12:50/180题/（单选、多选）
|
||||
3. 成绩PASS/FAIL
|
||||
4. 6～8周出成绩，电子证，8个月后收到纸制证
|
||||
5. 身份证原件/准考证
|
||||
6. 考场提供文具
|
||||
7. 3月底4月初报考（要考的，信息采集表现在要交了）
|
||||
8. 5个工作日审核PMI账号
|
||||
9. 约126分以上合格
|
||||
|
||||
# 三、续证与PDU：
|
||||
1. 
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: 第一课：项目管理的基本概念
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: 项目的概念、理解项目在组织机构中的定位，项目管理对于项目的作用，不论是项目管理还是项目本身，都是为了组织战略目标服务的。
|
||||
---
|
||||
|
||||
# 重点
|
||||
1. 管理学三原则：
|
||||
1. 目标管理：目标要清晰，可度量，参考SMART原则`明确性、衡量性、可实施性、相关性、时限性`
|
||||
2. PDCA原则（戴明环） `目标->计划->实施->检查`
|
||||
3. 以人为本
|
||||
1. 项目：为创造独特产品、服务或结果而进行的临时性工作。
|
||||
1. 临时性，项目一定是为了某个目标，做项目不是目的，能项目的产物，实现价值才是，因此做项目，肯定会有一个终点，这个做的过程会终止，所以说是临时性的。
|
||||
2. 独特性，产物是独一无二的可交付物，而不是例行工作。独特性导致了不确定性，因此都具有风险。
|
||||
3. 渐进明细，随着项目的推进，越来越明确，明确即更少的不确定性，项目的风险会越来越小。
|
||||
4. <font color=red face="黑体">项目的制约因素</font>（P13-4）
|
||||
1. 范围：有没有
|
||||
2. 质量：好不好，达不达到某某要求
|
||||
5. <font color=red face="黑体">项目的商业价值</font>（P14-2）
|
||||
1. 有形与无形的价值
|
||||
2. 创造商业价值是项目的终极目标
|
||||
1. 项目管理：<font color=red face="黑体">将知识、技能、工具与技术应用于项目活动，以满足项目的要求。</font>（P15-3）
|
||||
1. 战略（不考），理解战略与项目组合的关系，即公司一切的项目，项目集，项目组合都是为了实现公司战略目标，实现战略目标中定义的商业价值目标。
|
||||
3. <font color=red face="黑体">项目组合管理</font>（P17-4）
|
||||
1. 定义：为了实现战略目标，而放在一起管理的项目、集、子组合，与运营工作。
|
||||
2. 重点：
|
||||
1. 不全是临时性的项目工作，运营工作，也可以是组合中的一部分
|
||||
2. 资源分配的优先顺序
|
||||
3. 战略对齐
|
||||
4. <font color=red face="黑体">项目集管理</font>（P18-1）
|
||||
1. 定义：一组相互关联且被协调管理的项目，子项目集，和项目集活动。目标是统筹管理资源分配。
|
||||
2. 重点：
|
||||
1. 具有相关性、互相依赖性
|
||||
2. 关注项目间的依赖关系
|
||||
3. 集成管理，便于统筹规划
|
||||
5. <font color=red face="黑体">项目周期的特征</font>（P19-4）
|
||||
|
||||
1. <font color=red face="黑体">项目阶段</font>（P20-1,2,3）
|
||||
1. 相对大的项目活动，拆分成一组具有逻辑关系的项目活动集合。
|
||||
2. 每个阶段都可以视为一个子项目
|
||||
3. 阶段与阶段间，可以顺序执行，也可以交叠执行
|
||||
4. 阶段评审（理解为子项目验收/绩效评价）
|
||||
2. 项目的生命周期
|
||||
1. 三个范围的周期
|
||||
1. 项目生命周期
|
||||
2. 项目管理周期
|
||||
3. 产品生命周期
|
||||
2. 周期类型：
|
||||
1. <font color=red face="黑体">预测（瀑布）</font>（P21-1）
|
||||
2. <font color=red face="黑体">迭代</font>（P21-2），原型，逐渐完善优化。
|
||||
3. <font color=red face="黑体">增量</font>（P21-3），逐渐增加功能。
|
||||
4. <font color=red face="黑体">适应</font>（P21-4）区别于迭代与增量，迎接变化，严格评估每个周期要交付的内容。
|
||||
5. <font color=red face="黑体">混合</font>（P22-3）确定的预测，不确定的敏捷
|
||||
3. 适应型，区别于迭代与增量，严格评估每个周期要交付的内容。
|
||||
4. 项目管理过程
|
||||
1. 14个过程
|
||||
2. <font color=red face="黑体">五大过程组</font>（P23-3,4）
|
||||
|
||||
1. <font color=red face="黑体">十大知识领域</font>（P24-2）
|
||||
|
||||
1. 项目管理数据与信息
|
||||
1. 工作绩效数据，项目活动的原始观察数据
|
||||
2. 工作绩效信息，偏差结果
|
||||
3. 工作绩效报告，绩效分析与判断，预测
|
||||
1. <font color=red face="黑体">项目管理商业文件</font>（P26-1）
|
||||
1. 项目商业论证：经济可行性研究，论证收益评估的有效性。
|
||||
2. <font color=red face="黑体">项目收益管理计划</font>：定义创造、提高、保持项目收益的过程。（P26-4）
|
||||
2. <font color=red face="黑体">如何选择项目</font>
|
||||
1. <font color=red face="黑体">项目财务测量指标</font>（P27-3）
|
||||
1. <font color=red face="黑体">净现值NPV</font>（P28-2）比大小，越大越好
|
||||
2. <font color=red face="黑体">内部收益率</font>（P28-4）越高越好
|
||||
3. <font color=red face="黑体">回收期</font>（P28-4）越短越好
|
||||
4. <font color=red face="黑体">效益成本比（BCR）</font>（P29-3）越高越好
|
||||
5. <font color=red face="黑体">投资回报率（ROI）</font>（P29-4）越高越好
|
||||
2. <font color=red face="黑体">项目选择成本（P30-2）</font>
|
||||
1. 机会成本
|
||||
2. 沉没成本
|
||||
@@ -0,0 +1,211 @@
|
||||
---
|
||||
title: 第二课：二、三、四章讲义重点
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: --
|
||||
---
|
||||
|
||||
### 1 第一章：敏捷（夸张占70道题）
|
||||
* <font color=red face="黑体">敏捷宣言价值观</font>（P31-3）
|
||||
* 个体和互动 高于 流程和工具
|
||||
* 可工作的软件高于详尽的文档
|
||||
* 客户合作高于合同谈判
|
||||
* 响应变化高于遵循计划
|
||||
* <font color=red face="黑体">敏捷12原则</font>（P31-4）
|
||||
|
||||
* 敏捷是一种工作理念
|
||||
* <font color=red face="黑体">第一章重点清单</font>（P33-1）
|
||||
|
||||
|
||||
### 2 第二章 项目运作环境
|
||||
1. 事业环境因素（EEF）
|
||||
1. 外部 & 内部因素
|
||||
2. <font color=red face="黑体">事业环境因素是项目团队不能控制的、将对项目产生影响、限制或指令作用的各种条件。</font>
|
||||
3. 规划过程的输入，即在规划阶段，需要充分考虑EEF的限制和客观条件，对项目或有促进，或有限制。
|
||||
2. <font color=red face="黑体">组织过程资产（OPA）</font>
|
||||
1. 概念
|
||||
1. 内部的，用过的计划、流程、政策、程序和知识库；
|
||||
2. 来自组织的任何项目使用过的；
|
||||
3. 可用于执行或治理项目的任何产物、实践、知识。
|
||||
2. 项目管理过程的输入
|
||||
3. 包括：
|
||||
1. 过程、政策、程序；
|
||||
1. 启动和规划阶段，
|
||||
2. 执行和监控阶段
|
||||
3. 收尾阶段
|
||||
2. 组织知识库
|
||||
3. <font color=red face="黑体">组织系统</font>（P36-4）
|
||||
4. <font color=red face="黑体">治理</font>，是针对管理的管理.
|
||||
1. 公司的治理结构，如：股东会、CEO。
|
||||
2. 项目的治理结构，如：CEO、PMO、CCB。
|
||||
5. <font color=red face="黑体">组织结构</font>
|
||||
1. <font color=red face="黑体">基本结构</font>
|
||||
考题中提到矩阵型，如果没有特殊说明，就按平衡型矩阵理解。
|
||||
理解不同结构类型的优缺点
|
||||
|
||||
1. 职能型
|
||||
2. 矩阵型（弱、平衡、强）：理解在矩阵中，项目经理与职能经理的平衡、协调工作。
|
||||
3. 项目导向型
|
||||
1. <font color=red face="黑体">PMO项目管理办公室</font>（P41-1，2，3）
|
||||
|
||||
1. PMO三种类型：根据在具体项目中的权限高低，指令型、控制型、支持型，
|
||||
2. 作用
|
||||
1. 项目决策、管理知识传递
|
||||
2. 支持项目经理
|
||||
3. 理解，PMO是对项目管理的更高一层级管理，管理方法，管理过程标准定义与监督等。而项目管理是对具体项目负责，是管理方法或过程的应用。
|
||||
|
||||
### 3 第三章 项目经理
|
||||
* 项目经理的定义：由执行组织委派，领导团队实现项目目标的个人。
|
||||
* 干系人：受项目影响，能影响项目的个人、群体、组织。
|
||||
* 发起人：干系人之一，提供资源，决策人。
|
||||
* 领导力技能、领导力风格（理解：风格往往是这个人技能决定的）
|
||||
* 人际关系技能。
|
||||
* <font color=red face="黑体">权力理论</font>（P50-2）
|
||||
* 正式权力
|
||||
* 奖励权力
|
||||
* 惩罚权力、强制权力
|
||||
* 参照性权力
|
||||
* 专家权力
|
||||
### 4 第四章 整合管理
|
||||
#### 4.1 整合管理
|
||||
1. 整合管理：在项目的不同阶段，都有要整合的工作
|
||||
* 定义：包括对项目管理过程组内的各种<font color=red>管理过程</font>和<font color=red>管理活动</font>进行识别、定义、组合、统一与协调的各种过程和活动。
|
||||
* 职责：必须由项目经理负责。其他知识领导可以指派专家，但是项目经理就是唯一必须承担项目整合管理的专家。
|
||||
* 过程：整合管理这个知识领域，在不同项目阶段需要做哪些工作，结合<font color=red>矩阵</font>来看比较清晰
|
||||
|
||||
1. 启动阶段：制定《项目章程》
|
||||
2. 规划阶段：制定《项目管理计划》
|
||||
3. 执行阶段：
|
||||
1. 参照《项目管理计划》指导项目管理工作
|
||||
2. 管理项目知识
|
||||
4. 监控过程：
|
||||
1. 监控项目工作
|
||||
2. 实施整体变更控制
|
||||
5. 收尾阶段：结束项目或阶段
|
||||
2. <font color=red face="黑体">制定项目章程</font>（5分）
|
||||
* 定义: 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
|
||||
* 作用
|
||||
1. 明确项目与组织战略目标之间的联系
|
||||
2. 在组织整体计划中的地位
|
||||
3. 确认组织对项目的承诺
|
||||
* 项目经理在章程中确认任命时机
|
||||
1. 越早越好
|
||||
2. 项目经理应参与制定项目章程，以便于项目经理对项目需求有基本的了解
|
||||
3. 最迟在进行规划阶段前任务
|
||||
* 项目的启动
|
||||
* 由项目以外的人来启动，PMO授权，发起人，CCB等
|
||||
* 项目经理属于项目内部成员，不能启动
|
||||
* 过程
|
||||
|
||||
1. 输入
|
||||
1. 商业文件
|
||||
2. 事业环境因素
|
||||
3. 组织过程资产
|
||||
2. <font color=red face="黑体">工具</font>
|
||||
1. 专家判断：
|
||||
* 指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。
|
||||
* 具有专业学历、知识、技能或培训经历的任何小组或个人、都可以提供专家判断、尤其是主题专家（SME）
|
||||
1. 数据收集
|
||||
1. [[工具：头脑风暴]]，只为发散想法，不做最终决定。向干系人、主题专家、和团队成员收集数据，解决方案和创意。
|
||||
2. <font color=red face="黑体">焦点小组</font>，明确主题，召集干系人和专家进行讨论
|
||||
3. <font color=red face="黑体">访谈</font>，一对一，也可多对多、用于获机密、敏感信息。
|
||||
2. 人际关系与团队技能
|
||||
1. 引导，意见不一致时，通过引导，让干系人达成一致。
|
||||
3. 输出：
|
||||
1. <font color=red face="黑体">项目章程</font>必须由启动者，或项目发起人发布。标志着
|
||||
1. **项目正式启动**
|
||||
2. **干系人达成总体共识**，相关干系人对项目的交付成果、里程碑、以及项目参与者的角色和职责达成共识
|
||||
3. **发起人对项目经理的授权**，可以调度组织资源开展项目活动
|
||||
4. **包工头接受委托**，项目经理接受章程，即接受了发起人的项目委托
|
||||
2. <font color=red face="黑体">假设日志</font>（陪选项）
|
||||
1. 记录整个项目生命周期中所有的<font color=red>假设条件</font>和<font color=red>制约因素</font>。
|
||||
2. 启动之前，识别战略级商业论证的假设和制约因素，分析产品的运营条件或制约因素。
|
||||
3. 其他假设条件或制约因素，在项目过程中陆续生成。
|
||||
* <font color=red face="黑体">项目章程构成要素</font>
|
||||
|
||||
1. 制定章程的输入：<font color=red face="黑体">商业文件</font>
|
||||
1. 包括<font color=red face="黑体">商业论证</font>和<font color=red face="黑体">收益管理计划</font>
|
||||
2. 商业论证或类似文件
|
||||
* 从商业视角描述必要的信息，并据此决定项目的预期结果是否值得所需要投资。
|
||||
* 高于项目级别的经理和高管们常以此文件做决策依据。
|
||||
* 包括<font color=red>商业需要分析</font>与<font color=red>成本效益分析</font>
|
||||
* 论证项目的合理性、确定项目边界
|
||||
* 通过商业论证，保证项目符合组织的战略需要
|
||||
* 项目经理不可以对商业文件进行更新或修改，只可以提出建议。因为商业文件属于组织的战略依据，而项目经理的权力在项目范围内，项目不能反过来影响组织战略方向。
|
||||
3. 当项目的商业论证直接作为项目的章程输入，则为事业环境因素；当过往商业论证文件作为新项目商业论证的参考，则为组织过程资产。
|
||||
2. 制定章程的输入：<font color=red face="黑体">事业环境因素</font>
|
||||
5. 政府或行业标准
|
||||
6. 法律法规要求和（或）制约因素
|
||||
7. 市场条件
|
||||
8. 组织文件和政治氛围
|
||||
9. 干系人的期望和风险临界值
|
||||
3. 制定章程的输入：<font color=red face="黑体">事业环境因素</font>
|
||||
1. 组织的标准政策、流程和程序
|
||||
2. 项目组合、项目集和项目的治理框架
|
||||
3. 监督和报告方法
|
||||
4. 模板（如项目章程模板）
|
||||
5. 历史信息与经验教训知识库（如以往项目选择决策的结果）
|
||||
|
||||
#### 4.2 项目管理计划[22:28]
|
||||
* <font color=red face="黑体">制定项目管理计划</font>
|
||||
* 定义：综合性计划，定义、准备、协调所有组成部分，合成项目管理计划。
|
||||
* 作用：这份管理计划，是所有项目（执行、监控、收尾）工作的基础，以及执行方式。
|
||||
* 基准化概念：范围、质量、成本
|
||||
* 基准确认之前与之后
|
||||
* 项目三大基准与绩效测量基准
|
||||
* 制定工作过程
|
||||
|
||||
* <font color=red face="黑体">构成</font>
|
||||
|
||||
* 批准：
|
||||
* <font color=red face="黑体">项目管理计划，由干系人批准</font>，即干系人同意在项目中遵守这个管理计划的约定。
|
||||
* 批准点，即是管理计划的基准点。
|
||||
* <font color=red face="黑体">开工会议</font>
|
||||
|
||||
* 指导与管理项目工作
|
||||
|
||||
* 为了实现目标，依计划执行
|
||||
* 工作绩效数据，原始观察数据
|
||||
* 问题日志，记录问题的文档。
|
||||
* <font color=red>变更请求</font>
|
||||
* 定义：关于修改任务文件、可交付成果或基准的正式提议。
|
||||
* 包括
|
||||
* 纠正措施，纠正绩效偏差
|
||||
* 预防措施，防范绩效偏差
|
||||
* 缺陷补求，修正缺陷产品或组件
|
||||
* 更新，外部因素导致变更
|
||||
#### 4.3 <font color=red face="黑体">管理项目知识</font>
|
||||
* 使用现有知识生成新的知识
|
||||
* 显性知识与隐性知识，将隐性知识显性化。
|
||||
#### 4.4 <font color=red face="黑体">监控项目工作</font>
|
||||
|
||||
* 跟踪、审查、报告整体项目进展，以实现项目管理计划中的绩效目标
|
||||
* 收集、测量原始绩效数据
|
||||
* 分析绩效数据，得到绩效信息
|
||||
* 整理、预测趋势，得到绩效报告
|
||||
* 数据分析 - 挣值分析是啥？
|
||||
* always plan b
|
||||
#### <font color=red>工作绩效</font>
|
||||
1. 工作绩效数据
|
||||
2. 工作绩效信息：由绩效数据分析后，得到工作绩效信息，为项目决策提供可靠的基础。
|
||||
3. 工作绩交报告：
|
||||
|
||||
#### <font color=red>实施整体变更控制(重点)</font>
|
||||
* 
|
||||
* 变更控制系统
|
||||
|
||||
* 变更控制委员会(CCB)
|
||||
* 变更批准的权限
|
||||
* 不涉及基准的变更，可以由项目经理批准
|
||||
* 涉及基础的变更，由CCB批准
|
||||
* 涉及章程的变更，由发起人批准
|
||||
* 涉及合同，与实施项目的变更，由客户批准
|
||||
* 实施变更过程
|
||||
|
||||
* 多标准决策分析，综合多种纬度决策
|
||||
* <font color=red>变更日志</font>，需要熟悉变更请求在何时记录变更日志。
|
||||
|
||||
|
||||
#### <font color=red>结束项目或阶段</font>
|
||||
|
||||
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: 第三课：四章回顾，五章
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: 范围，代表了需求的边界。先确定范围，再细化需求。
|
||||
number headings: first-level 3, max 6, 1.1.
|
||||
---
|
||||
|
||||
### 1. 核心概念
|
||||
* <font color="#ff0000">范围管理的目的：做且只做所需要的全部工作，以成功完成项目。</font>
|
||||
* 管理项目范围主要在于<font color="#ff0000">定义</font>和<font color="#ff0000">控制</font>哪些工作包括在项目内，哪些不应该包括在项目内。
|
||||
* 范围基准包含：范围说明书、WBS、WBS词典
|
||||
* 范围区分
|
||||
* 产品范围 -- 通过需求文件来定义产品范围，即项目交付物需要包含什么，不需要包含什么。
|
||||
* 项目范围 -- 通过项目管理计划来定义项目范围，即项目过程需要做什么，不需要做什么
|
||||
|
||||
### 2. 规划范围管理：
|
||||
* 参考十五矩阵
|
||||
|
||||
|
||||
* <font color=red>规划范围管理</font>：
|
||||
* 定义：创建范围管理计划，书面描述将如何定义、确认、和控制项目范围的过程。
|
||||
* 作用：在整个项目中对如何管理范围提供指南和方向。
|
||||
* 范围管理计划是一个程序文件：那么如何理解<font color=red>程序文件</font>、<font color="#ff0000">规则文件</font>
|
||||
* 可以将项目管理计划以及其所有子计划都理解为程序文件
|
||||
* 所有的程序文件都没有具体细节，因为他们定义的是如何管理，和控制对应的知识领域，而不是知识领域输出内容本身
|
||||
* 输出：
|
||||
* 范围管理计划：描述将如何定义、制定、监控、控制和确认项目范围。
|
||||
* 需求管理计划：描述如何分析、记录、管理项目和产品需求。
|
||||
|
||||
### 3. 收集需求
|
||||
* 定义：为实现项目目标而确定、记录并管理干系人的需要和需求的过程
|
||||
* 作用：为定义产品范围、和项目范围奠定基础。
|
||||
* 输出：
|
||||
* 需求文件
|
||||
* 需求跟踪矩阵
|
||||
* 工具：
|
||||
* 问卷调查：受众多多，需要更多的数据样本
|
||||
* 标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
|
||||
* 标杆对象：内部或外部项目、同领域项目、不同应用领域的项目。
|
||||
* 决策：
|
||||
* 投票：<font color="#ff0000">一致同意</font>、大多数同意、相对多数同意。
|
||||
* 独裁型决策
|
||||
* 多标准决策分析
|
||||
* 德尔菲技术：用来获得专家意见的常用方法，防止个人对结果产生不恰当的影响。
|
||||
* 专家背靠背
|
||||
* 专家以匿名形式提出意见
|
||||
* 多轮
|
||||
* 旨在取得一致意见
|
||||
* <font color="#ff0000">引导与主题研讨会</font>：<font color="#ff0000">用于达成一致意见</font>
|
||||
* 结合使用，召集主要干系人一起定义产品需求
|
||||
* 快速<font color="#ff0000">定义跨职能需求</font>和<font color="#ff0000">协调干系人的需求差异</font>，
|
||||
* <font color="#ff0000">有效引导</font>的研讨会有助于参与者建立信任、改进关系、改善沟通，从而<font color="#ff0000">有利于干系人达成一致意见</font>。
|
||||
* <font color="#ff0000">题目关键词：多部门，多职能，需求差异</font>
|
||||
* 应用
|
||||
* 敏捷项目中，从需求研讨会产生，称为<font color="#ff0000">用户故事</font>
|
||||
* 原型法
|
||||
* <font color="#ff0000">需求文件：描述各种单一的需求将如何满足与项目相关的业务需求</font>
|
||||
* <font color="#ff0000">需求跟踪矩阵（RTM）</font>
|
||||
|
||||
### <font color="#ff0000">定义范围</font>
|
||||
* <font color="#ff0000">过程定义：制定项目和产品详细描述的过程</font>
|
||||
* <font color="#ff0000">过程作用：明确所惧的需求哪些将包含在项目范围内，哪些将排除在项目范围之外，从而明确项目、服务或成果的边界。</font>
|
||||
* 输出：
|
||||
* 项目范围说明书：是对项目范围、主要可交付成果、假设条件和制约因素的描述。
|
||||
* 项目文件更新
|
||||
* 假设日志
|
||||
* 需求文件
|
||||
### <font color="#ff0000">创建WBS</font>
|
||||
* <font color="#ff0000">定义</font>：把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程
|
||||
* <font color="#ff0000">作用</font>：对所要交付的内容提供框架
|
||||
* <font color="#ff0000">工具</font>：
|
||||
* 专家判断
|
||||
* 分解
|
||||
* <font color="#ff0000">输出</font>：
|
||||
* <font color="#ff0000">范围基准</font>
|
||||
* <font color="#ff0000">范围基准：是经过批准的范围说明书，WBS、WBS词典</font>
|
||||
* <font color="#ff0000">只有通过正式的变更控制程序才能进行变更</font>
|
||||
* <font color="#ff0000">被用做绩效比较的基础</font>
|
||||
* 项目文件更新
|
||||
* 假设日志：在创建WBS过程中，识别出更多的假设条件与制约因素，因此更新假设日志。
|
||||
* 需求文件：在创建WBS过程中，提出并已被批准的变更。
|
||||
* WSB的创建原则
|
||||
* 80小时原则
|
||||
* 100%原则：
|
||||
* WBS包括项目范围所定义的全部产品和项目工作以及项目管理工作
|
||||
* 通过把WBS底层的所有工作逐层向上汇总，确保即没有遗漏的工作，也没有多余的工作
|
||||
* <font color="#ff0000">滚动式规划</font>，就是一种渐进明细的具体方法：
|
||||
* <font color="#ff0000">一种迭代式的规划技术</font>
|
||||
* <font color="#ff0000">规划包体现了滚动式规划与渐进明细的精神</font>
|
||||
* WBS词典：
|
||||
* 针对WBS中的每个组件，<font color="#ff0000">详细描述</font>可交付成果、活动和进度等信息的文件。
|
||||
|
||||
### 控制范围 5.6
|
||||
|
||||
|
||||
### 确认范围 5.5
|
||||
* 过程定义：正式<font color="#ff0000">验收</font>已完成的项目可交付成果的<font color="#ff0000">过程</font>
|
||||
* 过程作用：使验收过程具有客观性，同时通过确认每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
|
||||
* 输出：
|
||||
* 验收的可交付成果
|
||||
* 工作绩效信息
|
||||
* 变更请求
|
||||
* 项目文件更新
|
||||
* 经验教训登记册
|
||||
* 需求文件
|
||||
* 需求跟踪矩阵
|
||||
|
||||
### 第五章重点：
|
||||
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
title: 六章 项目进度管理
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: 项目进度管理的主要要作内容在规划阶段与监控阶段。
|
||||
number headings: first-level 3, max 4, 1.1.
|
||||
---
|
||||
|
||||
### 1. 课程概述：进度管理的
|
||||
#### 1.1. 矩阵图：
|
||||
|
||||
#### 1.2. 理解：
|
||||
* 进度，即是对一项工作过程中的全部关键节点的跟踪。
|
||||
* 在这一个领域范围里，需要一个<font color="#ff0000">总纲</font>，即通过一个规则文件（程序文件），做一个总的方针，即6.1。后面的章节，都是对进度进行管控的具体操作了。
|
||||
* 活动，就是定义工作的内容与步骤，其实每个人理论上都能做自己的规划，但总是有人规划不好，毕竟很多人的认知都是只做好本职，而不会放眼整个项目，更看不到公司战略。换句话说，这就是项目经理管理职能的意义。所以定义活动，然后根据活动之间的依赖关系，以及优先级，确定活动顺序。目的是让活动可以高效的流转起来。这里涉及到，资源的配合，是项目经理协调、分配资源的综合能力。
|
||||
* 进度计划，是完成活动顺序和时间估算之后的一种展现
|
||||
* 那么在完成对活动的规划与估算，就会依照计划，来指导执行了。这就会开始对活动的监控。是否完成、通过绩效数据来体现事实活动，与计划活动差异。
|
||||
### 2. 分阶段拆分过程
|
||||
#### 2.1. 规划阶段：
|
||||
##### 6.1: 进度管理计划
|
||||
* 定义: 为规划、编制、管理、执行、和控制项目进度而制定政策、程序、和文档的过程。
|
||||
* 作用：为如何在整个项目中管理项目进度提供指南和方向。
|
||||
|
||||
##### 6.2: 定义活动
|
||||
* 概念
|
||||
|
||||
* 过程
|
||||
|
||||
范围基准包括:范围说明说、WBS、WBS词典
|
||||
* 分解
|
||||
* <font color="#ff0000">把项目范围和可交付成果逐步划分为更小、更便于管理的组成部分的技术</font>
|
||||
* 活动表示完成工作包所需要的投入
|
||||
* WBS和WBS词典是制定最终活动清单的基础
|
||||
* WBS中的每个工作包都需要分解成活动，以便通过活动完成相应的可交付成果
|
||||
* 滚动式规划
|
||||
* <font color="#ff0000">详细规划近期要完成的工作、同时在较高层级上粗略规划远期工作</font>
|
||||
* 输出：
|
||||
* 活动清单：
|
||||
|
||||
* 活动属性
|
||||
* 活动类型（支持型、独立型、依附性）
|
||||
|
||||
* 里程碑清单
|
||||
* 其他输出
|
||||
* 变更清求
|
||||
* 更新项目管理计划
|
||||
* 进度基准
|
||||
* 成本基准
|
||||
##### 6.3: 排列活动顺序
|
||||
* 过程
|
||||
|
||||
* <font color="#ff0000">定义：识别和记录项目活动之间的关系的过程。</font>
|
||||
* <font color="#ff0000">作用：定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率。</font>
|
||||
* 紧前关系绘图法（进度网络图PDM）
|
||||
* 四种活动启止的逻辑关系
|
||||
|
||||
* 活动整合时的依赖关系
|
||||
|
||||
* 提前量与滞后量
|
||||
* 输出：
|
||||
* 排列活动顺序：项目进度网络图
|
||||
|
||||
##### 6.4: 估算活动持续时间
|
||||
* 定义：根据资源估算的结果，估算完成单项活动所需工作时段数的过程
|
||||
* 作用：确定完成每个活动所需花费的时间量，为制定进度计划过程提供主要输入。
|
||||
* 过程结构：
|
||||
|
||||
* 工具
|
||||
* 工具 - 类别估算
|
||||
|
||||
* 工具 - 参数估算
|
||||
|
||||
* 工具 - 三点估算
|
||||
|
||||
|
||||
|
||||
* 工具 - 自下而上估算
|
||||
|
||||
* 工具 - 储备分析
|
||||
|
||||
##### 6.5: 制定进度计划
|
||||
* 定义:
|
||||
|
||||
* 过程结构
|
||||
|
||||
* 工具
|
||||
* 工具 - 进度网络分析
|
||||
|
||||
* 工具 - 关键路径法
|
||||
|
||||
|
||||
|
||||
|
||||
* 浮动时间
|
||||
|
||||
|
||||
* 资源优化
|
||||
* 资源平衡：在关键路径上去调整活动资源
|
||||
* 资源平滑：在非关键路径上去调整活动资源
|
||||
* 数据分析
|
||||
|
||||
* 进度压缩
|
||||
|
||||
|
||||
* 输出
|
||||
* 进度计划
|
||||
|
||||
* 项目进度计划
|
||||
* 项目进度网络图
|
||||
* 资源直方图
|
||||
* 项目日历
|
||||
#### 2.2. 监控阶段
|
||||
##### 6.6: 控制进度
|
||||
|
||||
|
||||
|
||||
|
||||
### 3. 重点回顾
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: 七章 项目成本管理
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: 成本管理
|
||||
number headings: first-level 2, max 2, 1.1.
|
||||
---
|
||||
课前练习：项目经理是流程专家
|
||||
|
||||
# 项目成本管理
|
||||
## 1. <font color="#ff0000">概念</font>
|
||||
项目成本管理包含为<font color="#ff0000">使项目在批准的预算内完成</font>，而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程。
|
||||
|
||||
<font color="#ff0000">沉没成本、机会成本</font>
|
||||
|
||||
## 2. 矩阵图
|
||||
|
||||
## 3. 理解项目成本管理
|
||||
|
||||
# 分阶段拆分过程
|
||||
## 1. 规划过程组
|
||||
### 7.1 规划成本管理
|
||||
* 概念
|
||||
|
||||
* 过程
|
||||
|
||||
* 输出：
|
||||
|
||||
### 7.2. 估算成本
|
||||
* 定义
|
||||
|
||||
* 过程
|
||||
|
||||
* 工具
|
||||
* 自下而上的估算
|
||||
|
||||
* 三点估算
|
||||
|
||||
* 储备分析
|
||||
|
||||
* 输出
|
||||
|
||||
* 待定“应急储备应包含在成本基准中，用来应对已经接受的已识别风险”
|
||||
|
||||
### 7.3. 制定预算
|
||||
* 定义
|
||||
|
||||
* 过程
|
||||
|
||||
* 输入
|
||||
|
||||
* 工具
|
||||
* 成本汇总与储备分析
|
||||
|
||||
* 历史信息审核
|
||||
|
||||
* 输出
|
||||
* 成本基准
|
||||
|
||||
|
||||
|
||||
## 2. 监控过程组
|
||||
### 7.4. 控制成本
|
||||
* 定义
|
||||
|
||||
* 过程
|
||||
|
||||
* 工具
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 输出
|
||||
|
||||
## 重点回顾
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: 八章 项目质量管理
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract: 质量管理
|
||||
number headings: first-level 3, max 3, 1.1.
|
||||
---
|
||||
# 一、项目质量管理
|
||||
* 定义：包括把<font color="#ff0000">组织的质量政策</font>应用于规划、管理、控制项目和产品质量要求，以满足干系人的目标各个过程。
|
||||
* 可交付成果的质量标准
|
||||
* 项目管理过程的质量标准
|
||||
* 质量与等级：对于项目来说,质量未达到要求是个问题，但低等级不一定是个问题
|
||||
* 质量：是一系列内在特性满足要求的程度。
|
||||
* 等级：是对用途相同但技术特性不同的可交付成果的级别分类。
|
||||
|
||||
# 二、分阶段过程拆分
|
||||
|
||||
## 1. 规划过程组
|
||||
|
||||
### 8.1. <font color="#ff0000">规划质量管理</font>
|
||||
* 定义：<font color="#ff0000">识别项目及其可交付成果的质量要求和/或标准，并局面描述项目将如何证明符合质量要求和/或标准的过程。</font>
|
||||
* 作用：<font color="#ff0000">为整个项目中如何管理和核实质量提供指南和方向。</font>
|
||||
* 过程：
|
||||
|
||||
* <font color="#ff0000">质量成本</font>
|
||||
|
||||
* 输出
|
||||
* 质量管理计划
|
||||
|
||||
* 质量测量指标
|
||||
|
||||
|
||||
## 2. 执行过程组
|
||||
|
||||
### 8.2. 管理质量
|
||||
* 定义：<font color="#ff0000">把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程。</font>
|
||||
* 作用：<font color="#ff0000">提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因。</font>
|
||||
* 识别质量问题的工具：
|
||||
* 实验设计
|
||||
|
||||
* 过程：
|
||||
|
||||
* 工具
|
||||
* 数据分析
|
||||
|
||||
* 因果图
|
||||
|
||||
* 直方图
|
||||
|
||||
* 散点图
|
||||
|
||||
* 审计
|
||||
|
||||
* 问题解决
|
||||
|
||||
* 输出
|
||||
|
||||
## 3. 监控过程组
|
||||
### 8.3. 控制质量
|
||||
* 定义：<font color="#ff0000">为评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。</font>
|
||||
* 作用：<font color="#ff0000">核实项目可将会成果和工作已经达到主要干系人的质量要求，可供最终验收。</font>
|
||||
* 过程：
|
||||
|
||||
* 工具：
|
||||
* 帕累托图
|
||||
|
||||
* 控制图
|
||||
|
||||
* 七点原则与失控
|
||||
|
||||
* 石川质量七工具
|
||||
|
||||
* 输出
|
||||
|
||||
|
||||
|
||||
* 变更的第0步：2：20
|
||||
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: 九章 项目资源管理
|
||||
category: PMP备考
|
||||
subCategory: 课堂笔记
|
||||
abstract:
|
||||
---
|
||||
|
||||
|
||||
# 一：项目资源管理概述
|
||||
* 定义：包括识别、获取和管理所需资源以完成项目的各个过程，资源包括
|
||||
* 实物资源
|
||||
* 设备
|
||||
* 材料
|
||||
* 基础设施
|
||||
* 人力资源
|
||||
* 团队资源
|
||||
* 人员
|
||||
* 理解团队的问题，由全部成员参与规划与决策。
|
||||
* 过程：
|
||||
|
||||
|
||||
# 二：分阶段过程拆分说明
|
||||
## 规划过程组
|
||||
### 规划资源管理
|
||||
* 定义：<font color="#ff0000">定义如何估算、获取、管理和利用团队以及实物资源的过程</font>。
|
||||
* 作用：<font color="#ff0000">根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度</font>。
|
||||
* 过程：
|
||||
|
||||
* 工具
|
||||
* 数据表现
|
||||
|
||||
* 层级型
|
||||
|
||||
* <font color="#ff0000">责任分配矩阵</font>
|
||||
|
||||
* 输出
|
||||
* 资源管理计划
|
||||
|
||||
* 团队章程
|
||||
|
||||
### 估算活动资源
|
||||
* 定义：<font color="#ff0000">估算执行项目工作所需的团队资源、材料、设备和用品类型和数量的过程。</font>
|
||||
* 作用：<font color="#ff0000">明确完成活动所需的资源种类、数据和特性。</font>
|
||||
* 过程：
|
||||
|
||||
* 输入：项目文件-资源日历：识别了每种具体资源的可用工作日或工作班次的日历。
|
||||
* 输出-资源分解结构（RBS）
|
||||
* 类别包括：人力、设备、材料和用品
|
||||
* 类型包括：技能水平、证书要求、等级水平等
|
||||
## 执行过程组
|
||||
### 获取资源
|
||||
* 定义：获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程
|
||||
* 作用：概述和指导资源的选择、并将其分配给相应的活动。
|
||||
* 过程：
|
||||
|
||||
* 输入
|
||||
* 工具：
|
||||
* 人际关系与团队技术，谈判（Negotiation）
|
||||
* 预分派：<font color="#ff0000">预先确定项目的实物或团队资源，在完成资源管理计划之前，制定项目章程过程或其他过程中指定了某些团队成员的工作分配</font>。
|
||||
* 虚拟团队：<font color="#ff0000">具有共同目标、在完成角色任务的过程中很少或没有时间面对面面工作的一群人</font>。
|
||||
* 输出：资源日历，<font color="#ff0000">表明每种具体资源的可用工作日、班次、正常工作上下班时间、周末和公共假期的日历</font>。
|
||||
### 建设团队
|
||||
* 定义：<font color="#ff0000">提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程</font>。
|
||||
* 作用：<font color="#ff0000">改进团队协作，增强人际关系技能，激励团队成员，减少摩擦，提升整体项目绩效</font>。
|
||||
* 塔克曼团队发展五阶段理论
|
||||
1. 形成阶段
|
||||
2. 震荡阶段
|
||||
3. 规范阶段
|
||||
4. 成熟阶段
|
||||
5. 解散阶段
|
||||
|
||||
* 过程
|
||||
|
||||
* 激励理论：
|
||||
* 马斯洛需求层次理论
|
||||
|
||||
* 赫兹伯格双因素理论
|
||||
|
||||
* 麦格雷戈X/Y理论
|
||||
|
||||
* 大内的Z理论
|
||||
|
||||
* 弗洛姆期望理论
|
||||
|
||||
* 麦克利兰成就动机理论
|
||||
|
||||
* 集中办公
|
||||
|
||||
### 管理团队
|
||||
* 定义：<font color="#ff0000">跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程</font>。
|
||||
* 作用：<font color="#ff0000">影响团队行为，管理冲突以及解决问题</font>。
|
||||
* 过程
|
||||
|
||||
* 工具：冲突管理（2分）
|
||||
|
||||
|
||||
* <font color="#ff0000">工具-情商</font>
|
||||
|
||||
|
||||
|
||||
## 监控过程组
|
||||
### 控制资源
|
||||
* 定义：<font color="#ff0000">确保按计划为项目分配被我资源，以及根据资源使用计划监督资源实际使用情况，并采取必要纠正措施的过程</font>。
|
||||
* 作用：<font color="#ff0000">确保所分配的资源适时适地可用于项目</font>。
|
||||
* 过程：
|
||||
|
||||
# 三：第九章重点内容
|
||||
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
number headings: first-level 2, max 3, 1.1.
|
||||
---
|
||||
# 一、项目风险管理概述
|
||||
* 定义：<font color="#ff0000">项目风险是一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标产生积极或消极影响</font>。
|
||||
* 目标：<font color="#ff0000">在于提高项目中正面风险的概率和/或影响，降低项目中负面风险的概率和/或影响，从而提高项目成功的可能性</font>。以可控的方式去面对项目中的不确定性，去冒险。平衡风险与回报，实现创造价值。
|
||||
## 1. 风险
|
||||
* 风险来源：<font color="#ff0000">源于任何项目中都存在的不确定性</font>。
|
||||
* 风险的分类：
|
||||
* 经营风险（项目团队主要精力应关注经营风险）
|
||||
* 纯风险/可保风险（注意风险转移）
|
||||
* 已知风险
|
||||
* 未知风险
|
||||
* 风险成因识别：
|
||||
|
||||
* 风险要素
|
||||
* 起因
|
||||
* 事件
|
||||
* 概率
|
||||
* 影响
|
||||
|
||||
# 二、分阶段过程拆分说明
|
||||
|
||||
## 1. 规划过程组
|
||||
|
||||
### 1.1. 规划风险管理（11.1）
|
||||
* 定义：<font color="#ff0000">定义如何实施项目风险管理活动的过程</font>。
|
||||
* 作用：<font color="#ff0000">确保风险管理的水平、类型和可见度与风险及项目对组织和其他干系人的重要性相匹配</font>。
|
||||
* 过程：
|
||||
|
||||
* 工具：
|
||||
* [[工具-专家判断]]
|
||||
* [[工具-数据分析]]
|
||||
* [[工具-会议]]
|
||||
* 输出：
|
||||
* 风险管理计划
|
||||
|
||||
|
||||
* 效用函数VNM：冯 诺依曼 摩根斯坦发明的，用于风险分析的方法。
|
||||
|
||||
*
|
||||
|
||||
### 1.2. 识别风险（11.2）
|
||||
* 定义：<font color="#ff0000">识别单个项目风险以及整体风险的来源，并记录其特征的过程</font>。
|
||||
* 作用：<font color="#ff0000">记录现有的单个风险，以及整体项目风险的来源，同时汇集相关信息，以便项目团队能够恰当应对与识别的风险</font>。
|
||||
* <font color="#ff0000">识别风险过程，贯穿整个项目生命周期，所有项目干系人，团队成员都需要参与</font>。
|
||||
* 过程
|
||||
|
||||
|
||||
* [[工具-SWOT]]
|
||||
* 输出
|
||||
* <font color="#ff0000">风险登记册</font>
|
||||
|
||||
* 风险报告：关于整体项目风险的信息，以及关于已识别的单个项目风险的概述信息。可能包括：
|
||||
* 整体项目风险的来源
|
||||
* 关于已识别单个项目风险的概述信息
|
||||
|
||||
### 1.3. 实施定性风险分析（11.3）
|
||||
* 定义：<font color="#ff0000">评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程</font>。
|
||||
* 作用： 定性，定的是风险的发生<font color="#ff0000">概率</font>、影响<font color="#ff0000">大小</font>、风险的<font color="#ff0000">优先级</font>，<font color="#ff0000">以便让项目管理团队重点关注高优先级的风险</font>。
|
||||
* 本过程会为每个风险识别出责任人，以便由他们负责规划风险应对措施，并确保其实施。
|
||||
* 过程：
|
||||
|
||||
* [[工具-风险数据质量评估]]
|
||||
* [[工具-风险概率和影响评估]]
|
||||
* [[工具-风险紧迫性评估]]
|
||||
* [[工具-风险分类]]
|
||||
* [[工具-概率和影响矩阵]]
|
||||
* 输出
|
||||
|
||||
### 1.4. 实施定量风险分析（11.4）
|
||||
* 定义：<font color="#ff0000">就已识别的单个项目风险和不确定性的其他来源对项目整体目标的影响进行定量分析的过程</font>。
|
||||
* 作用：<font color="#ff0000">量化整体敞口风险，并提供额外的定量风险信息，以支持风险应对规划</font>。
|
||||
* 过程：
|
||||
|
||||
* [[访谈]]
|
||||
* [[工具-模拟]]
|
||||
* [[工具：敏感性分析]]
|
||||
* [[工具-决策树分析]]
|
||||
* [[工具-预期货币价值]]
|
||||
|
||||
### 1.5. 规划风险应对（11.5）
|
||||
* 定义：<font color="#ff0000">为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程</font>。
|
||||
* 作用：<font color="#ff0000">制定应对整体项目风险和单个项目风险的适当方法</font>。
|
||||
* 过程
|
||||
|
||||
* 威胁应对策略：
|
||||
* 五种应对策略：上报、规避、转移、减轻、接受。
|
||||
* 上报：<font color="#ff0000">如果项目团队或项目发起人认为某威胁不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该采用上报策略</font>。
|
||||
* 规避：<font color="#ff0000">指项目团队采取行动来消除威胁，或保护项目免受风险影响的风险应对策略</font>。适用于发生概率较高，且具有严重负面影响的高优先级威胁。
|
||||
* 转移：<font color="#ff0000">涉及到将应对威胁的责任转移给第三方，让第三方管理风险并承担威胁发生的影响的风险应对策略</font>。外包是一种典型的风险转移策略。其他如保险、担保书等等。
|
||||
* 减轻：<font color="#ff0000">指采取措施降低威胁发生概率和/或影响的风险应对策略</font>。
|
||||
* 接受：<font color="#ff0000">指项目团队承认风险的存在，但不采取任何措施的风险应对策略</font>。
|
||||
|
||||
* 机会应对策略
|
||||
* 五种应对策略：<font color="#ff0000">上报、开拓、分享、提高、接受</font>。
|
||||
* 开拓：<font color="#ff0000">与规避相对应，旨在消除与某个特定机会相关的不确定性。增加某个机会的确定性，降低其不确定性</font>。
|
||||
* 分享：<font color="#ff0000">与转移相对应，指把应对smwff的责任转移给第三方，使其享有机会所带来的部分收益</font>。
|
||||
* 提高：<font color="#ff0000">与减轻相对，提高积极机会的发生概率和/或影响</font>。
|
||||
* 接受：<font color="#ff0000">承认机会的存在，但不主动采取措施去追求</font>。
|
||||
|
||||
* 应急应对策略
|
||||
* 担针对特定条件（有充分预警信号）发生时采用的专门计划过的应对措施。
|
||||
* 又称为应急计划。
|
||||
|
||||
## 2. 执行过程组
|
||||
|
||||
### 2.1. 实施风险应对（11.6）
|
||||
* 定义：执行商定的风险应对计划的过程。
|
||||
* 作用：确保按计划执行商定的风险应对措施，来管理整体项目风险敞口，最小化单个项目威胁以及最大化单个项目机会。
|
||||
* 项目风险管理的常见问题是，项目团队努力识别和分析风险并制定应对措施，然后把经商定的应对措施记录在风险登记册和风险报告中，但是不采取实际行动去管理风险。
|
||||
* 过程：
|
||||
|
||||
|
||||
## 3. 监控过程组
|
||||
|
||||
### 3.1. 监督风险（11.7）
|
||||
* 定义：<font color="#ff0000">在整个项目期间，监督商定的风险应对计划的实施，跟踪已识别风险，识别和分析新风险，以及评估风险管理过程有效性的过程</font>。
|
||||
* 作用：<font color="#ff0000">使项目决策都基于关于整体项目风险敞口和单个项目风险的当前信息</font>。
|
||||
* 过程：
|
||||
|
||||
* [[工具-储备分析]]
|
||||
* 变更请求
|
||||
|
||||
|
||||
# 三、十一章重点内容
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
tags: Task
|
||||
Status: Archived
|
||||
ref-link:
|
||||
---
|
||||
|
||||
[回放链接](https://www.qhclass.com/course/2499/activity/102684/replay/4118/custom_entry)
|
||||
## 项目采购管理概述
|
||||
### 背景
|
||||
1. 项目的各个环节都可以发起对外采购。
|
||||
2. 可以通过采购实现项目风险转移。
|
||||
### 核心概念
|
||||
<font color="#ff0000">项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程</font>。
|
||||
|
||||
|
||||
## 过程拆分
|
||||
|
||||
|
||||
### 规划采购管理
|
||||
* 定义：<font color="#ff0000">记录项目采购决策、明确采购方法、识别潜在卖方的过程</font>。
|
||||
* 作用：<font color="#ff0000">确定是否需要从外部获取货物和服务，如果是，则还需要确定何时、何种方式获取何种货物和服务</font>。
|
||||
* 采购一般步骤（参考）
|
||||
|
||||
* 过程
|
||||
|
||||
* 输入
|
||||
|
||||
* 合同
|
||||
|
||||
* <font color="#ff0000">总价合同</font>：
|
||||
* <font color="#ff0000">为既定产品或服务的采购设定一个总价</font>。
|
||||
* 适用场景：<font color="#ff0000">买方已明确定义需求，且不会出现重大范围变更</font>。
|
||||
* 子类型
|
||||
* <font color="#ff0000">固定总价合同</font>：
|
||||
* 买方应该准确定义要采购的产品和服务。
|
||||
* 总价加激励费用合同
|
||||
* <font color="#ff0000">总价加经济价格调整合同</font>
|
||||
|
||||
* 成本补偿合同
|
||||
|
||||
* 子类型
|
||||
* 成本加固定费用合同
|
||||
|
||||
* 成本加激励费用合同
|
||||
|
||||
* 工料合同
|
||||
|
||||
* 采购管理计划
|
||||
|
||||
* 招标文件
|
||||
|
||||
* 采购工作说明书
|
||||
* 定义：<font color="#ff0000">充分详细描述拟采购的产品、服务或成果，以便潜在的卖方确定他们是否有能力提供这些产品、服务或成果。</font>
|
||||
|
||||
### 实施采购
|
||||
* 定义：<font color="#ff0000">获取卖方应答、选择卖方并授予合同的过程</font>。
|
||||
* 作用：<font color="#ff0000">选定合格卖方并签署关于货物或服务交付的法律协议</font>。
|
||||
* 过程：
|
||||
|
||||
* [[工具-投标人会议]] 一分题
|
||||
* <font color="#ff0000">开会时机：投标书或建议书提交之前，在买方和所有潜在卖方之间召开的会议</font>。
|
||||
* <font color="#ff0000">会议目的：保证所有潜在卖方对采购要求都有清楚且一致的理解，保证没有任何投标人会得到特别优待</font>。
|
||||
* <font color="#ff0000">公平：买方要尽力保证每个潜在卖方都能听到其他卖方提出的问题，以及买方所做出的回答</font>。
|
||||
* <font color="#ff0000">问题与回答内容，以修正案的形式纳入采购文件</font>。
|
||||
|
||||
### 控制采购
|
||||
* 定义：<font color="#ff0000">管理采购关系、监督合同绩效，实施必要的变更和纠编，以及关闭合同的过程</font>。
|
||||
* 作用：<font color="#ff0000">确保买卖双方履行法律协议，满足项目要求</font>。
|
||||
* 过程：
|
||||
|
||||
* 输入-事业环境因素-[[合同变更控制系统]]
|
||||
* 工具-索赔管理
|
||||
* 索赔时机：买卖双方就变更及变更的补偿产生分歧时。
|
||||
* <font color="#ff0000">谈判是解决所胡索赔和争议的首选方法</font>。
|
||||
* [[工具-检查]] & [[工具-审计]]
|
||||
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
tags: Task
|
||||
Status: Archived
|
||||
ref-link:
|
||||
---
|
||||
[回放地址](https://www.qhclass.com/course/2499/activity/102685/replay/4126/custom_entry)
|
||||
|
||||
# 第十章，项目沟通管理
|
||||
## 概述
|
||||
* 定义：<font color="#ff0000">项目沟通管理包括为通过开发沟通工件，以及执行用于有效交换信息的各种活动，来确保项目及其干系人的信息需求得以满足的各个过程</font>。
|
||||
* 沟通类型对比：
|
||||
|
||||
|
||||
## 过程拆分
|
||||
|
||||
### 1 规划沟通管理
|
||||
* 定义：<font color="#ff0000">基于干系人或干系人群体的信息需求，可用的组织资产，以及具体的项目需求，为沟通活动制定恰当的方法和计划的过程</font>。
|
||||
* 作用：<font color="#ff0000">为及时向干系人提供相应信息，引导干系人有效参与项目，而编制局面的沟通计划</font>。
|
||||
* 过程：
|
||||
|
||||
* <font color="#ff0000">沟通需求分析</font>： <font color="#ff0000">确定项目该系人的信息需求，包括所需信息的类型和格式，以及信息对关系人的价值</font>。
|
||||
* 沟通渠道：反映了项目沟通的复杂程度。 渠道数=N*(N-1)/2
|
||||
* 沟通技术：即干系人之间传递信息的媒介，以及采用对应媒介的依据。
|
||||
* 沟通模型：
|
||||
|
||||
* <font color="#ff0000">沟通方法</font>
|
||||
* 互动沟通，沟通有来有回
|
||||
* 推式沟通，定向发送，通知，确保发送，不确保理解。
|
||||
* 拉式沟通，接收者自主访问内容
|
||||
* 人际关系与团队技能
|
||||
* <font color="#ff0000">沟通风格评估，评估沟通风格并识别偏好的沟通方法、格式和内容</font>。
|
||||
* 输出-沟通管理计划
|
||||
|
||||
|
||||
|
||||
|
||||
### 2 管理沟通
|
||||
* 定义：<font color="#ff0000">确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程</font>。
|
||||
* 作用：<font color="#ff0000">促进项目团队和干系人之间实现有效率且有效果的信息流动</font>。
|
||||
* 过程：
|
||||
|
||||
### 监督沟通
|
||||
* 定义：<font color="#ff0000">确保满足项目及其干系人的信息需求的过程</font>。
|
||||
* 作用：<font color="#ff0000">按沟通管理计划和干系人参与计划的要求优化信息传递流程</font>。
|
||||
* 过程：
|
||||
|
||||
## 第十章重点
|
||||
|
||||
|
||||
|
||||
# 第十三章 干系人管理
|
||||
|
||||
## 概述
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 过程拆分
|
||||
|
||||
### 识别干系人
|
||||
* 定义：<font color="#ff0000">定期识别项目关系人分析和记录他们的利益参与度相互依赖性影响力和对项目成功的潜在影响的过程</font>。
|
||||
* 作用：<font color="#ff0000">使项目团队能够建立对每个干系人或干系人群体的适度关注</font>。
|
||||
* 过程：
|
||||
|
||||
* [[工具-干系人分析]]
|
||||
* [[干系人映射分析-表现]]：从多个维度分析干系人
|
||||
* [[输出-干系人登记册]]
|
||||
|
||||
### 规划干系人参与
|
||||
* 定义： <font color="#ff0000">根据干系人的需要，期望利益核对项目的潜在影响，制定关系人参与项目方法的过程</font>。
|
||||
* 作用： <font color="#ff0000">提供与项目关系人进行有效的可行性计划</font>。
|
||||
* 过程：
|
||||
|
||||
* [[输入-章程]]
|
||||
* [[工具-评估干系人参与度]]
|
||||
* 输出-[[干系人参与计划]]
|
||||
|
||||
### 管理干系人参与
|
||||
* 定义：<font color="#ff0000">与干系人进行沟通和协作，已满足其需要与期望，处理问题，并促进干人合理参与的过程</font>。
|
||||
* 作用：<font color="#ff0000">让项目经理能够提高干系人的支持，并尽可能降低干系人的抵制</font>。
|
||||
* <font color="#ff0000">主动管理干系人参与</font>，可以降低项目，不能实现其目的和目标标的风险。
|
||||
* 干系人管理的核心工作内容：
|
||||
|
||||
* 过程：
|
||||
|
||||
* 工具-[[基本规则]]
|
||||
|
||||
### 监督干系人参与
|
||||
* 定义：<font color="#ff0000">监督项目干系人之间的关系，并通过修订参与策略及计划来裁剪干系人参与策略的过程</font>。
|
||||
* 作用：<font color="#ff0000">随着项目进展和环境变化维持或提升干系人参与活动的效率和效果</font>。
|
||||
* 过程：
|
||||
* 
|
||||
* 工具-[[干系人参与度评估矩阵]]
|
||||
## 十三章重点
|
||||
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
tags: Task
|
||||
Status: Archived
|
||||
ref-link:
|
||||
---
|
||||
[回放链接](https://www.qhclass.com/course/2499/activity/102688/replay/4155/custom_entry)
|
||||
|
||||
书签：1:46
|
||||
# 理解敏捷：
|
||||
- 对比<font color="#ff0000">瀑布</font>模式
|
||||
通过目标的确定性来区别判断，对于确定性强的项目，可以制定详细的规划，即瀑布式；而不确定的目标，通过敏捷的方式。
|
||||
- 对比<font color="#ff0000">增量</font>模式
|
||||
每个周期，增加一个功能，交付一个功能。每个周期都可以理解为一个瀑布式。
|
||||
- 对比<font color="#ff0000">迭代</font>模式
|
||||
周期与周期之间，是逐渐优化、细化的循环。最终一次交付。
|
||||
* 混合型
|
||||
根据项目的实际情况，混合使用敏捷与预测。
|
||||
|
||||
## <font color="#ff0000">敏捷宣言</font>
|
||||
* <font color="#ff0000">个体和互动</font> 高于 流程和工具
|
||||
* <font color="#ff0000">可工作的软件</font> 高于 详尽的文档
|
||||
* <font color="#ff0000">客户合作</font> 高于 合同谈判
|
||||
* <font color="#ff0000">响应变化</font> 高于 遵循计划
|
||||
|
||||
## <font color="#ff0000">敏捷12原则</font>
|
||||
1. 我们最优先考虑的是通过<font color="#f79646">尽早</font>和<font color="#f79646">持续不断</font>地<font color="#f79646">交付</font>有<font color="#f79646">价值</font>的<font color="#f79646">软件</font>使<font color="#f79646">客户满意</font>。（宣传4价值）
|
||||
2. 即使在开发后期也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。（欢迎变更）
|
||||
3. 采用<font color="#f79646">较短的</font>项目周期（从几周到几个月），经常地将会可工作的软件。（1～4周迭代）
|
||||
4. 业务人员和开发人员必须在整个项目期间每天一起工作。（全职/专注）
|
||||
5. 围绕富有进取心的<font color="#f79646">个体</font>而创建项目。提供他们所需的环境和支持，<font color="#f79646">信任</font>他们所开展的工作。（以人为本，团队为核心）
|
||||
6. 不论团队内外，传递信息效果最好且效率最高的方式是<font color="#f79646">面对面交谈</font>。（面对面可视化）
|
||||
7. 可工作的软件是度量进度的首要指标。（0～100）
|
||||
8. 敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持<font color="#f79646">稳定的开发步伐</font>。（可持续/不加班）
|
||||
9. 坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。（改进/重构）
|
||||
10. 以<font color="#f79646">简洁为本</font>，它是极力减少未完成工作量的艺术。（简洁/二八）
|
||||
11. 最好的架构、需求和设计出自于自组织团队。（自组织团队）
|
||||
12. 团队<font color="#f79646">定期地反思</font>如何能提高成效，并相应地协调和调整自身的行为。（回顾/检视）
|
||||
|
||||
## <font color="#ff0000">白金三原则</font>
|
||||
|
||||
|
||||
# 精益七原则
|
||||
* 精益的重点：最大化商业价值、最小化产品开发以外的活动
|
||||
* 消除浪费
|
||||
* 价值流图：帮助管理者来识别工作的增值活动和非增值活动，以消除效率低下。
|
||||
* 八种浪费：
|
||||
* 缺陷与返工
|
||||
* 过量生产/软件多余功能
|
||||
* 等待
|
||||
* 未组织好的人才及沟通
|
||||
* 搬运/多任务切换
|
||||
* 库存/在制品WIP
|
||||
* 移动/任务交接
|
||||
* 额外过程/过多文档及审批
|
||||
* 延迟决策
|
||||
* 尽快交付
|
||||
* 尊重成员
|
||||
* 赋能/授权团队和个人
|
||||
* 用任务领取，取代任务分配。
|
||||
* 优化整体
|
||||
系统性改进优化环境和机制。
|
||||
|
||||
## 敏捷基础方法
|
||||
* 点击查看关于[[SCRUM]]的详细介绍
|
||||
* 看板
|
||||
* XP
|
||||
|
||||
敏捷做题指导思想
|
||||
1. 敏捷采用倒三角思考法，首先考虑时间和成本，次要考虑范围。
|
||||
@@ -0,0 +1,149 @@
|
||||
### 集中办公
|
||||
1. 敏捷团队成员集中办公，便于沟通，目标是提升效率。
|
||||
2. 有私人区域和公共区域
|
||||
3. 避免信息孤岛
|
||||
|
||||
### 信息发射源
|
||||
1. 大白墙
|
||||
2. 看板/任务板，显示当前工作情况及整体进展概要
|
||||
3. 信息雷达
|
||||
|
||||
### 虚拟团队
|
||||
1. 分布式，分散式团队
|
||||
2. 线上沟通
|
||||
|
||||
|
||||
|
||||
## 敏捷产品规划
|
||||
|
||||
### 愿景声明/陈述/说明书
|
||||
对项目的简要、高层级描述，介绍了项目的目的，并激励团队为项目做出贡献。
|
||||
由发起人、PM、PO和团队共同制定。
|
||||
|
||||
### 项目章程
|
||||
不论是传统项目或是敏捷项目，章程都是明确项目原因。
|
||||
|
||||
*敏捷与传统的主要区别是，因为欢迎变更，所以在变更评审阶段会走简化流程*
|
||||
|
||||
### 团队章程（8遍）
|
||||
|
||||
|
||||
|
||||
### 项目路线图的7个步骤
|
||||
|
||||
|
||||
|
||||
### 敏捷规划
|
||||
|
||||
|
||||
|
||||
### 用户故事
|
||||
即用户使用场景的描述。即作为（用户角色）想要一个什么样的功能，以便实现某个价值。
|
||||
|
||||
### 需求层级
|
||||
1. 主题（Theme）
|
||||
1. 史诗（Epic）
|
||||
1. 特性（Feature）
|
||||
1. 用户故事（User Story）
|
||||
1. 任务（Task）
|
||||
|
||||
### 细化/梳理
|
||||
1. 滚动式规划：近期工作详细规划、无期工作粗略规划。
|
||||
1. 待办事项列表PBL
|
||||
2. 待办事项PBI，通过用户故事来描述
|
||||
|
||||
### 优先级排序工具
|
||||
1. 莫斯科法则
|
||||
2. 优先矩阵（价值与另一维度的二维矩阵）
|
||||
3. 四要素加权
|
||||
4. 根据风险调整待办事项的优先级
|
||||
|
||||
估算工具：
|
||||
1. [[德尔菲]]
|
||||
2. [[宽带德尔菲]]
|
||||
|
||||
### 准备就绪定义：
|
||||
一个大家认为已经充分理解并能开始工作的状态。
|
||||
|
||||
### 完成定义：
|
||||
商业干系人接收之前/发布之前，由PO和团队一至同意完成的标准。
|
||||
|
||||
### 速度/速度
|
||||
完成故事点的速度
|
||||
|
||||
### MVP/MMF
|
||||
MVP：<font color="#ff0000">最小可行产品。用最快的方式，最少的精力进行开发，获得对产品的反馈</font>。区别与探针是探针为了验证试探风险，而最小可靠产品是为了验证价值。
|
||||
MMF：最少可售特性。已经确认过有价值的产品特性，可以开发出来进行销售。
|
||||
|
||||
### 故事地图
|
||||
|
||||
|
||||
### 冲刺规划会议
|
||||
1. 冲刺目标：确定冲刺的待办事项列表
|
||||
2. 为什么做这一次冲刺
|
||||
3. 这一次冲刺需要做什么
|
||||
4. 开发团队将PBI分析为SBI（任务），指导如何去做这个冲刺
|
||||
5. 会议流程
|
||||
1. 两段式会议（上）
|
||||
1. PO提出冲刺目标，并与团队一起讨论、商定
|
||||
2. 从PBL中选出本次迭代的用户故事PBI
|
||||
3. 拆解PBI/补充PBI
|
||||
4. 冲刺承诺
|
||||
2. 两段式会议（下）
|
||||
1. 开发团队创建与每个用户故事相关联的任务
|
||||
2. 开发团队执行设计过程
|
||||
3. 确定任务都是围绕DoD定义的。
|
||||
4. 检查确认团队能够在冲刺的可用时间内完成任务
|
||||
5. 团队成员选择他的首要任务
|
||||
|
||||
### 生产能力
|
||||
|
||||
|
||||
|
||||
### 看板/任务板
|
||||
|
||||
|
||||
### 燃尽图
|
||||
|
||||
|
||||
### 风险燃尽图
|
||||
|
||||
|
||||
### 每日站会（1～3分）
|
||||
|
||||
|
||||
|
||||
### 其他可能考的工具
|
||||
1. <font color="#ff0000">结对工作/结对编程</font>：结对中的一个人进行代码编写，另一个人针对新增代码进行不断审阅、反馈。
|
||||
2. <font color="#ff0000">蜂拥技术</font>：对要完成的工作进行专业批量的处理，将造成“小瀑布”现象，从单个SBI的角度去看，整个过程中等待随处可见。“蜂拥而上”的模式从提高产品生产速度的角度出发，从个人转向团队，可以将团队效率最大化。
|
||||
3. <font color="#ff0000">探针/刺探</font>：小型独立试验，用以评估风险、设计选项及时间估算的一些任务，甚至可作为单独的迭代。
|
||||
4. <font color="#ff0000">良好实践：消除技术债</font>：为了在预期的时间内发布或演示，而采用快捷的方法，但对以后会带来隐患。所以，需要及时的为这些快捷的偷懒方法买单，不然就会形成债务。
|
||||
5. 良好实践：重构：及时重构，可以让项目的结构保持先进。
|
||||
6. 良好实践：持续集成：保持更新。
|
||||
7. 良好实践：测试驱动开发
|
||||
|
||||
## 冲刺评审会/演示会
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 冲刺回顾会
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 其他敏捷方法
|
||||
### 看板
|
||||
|
||||
|
||||
### 极限编程
|
||||
|
||||
|
||||
|
||||
|
||||
### 多敏捷团队协调
|
||||
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
cssClasses: cards
|
||||
category: PMP备考
|
||||
title: PMP备考汇总
|
||||
---
|
||||
|
||||
你的报考相关信息如下（请核对，有问题联系班班）：
|
||||
基金会账号：kyugao
|
||||
基金会密码：Pureblood001
|
||||
PMI账号：solonot@163.com
|
||||
PMI密码：GY18620897889
|
||||
PMI ID:7989903
|
||||
有效期：2024.4.1—2025.4.1
|
||||
考点：广州
|
||||
|
||||
### PMP课程笔记
|
||||
|
||||
```dataview
|
||||
table title as 主题, truncate(abstract, 30) as 概述, dateformat(file.cday, "yyyy-MM-dd") as 日期
|
||||
FROM "prepmp/notes"
|
||||
sort file.name desc
|
||||
```
|
||||
|
||||
### 每日三题
|
||||
|
||||
```dataview
|
||||
table without id externalLink as 查看, dateformat(file.cday, "yyyy-MM-dd") as 日期
|
||||
FROM "prepmp/daily_quest"
|
||||
sort file.cday desc
|
||||
limit 5
|
||||
```
|
||||
|
||||
### 每日打卡
|
||||
|
||||
````dataview
|
||||
table without id externalLink as 查看, truncate(abstract, 30) as 概述, dateformat(file.cday, "yyyy-MM-dd") as 日期
|
||||
FROM "prepmp/daily_on"
|
||||
sort file.name desc
|
||||
limit 7
|
||||
````
|
||||
@@ -0,0 +1,10 @@
|
||||
### 问题-1
|
||||
1. 项目管理计划规定选择预测型开发方法来交付项目可交付成果。在项目生命周期的哪个阶段，整体项目风险是最低的?
|
||||
A. 启动阶段
|
||||
B. 规划阶段
|
||||
C. 执行阶段
|
||||
D. 收尾阶段
|
||||
|
||||
### 考点参考：
|
||||
> [!QUOTE]- 1
|
||||
> ![[项目周期特性]]
|
||||
@@ -0,0 +1,12 @@
|
||||
### 问题
|
||||
预算短缺让一个正在进行的项目搁置时，在能够获得额外资金前，项目团队应该怎么做？
|
||||
|
||||
1. 要求重新分配到一个处于活动状态的项目
|
||||
2. 创建商业论证，获得额外资金
|
||||
3. 评估项目的当前状态，收集经验教训，并向项目干系人交付项目收尾文件
|
||||
4. 更新风险管理计划，提交风险减轻计划，并收集经验教训
|
||||
|
||||
### 考点参考
|
||||
根据职责
|
||||
1. 排除不在团队成员职责范围内的选项。
|
||||
1. 排除不属于当前过程组的选项。
|
||||
@@ -0,0 +1,10 @@
|
||||
### 问题
|
||||
项目经理一丝不苟地执行项目管理计划，但却难以有效地领导项目团队。项目团队成员之间以及与项目经理之间存在着大量的不健康的紧张关系。项目经理在会议中多次情绪爆发，导致会议突然中断。项目经理首先应该做什么？
|
||||
|
||||
1. 提交修改项目管理计划的变更申请，以取消回顾会议
|
||||
2. 积极主动地提高自己的情商（EI），成为更有效的领导者
|
||||
3. 通过需求分析，并与整个团队重新确定范围
|
||||
4. 带领项目团队成员进行一次培训，帮助他们成为有情怀的人
|
||||
|
||||
### 考点参考
|
||||
考项目经理的沟通，领导力，情绪控制。
|
||||
@@ -0,0 +1,17 @@
|
||||
### 问题
|
||||
你正在对完成一个大型跨国项目的项目工作所需的货币资源进行估算，该项目至少需要7年才能完成。你以前的项目都是国内项目，工期较短。作为你目前正在执行的过程的一部分，与你过去的项目相比，你可能需要做哪些不同的事情？
|
||||
|
||||
1. 创建干系人参与评估矩阵
|
||||
2. 制定更健全的风险管理计划
|
||||
3. 考虑其他事业环境因素
|
||||
4. 参考其他组织过程资产
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]+
|
||||
> ![[事业环境因素与组织过程资产#事业环境因素]]
|
||||
|
||||
* 理解：与过去项目不同事情，那么就工找到过去项目和现在项目的不同。
|
||||
* 而这些不同点，影响了要做的工作的差异
|
||||
* A&B都要做
|
||||
* C这个项目不同于过去的国内且工期较短的项目，需要找到更多的外界可能对项目影响的因素。
|
||||
* D过去的项目也同样会参考组织过程资产
|
||||
@@ -0,0 +1,13 @@
|
||||
### 问题
|
||||
项目经理管理桥梁建设项目。项目经理收到了监管干系人的重大变更请求，要求在工程设计中增加一个桥梁分支。项目经理准备了一份变更请求，并由变更控制委员会（CCB）审查和接受。项目经理现在应该做什么？
|
||||
|
||||
1. 将变更请求的批准通知项目团队
|
||||
2. 在设计中包括桥梁的新分支
|
||||
3. 将决定传达给要求变更的干系人
|
||||
4. 评估对项目管理计划的调整
|
||||
|
||||
### 考点参考
|
||||
|
||||
> [!QUOTE]+ 变更过程
|
||||
> 流程正义：在CCB批准变更之后，需要同时进行更新项目管理计划
|
||||
> ![[0321#<font color=red>实施整体变更控制(重点)</font>]]
|
||||
@@ -0,0 +1,12 @@
|
||||
### 问题
|
||||
一名关键干系人担心下一个工作包的交付以及与下个阶段相关的成本。项目经理可以从哪里找到这个信息？
|
||||
|
||||
A.问题日志报告
|
||||
B.采购工作说明书（SOW）
|
||||
C.工作绩效报告
|
||||
D. 控制图
|
||||
|
||||
### 考点参考
|
||||
|
||||
综合类型的问题，需要结合实际情况找到最适合的选项。
|
||||
可以在[[工作绩效报告]]找到项目进度，匹配是否能完成
|
||||
@@ -0,0 +1,12 @@
|
||||
### 问题
|
||||
项目经理完成项目章程的制定，并与关键干系人一起审查项目章程。项目经理下一步应该怎么做？
|
||||
|
||||
1. 制定项目管理计划\
|
||||
2. 与项目团队一起召开项目启动大会
|
||||
3. 获得项目发起人对项目章程的批准
|
||||
4. 获得干系人对项目章程的批准
|
||||
|
||||
### 考点参考
|
||||
|
||||
> [!QUOTE]+
|
||||
> ![[过程-制定项目的章程#过程的核心人员]]
|
||||
@@ -0,0 +1,11 @@
|
||||
### 问题-2
|
||||
公司正在考虑两个项目，Alpha和Beta。项目Alpha预计获得5000万美元的净利润，项目Beta则预计获得4500万美元的净利润。两个项目都可能非常有利可图、利润丰厚。但是，财务总监表示公司只能投资其中一个项目。如果选择项目Alpha，那么机会成本是多少？
|
||||
|
||||
1. 9500万美元
|
||||
2. 5000万美元
|
||||
3. 4500万美元
|
||||
4. 500万美元
|
||||
|
||||
### 考点参考：
|
||||
> [!QUOTE]- 1
|
||||
> ![[成本的分类]]
|
||||
@@ -0,0 +1,14 @@
|
||||
### 问题
|
||||
|
||||
* 一个多阶段项目已达到一个阶段关口。关键的项目干系人想要确定这个阶段是否满足了它的成功标准，以及项目是否应该进入下一个阶段。除了项目管理计划，还需要哪些文件？
|
||||
A. 风险登记册和风险报告
|
||||
B. 经验教训登记册和经验教训知识库
|
||||
C. 商业文件和项目章程
|
||||
D. 协议（包括采购合同）
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]- 1
|
||||
> ![[过程4-7：结束项目或阶段]]
|
||||
|
||||
> [!QUOTE]- 2
|
||||
> ![[过程-制定项目的章程#过程的输入]]
|
||||
@@ -0,0 +1,10 @@
|
||||
### 问题
|
||||
* 在项目执行过程中，团队发现项目为新产品开发的遥控器上的一些按钮不符合规格。提交并批准变更请求以替换按钮。下面哪个选项最好地描述了这个变更请求？
|
||||
A. 纠正措施
|
||||
B. 预防措施
|
||||
C. 缺陷补救
|
||||
D.镀金
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]-
|
||||
> ![[变更请求]]
|
||||
@@ -0,0 +1,13 @@
|
||||
### 问题
|
||||
* 你即将开始为一个大型而复杂的项目进行规划。由于项目的规模以及法规和环境方面的考虑，制定详细的项目管理计划至关重要。作为初始项目规划的起点，你应该做的第一件事情是什么？
|
||||
1. 召开项目开工会议，通知和争取干系人参与并获得他们的承诺
|
||||
2. 查看项目章程以了解项目的高层次信息
|
||||
3. 开始识别干系人过程，以便他们能够参与到项目规划中
|
||||
4. 与团队成员分享项目范围说明书，以形成对项目可交付成果的共识
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]+ 1
|
||||
> ![[十五矩阵#49个过程]]
|
||||
|
||||
> [!QUOTE]+ 2
|
||||
> ![[过程-制定项目管理计划]]
|
||||
@@ -0,0 +1,11 @@
|
||||
### 问题
|
||||
公司里面有A、B、C三个项目。这些项目根据公司的目标，按照一套相同的标准划分优先顺序。项目B的优先级较高，因为它将会扩大公司的市场份额，减少对不可靠供应商的依赖性。这是在执行什么活动？
|
||||
|
||||
1. 项目组合管理
|
||||
2. 项目集管理
|
||||
3. 项目管理
|
||||
4. 份额管理
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]+ 项目的竞争关系
|
||||
> ![[项目的超集#项目组合]]
|
||||
@@ -0,0 +1,10 @@
|
||||
### 问题
|
||||
你被要求领导一个将使用敏捷框架的产品开发项目。目前，你正处于起草项目章程的过程中，你希望将干系人和主题专家聚集在一起，讨论识别到的项目风险、成功标准和其他议题。实现这个目标的最好方法是什么？
|
||||
|
||||
1. 召开迭代回顾会议
|
||||
2. 邀请相关参与者参加每日例会
|
||||
3. 与已识别的个体进行访谈
|
||||
4. 安排一个焦点小组活动
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]- [[工具：焦点小组活动]]
|
||||
@@ -0,0 +1,10 @@
|
||||
### 问题
|
||||
一名项目团队成员生病了，几周内无法返回项目。在日常会议中，团队分享了他们的担忧，因为生病的团队成员是唯一一个熟练掌握他们正在开发的组件的人。项目经理应该做些什么来防止这种情况发生?
|
||||
A.在项目期间促进跨职能知识转移
|
||||
B.在每个组成部分获得了一个以上的熟练资源
|
||||
C.将特定组件的开发外包给另一个团队
|
||||
D.要求为组件的构建提供可靠的文档
|
||||
|
||||
|
||||
### 考点参考
|
||||
[[管理项目知识]]
|
||||
@@ -0,0 +1,11 @@
|
||||
### 问题
|
||||
对于一个即将进行的项目，需求评估和商业论证已经完成，项目管理办公室（PMO）正在对收益管理计划的草案进行评审。PMO强调了收益管理计划的一个要素，并要求在确定文件的最终版本之前删除该要素。以下哪一项最有可能是PMO要求删除的要素？
|
||||
|
||||
1. 通过项目实施所获得的预期有形和无形价值
|
||||
2. 为抓住商机而需要考虑的解决方案
|
||||
3. 实现项目收益的期限
|
||||
4. 用于显示已实现收益的测量
|
||||
|
||||
### 考点参考
|
||||
> [!QUOTE]+ 商业文件不包括具体的解决方案，只做价值论证
|
||||
> ![[商业文件#商业文件包含哪些内容]]
|
||||
@@ -0,0 +1,4 @@
|
||||
矩阵定位法
|
||||
通过过程组，和领域，判断问题属于哪个过程。
|
||||
|
||||
这个问题，干系人管理，启动阶段，两个。
|
||||
Reference in New Issue
Block a user