1 变更请求包括纠正措施、预防措施、缺陷补救和更新。
其中更新是由于受内、外部因素影响，对项目管理计划或文件进行增加或修改。
2 供应商选择 可使用加权系统来定义选择标准。
- 加权系统针对不同的标准，可以用数值分数、颜色代码或书面描述，来说明卖方满足采购组织需求的程度。据此以加权打分的方法排列所有建议书的顺序，以便确定谈判的顺序，并与某个卖方签订合同。
3 加权系统：指把定性数据加以量化，以**减少个人偏见对供方选择影响**的方法。
多数加权系统包括：
- 1）对每项评估标准赋予一个数字加权值
- 2）为期望卖方评定每项评估标准的得分
- 3）把得分乘以加权值
- 4）把所有乘积相加，求出总的得分
4 项目启动会（Initiating meeting）vs 项目开工会（kick-off meeting）
项目启动会
项目启动会时间：项目启动结束召开 (规划阶段)项目启动会内容： 1项目章程，2任命项目经理，3标志项目开始
项目开工会
项目开工会时间：项目管理计划完成后，实施之前(规划阶段)项目开工会内容：1团队成员项目认识，2正式批复项目管理计划，相关方达成共识，3 落实项目具体工作，明确团队职责范围，执行前做准备
5 滚动式规划技术: 当项目可能无法分解的可采用滚动式规划技术。项目的特点：渐进明细，逐步清晰工作所有可交付物。
6 沟通渠道计算:
沟通渠道计算公式，潜在沟通渠道的总量为 n(n-1)/2，其中，n 代表干系人的数量。so 14个干系人 91个沟通渠道 14*13/2=91。
7 项目协调员 vs 项目联络员:
项目协调员: 向高层经理汇报工作，且拥有一定的决策权力。
项目联络员: 无权做决定。
8 范围蔓延
未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大
9 核实可交付成果 vs 验收可交付成果
核实可交付成果: 成果技术正确 验收可交付成果: 技术正确 + 满足相关方需求
10 质量审计 & 风险审计 & 采购审计 & 配置项核实与审计
- 质量审计: 项目活动是否遵循项目政策,过程,程序的结构化独立过程
- 风险审计:评价风险管理过程有效性的审计
- 采购审计:对合同和采购过程完整性,正确性,有效性进行审查
- 配置项核实与审计:通过配置核实与审计,确保1项目的配置项组成正确,2变更登记,评估,批准,确保配置文件规定功能要求实现
11 里程碑 & 里程碑清单
- 里程碑：项目中重要的时点或事件
- 里程碑清单：列出项目中所有的里程碑，指明里程碑是强制性（合同要求）及可选的（历史信息确定），里程碑持续时间为零，应因为其代表一个重要时间或事件。
12 三重约束
- 三重约束：是一种实用的方法，范围、成本和时间方面的权衡是项目管理的重要组成部分，并在最终确定项目成功方面发挥核心作用。
13 项目管理信息系统
整合管理 - 指导与管理项目工作的工具
进度管理 - 排列活动顺序工具
资源管理 - 估算活动资源 / 管理团队工具
沟通管理 - 管理沟通 / 监督沟通工具
- 1 含采购管理，记录采购管理系统
- 2 含配置管理系统
- 记载产品特性组成
- 变更实施
- 核实产品服务是否符合标准
- 3 含变更管理系统 ：跟踪变更控制活动及审批情况 指导与管理项目工作 的 工具
- 1 变更管理系统: 负责变更的系统(明确ccb角色职责)
- 2 配置管理系统: 收集正式文件(识别产品, 记录变更)
- 3 项目管理信息系统: 记录管理系统(含采购)
- 4 项目管理系统: 包含变更 记录
项目管理系统: 制定进度计划，
项目管理信息系统: 收集需求, 排列活动顺序，控制进度，估算成本 成本控制 估算活动资源 管理团队 控制资源 实施风险应对
14 项目特征
- 临时性 独特性 渐进明细
15 名次解释
- sow: 采购工作说明书
- 测试驱动开发TDD（Test-Driving Development）/ 行为驱动开发 BDD（Behavior-Driving Development）/ 验收测试驱动开发 ATDD
- WIP（Work in Process）在制品限制，拉动式生产
- MVP（Minimum Viable Product - 最小可行产品）
- 冲刺映射: 冲刺阶段会映射在时间表上
相关敏捷名词解释 zhuanlan.zhihu.com/p/652641765
16 敏捷的 "速度"
- 速度，一次固定迭代中团队可交付的需求数或用户故事数。
- 速度，速度是每个迭代中对团队能力的度量，帮助我们基于上一个迭代完成的故事点数量评估团队后续的工作能力。与特性无关。
- 敏捷项目速度一般不轻易改变。
17 敏捷的 "周期时间"
- 周期时间，实际花费在工作项目上的时间总和（不包括等待时间）。当任务进入“工作”栏时，周期时间就会被度量。
18 Disc性格模型 (敏捷方法)
Disc性格模型将人的性格分为四种典型,分别是支配型,影响型,稳健型以及谨慎型。
支配型(Dominance),喜欢主宰或支配他人,占据主导地位,如西游中孙悟空、三国中吕布、张飞等。
影响型(Influence),性格外向,喜欢展现自我,如西游中八戒、水浒中潘金莲。
稳健型(Steadiness),做事沉稳,足够耐心,不容易情绪化,如西游中沙僧、三国鲁肃。
谨慎型(Compliance),服从、遵守规则、追求精准,谨小慎微,如唐僧、诸葛亮、林冲等人。
19 MoSCoW (敏捷方法)
MoSCoW技术来进行需求排序的敏捷方法。
在这种技术下，需求基于以下方面排序：
• Must必须有-这些需求是强制性的
• Should应该有-这些需求不是强制性的，但是高度渴望的
• Could可以有-这些需求如果满足会很好
• Won’t不会有-当下可以不去满足，但是将来可以加入
在开始新一轮时间箱前，会有一个新的MUSTs加入。这些可能是新的需求，或者现有需求被调整优先级进而转移成为MUSTs
20 SAFe (规模化敏捷框架)
(Scaled Agile FrameWork, SAFe) SAFe基础构造块,带来精益敏捷领导力
21 结对编程
结对编程 的结对是指程序员只使用一台计算机，一名开发人员“驾驶”（敲代码），另一名开发人员观察。虽然这种方法最初听起来可能很耗时、没效率，甚至令人不爽，但成功的结对编程可能会更加高效，因为两个程序员一起工作通常会激发更好的问题解决能力，同时减少代码中的错误和错误。
22 正式权力、专家权力、参照性权力、奖励权力和惩罚权力
正式权力：也叫合法权力，是指由所在公司的高级管理层赋予的、在项目经理的职位描述中规定的上级对下级的权力。所谓的“在其位，谋其政”，是指来自职位的权力。一旦离开这个职位，正式权力也就不在了。项目经理的正式权力往往不足。
专家权力：是指作为技术专家或项目管理专家而产生的权力。专家具有很好的专业知识与技术，自然就能得到别人的尊重和自愿服从。例如，医生叫你吃哪一种药，你就会乖乖地吃这种药。获得PMP资格认证的人，就具有项目管理知识和技术方面的专家权力，在工作中自然更有威信。
参照性权力：是指个人的性格魅力，以至于别人愿意以你为参照物，以你为榜样。如果管理者举手投足间都散发出人格魅力，体现自己的内在素养、道德情操，就容易被下属成员接受、敬仰，成为成员的表率及模仿对象.
奖励权力：即奖励别人（通常是下属）的权力，通常与正式权力紧密相连。管理者需要根据下属的表现，及时给予奖励，以鼓励他们的良好行为。
惩罚权力：也叫强制权力，即惩罚别人（通常是下属）的权力，通常与正式权力紧密相连。当下属违抗命令或行为不符合要求时，管理者可以动用惩罚权力，以制止他们的不良行为。
在这五种权力中，专家权力和参照性权力来源于项目经理个人，是项目经理真正自己“挣得”的权力，依附于项目经理的人身。这两种权力都是基于别人自愿服从的。
正式权力、奖励权力和惩罚权力则来源于项目经理的职位，是高级管理层授予的权力，随时可以被剥夺。这三种权力都是由相关规章制度强制下属服从。
优秀的项目经理应该较多地运用专家权力、参照性权力和奖励权力，较少地运用正式权力，尽量不用惩罰权力。前三种权力，你用得越多，越能调动团队成员的积极性。
23 敏捷反馈流程
敏捷团队在评审会上收到反馈后，需要将需求添加到PB中，并由产品负责人排列优先级。(参见: 模拟1-175)
24 项目模型 ( 四种)
瀑布模型、迭代模型、增量模型、原型模型，是项目管理常见的四种模型。
一 瀑布模型
用瀑布模型做项目就像古代匠雕刻玉石，先有完整的设计图，然后按部就班往前推进，中间不能出一点差错，追求的是“一次成型”。
这就是瀑布模型，最基本也最常用的一种项目管理模型，又称线性模型。
采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作。 成果就是此项活动所产生的工作文档，以及在此基础上形成的产品。
瀑布模型最大的优点有两个：
- 每个阶段的开发质量都有保证，减少了返工。
- 是文档细致，降低了沟通成本，有利于及早发现问题。
但是这张图纸也有缺点，每一步都不可行差踏错，因为一旦雕坏了，就得摔了重来。
这也正是瀑布模型的缺点：周期长，不易变更。
用户直到项目开发晚期才能了解产品的真实面貌和质量。这时候提出变更，成本会非常大。
PS：适合采用瀑布模型的项目类型，通常是对用户需求非常明确的项目。同时还要求项目预算充足，人员齐备
二 .迭代模型
其实，迭代模型项目就是数个小而快的瀑布式项目组成的。
因为，每一次开发迭代都是一次完整地经过所有工作流程的过程： 需求、分析设计、实施和测试工作流程。
每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了四个活动：制定计划、风险分析、实施工程、客户评估。
使用迭代模型进行软件开发，项目活动包含以下几个阶段：
- 初始阶段为系统建立商业案例并确定项目的边界。
- 细化阶段细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
- 构造阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。
- 交付阶段交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。
迭代模型的风险管理成本较高，在风险分析，进度管理方面，对项目组成员的要求也非常高。
PS：选择迭代模型的项目，通常属于高风险项目，且需求不确定，用户能在整个开发过程中不同程度地参与。
三. 增量模型
增量模型是通过对用户需求的判断，在定义了用户要求和系统需求,进行总体构架设计后，采用序列化地创建产品的方法进行开发的过程。
增量模型本质上是迭代的，但其强调：每一个增量均发布一个可操作产品。
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。
增量模型三大优点：
- 在达到初始需求之前可降低成本。
- 可快速生产出可使用的系统。
- 能够有计划地管理技术风险。
四.原型模型
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发。
原型模型是一种用户需求驱动的方法。 它能减少系统开发的风险，特别是在大型项目的开发中,由于对项目需求的分析难以一次完成，应用原型法效果更为明显。
原型模型根据其最终保留情况分为非抛弃型和抛弃型两种：
非抛弃型原型： 先根据用户的最主要的要求，开发出能实现系统最基本功能的一个原型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到等到用户满意的最终系统为止。
抛弃型原型模型：一般用来描述和验证用户需求，可以采用与实际开发所不同的开发工具，建立模拟的数据库系统，从而达到与用户交流的最好效果。到用户需求确定之后即不再继续开发此原型。
原型模型适用的项目特点：
- 处理简单过程明确、涉及面窄的小型系统；
- 大型系统的需求阶段，用原型去跟用户交流，需求分析会更加明确和细化
针对不同类型的项目。应选择什么样的开发模型，应从实施推广的难度和项目管理的侧重点两方面进行慎重考虑：再结合这些特点，选择最适合项目的开发模型，就能起到事半功倍的效果。
各模型项目特点：
瀑布模型——文档驱动型
迭代模型——风险驱动型
增量模型——任务驱动型
原型模型——需求驱动型
25
26 合同选择汇总
目合同主要包括四大类，分别为总价合同、成本补偿合同、工料合同、单边合同。
一、总价合同 (工作范围明确, 买方成本风险低)
总价合同是对合同工作规定一个总价。在这种合同下，买方必须准确定义工作范围，只有工作范围很清楚的项目才可以使用总价合同。从成本风险的角度来说，业主方（甲方）的成本风险最低，基本没有成本风险。
总价合同又可分为：
1.固定总价合同(FFP)。 在既定的工作范围之下，价格是绝对固定的，除非工作范围出现变更，否则不允许调整价格。
2.总价加激励费用合同(FP-EPA)。 在总价的基础上规定相应的激励费用，以调动卖方的积极性，使买卖双方的目标趋于一致。在这种合同下通常会规定一个最高限价，付款总数不得超过最高限价
3.总价加经济价格调整合同(FPIF)。 在总价的基础之上允许根据通货膨胀的情况来调整合同价格。适用于履行期较长的合同。
二、成本补偿价合同 (工作范围不明确, 买方的成本风险最大 )
成本补偿合同是指以卖方从事项目工作的实际成本作为付款的基础，即成本实报实销。
适用于买方工作范围很不清楚的项目，或者买方非常信任卖方，想与卖方合作的情况。在这种合同下，买方的成本风险最大。
成本补偿合同又可分为：
1.成本加固定费用(CPFF)。 成本实报实销，买方另外向卖方支付固定利润，无论实际成本多少，利润都保持不变。
2.成本加激励费用(CPIF)。 买方向卖方的付款由三部分组成：实际成本、一笔固定费用、按合同规定的方法计算的对固定费用的调整数。
3.成本加奖励费用(CPAF)。 成本实报实销，买方再凭自己的主观感觉给卖方一笔利润，卖方只能无条件接受。
4.成本百分比。 买方在卖方实际成本的基础上，再加上以该成本的某个百分比计算的利润向卖方付款，卖方的实际成本越高，所得到的利润也就越高。
三、工料合同(T&M) (工作性质清楚,具体工作量无法确定)
工料合同也叫“时间和手段合同”，是指按项目工作所花费的实际工时和材料数、事先确定的单位工时费用标准和单位材料费用付款。
适用于工作性质清楚但具体工作量无法确定、规模小、工期短、不复杂的项目。在这种合同下，买卖双方分担成本风险，即买方承担工作量的风险，卖方承担单价的风险。
四、单边合同
另外，项目中还有一种常用合同是订购单。对于大量采购标准化产品，通常可以买方直接填写卖方提供的订购单，卖方照此供货，又叫单边合同。
合同解题思路:
先确定四个关键项
-
- 定义范围 2. 买/卖方 3. 内行/外行 4. 时间紧急与否
参考一 : 范围明确与否
-
- 范围明确选, 总价合同
-
- 范围不明确选, 成本补偿合同(成本加激励) 范围无法定义 工料合同
-
- 如果是卖方选, 成本补偿合同(固定 -> 激励 -> 奖励)
-
- 如果是买方, 是内行, 选成本补偿合同(可以很好参与项目) 是外行, 选工料合同
参考二: 选择风险小的:
-
- 如果是买方, 选总价合同, 固定总价合同(FFP), 风险最小
-
- 如果是卖方, 选成本补偿合同, 成本加激励费用(CPIF), 风险险最小
参考三: 时间紧急与否:
- 时间紧急, 选工料合同
工料合同相关信息:
- 增加人员, 聘请专家,获取外部支持(在不能快速制定工作说明书情况下)
- 工料合同适用于短期小金额的项目
27 项目依赖关系 (四种)
28 领导管理风格
（1）独裁型
独裁型风格是指规定具体的工作方法、单方面制定决策、限制员工参与的领导风格；
（2）民主型
民主型风格是指让员工参与决策制定，向员工授权，并且把反馈作为教导员工的机会的领导风格；（最有效）
（3）放任型 放任型风格是指团队做决策，用任何合适的方法完成任务的领导风格
29 项目管理相关方职责
1、高级管理层
特指项目经理的直接或间接领导，如项目总监、事业部总经理、CEO等，出现次数不多，但他们掌握着项目的管理储备，当遭遇未知风险时，由高级管理层决策是否动用管理储备来应对。
2、变更控制委员会(CCB)
CCB是由项目经理、客户、专家、项目发起人等主要项目相关方或其代表组织的一个常设但非固定的正式团体，其主要作用是批准或拒绝影响基准的变更请求。
3、项目管理办公室(PMO)
PMO是指对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术实现共享的部门。
4、职能经理
是指为项目提供资源(如专业人才)和支持的职能部门负责人。
5、发起人
可以理解为出钱让你做项目的人。项目章程由发起人签署发布，若张承中的项目目标定义有误，责任就在发起人，只有发起人有权修改章程；若项目失败，损失主要由发起人承担。
负责管理的收益、目标，以及重大变更等事项的决策处理。
6、项目经理
是指负责整合资源、制定计划并带领团队实现项目目标的人。
7、团队
这里指项目团队。团队出镜率很高，原因有二：第一，项目成功是团队齐心协力共同努力的结果;第二，团队成员必须充分参与项目管理的大量具体工作，包括计划的编制、变更的评估、偏差的监控等。
8、项目相关方
是指所有参与项目的各方和受项目影响的各方。虽然众口难调，但项目的重要目标之一就是让相关方满意。
题目1：你所管理的项目正处在实施的高峰时期，所在公司又启动了一个新项目。由于公司把新项目的优先程度排在你的项目前面，以至于你的几个重要的团队成员向你提交辞职报告，打算到新项目上去工作。这几个成员的离开，将给你的项目带来很大的麻烦。你应该：
A.不批准这几个成员的辞职报告
B.向管理层求助
C.向项目发起人求助
D.要求新项目的经理不要接受这几个人员解释
正确答案是: B 由于团队成员辞职的问题是因项目的优先顺序排列引起的，所以你只有求助于管理层。选项A与选项D，都不是合理的做法。选项C也不好，因为发起人的主要作用是提供资金。
题目2: 一项目在执行过程中，项目相关方建议做出重大变更，这会造成项目的第3次全面检查。同时，项目经理发现一个主要的工作包没有完成，因为一名团队成员的领导把他调到另一个重要性更高的项目中去了。项目经理最好和谁谈这个问题？
- A.Team 团队
- B.Senior management 高级管理层
- C. Customer 客户
- D. Sponsor 出资人
正确答案: D 出资人的责任是防止不必要的变更，为各个项目设定优先级。本题中的情况说 明出资人没有做这些工作，所以项目经理必须去找问题的根源，出资人。
30 风险应对
一、威胁(消极风险)应对措施：
1、规避(Avoid)
• 改变项目计划，以排除风险发生的条件;
• 延长进度、改变策略、缩减范围、取消项目;
• 澄清需求、获取信息、改善沟通或取得专有技能来加以回避。
2、转移(Transfer)
• 将风险的后果连同应对的责任转移到第三方， 应对财务风险有效;
• 保险、履约保函、担保书、保证书;
• 可以利用合同把某些具体风险转移给另一方。
3、减轻(Mitigate)
• 降低不利风险事件的概率与(或)后果;
• 早期预备比事后补救更有效;
• 原型试验，更多测试，靠谱的供应商，简单的流程或工序。
4、接受(Accept)
• 主动接受(关联应急储备);
• 被动接受(认了)。
5、上报(Escalation)
• 风险超出团队可管理性，并将风险责任上报到组织中的更高层。
二、机会(积极风险)应对措施：
积极风险应对记住八字方针：提高数量，开拓质量。
1、开拓Exploit
• 消除与某个特定积极风险相关的不确定性， 确保机会肯定出现;
•分派更(最)有能力的资源给项目。
2、分享Share
• 将风险的所有权转移给第三方(最能为项目的利益获取机会的);
• 包括建立风险共担的合作关系和团队，以及为特殊目的成立公司
或联营体;
• 充分利用机会，使各方都从中受益。
3、提高Enhance
• 提高机会发生的概率或积极影响;
• 增加资源。
4、接受Accept(乐见其成)
5、上报(Escalation)(应对措施超出项目经理的权限)
转移: 外包给分包商, 买保险 分享: 自己实力不够, 拉上一个合作
31 有哪些测试机制
- 基于行为和测试驱动开发的测试
- 独立的个人测试
- 故事测试
- 所有可能选择项的实验性方法
这是个结构 价值驱动结构(敏捷结构)
32 偏差分析、趋势分析、绩效审查
- 绩效审查: 对比分析进度绩效, 如计划完成百分比
- 趋势分析: 项目绩效, 随时间变化情况
- 偏差分析: 实际开始/完成日期 与计划开始/完成日期 偏差(浮动时间差)
33 各种法则
- 利特尔法则
- 库存(在制品)/吞吐量(服务速度) = 等待时间
- 通过减少在制品, 达到减少等待时间
- zhuanlan.zhihu.com/p/550265126
- 帕金森定律
- 是说只要还有时间，工作就会不断扩展，直到用完所有的时间。
- 收益递减规律
- ★★收益递减规律：在保持其他因素不变的情况下，增加一个用于确定单位产出所需投入的因素（如资源）会最终达到一个临界点，在该点之后的产出或输出会随着增加这个因素而递减。
工程加一倍资源, 未必能减少一半工期
- 精益交付时间原则
- 按照客户需求品种及数量准时生产
- 特征: 按需生产, 低成本, 高质量
34 项目组织结构
以下通过一个虚拟的组织人员架构图来讲解职能（集中式）型、强矩阵（矩阵-强）型、弱矩阵（矩阵-弱）、平行矩阵（矩阵-均衡）、项目型（项目导向）、混合型这五种组织结构对项目的影响。
- 职能型组织结构
职能化组织结构，工作流程化流程化，对运营较为高效。
职能化组织结构
从上图可以看出，在总经理管着设计部的设计经理、市场部的市场经理、生产部的生产经理、销售部的销售经理；设计部、市场部、生产部、销售部各施各职，相互独立，各自完成各自的职能。产品设计完成，交给销售部生产，产品生产出来了，交给销售部销售，市场部负责为产品打开知名度，方便销售部销售产品。
- 强矩阵（矩阵-强）型组织结构
强矩阵型组织结构，项目经理全职，拥有中高等权力。
强矩阵型组织结构
看上图的组织人员架构，在项目经理和各部门经理下方画了条蓝色的虚线，这条虚线是想说明，在强矩阵（矩阵-强）型组织里，项目经理和各部门经理是同级关系，那么，既然各个部门经理有实权，项目经理作为同级，自然也是有实权的。
这张图为什么要加个PMO在组织人员架构里混肴视听呢？
因为想说明，这里的项目经理是指定角色，全职的。谁有权力指定项目经理？PMO就能指定项目经理。
- 弱矩阵（矩阵-弱）型组织结构
弱矩阵型组织结构，助理兼职项目经理的角色，权力少，充当协调员。
弱矩阵型组织结构
总经理想开一个新的项目，但是总经理很忙，没时间盯着项目，下面的职能部门经理，都只是专注于自己的职能，没有人协调项目。那这个时候，总经理就派了他的助理来协调了，项目需要什么资源（人员、物料），由总经理拍板，然后助理跟各个部门经理协调，这里的助理，可以看做是一个兼职的项目经理。看上图，蓝色虚线，指助理（兼职的项目经理）是总经理的下属；橙色虚线，指助理跟各个职能部门的普通员工是同级，所以是没有实权的。
- 平行矩阵（矩阵-均衡）型组织结构
平行矩阵型组织结构，项目经理是个兼职，跟各部门经理是平级关系，项目经理下面的人，由部门经理分配。
平行矩阵型组织结构
见上图，在各个职能部门的基础上，还设置了一个项目组，里面放置着项目经理；蓝色虚线代表项目经理与各职能部门经理同级，均拥有实权；橙色虚线代表，项目经理下面的项目人员，都是向各职能经理申请调拨来的。
- 项目型（项目导向）型组织结构
项目型组织结构，项目经理有实权，负责项目大小事务。
项目型组织结构
从上图可以看出，总经理下面就是各个项目经理了，项目经理下面管理着不同职能的项目成员。
- 混合型组织结构
混合型组织结构
上图，在一个组织架构里，既有职能部门，也有项目组（部门），职能部门经理管着属于该职能的员工，而项目经理管理着拥有不同职能能力的员工，这就是混合型组织结构。
35 当团队成员不清楚职责时
当团队成员不清楚职责时，应查看三份文件：（1）资源管理计划中的角色与职责，（2）责任分配矩阵 (RACI) A: 决策人（3）WBS字典。
责任分配矩阵(规划资源工具) -> 资源管理计划
36 根本原因分析 RCA
根本原因分析是确定引起偏差、缺陷或风险的根本原因的一种分析技术.
项根本原因可能引起多项偏差、缺陷或风险. 根本原因分析还可以作为一项技术，用于识别问题的根本原因并解决问题. 消除所有根本原因可以杜绝问题再次发。
根本原因分析和鱼骨图选项在其它题目中独立存在时没有区别，只是放到一起的时候建议选根本原因分析，因为鱼骨图只是图形化表现。
37 极限编程
极限编程（XP）是一个敏捷软件开发框架，旨在帮助开发团队达成更高质量的开发节奏，开发更高质量的软件。XP是描述软件开发工程具体实践的敏捷框架。
Scrum是一个能够解决复杂适应性问题的敏捷开发框架，同时以富有创造力的方式交付最高价值的产品，帮助团队在复杂产品上进行有效协作。
极限编程敏捷框架 与 scrum敏捷框架比较 zhuanlan.zhihu.com/p/382955425
38 风险四要素
风险事件 风险发生概率 风险产生的影响 风险发生的原因
39 相关方登记册 相关方评估矩阵 相关方参与计划
识别相关方 -> 相关方登记册 ->相关方评估矩阵(工具) -> 相关方参与计划
40 风险管理计划 风险登记册 风险报告 问题日志
- 风险管理计划(规划风险)
- 识别风险
- 风险登记册(未发生|单个风险)风险报告(未发生|整体风险), 问题日志(发生)
- 定性风险分析/定量风险分析
41 根本原因分析 鱼骨图/石川图/因果图
只是放到一起的时候建议选根本原因分析，因为鱼骨图只是图形化表现。
42 沟通管理
相关方参与度评估矩阵(规划工具) -> 沟通管理计划(和谁?怎么?收集信息) ->
43 成本估算 vs 制定预算
| 成本估算 | |
|---|---|
| 含义 | 是对完成项目工作所需资源成本进行近似估算的过程 |
| 目的 | 本过程的主要作用是，确定项目所需的资金。 |
| 使用场景 | 估算成本，更多是对完成某项活动或工作包所需的成本进行估算。估算一般包括两部分，完成该活动或工作包本身所需要的成本，和完成活动或工作包期间为应对已知风险而估算的应急储备 |
| 使用工具 | 类比估算、参数估算、三点估算、专家判断、自下而上估算，不同的场景可以使用不同的方式 |
| 制定预算 | |
|---|---|
| 含义 | 是汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程 |
| 目的 | 本过程的主要作用是，确定可据以监督和控制项目绩效的成本基准。 |
| 使用场景 | 制定预算，更多是在前期已经完成各个活动或工作包成本估算的基础上，通过自下而上汇总的方式，形成整个项目的成本基准。这个成本基准就是后续我们在项目执行过程中，通过挣值管理工具对实际成本绩效进行管理的依据，一旦发现实际成本绩效偏离这个绩效基准，就要即使采取纠正措施，以保证项目最终按照预定的成本完成。 |
| 使用工具 |
| 完整的项目预算 | |
|---|---|
| 含义 | 需要在这个成本基准上，增加应对未知风险的管理储备，然后才形成完整的项目预算 |
44 相关方登记册 相关方参与计划 沟通管理计划
相关方登记册 是识别相关方的输出，记录关于已识别相关方的信息，包括：身份信息、评估信息、相关方分类； 相关方参与计划 是确定用于促进相关方有效参与决策和执行的策略和行动； 沟通管理计划 描述将如何规划，结构化、执行与监督项目沟通，以提高沟通的有效性。 通俗地说： • 相关方登记册 是记录了 有哪些人； • 相关方参与计划 是规定人们 怎样参与项目； • 沟通管理计划 是如何与相关方 交流信息。 解题思路： 如果 不知道项目有哪些相关方，或者相关方有什么要求，查看 相关方登记册。 如果不知道相关方 如何参与项目，看相关方参与计划。 如果相关方 抱怨收到的报告、信息或者会议内容不合适，传达方式不合理，这些与 沟通管理计划 有关。
45 敏捷测试机制
1 涵盖所有可能选择项的实验性方法 2 基于行为和测试驱动开发的测试 3 故事测试
某公司一直在对其当前的业务模式实施变革，该变革需要借助多个敏捷团队实施一个复杂的项目。项目经理应让测试团队将以下哪三个方案作为测试机制？（选三项） A 涵盖所有可能选择项的实验性方法 B 基于行为和测试驱动开发的测试 C 独立的个人测试 D 故事测试 E 安全性、性能测试 正确答案：ABD 解析： 选项A正确：这是一种分支覆盖的测试机制，它要求测试需覆盖所有可能的分支。 选项B正确：这也是测试机制之一。 选项C错误：独立测试不具有代表性，会存在漏测的情况。 选项D正确：这也是一种测试机制。选项E错误：与题意无关
46 360度审查
通过同行，上级，下级得到某人的绩效反馈
作用：个人的绩效评估
