赞
踩
项目管理概述:
解题技巧:
解题技巧:
解题技巧:
1.只要是项目的相关方,都可提出变更请求,除非相关方无作用力否则不能直接拒绝。
2.变更请求可以以书面和口头方式提出,但口头提出后需补书面记录。
3.变更请求通过变更控制程序处理。
4.所有的变更请求提出后,都需要相应的责任人批准或否决。
5.基准变更后,以前的基准需要保存。
6.不是所有变更都需要经过CCB,只有涉及基准变更的才会交付CCB审核处理,一般的变更PM即可处理,特殊、紧急的涉及基准的可不通过CCB由PM紧急处理。
解题技巧:
解题技巧:
净现值(NPV):是反映投资方案在计算期内获利能力的动态评价指标。
投资方案的净现值是指用一个预定的基准收益率(或设定的折现率)i,分别把整个计算期间内各年所发生的净现金流量都折现到投资方案开始实施时的现值之和。
动态指标:
静态指标:
计划评审技术(三点估算PERT)其概念如下:
计算公式:
公式 | 描述 |
---|---|
![]() | Te为时间期望值;O为最乐观时间;M为最可能时间;P为最悲观时间; |
![]() | δte为(单个活动)期望时间的标准差;目的:为每一项活动和关键路径设置一个置信区间 |
PMP考试中,默认是贝塔(β)分布!
解题要点:
沟通渠道的数量= n(n-1)/2,其中n代表干系人的数量
这类题目比较简单,但是答题过程中要看清题目问什么,是问沟通渠道总共有多少条,还是增加到了或增加了多少条。
如果题目中单独提到了项目经理,分析n是否包括项目经理。
期望货币值(EMV):
风险值(EMV)与决策树一起使用,综合考虑了概率与影响两方面的因素
合同计算相关概念:
合同成本计算公式:
描述:
① 总价合同 —— 固定总价合同(FFP)
举例:
合同价格:$1,1000K
- 实际成本$800K,则卖方获取的利润=$1,000K-$800K
- 实际成本$1,200K,则卖方损失 =$1,200K-$1,000K
② 总价合同 —— 总价加激励费用合同(FPIF)
举例:
目标成本:$1000K ,目标费用: $100K
封顶价格:$1300K ,分享比例:70/30(买方70%,买方30%)
- 实际成本$800K , 则:合同价格 = $800K + $100K + $200K x 0.3
- 实际成本$1500K , 则:合同价格 = $1300K
- 实际成本$1200K , 则:合同价格 = $1200K + $100K - $200k x 0.3
③ 总价合同 —— 总价加经济价格调整合同(FPEPA)
① 成本补偿合同 —— 成本加固定费用合同(CPFF)
举例:
目标成本:$1000K 百分比:10%($100K),预计总价:$1100K
- 实际成本 $800K,则合同价格 = $800K+$100K
- 实际成本 $1200K, 则合同价格 = $1200K+$100K
② 成本补偿合同 —— 成本加激励费用合同(CPIF)
举例:
目标成本:$1000K , 目标费用:$100K,分享比例:70/30(买方70,卖方30)
1)实际成本$900K,则合同价格 = $900 + $100k + $100K x 0.3
2) 实际成本$1100K,则合同价格 = $1100k + $100k -$100k x 0.3
③ 成本补偿合同 —— 成本加奖励费用(CPAF)
基本概念:
公式(记忆点:EV
在上):
公式 | 描述 |
---|---|
进度偏差 SV = EV - PV | SV>0进度提前;SV<0进度落后。项目完工时,全部的计划价值都将实现(即成为挣值),所以进度偏差终将等于0。即当工作范围不变的情况下,完工时EV=PV=BAC |
成本偏差 CV = EV - AC | CV>0 预算节约,CV<0预算超支 |
进度绩效指数 SPI = EV /PV | SPI>1是好的,SPI<1是不好的,SPI测量的是项目总工作量,所以还需要对关键路径上的绩效进行单独分析,以确认项目是否将比计划完成日期提早或延迟完工 |
成本绩效指数 CPI = EV /AC | CPI>1是好的,CPI<1是不好的,CPI不需要对关键路径上的绩效进行分析 |
趋势分析ETC
:
ETC = BAC - EV
):预计未来的全部ETC工作都将按预算单价完成。特殊的/非典型的/仅此一次假设ETC = (BAC-EV)/CPI
,考试默认此公式):假设项目将按截至目前的情况继续进行,即ETC工作将按项目截至目前的累计成本绩效指数(CPI)实施。ETC = (BAC-EV)/(CPI*SPI)
):成本、进度绩效都不理想,而又要求必须按期完工。CPI*SPI的结果又称为“关键比率”,用来考核成本与进度的总和绩效。完工估算EAC:
EAC = AC+ETC
EAC = AC+BAC-EV
:按预算单价完成ETC工作,特殊的/非典型的EAC = BAC/CPI
典型的,以当前CPI完成完工尚需绩效指数TCPI:
TCPI=(BAC-EV)/(BAC-AC)
TCPI
= 剩余工作需要的钱/剩余实际的钱数TCPI=(BAC-EV)/(EAC-AC)
如果总时差为负,说明进度已经延期或者管理层有强制完工日期,需要进度压缩。
方位 | 定义 | 姓名 |
---|---|---|
上方 | 发起人、企业高层 | 如来、观音 |
下方 | 团队成员 | 孙、猪、沙、白 |
前方 | 提供帮助和支持的人、如专家等 | 山神、土地 |
后方 | 内部相关方,职能部门,其它项目人员等 | 各路神仙 |
左方 | 外部相关方,包括客户、供应商、政府部门、行业协会、竞争对手等 | 大唐皇帝、各方妖怪 |
右方 | 进行监督检查审计验收的相关方 | 如来 |
方格模型:权力利益方格(职权大小)、权力影响方格(参与意愿)、影响作用方格(改变项目的能力)等。
相关方立方体:方格模型的改良,用于将权力、作用、影响、利益等形成多个实体,以全面分析相关方的重要性。
凸显模型:评估相关方的权力、紧迫性(时间紧急),合法性(相当于作用),适用于复杂的项目。
影响方向:将相关方的影响力按向上(高层)、向下(团队、临时)、向外(组织外)、横向等维度进行分类。
优先级排序: 如果存在大量相关方,相关方的成员频繁变化或相关方之间关系复杂,则需要对相关方进行合理的优先级排序。
权力利益方格图:
相关方立方体图:
凸显模型图:
将相关方当前参与水平与期望参与水平进行比较,对相关方参与水平进行分类,并策划如何把他们的参与程度提高到项目需要的程度。
例1:风险中串了变更,在风险发生后,更新了风险登记册,然后分析风险,接下来提交变更请求,这个时候大家就又糊涂了,不是先记录再分析吗,这里怎么变更先分析再记录了,原因是此分析非彼分析,这里的分析是在分析风险,分析完了制定措施的时候可能进入变更流程,当进入变更流程后还是(记录变更请求-分析变更-批准变更-执行),也就是还是记录在前分析现后;
例2:问题中串了变更,问题发生,定义问题(含记录)-分析问题-解决方案,在此时可能会出现变更,这个时候又是分析在变更前,但是人家分析的是问题而不是变更,进入变更流程后,还是(记录变更请求-分析变更-批准变更-执行),也就是还是记录在前分析现后;
原则1:风险发生成为问题,先更新风险登记册,再更新问题日志,再走变更流程
原则2:题干讲风险,走风险管理流程
原则3:题干讲问题,走问题解决流程
原则4:题干讲变更,走变更管理流程
风险管理流程:
问题解决流程:
变更管理流程:
审计:
质量审计 | 风险审计 | 采购审计 |
---|---|---|
审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展,如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。 | 风险审计是一种审计类型,可用于评估风险管理过程的有效性。项目经理负责确 保按项目风险管理计划所规定的频率开展风险审计。风险审计可以在日常项目审查会上开展,可以在风险审查会上开展,团队也可以召开专门的风险审计会。在实施审计前,应明确定义风险审计的程序和目标。 | 审计是对采购过程的结构化审查。应该在采购合同中明确规定与审计有关的权利和义务。买方的项目经理和卖方的项目经理都应该关注审计结果,以便对项目进行必要调整。 |
看到以上三个审计的红字部分描述,你会发现审计关注的是过程,而不是结果。换句话说,审计不关注你的产品、成果、目标做的好坏,而是关注你通过什么样的流程、方法、过程来实现这些产品、成果、目标,如果组织已经设置好相应得流程、程序,那么审计就检查你是否遵守了这些流程、程序。所以审计更强调的是合规性。
检查:
验收检查 | 质量检查 | 采购检查 |
---|---|---|
检查是指开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。在某些应用领域,这些术语具有独特和具体的含义。 | 检查是指检验工作产品,以确定是否符合书面标准。检查的结果通常包括相关的测量数据。检查可在任何层面上进行。可以检查单个活动的成果,也可以检查项目的最终产品。检查也可称为审查、同行审查、审计或巡检。在某些应用领域,这些术语的含义比较狭窄和具体。检查也可用于核实缺陷补救。 | 检查是指对承包商正在执行的工作进行结构化审查,可能涉及对可交付成果的简单审查,或对工作本身的实地审查。在施工、工程和基础设施建设项目中,检查包括买方和承包商联合巡检现场, 以确保双方对正在进行的工作有共同的认识 |
在这里,通过红字部分我们可以了解到检查和审计正好相反,检查针对的是成果、产品、目标。检查不关心你如何得到这些成果、产品,不关心你的流程、政策,只关系你的成果、产品是否符合标准和要求,这些检查主要在于产品、成果的正确性,以便得到用户的认可。
敏捷(适应型生命周期)是指采用迭代或增量的方式开发项目产品,在需求不明确的情况下,主动快速的响应变化的一种开发方式
价值1:个体和交互胜于流程和工具
价值2:可工作的软件胜过面面俱到的文档
价值3:客户合作胜于合同谈判
价值4:响应变化胜于遵循计划
原则1:我们的首要任务是通过早期和持续交付有价值的软件来满足客户
• 要点:客户满意、有价值、持续交付
原则2:欢迎变更,即使到了开发后期,利用需求变更为客户获得竞争优势
• 要点:持续拥抱变更、保持灵活性以随时适应变化
原则3:经常交付可工作的软件,几周到几个月不等,时间间隔越短越好
• 要点:经常交付、尽早交付、越快越好(1-4周)、消除“惊讶”
原则4:业务人员和开发人员必须自始至终共同完成项目的日常工作
• 要点:业务与开发全程合作、团队与客户需要彼此理解
原则5:由被激励的个体去完成项目。给予需要的支持和环境,相信他们能够完成工作
• 要点:激励、支持,个体比流程更重要
原则6:面对面地交谈是开发团队中最有效的信息交流方式
• 要点:交互式沟通、文档代替不了交谈
原则7:可工作软件是项目进展状况的主要度量
• 要点:度量标准、目标导向、可工作的软件
原则8:提倡可持续的开发。发起人、开发人员和用户应该始终保持步调稳定
• 要点:可持续开发、稳定的速度、不透支明天的精力
原则9:对卓越技术和良好设计的持续关注有助于提高项目的敏捷性
• 要点:保持设计的清晰、高效和变更的灵活性、重构以加强根基
原则10:追求极简化,尽量减少不必要的工作
• 要点:轻文档,轻流程,重产出,重目标(MVP)
原则11:最好的架构、需求和设计都源于自组织的团队
• 要点:共同的目标,共同承担责任,共同解决问题
原则12:团队定期反映如何提高工作效率,然后相应地调整其行为
• 要点:不断学习、持续改进、反思与调整、回顾会议
3个角色:
Product Owner
)Scrum Master
)Scrum Team
)3个工件:
Product Backlog
)Sprint Backlog
)Burn-down Chart
)4个仪式:
Sprint Planning Meeting
)Daily Meeting
)Sprint Review Meeting
)Sprint Retrospective Meeting
)5个价值观:
产品负责人 (Product Owner)
Product Owner的核心工作对团队对外交付的价值负责,是PB列表的唯一责任人。
• 清晰的表述产品待办列表项、确保团队成员清晰理解
• 定义需求及需求优先级、验收标准、确保需求的价值
• 定义产品发布内容与日期
• 客户不能直接对PB进行排序,只能提供输入
• PO可以直接拒绝团队的可交付成果
• 如遇到干系人要增加需求,先由PO来判断价值,不能由团队直接决定做不做
敏捷教练(Scrum Master)
Scrum Master的核心工作是帮助团队遵循Scrum 框架,扫除障碍,提供帮助与支持 。
• 清除障碍,仆人式的领导
• 团队出现问题与冲突,先团队自组织的解决
• 团队士气低落,SM要去激励团队,此时无法靠自组织
• 保护团队免受外界打扰
• 客户、高层等对敏捷文化、原则误解,需要SM来进行宣导,告知价值的正确性
团队(Scrum Team)
Scrum team 对交付成果负责,在每个 Sprint 结束时交付潜在可发布且“完成”的产品增量。
• 自组织团队,不认可任何头衔,特征符合塔克曼团队发展阶梯模型
• 团队首先要敏捷(5-9人),没有子团队、人多建议分解
• 团队自己决定做什么、做估算,不是由PO或者SM来进行分配或估算
• 质量保证的工作是由团队来做,不是靠PO频繁的检查
• 当团队发现一个好方法的时候,SM引导,然后由团队来决定是否采纳
• 如果团队士气低下,则不能依靠自组织,需要SM的介入
• 拥有解决全部问题的所有技能,SM要培养团队跨职能技能
产品待办事项 (Product Backlog)
Product Backlog即产品视角的完整需求清单。
• PO是唯一负责人,包括增删及优先级。
• 用户故事是其中一种最佳实践。
• 每项需求都需要描述其外部价值,并用用户语言加以描述。
• 遇到新需求都要放到PB表中重新排序。
Sprint 待办事项 (Sprint Backlog)
Sprint Backlog即此次迭代周期内规划要完成的内容。
• 来源于Product Backlog。
• 由团队评估和选择Product Backlog中哪些放入Sprint Backlog。
• 团队需要一起定义“完成”的标准。
• 每个团队成员都可以更改Sprint Backlog,是团队的资产。
燃尽图( Burn-down Chart)
Burn down Chart 显示了Sprint中累积剩余的工作量,是一个反映工作量完成状况的趋势图。
• Sprint开始的时候,团队会定义当前迭代的全部任务。
• 每天结束时,剩余任务会减少。
• 最后一天结束,累积剩余工作是为0,迭代结束。
燃起图( Burn-up Chart)
Burn up Chart展现项目时间与已完成的工作之间的关系。
• 燃起图有助于展示团队的工作成果
• 可以区分不同角色展现工作量的完成状况。
• 可以度量项目的迭代速率和工作效率。
冲刺(Sprint )
冲刺或迭代是一个特殊的事件,或者说其一个容器事件,后续四个事件(仪式)包含在其中。
• 固定周期(2-4周),固定时间开始,固定时间结束
• 固定时间盒,如果有需求没做完的也不能延长时间交付
• 按优先级做事,每次交付的是有价值的产品
• 如果当前有一些工作无法完成,尽力按照高优先级的事项先做,等到回顾会再去梳理问的原因,在下一个迭代进行调整。
Sprint规划会 (Sprint Planning Meeting) 时间盒:2小时/周
Sprint规划会的核心议题是定义下一次冲刺要实现的目标和范围。
• 确定 Sprint的目标、工作方法、工作量。
• 对产品backlog 中 item 进行估算,以确定是否放入迭代周期。
• 对于需求不清楚的 item,请 Product Owner 说明。
• 输入是 Product backlog,输出是 Sprint backlog。
• Part1:需要做什么,产品负责人向开发团队介绍排好序的产品待办事项,由整个Scrum团队共同理解这些工作(PO\SM\TEAM)
• Part2:决定如何做,团队成员根据PB,确定产品增量,进行任务分解,并形成Sprint backlog(SM\TEAM)
每日站会 (Sprint Daily Standup) 15分钟/日
站会的目标是促进信息在团队内共享与透明。
• 从昨天的站立会到现在,我完成了什么;
• 从现在到明天的站立会,我计划完成什么;
• 有什么阻碍了我的进展。
• 阐述问题,但不讨论和解决(会后解决);
• 关于比较深远的问题,等到回顾会处理。
• 站会不是任何人汇报进度。它是一个开发团队内部的沟通会议,来保证信息共享透明。
Sprint 评审会 (Sprint Review) 时间盒:1小时/周
Sprint 评审会在冲刺末期召开,团队和相关人员一起评审Sprint的产出。
• 团队全体参与、邀请相关干系人参与
• PO可以拒绝接收成果,并对未来做出最终的决定
• sprint 评审会议的结果是一份修订后的PB,阐明很可能进入下个 Sprint 的产品待办列表项
Sprint 回顾会 (Sprint Retrospective ) 时间盒:1小时/周
团队一起复盘本次冲刺的过程,总结经验与教训,并形成切实可行的改进清单。
• 三个目的:做的好的,不好的,改进的措施(行动项)
• 回顾一下团队在流程、人际关系以及工具方面做得如何
• 关于团队过程中的问题,在此会议上解决
按需进度计划:又称拉动式进度计划,用于看板体系,基于制约理论和精益生产的理念安排计划。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。