项目基础--项目的概念（掌握）
项目——是为创造独特的产品、服务或者成果而进行的临时性工作。（结果独特、并可验证，可以有型也可以无形）。可交付成果：deliverable。
临时性：具备明确的起点和终点，并不意味着项目的时间短。项目临时，但结果持久。
独特性：项目所创造的产品或服务在一定的程度或在某些方面与其他的产品和服务相比较，有明显的差别（独特性带来不确定性，带来的是风险）。某些可交付成果中可能存在重复的元素，但不会改变项目的独特性。
渐进明细性：指项目的成果性目标是逐步完成的。在项目渐进明细的过程中一定会有修改，产生相应的变更。因此，在项目执行过程中要对变更进行控制，以保证项目在各相关方同意下顺利开展。
项目驱动变更——从商业角度来看，项目旨在推动组织从一个状态（当前状态）转到另一个状态（将来状态），从而达成特定目标。
项目的商业价值——项目的成果能够为干系人带来的效益，效益可以是有形的、无形的或两者兼有之。
（1）有形效益：货币资产、股东权益、固定资产、工具、市场份额等。
（2）无形效益：商誉、品牌认知度、公共利益、战略联盟等。
项目管理——将知识、技能、工具和技术应用于项目活动，以满足项目的要求。
作用：管理制约因素（范围、进度、成本、资源、质量、风险，哪一个因素最重要由组织决定）。平衡制约因素对项目的影响（例如范围扩大可能会增加成本或延长进度）。
项目成功标准：除了应达到时间、成本、范围和质量等项目管理测量指标（记录在项目章程里）外，还应考虑项目目标的实现情况，这些项目目标可能包括：完成效益管理计划、达到财务测量指标、完成从“当前状态”转到“将来状态”，履行合同，干系人满意，达到组织战略和目标等等。
项目内外运行环境：事业环境因素和组织过程资产（重点）。
事业环境因素：大环境因素，客观存在。项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。
组织内部：组织文化，基础设施，办公软件，员工能力等。组织外部：市场条件、法律法规，商业数据库、行业标准、物理环境等。
组织过程资产：执行组织特有（遗留下来的）并使用的计划、过程、政策、程序和知识库，会影响对具体项目的管理。 在整个项目期间，项目团队成员可对组织过程资产进行必要的更新和增补。（可以参照、不参照、更新等）。
简称：安知数理过。过程资产：模板、框架、工具、方法等。治理文件：政策流程等。数据资产：数据库、工具、度量指标等。知识资产：专家的隐形知识等。安保和安全：对设备访问、数据保护、保密级别的程序等。
组织系统——组织结构（环境事业因素）（重点）
组织的全体成员在管理工作中进行分工协作，在职务范围、责任、权力方面形成的结构体系。
职能型（集中式）：兼职项目经理（联络员，权限0）；协调路径（职员A->职能经理A（权限100）->职能经理B（权限100）->职员B）；职业路径清晰、横向联系薄弱。
项目型：全职项目经理（权限100）；协调路径（项目经理A->职员A、B、C）；项目经理控制度高；重复配置、无家可归。（职能经理权限0）。

弱矩阵型（项目经理：20；职能经理：80）：兼职项目经理（协调员，职权<职能经理）；协调路径（职员A->职员B、C）。
平衡矩阵（项目经理：50；职能经理：50）：兼职项目经理（职权≈职能经理）；协调路径（项目经理->职员B、C）。
强矩阵型（项目经理：80；职能经理：20）：全职项目经理（职权>职能经理）；协调路径（项目经理A->职员B、C）；出现“全职项目经理的经理”。

其他类型（了解）
有机型或者简单型组织：有机组织是一个非常灵活的组织，能够很好地适应变化。它的结构是：工作专业化少，管理层次少，决策分散，监督不多。
多部门组织：一个中心，多个部门或分区，这些分区实行半自治，中心对其 下达财务指标。
虚拟型组织：-临时把人员召集起来，以利用特定的机遇，待目标完成后即行解散的一种临时组织。虚拟组织结构，也称为网络型组织。

组织系统--项目管理办公室PMO（掌握）
项目管理办公室（PMO）----是对与项目相关的治理过程进行标准化并促进资源、方法论、工具和技术共享的一个组织结构。PMO所支持和管理的项目不一定彼此关联。
PMO类型（支控指）：
支持型：支持，是顾问、项目资源库，对项目控制程度很低。
控制型：支持+要求服从，对项目控制程度中等。
指令型：直接管理和控制，项目经理由PMO指定并向其报告，对项目控制程度很高。
组织系统--PMO对项目经理支持的方式 ：案例分析可能出现（掌握）
（1）管理“共享资源”，识别和制定“最佳实践”和“标准”（管理功能）
（2）通过“项目审计”，监督对“标准”的遵守程度（监督功能）
（3）制定和管理政策、程序、模板，提供指导和培训（指导培训功能）
（4）协调“跨项目”的沟通（协调功能）

项目经理的角色：（掌握）
项目经理----由执行组织委派，领导团队实现项目目标的个人。专注项目目标的达成。无需承担项目中的每个角色，但应具备项目管理知识、技术知识、理解能力和相关经验。
职能经理：专注于对某个职能领域或业务部门的管理监。
运营经理：专注业务运营的高效性。

项目经理的影响力范围：项目类、组织类、行业类、专业学科类和跨领域类。（了解）
项目经理的能力：PMI三角。（掌握）
技术项目的管理技能：有效运用项目管理知识实现项目集或项目的预期成果的能力，有助于项目经理了解与项目相关的商业因素。
战略和商务管理技能：纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力。
领导力技能：指导、激励和带领团队的能力(协商、抗压、沟通、解决问题、批判性思考、人际关系技能)。
项目经理的品质和技能（了解）：有远见、能运用批判性思维、关注重要事情、终身学习结果导向、正确沟通、积极乐观、管理关系的冲突。

领导力技能：政策和权力（掌握）

项目经理领导力与管理（掌握）：
领导力——通过讨论或辩论方式与他人合作，带领他们从一个位置到另一个位置。
管理——指挥一个人执行一系列已知的预期行为从一个位置到另一个位置。
项目经理必须同时采用领导力和管理这两种方式，针对不同的情况找到恰当的平衡点。

费曼学习法
以教促学：用教会别人的方式，来巩固自己学习的知识。
执行起来分为四个步骤，以学习一个知识点为例：
概念（Concept)：学习知识点相关知识，直到感觉自己掌握。
讲述（Teach)：用自己的语言，将这个知识点教给别人，让别人能够听懂，学会。
回顾（Review)：讲述结束后，分析自己在讲述过程中，有哪些理解不透彻，甚至理解错误的地方，或者虽然自己感觉是理解了，但是讲出来还是让人感觉晦涩难懂。
简化（Simplify)：针对第三步中发现的问题，继续学习，直到能够以更加自然流畅、简洁精准的语言将知识点阐述清楚，更容易让人理解。
完成以上四步之后，再重复这个过程，直到讲述过程简单、生动、形象，相关案例能信手拈来。

SQ3R阅读法
五个阶段（Survey，Question，Read，Recite，Review），预览、提问、阅读、复述、复习。
浏览—：拿到书之后，先把书的目录、标题等看一遍，了解这本书的大概内容。
发问—：粗读一下书籍，并把自己的疑问记录下来，以催进学习兴趣，激发主观能动性。
阅读—：精读书籍，边读边做标记和笔记，做到眼到、口到、心到、手到，边读边思考，可以做一些标记，让自己沉浸到书中。
复述—：合上书本，让书中的内容在脑中“过电影”方面巩固记忆，一方面检查知识是否有卡壳和遗漏，便及时打开书，以把知识漏洞补上。
复习—：复述一、两天内，要进行复习，隔一段时间，再重新复习，一方面对知识进行巩固，另一方面，在复习过程中，会有新的体会。

题目学习法
1、无论直播还是录播，先完整地听一遍课。
2、课后对照讲义和知识点清单复习，不求做到熟记，但理解程度要达到70%+，有不理解的可询问、讨论或回听对应的课程段。
3、结合复习的结果来做题，如每日一练、周末章节题、模拟题等。
4、接下来是核心重点——做完的题无论是对还是错，每一题分别去讲义或书上找到对应的知识点并加以复习，同时往前推5行，往后推5行把其中包含的知识点内容也予以熟悉。
注：该方法的特点是，通过题目复习巩固知识点，并因各题对应的知识点位置前后推5行覆盖的范围很大概率交叉重叠，这样在题目做得越多情况下，各知识点重复复习概率越高，重复得越多，自然掌握越牢固。

1，“淘汰效率低下的销售渠道。几个干系人认为，一个表明创造价值下降的渠道仍然些计划保留的渠道更有效”，说明一些原以为效率低的渠道搞错了，用敏捷的做法，以价值驱动来确认 价值低的淘汰，价值高的保留。
2，“收尾阶段，客户提及之前从未讨论过的需求”，对于未讨论的需求，讨论验收标准就没有意义。应该跟踪需求矩阵，确认当初是否包含这个需求。
3，太多干系人意见不一致，可能导致项目失败，分开谈还是一起谈，关键在于能否达成共识，意见不一致是有分歧，所以要引导大家一起开会，协调差异。跟干系人参与计划没关系，参与计划没问题。
4，工作场所外，团队成员和发起人会面，发现有新期望，这个做法没问题，况且该团队成员没有决策也没有执行。所以项目经理应该去了解发起人的期望。重点：不要和干系人审查沟通管理计划，反而要根据干系人的需求更新沟通管理计划。
5，“购买该地产是为了使土地所有者的利润最大化。项目经理获悉，该市可能计划会改变该地区的分区，以允许在一块土地上设置多处出租物业。业主要求项目经理监督该风险。”这是一个机会，考虑风险里机会的应对策略。
6，更换项目发起人，换人已经是客观事实，没有不确定性，不属于风险。首先要识别干系人，引导干系人参与，应该和干系人会面，介绍项目。
7，进度绩效指数(SPI)为0.8，成本绩效指数(CPI)为1.4。省钱了，但进度落后，应该赶工，花钱买时间。
8，“每日站会上，一些团队成员就一些复杂的任务寻求帮助。”站会不解决问题，只提出问题。所以项目经理要求团队在站会外解决技术问题。
9，“一名经验更丰富的成员命令其他团队成员执行超出其职责范围的任务”。干系人参与计划是搞人的策略，搞的是执行团队以外的人。团队内的人走的是获取资源的路线。项目经理只能参考组织过程资产。
10，“一个代码的版本在未经授权的情况下被修改了，并且没有人愿意为此修改承担责任。”考察的是PMP的要求，要确保基本规则。PMP没讲过关于安全策略。
11，“担心项目设备和基础设施可能会因洪水而受损，而且主要道路可能会封闭。”应该优先选择减轻风险，保险和被动接受都是只能是无奈之后的选择。高危风险一般不会选择保险的策略。
12，长期有效的冲突解决方法：合作解决问题。
13，层级结构有问题，决策仍然还是高级管理层做，说明高级管理层未授权，应该让组织高层了解敏捷的方法。
14，经常发生激烈的意见分歧，要想办法解决冲突，就问题讨论达成解决方案。如果只是观察评估没有解决冲突。
15，成果审查时，干系人对最终产品提出了担忧，怀疑成果有问题。首先查一下需求文件，看下是不是真有问题。然后再去讨论干系人担忧的问题。
16，被排斥在团队之外，优先考虑团队协作，要开展团队建设。
17，风险何时从风险登记册转移到问题日志？发生后才可能成为问题。
18，奖励怎么算有效奖励？满足当事人某个需求，要根据当事人的需要去选择奖励。
19，凸显模型适合于复杂人多的干系人。人少的时候适合权利利益方格。
20，如何对干系人分类？考虑职权进行分级；根据影响力进行分组；不能只听某个干系人的意见。
21，预测转移到敏捷，要求提高团队凝聚力。尽量每天一起工作，遵循冲刺计划（因为都有共同的目标）。每天持续改进跟提高凝聚力关系不大。
22，确保干系人的适当参与？对干系人排序，制定评估矩阵。评估干系人没问题，但是没有评估完就能跟项目目标保持一致这种说法。
23，敏捷项目里，预算用完了可以考虑优先级并缩小范围。预测项目范围是固定的，只能做进度压缩。

1，敏捷项目里，当前sprint不做变更，所以项目经理不能再当前迭代里做紧急更改。
2，项目正在被延迟，已经是一个问题。项目经理将谈判已经记录为风险，这是一个已识别并发生的风险。所以，整体来说应该是记录问题，并遵循风险应对计划的行动。
3，审计审查过程，问题是没有遵守政策流程和审批手续。应该按照质量管理计划的内容，审查流程，找到缺失的差距。
4，项目经理发现一个风险，做为风险管理的一部分，这是一个机会。应该告诉管理层，这是一个扩大市场份额和开发新产品的机会。
5，团队专注于sprint目标，解决障碍应该是项目经理的事，PMO实施的框架跟当前敏捷交付不见人，说明这是一个障碍，理论上不应该直接让团队进入，应该先审查框架，再决定是否让团队参与沟通。
6，关键干系人无法参加会议，如果重新安排会议的话，即使这次可以参加，那后续仍然无法参加，应该是分享会议议程，期望达成目标。
7，客户的标准，指的是验收的标准，就是确认范围。收集需求——定义范围——范围说明书有可交付成果的定义及验收标准，所以开始的时候要记录和定义【需求】。目标在项目章程里，不在标准里。
8，规划质量是描述项目将如何证明符合质量要求和(或)标准的过程。要确保在执行阶段符合质量要求那么需要做好规划质量管理。持续调查可交付成果的质量，这是控制质量查结果。质量不是靠检查出来的。每个阶段都能做五大过程组，所以实施阶段也可以做规划质量管理。
9，在xxx之前，不能开始一项活动，这xxx就是前提，属于强制依赖关系。而快速跟进是选择性依赖关系。所以这种制约因素，可以记录在假设日志里，包含前后的相关性。
10，项目目标是产品上市，涉及到这个项目的问题，会涉及项目目标不能达成，可能会失败，此时可以考虑上报项目发起人。
11，技术问题阻止交付，人员也要离职；参考资源管理计划只能解决人的问题，无法解决技术问题。所以整体来说审查整体的制约因素，评估计划的发布，再决定如何解决问题。
12，最常见的问题是什么工件将取代项目时间表。项目经理应该如何回应？待办事项列表跟需求范围有关系，跟进度没直接的关系。所以项目经理应查看冲刺计划和产品路线图。冲刺计划涵盖了时间进度。
13，“一些资源与由各自的业务单元发起的计划之外的其他项目共享”，资源和其他项目共享，就该先咨询其他项目的项目经理。
14，算法，属于技术问题，跟用户故事无关，算法属于执行层面由团队自组织决定。《创建一个新条目来确定合适的算法》属于一个spike，在某个迭代里做个刺探来决定。敏捷主管无法决定技术问题。
15，“难以访问”跟项目存储库是不是新不新没关系，最多是访问的版本不是新的。应该做好团队交叉培训知识共享。
16，“确保团队和项目目标一致”，是为了搞清楚目标是什么，而不是为了修改目标，目标记录在项目章程里。没必要讨论，我们不是为了修改。只要查看项目章程就可以满足题目。
17，“团队成员希望提高自己的引导技能”，说明团队成员希望自己去主持并引导会议，不涉及团队的技能不足，只是说没机会引导，不涉及培训。项目经理应该给团队机会。
18，冲突是分为积极和消极的，成功的冲突管理是可以提高生产力。pmpbok里没涉及结构性或者人际冲突。
19，沟通和协作，不涉及技能不足，不涉及团队的培训和知识转移。沟通有差距应该解决组织会议相互了解。
20，敏捷项目里，谁的需求是最重要的？客户。
21，在试图确定一个项目的领导风格时，应该先考虑组织文化。
22，“发起人一直要求最重要的项目里程碑的具体日期”，考察项目章程包括哪些内容，范围，需求，目标，成功标准和退出标准，审批计划和干系人，整体里程碑和进度计划，里程碑是一个时间点已经包括。
23，一个风险一旦上报之后，项目经理只能看高级别领导的决策，无法做更多的行动。

1，冲突才有冲突的解决方法。想法的分歧属于观点的争论，允许自组织团队自己解决。
项目经理介入：有人明确违反基本规则、冲突双方有来找项目经理投诉、冲突进一步升级、明确说团队已经无法协作等。
2，审计目标：识别做的好的和不好的、分享其他项目的良好实践、协助改进、积累经验、确认（变更有没有被正常执行）。
3，准备报告后，要进行汇报沟通，沟通是定制化需求量身定制，没有标准SOP操作程序。在完成报告前可以跟干系人开会了解需要什么内容，进行需求沟通分析。
4，Scrum敏捷过程采用故事点估算方法，也叫相对估算。
5，根本原因分析是问题发生之后做，不适合“如何预防”类问题。
6，潜在要发生的事情，是一个风险，没有明确要发生问题。
7，敏捷是固定的时间盒，不能调整。如果团队需要时间来培训，在固定时间内的产能就要降低。
8，干系人不允许推进项目的情况，“非常规策略”不能选择，属于不正常策略。
9，如何让干系人了解项目当前已经实现的价值？ 参加迭代演示。
10，已完成项目管理计划，确保获得干系人的支持，干系人的问题，引导参与获得支持，应管理干系人的参与，确保干系人或者其团队部门都能参会了解。
11，一位非常重要的专家不能继续工作，属于资源缺失，重点应该沟通资源的需求。
12，因xx原因导致改变了方向，意味着项目范围已经更改且明确，团队士气低落应该鼓励团队。如果范围不清晰则需要澄清范围。
13，敏捷项目，新功能，应该和PO审查信息安全问题，并识别风险。
14，认可与奖励的考点，就是激励，分有形和无形，要满足某个需求才算有效的奖励。项目经理如何使用奖励，最好的办法是听一下团队的意见。
15，沟通是信息的交换，信息的多、少、不懂算沟通。不能解决干系人的各种担忧，应该是想办法解决引导干系人参与。
16， 组织内获取资源：谈判，跟职业经理谈，和其他干系人谈等。
17，合同执行过程组收到重大差异，项目经理在最初该做什么？以前没差异，现在有了，应识别差异。
18，项目经理接收新项目，缺少绩效的记录，应该根据关键绩效指标KPIS来评估，符合客观事实。
19，商业价值发生变化，要重新审查商业价值，将调整后的商业价值重新评估并考虑。
20，项目启动需要开展的任务：制定项目章程、识别干系人。
21，干系人说工作不满足实际业务需求，首先要先跟该干系人确认未包含哪些功能，然后确认是否属实。
22，如何确保合规？咨询一下专家，不能确保最终合规。写到项目管理计划里，项目会按照项目管理计划执行，可以合规。在质量管理计划记录新设备的信息，不能确保。合规要求不仅仅和质量有关系，也可能跟需求有关系，所以不能仅仅关注质量管理计划。
23，促进新成员和干系人互动，首先要了解有哪些干系人，审核干系人登记册；然后看下如何跟干系人沟通，查看感谢人参与计划；最后安排和干系人的会议。
24，目的：为了发放更新后的会议决策，应该参考：沟通管理计划，信息的发放。
25，评估两个项目，这对组织的财务健康状况有帮助，换句话说就是，考察项目的财务指标：计算项目的内部收益率。
26，连续6周连续加班，法律上不允许，中国法律规定每月加班不得超过36小时。所以要优先考虑法律法规问题。
27，敏捷项目无法明确详细的项目范围，需求都在PB里，而不是在业务需求文件，所以产品待办列表PB可以用来解释项目范围。
28，自制外购分析有关的价值指标。PMBOK第六版P473：在自制或外购分析中，可以使用回收期、投资回报率(ROI)、内部报酬率(IRR)、现金流贴现、净现值(NPV)、收益成本(BCA)或其他分析技术，来确定某种货物或服务是应该在项目内部自制，还是从外部购买。
29，采取措施解决问题，但是问题依然存在，说明采取的措施有问题，应该考虑重新分析制定新的措施。记录在问题日志中没有必要，没有解决问题。
30，PMO要审计当前迭代的进度，要参加sprint冲刺评审会。回顾是总结经验教训的。发布评审未提过有这样名称的会议。
31，客户尽快发布产品，增量法才能尽快发布。迭代法是优化，获取反馈，不适合。
32，项目遇到技术问题，需要找干系人参会评审并确认，公司内部和管理层都无法代替最终的用户，所以最好的干系人是用户团队。
33，团队成员刚刚加入团队，就立即开始质疑当前项目主管的所有决定，这种做法是典型的违背的基本规则的情况，而不是普通的双方的冲突。跟当前主管也没关系。
34，如何监控合规性？项目审计，无论是安全合规还是质量合规。