PMP——高效应对新考纲
2022-03-04 15:24:32 2 举报AI智能生成
登录查看完整内容
应对最新的PMI考纲进行考点梳理，并附例题
作者其他创作
大纲/内容
PMP考试不仅是知识层面的考察，同时也是价值观的宣贯。
PMI有自己的基础价值观，主要通过《道德规范与专业操守守则》《道德决策框架》等文件呈现
这些基础价值观是比较抽象、笼统的，我们的工作就是将其解读得更加具体和落地，作为考试中解决问题和处理人际关系的指导原则。
改考纲，不改原则
如何管事：项目经理用什么样的态度来对待工作和处理问题
如何处人：项目经理用什么样的态度来对待团队成员及相关方。
做事情要遵循程序
答案：C
如果没有程序，那就先制定一个
答案：B
依靠程序和规则来预防和解决问题，而不是依靠某个人
原则1.1— — 用程序和规则解决问题
答案：A
答案：D
制定好的程序、计划和规则，任何人都要遵守，不能突破
预测型项目，变更尤其要遵循整体控制流程
高度关注合规，确保行为合规
不依靠破坏合规来获取任何利益
对合规的尊重要严格到死板的程度
原则1.2— — 尊重程序，确保合规
不用降低项目成果质量和项目质量标准的方式去解决问题
质量保证和质量控制过程一般不取消或缩减，质量成本要考虑全面
预测型项目在范围基准建立以后，不依靠缩减范围来解决问题（预算被削减除外）
原则1.3— — 质量和范围不妥协
答案：D 执行由风险部门经理 负责依然还是项目经理
工作过程和程序本身也需要优化，审计是重要工具
欢迎通过审计来改善工作的合规性，提升过程的有效性
注重过程的持续改进
原则1.4— — 欢迎审计，改进过程
责任范围内的问题，项目经理必须主动承担
重要工作必须本人来做，不能退缩
明确职责范围，已经交接出去的工作不越权处理
原则1.5— — 主动承担职责，但不越权
如何管事
两方面
为什么要学习PMI的基本原则
诚实、客观、公正
不追求不应该获得的利益
不隐瞒问题，遇到违规要报告
原则2.1— — 诚实透明，不隐瞒问题
在任何两个主体之间都要保持基本的利益平衡，不要偏袒一方
即使牵涉自身利益，也要努力追求双赢
为所有人提供同等、公平的机会和条件，包括信息条件
原则2.2— — 平衡公平，追求双赢
答案：B
相关方的诉求，不能忽略、不能直接拒绝
不要阻止相关方提出诉求和意见
即使相关方不主动提供必要的需求和意见，项目经理也不能忽略，而应该积极了解
原则2.3— — 对相关方不忽略不拒绝
尊重文化的多样性和不同文化习俗，通过沟通去解决文化差异带来的问题
主动建立文化意识，以改善沟通和团队合作
(文化意识，即理解不同文化之间的差异并据此调整沟通策略的能力)
原则2.4— — 了解并尊重文化差异
有人表现不佳或犯错误，优先通过私下沟通来帮助他改善
无法解决再考虑升级上报，不要用威胁、惩罚的手段
慎用批评，基本不做公开批评，更不要使用开除等极端手段
原则2.5— — 慎用批评及威胁、惩罚
如何处人
一、解析PMI基本原则
为什么要用“情景模拟”来学习PMP？
不考察概念，而考察解决实际问题的能力
考察方式变化
不从知识领域/过程入手，而从遇到问题入手
应对方式变化
\"情景模拟\"总体思路
项目经理现在应该做什么？
项目经理能够如何完成这项工作？
项目经理应该使用什么来进行回复？
典型情景
如果多个答案都合理，选择其中最重要、最能解决问题的方法
重要优先
选择最符合PMI核心价值观的方法
原则优先
符合规则，强调遵守流程
合规优先
对题目中给到的制约因素，要进行考虑和响应，已经尝试过但无效的方法，不再重复
响应题目
处理思路
例题
1、问现在
项目经理首先应该做什么？
项目经理下一步应该做什么？
项目经理应该指示团队下一步做什么？
强调步骤的执行顺序，如果多个选项都是正确的行为，要选其中顺序在前的步骤
顺序优先
讨论分析影响（和团队一起)、更新问题日志
遇到问题时
更新相关方登记册
识别出新的相关方/现有相关方发生变化时
更新风险登记册
识别出新风险/已识别风险发生变化时
分析影响、正式提交变更请求
提议变更时
优先考虑的选项
答案：A 下一步是记录到问题日志，然后才是与发起人开会，了解他们的期望
2、问首先
项目经理事先应该采取什么不同的做法？
项目经理如何在项目开始时管理此情形？
若要避免这种情况，项目经理应该做什么？
下列哪一项可以预防该问题？
目前已经发生的问题，根本原因是什么？
先分析根本原因
编制正确的计划
确保执行正确的流程，尤其是： 严格控制变更、要求相关方遵循变更管理计划
让相关方尽早参与、尽早表达意见、进行充分的沟通和确认
充分收集需求
充分识别风险并制定应对计划
再从根源上、流程上消除这个原因，主要的解决办法包括：
是否做了这件事，就可以避免现在的问题？
有答案后，代入题目进行验证思考
答案：D 此题问的是现在需要怎么做 选择D 可能使用的方法是 强迫
答案：A 此问题是问事先
对比“问现在”和“问事先”
3、问事先
项目经理应该做些什么来确保在未来的项目中不会发生这种情况？
若要确保在未来的项目中不会再次发生这种情况，项目经理应该做什么？
在结束项目之前，项目经理应该如何提高未来项目的绩效？
记录本项目的经验教训，并纳入组织过程资产
在未来项目中规避问题，主要方式是
收集和记录本项目的经验教训
创建/更新组织知识库
创建/更新组织经验教训库
在本项目的未来过程中避免问题，参考“问事先”
答案：D A项未来的项目经理不一定就是你，不一定是你来规划
4、问未来
识别时间点的四种情况
识别时间点
项目经理正在尝试完成项目章程/项目章程还为批准
已经提供了项目目标，项目经理正在确定项目章程中应包含哪些内容
正在编制商业论证/可行性报告
制定项目章程并获得正式批准
此阶段（初步任命的）项目经理要的核心任务是
项目经理应该参与章程的制定和批准，态度要积极，主动整合各种因素和意见，不要消极等待
此阶段遇到重要问题可以与发起人沟通解决
商业文件是项目章程的前置条件，应先于章程进行开发
商业文件一般由发起人委托商业分析师制定
项目经理在参与制定章程的过程中，应考虑商业文件给出的结论，并在此基础上，与相关方进行项目评估/评审，来判断项目可行性
章程必须得到（发起人/所有关键相关方)正式批准，否则不能继续开展工作
启动阶段同时要识别相关方，如果相关方在需求等问题上有分歧，不能搁置，要通过项目章程的制定和批准过程加以解决，可使用引导(引导式研讨会)、冲突管理等方法促进达成共识
在此阶段识别出的各种初步、概要性信息（如高层级风险)，应纳入项目章程
启动阶段，项目经理手里有部分项目文件的最初版本，如相关方登记册、假设日志，但还没有详细的各种管理计划，尤其没有基准，遇到问题时，只能查阅手里现有的文件
答案：A A中说的建立职权 是项目章程中最重要的意义 比B更好点 B也没有错 只是相对本题来说 A更符合要求
启动阶段：项目章程制定完毕并获得批准之前
启动阶段项目经理的核心任务和处理思路
项目章程已经获得批准
在项目规划期间/阶段
正在指定项目管理计划
在章程批准后，项目经理已经转为主要负责人
此后，“联系发起人”“联系高级管理层”基本不要选
章程是很严肃的文件，批准以后保持稳定，不轻易修改
即使发现章程需要修改，项目经理也无权直接进行修改，要联系发起人建议修改
批准后的章程可以与外部相关方和内部团队分享，来解决他们对项目主要内容不清楚或认识不一致的问题，如目标、高层级需求等等
按照项目章程制定项目管理计划，并获得批准
此阶段项目经理的核心任务
制定项目管理计划必须以项目章程为依据
此阶段基准还没建立，因此不存在变更问题，初步作出的管理计划可以直接调整
规划阶段的结束标志是开工大会（Kick-off Meeting），目的是获得相关方的支持和承诺
在开工大会之前，项目经理应该准备好初步的项目团队职责分配计划，并且与相关方取得共识
项目管理计划必须获得关键相关方的批准，一旦批准，再调整就必须进行整体变更控制
答案：B 与前面启动阶段的一题比较相似
答案：A 需要两部判断 首先是项目章程和个人需求的判断 项目章程大 以项目章程为主 然后判断A和D 相对来说A更合适 一个是制定好的规则和人之间的关系 一个是其他人的意见怎么处理
规划阶段：章程 → 项目管理管理计划
在项目执行期间/阶段
正在努力进行可交付成果的工作
一位新项目经理负责管理一个处于规划阶段之后的项目
此时已经有了经过批准的项目管理计划，要严格按照计划和流程做事
主要的变更控制问题都发生在这个阶段，要严守变更管理流程
此阶段项目经理的核心任务是：执行计划，努力解决出现的问题，确保项目绩效符合基准
遇到问题，按照《问题解决的思维模型》去处理
先分析原因和影响，再考虑如何解决问题
如果遇到问题，项目经理要积极主动地解决，承担责任，努力维护现有的基准
沟通、谈判，以确保资源就位
变更执行方法（如进度压缩、资源优化)
使用冲突管理、引导等技能，解决团队之间、相关方之间的问题
了解相关方的期望，解决他们关切的问题，获得相关方的支持
解决方式包括
如果仍无法解决，可以发起变更，申请调整成本基准和进度基准
质量不妥协：不会用降低质量的方式去解决问题
范围不缩减：定义好范围后，除了预算被砍的情况，不会用缩减项目范围来适应问题
始终注意合规性和价值观
答案：B 有额外资源 可以赶工
答案：C 项目处于进度落后成本超支的状况，需要快速跟进，并行实施，以缩短项目实际进度与计划进度的偏差，并且不额外增加新的成本。
执行阶段：项目管理计划发布 → 可交付成果基本完成
一个项目即将完成
一个项目的用户验收阶段
在项目的收尾期间
在此阶段，项目经理的首要工作是完成可交付成果的验收
在收尾阶段，如果发现成果不满足需求或不符合质量标准，不能忽略，必须要解决掉问题（往往需要进行变更），确保最后交付的是合格且满足需求的产品
PMI非常重视收尾时总结经验教训，然后纳入组织过程资产
收尾阶段要总结归档各种信息，交接清楚责任义务
项目收尾的最后一项工作是解散团队释放资源
验收—移交—总结—归档—释放
项目结束后还需要完成收集相关方对项目的反馈和建议
项目经理的职权在项目收尾结束后完成，此后，对于已经移交了的成果，你不再是负责人，如果出现问题，应该由当时的负责人（比如运营经理）牵头解决
项目终止、取消等异常结束，也要进行收尾
答案：A 完成了任务的意思就是 可交付成果已经生产出来 那么下一步就应该是请求验收可交付成果
答案：BDF
收尾阶段：可交付成果基本完成 → 项目工作全部结束
项目阶段不等于项目管理过程组
识别项目阶段
一位相关方请求将项目的完成日期提前一个月；
客户对项目绩效感到满意，但他们要求将交付日期提前一周；
项目发起人要求使用剩余预算来为另一个项目提供资金；
一名团队成员发现范围蔓延正在影响成本；
在建造一栋新建筑的中途，政府采用新的消防法，所有新建筑都必须遵守这些法律；
项目经理发现一位团队成员接受了客户要求的对约定项目范围的变更，客户表示该变更不对成本或进度产生任何影响；
在一个项目的最终测试阶段，项目经理发现一名团队成员在其不知情的情况下实施了一个微小变更，这项变更对预算或进度计划没有影响；
一个项目已完成80%以上，这时一位重要相关方请求对一个过程进行变更
直接实施变更，或者直接调整计划
直接接受实质变更
直接拒绝外部相关方的变更建议
三种“硬伤”操作
变更的前提是项目管理计划获得批准，否则可以直接修订计划，不存在变更
只要项目管理计划批准了，对计划的调整都要走变更控制流程，进行整体变更控制
处理方法：请他正式提出变更请求（request）——（分析影响）—— 提交审批
有的时候，外部相关方提出的已是一个正式的变更请求，则：（分析影响）—— 提交审批
如果外部相关方（如发起人、客户）提出了一个变更的建议（proposal），不能直接决绝
如果项目团队内部提出一个变更的建议，项目经理要进行评估，合理的想法再以团队的名义提交给CCB审批，不合理的可以不提交
CCB已经批准的变更，项目经理和任何人都只能接受，无权拒绝
变更批准后，应先对受影响的计划（如项目基准）进行调整，再加以执行
无论变更是否批准，都要对变更日志进行更新，并将结果通知有关的相关方
如果团队未走流程就进行私自变更，项目经理发现后，应先令其停止，然后必须将这个变更纳入控制流程，进行追认或否决。同时要向团队强调遵守变更流程。
关于变更的最高规定是变更管理计划，“变更控制系统”是变更管理计划的执行程序
控制相关方频繁要求变更的干扰，主要方法是让相关方尽早参与、制定变更流程
针对工作绩效，目的是使已经偏离计划（基准）的绩效与计划恢复一致
纠正措施
针对工作绩效，确保未来的绩效符合计划
预防措施
针对成果，对质量不合格、范围未实现的成果进行补救，使其达到约定的标准
缺陷补救
针对计划和成果，往往是由外而内的，如新出现的法律法规要求，会使产品范围、项目范围发生变化
更新
变更的四种类型
维护制定好的计划，调整工作来符合计划
调整计划以符合相应的变化
要求变更/发现私自变更
一位技术负责人警告称：缺乏对产品有经验的工程师，除非再增加两名工程师，否则该技术负责人无法承诺按时完成该产品。项目经理应该做什么？
在一个小型开发项目的中途，一位关键开发人员被调走
由于组织变更，团队将从70人缩减到50人，项目经理应该怎么办？
在项目执行中途，公司希望重新安排一名重要资源，项目经理应该怎么做？
项目经理已准备好开始执行多个项目，但可用资源不足，项目经理应该怎么做？
团队中有一半成员刚接触项目化环境，而另一半成员则不熟悉业务领域
资源何时可用、可用多久，记载在资源日历中。如果需要核实资源可用性，查看资源日历。
如果资源不满足要求，先分析影响，再制定应对方案
项目经理应该积极调配资源来解决资源问题的后果（如进度延误），而不要先申请调整基准
磨人的弱矩阵环境下，组织内部人力资源掌握在职能经理中，项目经理要去和职能经理谈判
如果组织内部资源短缺或不可用，要积极选择使用外部资源，在PMI看来外部资源≈内部资源
已经明确要抽调的资源，就不要再争夺了，要找替代性资源
如果项目时间充裕，可以对成员进行培训以提升技能
培训是项目工作的一部分，由项目经理而非职能经理负责，培训的方案记录在资源管理计划中
如果时间紧迫，那么不能通过培训来解决短缺问题，要找替代性资源
“提高团队效率”
“把工作分配给其他人”
PMI不提倡的解决方式
资源问题也可以视为风险，按照风险识别和应对的思路进行解决
已经在团队里，且具备技能的
一级
已经在团队里，但技能不足的，在时间不紧急的情况下，可以加以培训再用
二级
组织内的其他资源（跟职能经理沟通）
外部资源（采购）
上述都不满足的情况下（时间紧急来不及培训）
三级
资源使用优先级
答案：CE A不选的原因是题目给定的制约因素不要去违背
资源短缺/技能不足
职能经理拒绝释放所需的资源
职能团队中有一位资源称其正在忙于其他任务。项目经理应该做什么？
项目经理了解到团队成员很少遵循该组织中的变更标准
一个具有独特和关键技能的主题专家（SME），不愿接受项目经理的指令
对于团队成员，首先进行私下的沟通，如果沟通无效，再上报给成员的上级（如职能经理）
对于同级相关方，可以先通过直接沟通和谈判争取配合，向其强调遵守规则和完成项目工作的重要性，如无效，在考虑上报高层
对于高层、外部相关方，通过沟通来调整他们的参与程度，查询和遵循相关方参与计划
使相关方改变不配合态度的“套路”：与他沟通，了解他的期望，解决他关心的问题
相关方不配合不支持
一个关键相关方没空参加这次会议
项目经理与关键相关方举行了成本效益分析研讨会，其中一位关键相关方未能参加
因为一些相关方未能参加启动会议，一个项目遇到困难
如果缺席的是非常重要的相关方，且需要获得他们的正式批准，那么不能突破流程，一定要获得他们本人或者约定好承担其责任的人的正式批准/签字，才可以进行后续步骤
如果地理位置分散导致可能缺席，可以使用虚拟会议的方式来解决
如果个别相关方缺席，可以其他人先开会，然后将会议记录发送给缺席者，并收集反馈意见
一般不选择“取消会议，与相关方单独沟通”“大多数人开会（忽略少数人）”
事先问，应该是和相关方确认、沟通，确保其参会
相关方缺席会议
识别典型情景
识别人物关系
情景模拟的“四个识别”
二、掌握常见情景应对方式
什么是问题
答案：C
答案：B 此处质量成本为不一致性成本，为了预防不一致性成本，需要增加一致性成本 故选B
解决问题的两大思路
强调步骤的执行顺序
可能有多个选项都是正确的行为，要选顺序在前的步骤
遇到问题时：讨论分析影响（和团队一起）、更新问题日志
相关方发生变化时：更新相关方登记册
识别出新风险/原有风险发生变化时：更新风险登记册
接近于“问首先”
思路一：减轻影响，拉回正规
先分析原因——目前已经发生的问题，根本原因是什么？
执行正确的流程、编制正确的管理计划
在相关方之间强化规则（程序性计划），确保规则得到执行
尤其是：严格控制变更、要求相关方遵循变更管理计划
让相关方尽早参与、进行充分的沟通和确认
充分识别风险，并制定应对计划
再从根源上消除这个问题，主要的解决办法包括
思路二：寻找根源，从程序上解决
总结
三、问题解决的思维模型
客户在初始阶段就能给出完整、准确的需求
传统开发方法的基本假设
在项目初期尽可能详细获得需求，然后严格控制变更
通过明确的流程和严格的控制进行产出
开发策略
需求随着开发过程不断涌现
需要解决探索性问题
实际情况
缩短提出需求——验证需求的周期
尽快提供可用产品，根据评估和反馈快速调整
团队合作，寻找方法解决问题
在合作环境下，由自组织团队进行产品迭代开发的过程
什么是敏捷
也就是说，尽管右侧事项确有其价值，但我们更重视左侧事项的价值
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人由此我们建立了如下价值观：
答案：A 可用的软件胜过详尽的文档
敏捷的价值观
Scrum、FDD、XP、DSDM、Crystal ……
方法/框架
精益（Lean）、看板、精益六西格玛
原则/理念
敏捷的主要框架模式
敏捷的基本执行方法：Scrum
敏捷型与预测型不同的约束方式
谁要使用这个功能
角色
需要实现什么样的功能
活动
为什么需要这个功能，这个功能带来了什么样的价值
商业价值
三个要素
作为一个<角色>，我想要<活动>，以便<商业价值>
（作为学员，我希望做完模拟题后能看到错题，以便有针对性回顾）
典型描述方法
每个用户故事应足够小，使团队能够在一次冲刺迭代中完成
不能够使用技术语言来描述，要使用用户可以理解的业务语言
用故事点/估点（story point）来评估用户故事的大致工作量
从用户的角度来描述所需要得到的功能，是较小的功能单元
产品待办列表（Product Backlog）：需求的动态管理
用户故事（User Story）：敏捷需求的表现形式
刚好具备足以表达产品核心概念的部分功能的产品，用以验证需求
最小化可实行产品 MVP = Minimum Viable Product
产品主管（PO）、敏捷负责人（SM）、开发团队（Dev Team，3-9个人）
互动不够，技能有约束
人员太少
需要过多的协调工作
人员太多
构成
包含成功完成冲刺目标所需的多个只能/学科人员的组合
跨职能
团队拥有自主权来选择实现目标的最佳方法，并需对这些目标负责
自组织
在冲刺期间，团队通过自组织的方式实现目标，包括决定执行人、解决问题……
强调100%专职投入，尽可能在同一个场所工作（目前趋势已允许分布式团队）
敏捷团队（Scrum Team）
两个关键角色：PO与SM
每次冲刺前
从产品待办列表中选出冲刺待办列表，为本次冲刺确定范围
PO，SM，开发团队
PO要起关键作用
冲刺规划会
冲刺时每天简短
沟通，同步当前进展
团队，SM，（PO）
不是汇报会，不是问题解决会
项目经理起重要作用
每日展会
冲刺后
评审本次冲刺的成果
PO，SM，团队，其他相关方
同时讨论产品待办列表的增加和调整
PO起重要作用
冲刺评审会
评审会后
对本次冲刺的过程进行经验总结，促进团队改进
团队，SM，PO
项目经理不负责提供答案，只是协调团队找到更好的方法
冲刺回顾会
Scrum方法的四个会议
敏捷工具——迭代燃尽图/燃起图
团队需要满足的所有标准的核对单
DoD
类似于预测型项目中的质量测量指标
每次开始迭代前，开发团队和SM，PO需要对DOD达成共识，以避免返工
DOD可以明确对完成的预期，确保项目中的内外部相关方对完成的含义达成理解一致
所有代码不能包含编译错误
所有代码必须通过团队内部项目评审
必须同事提交与需求对应的单元测试结果
所有的SQL脚本必须通过团队内部评审
示例
完成的定义（DOD = Definition of Done）
信息发射源（Information Radiator）
对于地理位置分散的团队，每天结束时将工作移交给下一工作地点（可能相差很多时区）的方法，旨在为加快产品的开发。
追逐太阳
通过在团队分布的各个地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作开始时，人们打开链接，工作结束时，关闭链接。通过这种方式，人员可以自然地看到彼此并进行互动，减少了身处不同地点工作所固有的协作滞后问题。
鱼缸窗口
通过使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程结队。只要考虑了时区差异因素，这种方法几乎和面对面的结对一样有效。
远程结对
持续将工作整合到此前的系统中
持续整合
可能会出现的敏捷理念和工具
直接指明生命周期/开发方法，或者出现敏捷的框架名称，如：敏捷、适应型、迭代、Scrum、冲刺（Sprint）、精益、看板
出现敏捷的标志性角色，如：产品负责人/产品主管、敏捷项目经理/敏捷教练
出现敏捷的需求内容，如：待办列表、用户故事
出现敏捷相关的会议和活动，如：冲刺规划会、每日站会/每日例会、评审会、回顾总结会
出现敏捷相关的工具，如：迭代燃尽图、完成的定义（DOD）、看板
如何识别敏捷情景？ —— 关键词触发
在比较确定的进度和成本约束下，范围可灵活调整
敏捷的变更可以不经过变更流程，由产品负责人直接决定
拥抱变更
不断对未完成需求进行优先级排序，按照排序完成
优先交付
产品负责人管范围
项目经理是协调员，不能命令团队，不要主导
团队自我组织、自我管理
敏捷解题的基本原则
四、敏捷的价值与要点
PMP——高效应对新考纲
0 条评论
回复 删除
下一页
