PMP学习笔记按章节梳理核心考点.docx
- 文档编号:30017349
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:132
- 大小:19.71MB
PMP学习笔记按章节梳理核心考点.docx
《PMP学习笔记按章节梳理核心考点.docx》由会员分享,可在线阅读,更多相关《PMP学习笔记按章节梳理核心考点.docx(132页珍藏版)》请在冰豆网上搜索。
PMP学习笔记按章节梳理核心考点
第一章
1.2项目要素
1.2.1项目
项目是为创造独特的产品、服务或成果而进行的临时性工作。
◆独特的产品、服务或成果。
开展项目是为了通过可交付成果达成目标。
◆临时性工作。
项目的“临时性”是指项目有明确的起点和终点。
“临时性”并不一定意味着项目的持续时间短。
虽然项目是临时性工作,但其可交付成果可能会在项目的终止后依然存在。
◆项目驱动变更。
项目驱动组织进行变更。
有些项目可能会创造一个过渡状态,即由多个步骤组成的连续区间,以过渡到将来状态。
◆项目创造商业价值。
项目特点
1.2.3项目、项目集、项目组合以及运营管理之间的关系
从组织的角度来看项目、项目集和项目组合管理:
◆项目集和项目管理的重点在于以“正确”的方式开展项目集和项目;
◆项目组合管理则注重于开展“正确”的项目集和项目。
运营管理
运营管理关注产品的持续生产和(或)服务的持续运作。
它重点管理那些把各种输入(如材料、零件、能源和劳力)转变为输出(如产品、商品和(或)服务)的过程。
运营与项目管理
项目与运营会在产品生命周期的不同时点交叉,例如:
◆在新产品开发、产品升级或提高产量时;
◆在改进运营或产品开发流程时;
◆在产品生命周期结束阶段;
◆在每个收尾阶段。
1.2.4指南的组成部分
1.2.4.1项目和开发生命周期
项目生命周期指项目从启动到完成所经历的一系列阶段。
它为项目管理提供了一个基本框架。
这些阶段之间的关系可以顺序、迭代或交叠进行。
项目生命周期可以是预测型或适应型。
项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关,这些阶段称为开发生命周期。
开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式:
项目阶段
项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。
项目可以分解为不同的阶段或子组件。
阶段名称的例子包括:
概念开发;可行性研究;客户要求;解决方案开发;设计;建造;测试;试运行;里程碑审查;经验教训。
阶段关口
阶段关口在项目阶段结束时进行,将项目的绩效和进度与项目和业务文件比较
根据比较结果做出决定(例如继续/终止的决定),以便:
进入下个阶段;整改后进入下个阶段;结束项目;停留在当前阶段;重复阶段或某个要素。
1.2.6项目管理商业文件
1.2.6.1项目商业论证
项目商业论证指文档化的经济可行性研究报告。
商业论证列出了项目启动的目标和理由。
(不是项目章程。
项目章程一般没有记录理由)
它有助于在项目结束时根据项目目标衡量项目是否成功。
在项目启动前进行商业论证。
需求评估通常是在商业论证之前进行,包括了解业务目的和目标、问题和机会,并提出处理建议。
1.2.6.4项目成功标准
◆完成项目效益管理计划
◆达到商业论证中记录的已商定的财务测量指标:
净现值(NPV)、投资回报率(ROI)、内部报酬率(IRR)、回收期(PBP)、效益成本比率(BCR)
◆达到商业论证的非财务目标;完成组织从“当前状态”转到“将来状态”
◆履行合同条款和条件;达到组织战略、目的和目标;使相关方满意;
◆可接受的客户/最终用户的采纳度;将可交付成果整合到组织的运营环境中;
◆满足商定的交付质量;遵循治理规则;
◆满足商定的其他成功标准或准则(例如过程产出率)。
第二章项目运行环境
2.2事业环境因素
2.3组织过程资产
2.4组织系统
运行项目时需要应对组织结构和治理框架带来的制约因素。
为有效且高效地开展项目,项目经理需要了解组织内的职责、终责和职权的分配情况。
这有助于项目经理有效地利用其权力、影响力、能力、领导力和政治能力成功完成项目。
单个组织内多种因素的交互影响创造出一个独特的系统,会对在该系统内运行的项目造成影响。
这种组织系统决定了组织系统内部人员的权力、影响力、利益、能力和政治能力。
系统因素包括(但不限于):
◆治理框架:
治理指组织各个层面的有组织的或有结构的安排,旨在确定和影响组织成员的行为。
◆管理要素:
管理要素指组织内部关键职能部门或一般管理原则的组成部分。
◆
组织结构类型:
组织需要权衡两个关键变量之后才可确定合适的组织结构类型。
项目管理办公室
除了被集中管理以外,PMO所支持和管理的项目不一定彼此关联。
第三章项目经理的角色
3.2项目经理的定义
项目经理的角色不同于职能经理或运营经理。
一般而言,职能经理专注于对某个职能领域或业务部门的管理监督。
运营经理负责保证业务运营的高效性。
项目经理是由执行组织委派,领导团队实现项目目标的个人。
3.3项目经理的影响力范围
◆项目:
项目经理领导项目团队实现项目目标和相关方的期望。
项目经理利用可用资源,以平衡相互竞争的制约因素。
◆组织:
基于组织结构,项目经理可能向职能经理报告。
而在其他情况下,项目经理可能与其他项目经理一起,向PMO、项目组合或项目集经理报告。
项目经理还需与其他角色紧密协作,如组织经理、主题专家以及商业分析人员。
◆行业;专业学科;跨学科领域。
3.4项目经理的胜任力
3.5执行整合
第四章整合管理
项目整合管理核心概念
项目整合管理由项目经理负责。
虽然其他知识领域可以由相关专家(如成本分析专家、进度规划专家、风险管理专家)管理,但是项目整合管理的责任不能被授权或转移。
项目与项目管理本质上具有整合性质,例如,为应急计划制定成本估算时,就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。
敏捷或适应型环境中需要考虑的因素:
迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。
团队成员自行决定计划及其组件的整合方式。
(自组织)
把对具体产品的规划和交付授权给团队来控制。
项目经理的关注点在于营造一个合作型的决策氛围。
4.1制定项目章程
◆过程定义:
编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
◆过程作用:
明确项目与组织战略目标之间的直接联系,确立项目的正式地位,并展示组织对项目的承诺。
◆在执行外部项目时,通常需要用正式的合同来达成合作协议。
◆不要把项目章程看作合同。
4.1.1输入
4.1.1.1商业文件
◆商业文件不是项目文件,项目经理就不可以对它们进行更新或修改。
4.1.2工具与技术
4.1.2.2数据收集
◆头脑风暴:
用于在短时间内获得大量创意,适用于团队环境,需要引导者进行引导。
Ø头脑风暴由两个部分构成:
创意产生和创意分析。
◆焦点小组:
焦点小组召集相关方和主题专家讨论项目风险、成功标准和其他议题,比一对一访谈更有利于互动交流。
◆访谈:
访谈是指通过与相关方直接交谈来了解高层级需求、假设条件、制约因素、审批标准以及其他信息。
4.1.2.3人际关系与团队技能—引导
引导是指有效引导团队活动成功以达成决定、解决方案或结论的能力。
引导者确保参与者有效参与,互相理解,考虑所有意见,按既定决策流程全力支持得到的结论或结果,以及所达成的行动计划和协议在之后得到合理执行。
4.1.3输出—项目章程☆
项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。
4.2制定项目管理计划
◆过程定义:
定义、准备和协调项目计划的所有组成部分,并把它们整合为一份综合项目管理计划的过程。
◆过程作用:
生成一份综合文件,用于确定所有项目工作的基础及其执行方式。
◆项目管理计划应基准化,即,至少应规定项目的范围、时间和成本方面的基准。
◆一旦确定了基准,就只能通过实施整体变更控制过程进行更新。
◆该计划需要通过不断更新来渐进明细,并且这些更新需要得到控制和批准。
4.2.2工具与技术
4.2.2.2数据收集—核对单
核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
4.2.2.4会议
4.2.3输出—项目管理计划☆
4.3指导与管理项目工作
◆过程定义:
是为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。
◆过程作用:
对项目工作和可交付成果开展综合管理,以提高项目成功的可能性。
◆在项目执行过程中,收集工作绩效数据并传达给合适的控制过程做进一步分析。
4.3.2工具与技术—项目管理信息系统(PMIS)
PMIS提供信息技术(IT)软件工具,例如进度计划软件工具、工作授权系统、配置管理系统、信息收集与发布系统,以及进入其他在线自动化系统(如公司知识库)的界面。
自动收集和报告关键绩效指标(KPI)可以是本系统的一项功能。
4.3.3输出
4.3.3.1可交付成果☆
可交付成果(Deliverables)是在某一过程、阶段或项目完成时,必须产出的任何独特并可核实的产品、成果或服务能力。
一旦完成了可交付成果的第一个版本,就应该执行变更控制。
4.3.3.2工作绩效数据
工作绩效数据是在执行项目工作的过程中,从每个正在执行的活动中收集到的原始观察结果和测量值。
在工作执行过程中收集数据,再交由控制过程做进一步分析。
4.3.3.3问题日志
在整个项目生命周期中,项目经理通常会遇到问题、差距、不一致或意外冲突。
所需记录和跟进的内容可能包括:
问题类型;问题提出者和提出时间;问题描述;问题优先级;由谁负责解决问题;目标解决日期;问题状态;最终解决情况。
4.3.3.4变更请求☆
变更请求是关于修改任何文件、可交付成果或基准的正式提议。
任何项目相关方都可以提出变更请求,应该通过实施整体变更控制过程对变更请求进行审查和处理。
变更请求源自项目内部或外部,是可选或由法律(合同)强制的。
变更请求可能包括:
◆纠正措施:
为使项目工作绩效重新与项目管理计划一致,而进行的有目的的活动。
◆预防措施:
为确保项目工作的未来绩效符合项目管理计划,而进行的有目的的活动。
◆缺陷补救:
为了修正不一致产品或产品组件的有目的的活动。
◆更新:
对正式受控的项目文件或计划等进行的变更,以反映修改或增加的意见内容
4.4管理项目知识
◆过程定义:
使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。
◆过程作用:
利用已有的组织知识来创造或改进项目成果,并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段
◆知识通常分为:
☆
Ø显性知识:
易使用文字、图片和数字进行编撰的知识。
Ø隐性知识:
个体知识以及难以明确表达的知识,如信念、洞察力、经验和诀窍。
◆一个常见误解是,知识管理只是将知识记录下来用于分享;另一种常见误解是,知识管理只是在项目结束时总结经验教训。
◆知识管理最重要的环节就是营造一种相互信任的氛围,激励人们分享知识或关注他人的知识。
4.4.2工具与技术
4.4.2.2知识管理
4.4.2.3信息管理
通过增加互动要素,如“与我联系”的功能,使用户能够与经验教训发帖者联系,并向其寻求与特定项目和情境有关的建议。
这样一来,就能够强化信息管理工具和技术的使用。
4.4.3输出—经验教训登记册
经验教训登记册可以包含情况的类别和描述,经验教训登记册还可包括与情况相关的影响、建议和行动方案。
4.5监控项目工作
◆过程定义:
跟踪、审查和报告整体项目进展,以实现项目管理计划中确定的绩效目标的过程。
◆过程作用:
让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动,以及通过成本和进度预测,让相关方了解未来项目状态。
监控项目工作过程关注:
◆把项目的实际绩效与项目管理计划进行比较;
◆定期评估项目绩效,决定是否需要采取纠正或预防措施,并推荐必要的措施;
◆检查单个项目风险的状态;在整个项目期间,维护一个准确且及时更新的信息库,以反映项目产品及相关文件的情况;
◆为状态报告、进展测量和预测提供信息;做出预测,以更新当前的成本与进度信息;
◆监督已批准变更的实施情况;确保项目与商业需求保持一致。
◆如果项目是项目集的一部分,还应向项目集管理层报告项目进展和状态;
4.5.2.2数据分析
4.5.3输出—工作绩效报告
工作绩效信息可以用实体或电子形式加以合并、记录和分发。
工作绩效报告的示例包括状态报告和进展报告。
工作绩效报告可以包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息和风险情况概述。
4.6实施整体变更控制☆☆
◆过程定义:
是审查所有变更请求、批准变更,管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。
◆过程作用:
确保对项目中已记录在案的变更做综合评审。
◆在整个项目生命周期的任何时间,参与项目的任何相关方都可以提出变更请求。
◆实施整体变更控制过程贯穿项目始终,项目经理对此承担最终责任。
◆每项记录在案的变更请求都必须由一位责任人批准、推迟或否决,这个责任人通常是项目发起人或项目经理。
应该在项目管理计划或组织程序中指定这位责任人。
◆必要时,应该由变更控制委员会(CCB)来开展实施整体变更控制过程。
CCB是一个正式组成的团体,负责审查、评价、批准、推迟或否决项目变更。
◆对于会影响项目基准的变更,通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。
这种变更应由CCB(如有)和客户或发起人审批,除非他们本身就是CCB的成员。
4.6.2工具与技术
4.6.2.2变更控制工具☆
◆配置控制:
重点关注可交付成果及各个过程的技术规范。
(技术规范)
◆变更控制:
着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
(变更的流程控制)
4.6.2.5会议
与变更控制委员会(CCB)一起召开变更控制会。
变更控制委员会负责审查变更请求,并做出批准、否决或推迟的决定。
大部分变更会对时间、成本、资源或风险产生一定的影响。
CCB也可以审查配置管理活动。
4.6.3输出—批准的变更请求
由项目经理、CCB或指定的团队成员,根据变更管理计划处理变更请求,做出批准、推迟或否决的决定。
批准的变更请求应通过指导与管理项目工作过程加以实施。
对于推迟或否决的变更请求,应通知提出变更请求的个人或小组。
4.7结束项目或阶段
◆过程定义:
终结项目、阶段或合同的所有活动的过程。
◆过程作用:
存档项目或阶段信息,完成计划的工作,释放组织团队资源以展开新的工作。
项目或阶段行政收尾所需的必要活动包括(但不限于):
◆为达到阶段或项目的完工或退出标准所必须的行动和活动。
例如:
确保所有文件和可交付成果都已是最新版本,且所有问题都已得到解决;确认可交付成果已交付给客户并已获得客户的正式验收;确保所有成本都已记入项目成本账;关闭项目账户;重新分配人员;处理多余的项目材料;重新分配项目设施、设备和其他资源;根据组织政策编制详尽的最终项目报告。
◆为关闭项目合同协议或项目阶段合同协议所必须开展的活动。
例如:
确认卖方的工作已通过正式验收;最终处置未决索赔;更新记录以反映最后的结果;存档相关信息供未来使用。
◆为完成下列工作所必须开展的活动:
收集项目或阶段记录;审计项目成败;管理知识分享和传递;总结经验教训;存档项目信息以供组织未来使用。
◆为向下一个阶段,或者向生产和(或)运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
◆收集关于改进或更新组织政策和程序的建议,并将它们发送给相应的组织部门。
◆测量相关方的满意程度。
如果项目在完工前就提前终止,还需要制定程序,来调查和记录提前终止的原因。
4.7.3输出
4.7.3.2最终产品、服务或成果移交
项目交付的产品、服务或成果可转交给另一团队或组织,并由其在整个生命周期中进行运营、维护和支持。
本输出所指的正是把项目交付的最终产品、服务或成果(对于阶段收尾,则是所在阶段的中间产品、服务或成果)从一个团队转交到另一个团队。
4.7.3.3最终报告
用最终报告总结项目绩效,其中可包含诸如以下信息:
项目或阶段的概述;范围目标、范围的评估标准,以及证明达到完工标准的证据;质量目标、项目和产品质量的评估标准、相关核实信息和实际里程碑交付日期以及偏差原因;成本目标,包括可接受的成本区间、实际成本,以及产生任何偏差的原因;最终产品、服务或成果的确认信息的总结。
第五章范围管理
项目范围管理核心概念
◆范围管理目的:
做且只做所需的全部工作,以成功完成项目。
◆项目范围有时也包括产品范围
◆范围基准由范围说明书、WBS、WBS词典共同构成
◆范围区分:
Ø产品范围:
某项产品、服务或成果所具有的特征和功能
Ø项目范围:
为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
◆衡量依据:
Ø产品范围:
根据产品需求来衡量(需求文件)
Ø项目范围:
根据项目管理计划来衡量(项目管理计划)
预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。
适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。
在适应型或敏捷型生命周期中,发起人和客户代表应持续参与项目,确保产品未完项反映他们的当前需求。
在每次迭代中,都会重复开展:
确认范围和控制范围。
在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围是一个持续性的过程
在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的WBS词典构成项目范围基准。
只有通过正式变更控制程序,才能进行基准变更。
在开展确认范围、控制范围及其他控制过程时,基准被用作比较的基础。
而采用适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。
确认范围是正式验收已完成的项目可交付成果的过程。
从控制质量过程输出的核实的可交付成果是确认范围过程的输入,而验收的可交付成果是确认范围过程的输出之一,由获得授权的相关方正式签字批准。
5.1规划范围管理
◆过程定义:
创建范围管理计划,书面描述将如何定义、确定和控制项目范围的过程
◆过程作用:
在整个项目期间对如何管理范围提供指南和方向
◆项目范围管理计划是项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围
5.1.3输出
5.1.3.1范围管理计划
◆项目管理子计划之一。
描述将如何定义、制定、监督、控制和确认项目范围
◆范围管理计划对下列工作的管理过程做出规定:
Ø制定项目范围说明书
Ø根据详细项目范围说明书创建WBS;确定如何审批和维护范围基准
Ø正式验收已完成的项目可交付成果
Ø处理对详细项目范围说明书的变更(与实施整体变更控制过程直接关联)
◆根据项目需要,范围管理计划可以是正式或非正式的,非常详细或高度概括的
5.1.3.2需求管理计划
◆项目管理子计划之一。
描述将如何分析、记录和管理项目和产品需求
◆主要内容:
如何规划、跟踪和报告各种需求活动;配置管理活动;需求优先级排序过程;测量指标及使用这些指标的理由;反映哪些需求属性被列入需求跟踪矩阵
5.2收集需求
◆过程定义:
为实现项目目标而确定、记录并管理相关方的需要(needs)和需求(requirements)的过程
◆过程作用:
为定义产品范围和项目范围奠定基础
◆需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件和能力。
包括发起人、客户和其他相关方已量化且书面记录的需要和期望(expectation)
◆需求将成为工作分解结构(WBS)的基础,也是成本、进度、质量和采购规划的基础
5.2.2工具与技术
☆需熟悉收集需求过程中主要工具的特点和适用场景。
5.2.2.2数据收集
◆问卷调查:
指设计一系列书面问题,向众多受访者快速收集信息
适用场景:
受众多、需快速完成调查、受访者地理位置分散、适合适用统计分析
◆标杆对照:
将实际或计划的产品、过程或实践,与其他可比组织的实践进行比较,以便识别最佳实践。
形成改进意见,并未绩效考核提供依据
5.2.2.3数据分析(文件分析)
通过分析现有文档,识别与需求相关的信息,来挖掘需求。
可供分析的文件包括:
(协议;商业计划;业务流程或接口文档;业务规划库;现行流程;市场文献;问题日志;政策和程序;法规文件;建议邀请书;用例)
5.2.2.4决策
◆投票:
一种为达成某种期望结果,而对多个未来行动方案进行评估的集体决策技术
Ø一致同意(Unanimity)。
德尔菲技术
Ø大多数同意(Majority)。
超过50%同意,奇数原则
Ø相对多数同意(Plurality)。
候选项超过两个时使用
◆独裁型决策
◆多标准决策分析:
借助决策矩阵,用系统分析方法建立不同标准
●☆德尔菲技术:
用来获得专家意见的常用方法,防止个人对结果产生不恰当的影响。
⏹由一组选定的专家回答问卷,并对每一轮需求收集的结果再给出反馈,专家的结果只能交给主持人以保持匿名状态
⏹属于头脑风暴的一种形式。
⏹在最后一轮达成的结果才是最终可能的估算
⏹遵守下列基本原则:
(☆德尔菲技术vs头脑风暴)
✓专家之间背靠背、专家以匿名形式提意见、多轮次、旨在取得一致性意见
5.2.2.5数据表现
5.2.2.6人际关系与团队技能
5.2.2.7系统交互图
系统交互图是范围模型的一个例子。
对产品范围的可视化描述,显示业务系统及其与人和其他系统之间的交互方式
系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者
5.2.2.8原型法
5.2.3输出
5.2.3.1需求文件
◆需求文件描述各种单一需求将如何满足与项目相关的业务需求,一开始可能只有高层级的需求,随着有关需求信息的增加而逐步细化。
需求文件可详可简。
◆主要相关方认可的、明确的(可测量可测试的)、可跟踪的、完整的、相互协调的需求才可作为需求基准。
◆需求分类:
☆
Ø业务需求:
整个组织的高层级需求
Ø相关方需求:
个人或群体的需要
Ø解决方案需求:
●功能需求:
产品应具备的功能
●非功能需求:
产品正常运行所需的环境条件或质量要求。
如保密性、可靠性、性能、安全性、服务水平、可支持性、保留或清除等。
Ø过渡和就绪需求:
从当前状态到将来状态所需的临时能力。
如数据转换和培训需求
Ø项目需求:
项目需要满足的行动、过程或其他条件,如里程碑日期合同责任等
Ø质量需求:
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。
如测试、认证、确认等。
5.2.3.2需求跟踪矩阵
5.3定义范围
◆过程定义:
制定项目和产品详细描述过程。
◆过程作用:
描述产品、服务或成果的边界和验收标准。
明确所收集的需求哪些包含在项目范围内,哪些将排除在项目范围外
◆定义范围需从需求文件中选取最终项目需求
◆需要多次反复开展定义范围过程,在迭代性生命周期项目中,更是如此
5.3.2工具与技术
5.3.2.5产品分析
产品分析可用于定义产品和服务,包括针对产品和服务提问并回答,以描述要交付的产品的用途、特征及其他方面。
5.3.3输出
5.3.3.1项目范围说明书☆
◆是对项目范围、主要交付成果、假设条件和制约因素的描述。
◆记录了整个范围,包括项目和产品范围
◆详细描述项目的可交付成果,以及创建这些可交付成果而必须开展的工作
◆代表了项目相关方之间就项目范围达成的共识
5.4创建WBS☆
◆过程定义:
把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
◆过程作用:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- PMP 学习 笔记 章节 梳理 核心 考点