PMP学习笔记.docx
《PMP学习笔记.docx》由会员分享，可在线阅读，更多相关《PMP学习笔记.docx（63页珍藏版）》请在冰豆网上搜索。
PMP学习笔记
PMP学习笔记
PMP学习笔记之一—项目管理框架
主要的知识点归纳如下:
1、项目、项目管理相关概念:
项目与日常运维的区别
2、项目生命周期:
产品生命周期与项目生命周期的区别
3、项目干系人:
理论上是无穷的，分析需求时，应考虑所有干系人的需求（所以要寻求最有效的途径）;
但是沟通计划的发送不需发给所有项目干系人，只给确定的主要人员。
项目干系人经常有不同目标，处理原则是以有得于客户的方式解决。
4、五大过程组:
哪个阶段风险最大?
占用资源最多?
过程数目最多?
5、组织结构:
着重了解各种组织结构的特点，重点是矩阵型。
6、目标管理、领导与管理:
掌握一些基本概念
PMP学习笔记之二—项目综合管理与项目范围管理
一、项目综合管理:
三个主要文件:
项目章程（whether是否要做）、初步项目范围说明书（what做什么）、项目管理计划（how怎么做）
l项目章程:
正式批准项目的文件
授权PM在项目活动中动用组织资源
一般由项目发起人赞助人签发，或者由项目之外的领导签发
项目选择方法:
收益衡量法、数学模型法。
收益衡量法:
掌握几个概念:
回收期、收益成本比率、净现值、内部回收率
l初步项目范围说明书:
记录和界定项目及其产品与服务的边界及特
征，及验收与范围控制的方法。
可以认为是项目范围说明书的初稿，在范围
定义时，由项目团队细化为项目范围说明书
l项目管理计划:
定义、综合、协调所有项目管理子计划，以形成项目
管理计划，由项目管理团队制定，包含的内容很多。
l变更控制委员会（CCB）:
正式成立的一个项目干系人组织，负责审
议、评价、批准、推迟或否决项目基准的变更
主要包括3部分:
Paperwork书面文件、Aprovelevel审批层次、Tracking
system跟踪系统
原则:
紧急情况下，变更可由PM决定，不经过CCB，但一定要有记录。
二、范围管理:
l定义:
确认项目包括成功完成项目所需的全部工作，但又只包括必须
完成的工作的各个过程。
产品范围:
产品、服务或成果的特征与功能
是否完成以产品要求作为衡量标准
项目范围:
为提供具有规定特征与功能的产品、服务或成果面需要完成的工作。
是否完成以项目管理计划、项目范围说明书、WBS为衡量标准。
包括五个子过程:
范围规划、范围定义、制作WBS、范围核实、范围控制。
两个主要项目文件:
项目范围说明书、WBS
l重点:
WBS
WBS:
面向可交付成果的对项目工作的层次化分解。
百分百原则:
WBS覆盖项目所有范围。
下一层必须百分百表示上一层元素的工作
WBS元素应该是名词还是动词,以产品纬度还是项目工作纬度,还是其它纬度分解,
没有固定。
三、总结:
在学习时，与目前工作中的相关项目文件作了对比。
感觉PMBOK是高度抽象，它从过程和领域两个维度对项目工作作了分解。
1、项目章程:
PMBOK中，从过程纬度，从最初的商务分析，一直到确定项目要做，此为一分界点，输出为项目章程，然后是初步项目范围说明书。
实际中，我们在启动阶段，一般有两个文件:
项目建议书，立项书。
前者侧重于项目的商业和市场分析，后者包括项目初步范围、初步组织等。
实际上是将商业分析单独出来，将项目章程与范围说明书合为立项书。
2、项目管理计划:
实际中一般会根据项目性质进行裁减。
我们常将将项目进度计划称为项目计划，实际上在PMBOK，项目管理计划，
除了项目进度管理计划，还包括它其领域的相应管理计划。
3、WBS:
实际中，一般将WBS与进度活动一起，形成进度表，录入项目管理软件中，
形成甘特图，进行跟踪。
没有必要过于区分WBS和活动，一般是要考虑的是进度
活动细到什么程度。
PMP学习笔试之三—项目进度管理和成本管理
PMBO上翻译为项目时间管理和费用管理，感觉还是用进度管理和成本管理较妥切，大家已习惯这样叫了。
1、项目进度管理:
本节术语较多、涉及的工具&技术也不少。
主要包括活动定义、活动排序、活动资源估算、活动历时估算、进度制定、进度控制6个子过程。
1.1活动定义:
就是对WBS的进一步分解。
将WBS的工作包分解为更小的部分-进度活动
1.2活动排序:
两种项目进度网络图:
前导图（PDM）、箭线图（ADM）
前导图可表示四依赖关系:
FS、SS、FF、SF，箭线图只表示一种依赖关系:
FS
两个术语:
提前与滞后
1.3活动资源估算:
确定要使用何种资源、数量，及何时使用，该过程与成本估算紧密配合。
1.4活动历时估算:
也就是我们常说的工作量估算。
四种工具与技术:
专家判断
类比估算
参数估算
三点估算（PERT法）:
要重点掌握:
三点估算方法、正态分布计算。
1.5进度制定:
关键路径法（CPM）:
是项目整个路径中最长的路径，是项目完成的最短时间
关键路径可以有多个，但是越多，项目风险越大。
向关键路径要时间，向非关键路径要资源
掌握相关的术语:
浮动时间、
进度压缩两种方法:
赶工、快速跟进
书中还提到一种关键链法，是考虑了缓冲时间。
预留一个总缓冲时间。
2、项目成本管理:
3个过程:
成本估算、成本预算、成本控制。
2（1成本估算:
估算完成每项进度活动的所需的资源的近似费用。
之前的过程是活动资源估算。
启动阶段，粗略估算，估算范围为-50%-+100%
项目后期，估算精度能缩小至-10%-+15%
成本估算工具:
类比估算法、自下而上（基于WBS）、参数估算、储备金
分析
估算类型:
粗略量级估算（启动阶段）-50%-+100%
量级估算（概念阶段、可行性调研，大约的）-25%-+75%
预算估算（计划编制阶段，项目的批准）-10%-+25%
确定性估算（计划编阶段，基准）-5%-+10%
2（2成本预算:
将单个进度活动或工作包的估算成本汇总，以确立测量项目绩效的总体成本基准。
之前的过程是成本估算。
成本估算与成本预算的区别:
成本估算是一个数值，成本预算是一条线，输出的是成本基线，成本基准可以有多个。
估算是项目团队做的，预算需要管理层参与，加一种储备金，叫管理储备。
2（3成本控制:
重点是挣值/实现价值技术，需要掌握。
PV、EV、AC，CV、SV、CPI、SPI等概念。
总结:
进度管理中，实际中，一大堆的网络图和概念都不用过于记忆，一般的软件工具都支持了。
主要是细化好项目的活动、工作量估算，对于软件开发，工作量估算一直是软件开发中较头痛，专家+经验，是最常用的了。
然后就是时间安排。
需要注意的是，一定要确保单点任务，即每项活动必须落实到一个人头上。
对于研发型组织的项目经理，一般较少涉及成本管理，项目经理主要关注范围、进度、资源、质量等。
挣值技术在研发型组织中基本用不上，但还是要认真了解下，可以作为参考。
PMP学习笔试之四—项目质量管理、人力资源管理、沟通管理1、项目质量管理:
1.1质量的定义:
内在系统特性满足要求和程度
质量与等级的区别
了解现代质量管理中几个代表人:
舒瓦特:
统计质量控制之父，控制图的发明者
戴明:
PDCA循环，85%责任在管理层，15%责任在团队
朱兰:
质量三部曲
克劳斯比crosby:
零缺陷
田口宏一:
质量是设计出来的，而非检查出来的
1.2包括3个过程:
质量规划、质量保证、质量控制
质量规划的输出:
质量管理计划
质量保证:
确保遵守相关过程，不关心具体的成果。
可以给大家提供信心
质量控制:
监视结果是否符合要求。
质量控制的工具:
质量7工具:
因果图、控制图、流程图、直方图、帕累托图、趋势图、散点图
了解每种图的特点和主要用处。
2、项目人力资源管理:
2.1包含四个子过程:
人力资源计划、项目团队组建、项目团队建设、项目团队管理。
重点掌握:
项目团队组建和项目团队建设的工具&技术:
项目团队组建的工具&技术:
预选分派、谈判、招募、虚拟团队
项目团队建设的工具&技术:
通用管理技能、培训、团队建设活动、规则、集中办公、奖励与表彰
项目团队建设评估的指标有:
技能的提升、能力和情感的的提升、团队成员流动性降低
2.2领导风格、权力类型
冲突解决技巧:
了解5种解决方法（妥协、面对、缓和、强制、撤退）的区别
2.3补充知识:
马斯洛需求层次，赫茨伯格的卫生理论，麦克哥雷格的X、Y理论，威廉大内的Z理论，
亚当斯的公平理论，维克托维如姆的期望理论，浩罗效应
3、项目沟通管理:
项目经理75%-90%花在沟通上
包含四个子过程:
沟通计划、信息发布、绩效报告、项目干系人管理
3.1沟通计划:
确定项目干系人的信息与沟通需求
沟通渠道数:
N（N-1）/2
沟通类型:
书面:
正式、非正式
语言:
正式、非正式
非语言
人际沟通:
7%靠语言表达，38%取决于语调和声音，55%靠肢体语言
3.2信息发布:
及时将需要的信息发送给项目干系人
工具:
信息发布系统
3.3绩效报告:
收集所有基准数据，并向项目干系人提供所有绩效信息。
包括:
状况报告
进度报告
预测
一般应提供有关范围、进度、成本与质量的信息，必要时还包括风险与采购的信息
工具:
EVM
3.4项目干系人管理:
对沟通进行管理，以满足项目干系人的需求并与项目干系人一起解决问题。
面对面会议是最有的沟通手段。
4、总结:
质量是每个人都要关心，首先要管理层重视，这样才会在流程和资源上给予保证。
应该从开始的设计、到开发、测试，整个过程都要重视，过程决定质量。
质量管理是一门单独的学科，要掌握更多的相关知识，需要根据行业，了解更多。
人力资源管理:
团队建设、是PM必须具备的。
这一项，属于软能力较多，我想最重要的你要关心团队成员，尊重个人发展。
沟通管理:
沟通也是要管理的。
对于PM，重点不是我们说的人际交往的一些沟通技巧，而是要对沟通进行管理，包括识别所有的项目干系人以及不同干系人的不同信息需求，制定相应的沟通计划等。
PMP学习笔试之五—项目风险管理、采购管理
1、项目风险管理:
项目风险:
一种不确定的事件或状况
包含6个子过程:
风险管理计划、风险识别、风险定性分析、风险定量分析、风险应对计划、风险监控
1.1风险管理计划:
决定如何进行项目风险管理活动的过程。
之前要做的是范围定义。
1.2风险识别:
确定哪些风险会影响影响项目，并将其特性记载成文。
输出是风险登记册。
重点掌握相关的工具&技术:
文件审查、信息收集技术、核对表分析、假设分析、图解技术
信息收集技术:
集思广益法、Delphi法、访谈法、根本原因识别（鱼骨图）、SWOT分析
1.3风险定性分析:
确定风险的重要性，排优先次序
工具&技术:
概率/影响矩阵（PI矩阵）
1.4风险定量分析:
从数量上分析已识别的风险对项目目标的影响大小，分析详细的概率和后果，以数字
说明。
重点掌握工具&技术:
龙卷风图、决策树、蒙特卡罗模拟。
1.5风险应对计划:
为项目目标增加实现机会、减少失败威胁而制定方案，决定应采取对策的过程。
风险效用函数:
风险反感者、冒险者、中立者。
PMI建议理性偏冒险
消极风险或威胁的对策略:
回避、转嫁、减轻
积极风险或机会的应对策略:
开拓、分享、提高
威胁和机会的应对策略:
主动接受、被动接受
应急应对策略:
应急储备、管理储备
残留风险与次生风险
1.6风险监控:
包括:
识别新生风险、重新分析现有风险、监测应急计划的触发条件、监测残余风险、
审查风险应对评估其效力。
权变计划:
对以往未识别或被动接受的风险采取的示经计划的应对措施。
是应对措施，而不是计划
2、项目采购管理:
包括5个子过程:
采购计划、发包计划、卖方应答（询价）、卖方选择、合同管理、合同收尾
2.1采购规划:
确定买什么，不买什么，购买还是自制。
之前的过程是范围定义
工具&技术:
自制或购买分析
合同类型:
按卖方风险高到低排序:
固定总价、固定总价加奖励费、成本加奖励、成本加固定费、成本加成本百分比
对买方的风险则反之。
掌握每种合同类型的特点
还有一种工料合同，即时间与材料合同:
与成本补偿合同类似，同属敞口合同。
2.2发包规划:
对确定要购买项形成相应的要求。
为以下两个过程:
卖方应答和选择卖方做书面准备
2.3卖方应答:
从预期的卖方那里得到如何项目需求的应答，实际工作通常由卖方完成，买方通常
无须支付任何费用。
输出是合格卖方清单，即短名单。
2.4卖方选择:
确定最终卖方
了解下相应的工具&技术:
加权系统、独立估算、筛选系统、合同谈判
2.5合同管理:
双方确保本身与以坟者发行其合同义务，并确保自身的合法权利得到保障。
了解下相关的工具&技术:
合同变更控制系统、索赔管理
输出:
合同文件
2.6合同收尾:
完成与结算合同的过程，包括解决所有遗留问题并结束每一份合同。
2.7与合同相关的一些术语:
仲裁arbitration、终止termination、保函bonds、违约breach、弃权waiver
3、总结:
实际项目中，项目风险管理一般都有涉及，但PMBOK中讲的方法，有点偏理论化，实际中，风险识别、分析主要靠过去历史经验、以及大家头脑风暴分析多些。
采购管理，工作中较少涉及。
但章节中对于采购中每个子过程的输入输出，还是可以参考。
浅谈项目管理中的沟通
通对象，需要的信息，信息发布频率等都要确定好;
3、执行沟通计划。
看上去，很简单，每个项目都可以依此模式套用，但实际上很多项目在执行中都会出现沟通问题，
我认为大部分情况下是项目经理犯有沟通障碍症，主要有以下几类:
1、“我以为”的错误:
以为沟通过，别人就清楚了，以为没有反馈就是没有意见了。
特别是跨部门的沟通，无论是口头还是书面，更是要注意双方是否理解一致。
2、不敢越级沟通，不敢与高层直接沟通:
不少公司的项目经理在职能上，一般比部门经理要低，所以经常出现项目经理不敢直接找高层或其它部门总经理沟通，都要上级职能经理的协助，
我认为这是需要改进的，当然，这与企业文化也有一定关系，但在一个以目标驱动，强调解决问题的组织，没有人会反对这样做，包括你的上级。
特别是对跨部门的较为得杂项目中，项目经理要敢于“管理”公司高层，就项目问
题也高层进行直接沟通。
可能有部分项目经理是担心不知如何与高层沟通，，因为高层的思维是较发散和概要的，如果你下谈解决方案等细节问题，估计很难交流，这里也要求项目经理要对问题有很好的抽象归类能力。
3、害怕被拒绝:
这是人的本性。
如果在销售岗位，估计有专门针对的培训。
在项目推进中，经常出现这样的情况，你可以有一些想法建议，要么思考很久才敢提出来，
不要不敢与项目干系人提出，白白延误了好时机，或者需要其它部门协助时，不敢提出来。
4、没有提前计划沟通活动，造成等人局面:
经常出现这样的时候，要确定某个事项，需要个负责人参加，但因为没有提前计划，到时约不到人，结果推迟等待，无谓的增长滞后时间。
实际上，对于难度较大问题，至少要提前两周计划好，预约好相关人员。
5、欠缺适当的沟通技巧:
我们不是管理专家，不用在沟通技巧中耗费太多时间，掌握一些适当的沟通技巧，是主要是对人对事的敏感度，
能针对具体事情判断是单独沟通、书面沟通、口头沟通更有效，还是需要适当借力。
能达到这个层次就可以了。
我认为沟通中
最重要的不是技巧，而是你的真诚。
如果你能与沟通对象建立信任关系，就是沟通的最高境界了。
沟通对于项目的成功是相当关键的，但同时又是容易被大家不够重视的，作为项目经理，做好沟通管理是基本的要求。
Kintana——Mercury的变更管理工具
转自平凡岁月blog
Kintana是Mercury的变更管理工具
整个流程中涉及到的角色有:
IT经理，项目经理，业务专家，开发人员，QA经理，自动化测试工程师。
具体流程，所有涉及到的角色，都用红色标注:
1、业务专家首先在Kintana中提出变更的需求，并且将变更的细节作为附件。
Kintana将为这个变更的需求分配一个ID，这个唯一的ID将是整个变更流程的唯一的跟踪点。
2、Kintana将这个变更的需求加入到IT经理的工作列表中，然后通知IT经理。
3、IT经理评审变更的需求，并同意。
4、Kintana将批准的变更需求加入到项目经理的工作列表中，然后通知项目经理。
5、项目经理将该任务分配给开发人员。
6、Kintana将任务加入到开发人员的列表中，然后通知开发人员。
7、开发人员根据任务和附件，进行设计。
与此同时，在Kintana中，QA的工作流也开始了。
8、Kintana发送一封电子邮件给QA经理，电子邮件中包含创建测试需求的链接9、QA经理根据链接在QC内创建测试需求，并且将测试需求的状态更改为Reviewed
10、Kintana发送一封电子邮件给QA经理，电子邮件中包含创建测试用例的链接。
11、QA经理根据链接在QC内创建测试用例，并且其状态为“Completed”12、与此同时，在设计被批准之后，开发人员开始进行编码工作，并且将应用部署到测试环境中。
13、当应用系统被部署到测试环境后，Kintana发送一封电子邮件给自动化测试工程师，其中包括建立测试集的链接。
14、当QA经理将评审过新建立的测试集后，将其状态置为“Reviewed”。
15、执行测试，将结果写回到QC中。
16、所有的缺陷都和在Kintana中产生的ID想关联。
缺陷的整个生命周期在QC内完成。
17、QA经理标识整个测试阶段完成。
18、Kintana通知IT经理，IT经理批准发布。
需求管理思想
一、前言
在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。
在软件项目管理过程中，项目经理经常面对用户的需求变更。
如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。
这决定了项目组必须拥有需求管理策略。
二、需求管理复杂性分析
软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面:
1、需求的描述问题。
缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。
在用户方进行的需求评审会完全是走形式，因
为用户根本不去听他读那上百页的需求文档。
不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。
需求如何做到没有遗漏,如何准确划定系统的范围,这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。
即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。
3、需求开发的工期问题。
在需求上花费了大量的时间，客户、软件公司是否能够忍受,为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已～他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。
4、需求的细致程度问题。
需求到底描述到多细，才算可以结束了,仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。
但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。
5、需求的变化问题。
在软件开发过程中如果只有一条真理的话，那一定是:
需求的变化是永恒的，需求不可能是完备的。
软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多，如:
一开始没有识别全，需要增加需求;
业务发生了变化，需求必须变化;
需求错误;
需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办,管理它～使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。
难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（ProjectScopeCreep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
三、需求管理策略
需求管理需要遵守以下策略:
1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。
人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。
但是，接受需求变更目前却是软件开发商不得不咽下的苦果。
所以，在项目的开始无论是开发方还是出资方都要明确这一条:
需求变，软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更
有成本的概念，能够慎重地对待需求的变更。
笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程，否则会积少成多。
在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。
正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。
太细的需求定义对需求渐变没有任何效果。
因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。
注意沟通的技巧。
实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的
升级会员 