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，如何监控合规性？项目审计，无论是安全合规还是质量合规。

1，阐述不是产品在实施的过程中需要变更，而是要改造“现有产品"，其实是一个产品改造的项目，希望项目获得成功，那么必须先定义项目的成功标准。还没到确定定期更新还是一次性更新的步骤。
2，涉及额外的成本，已经不是问题解决的思路，而是项目的变更。走变更流程。问题解决思路：1记录、2识别、3生成方案、4选择一个方案、5执行、6验证。
3，敏捷注重价值驱动交付。
4，根本原因分析RCA的作用是，分析问题发生的根本原因，杜绝问题再次发生。
5，产品内部开发，一定会有组织过程资产，项目经理可以参考历史经验教训。项目正在启动，还没有开始识别风险，也没有新的经验教训。干系人参与和识别风险都在规划阶段，不在启动。
6，团队建设是为了解决团队成员之间协调工作，一个人太忙表达不满属于个人问题，跟团队无关。
7，进度表属于进度基准，进度表没更新版本不对，应该定期更新项目文件，更新项目管理计划并共享。
8，共享资源导致推迟，如何防止？应该提前沟通好资源的利用。确定影响是事后的事情，不是防止。
9，有客户在场的会议，要注意沟通内容，关注沟通管理计划。成本管理计划是指南，跟成本没有关系，预算的内容在成本基准。
10，问卷调查是调研需求的，无法让所有人达成共识。要达成共识可以考虑开会，引导式研讨会。
11，要求得不到满足，是担心需求无法满足，无法确认有无问题，审查需求跟踪矩阵，不是审核需求是否缺失。
12，收集需求的第一步是了解需求背景以及各种要求，有了需求才确认范围，后续才会矩形规划会议。
13，出现干系人、团队或其他人第一次知道某个信息，属于沟通问题，信息沟通不及时，应正确使用沟通管理计划。
14，关键干系人参加展会影响团队，是团队遇到障碍。回顾会是总结经验教训，识别所需要的改进，跟干系人的问题没有关系。正确做法是直接与干系人开会，解决他们的问题。
15，公开争吵，绕开项目经理做决策，完全没遵守规定。应该重申规则，确保遵守，并解决每个成员的行为问题。
16，客户要取消，如何影响客户？先做成本效益分析，确认可以做。多标准决策分析，涉及到价值的维度，确认项目有价值。
17，没有预见的风险，涉及管理储备和成本基准。
18，找项目的根本原因，五个为什么（why）以及石川图，鱼骨图，因果图等。
19，讨论下一次开发哪些功能，首先涉及产品待办事项（PB），筛选要做哪些；让sprint会议有成效，要确认本次的冲刺目标。燃尽图是进度，跟范围没关系。
20，员工流动的风险，如何缓解？如何减轻员工离职的风险？减低员工离职的概率，减少离职的影响。奖励、激励、增加后备等。关于培训员工，本质上也属于增加后备的内容。
21，合规性要遵守，优先级不一定最高。所以要询问优先级并排序。
22，敏捷的合同，可以分层；要考虑动态范围变更的方案，自助团队而不是自资助范围（包人头）。
知识普及：
在大型项目上，可能针对某些可交付成果采用适应型方法，而对其他部分则采用更稳定的方法。来管辖整体协作关系，而将适应型工在这种情况下，可以通过主体协议，如主要服务协议(MSA)作写入附录或补充文件。这样一来，变更只针对适应型工作，而不会对主体协议造成影响。
对应知识点：客户协作高于合同谈判、考虑动态特性的合同、主协议和补充的多层结构。
补充：关注用户故事而非整个项目的预算、动态范围方案、提前取消方案、资助团队而非范围(包人头)。

1，结尾，获得项目验收、（干系人满意度调查）、移交成果、总结记录、组织过程资产更新、文件归档、（庆功会）、释放资源。
2，团队有新成员加入，团队会自动到 形成和震荡阶段，应该引导团队到规范和稳定阶段，并且团队也可能跳过震荡阶段，无需引导。换人后KPI下降，可能是团队的协同不好，团队建设的关键词之一是提高团队协同工作。、
3，情商工具，为了管理自己和他人的情绪，作用减轻压力，加强合作。PMP里，沟通是在说信息的交换。
4，优先考虑功能，成本效益分析。先考虑价值和时间，方法是看预期取得的效益，即 价值/时间，价值除以时间。
5，项目经理要推广敏捷，要让干系人认可。首先要培训敏捷方法，而不是使用敏捷改造组织。
6，仪表盘是信息报告，属于沟通的问题。干系人参与评估矩阵，是规划参与人的工具，属于搞人计划。应该是更新沟通管理计划。
7，干系人参与度越来越低，导致拒绝可交付成果。“由于额外的责任”，干系人承担了更多的事情，需要考虑参与人属性的变化，比如期望等。
8，时间不够，预算研招办不足，不做大而全，应该做减法，出最小可行产品MVP。“解释做不了”属于告诉对方这事不能做，推卸责任。
9，预测方法中，选用滚动式规划来加快交付，影响映射（impact mapping）用来组织目标和客户价值创造达成一致的工具。 Scrums of scrums是多敏捷团队的沟通方法。
10，障碍属于一个问题，风险要识别并且有对应风险的计划，但障碍只有步骤，没有解决的计划，多个障碍要先确定解决障碍的顺序。问题的解决：定义问题，识别原因，定方案，实施方案，检查方案。风险的解决：识别、定性定量，制定策略、实施、监控、更新风险管理计划。
11，风险管理计划里没有对风险的应对策略，正常应该是查风险登记册。
12，获取支援在执行过程组，识别风险在规划，监控风险在监控过程组。
13，多个小规模团队合作冲刺，问如何保证冲刺成果。追逐太阳，遵循接力的模式，每个团队完成后移交给下一个团队。
14，一个项目对成员的期望，是对成员的角色和职责的确认，记录在资源管理计划里。
15，采购管理计划是一个指南，how，只记录 步骤。具体的方案方法流程记录在采购策略里。
16，效益管理计划里包括了目标效益、战略一致性等内容。
17，自己的公司搞了两次还搞不成，许多团队无法在一夜之间切换到敏捷工作方式，因此可以用混合型生命周期作为过渡策略，就可以考虑引入第三方公司给与指导设定方案。
18，进度落后但是成本节约，为了证明项目处于控制之下，要说明有充足的预算增加资源或者成本换时间，维持计划内的项目进度。
19，sprint迭代评审会：1，演示，获得反馈；2，更新待办事项列表PB。
20，站会上不解决问题，但是会后要解决。遇到障碍应该在站会后沟通解决方案，障碍不是需求，也不是新的规则内容，可以再当前sprint解决，尤其是技术问题，不解决无法继续执行。放PB内容：新需求，新规则，评审发现的新缺陷，需要的改进等。
21，项目规划阶段，多年计划包括很多跨职能干系人，跟人有关，首先制定干系人的沟通管理计划。
22，sprint规划是确定当前sprint工作内容。要解决团队冲突，要和团队一起回顾，总结经验教训和改进。不是sprint规划。

1，站会上只说明各自工作内容和障碍，不评论其他内容，也不会褒奖或者批评别人，所以要强调站会基本规则，然后关注障碍和给予帮助。站会上遇到的问题，会后解决，而不是冲刺回顾中解决。
2，基本套路之一：采购中遇到任何问题和争议，首先查看合同&协议。
3，前说：该框架没有定义好哪些工作时可以测量的，那么就先定义到底哪些可以测量
4，计划扑克：多轮估算，计划驱动，用于估算故事的大小。是基于德尔菲估算技能、是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。
5，不同时区导致的工作停顿，是时差导致的问题，所以项目经理应该制定客服时差的挑战，安排好工作任务和时间。
6，敏捷应该如何评估和管理风险？在每个sprint中通过每日站会、迭代会和回顾会中形成反馈。
7，沟通需求：沟通的方式、所需信息的内容、格式、详细程度等。
沟通被理解并要求反馈，这是沟通的模型。沟通方法：推式、拉式、交互式。
8，确保团队作为一个有组织的单位来运转：1，定规矩，团队章程和团队行为。
9，动用管理储配要走变更，变更批准后要纳入到成本基准里。项目预算=成本基准+管理储备。应急储备已经包含在成本基准里。
10，团队缺少主题专家SME，未来也需要这种专业知识，所以意思是，我们需要培训一名成员成为SME。有选项里“下一次”的意思是要等待，一般来说很少选择。
11，客户没有敏捷经验，我们要服务于客户及干系人，给别人推荐计划或者文档这种方法是让别人自己去学，不符合仆人式服务的原则。
12，有人离开，先查原因，再查影响。
13，询问最小可行产品MVP成本，说明项目还没开始，也就没有EV、CPI和BAC等。敏捷没有控制账户（在WBS讲过），并且自上而下估算不够细致。
14，团队成员有成功之处，最好的办法是开项目组会议，并记录该成员的贡献。项目管理计划是个指南，不做记录成员信息。责任分配矩阵记录团队角色和职责，不记录成员贡献。
15，组建虚拟团队，招募资源和沟通，确定活动需要的类型和数量这属于估算活动和资源，输出rbs（资源分解结构），跟组建团队没关系。要考虑成员的档期和时间，类似与资源日历。
16，干系人问题，管理干系人参与（早识别早分析早参与），获得干系人支持。跟风险没关系。
17，敏捷什么情况下产生影响？在考虑变更还是不变更的时候考虑，敏捷让PO处理优先级，而不是团队成员评估影响。
迭代评审会除了演示交付成果外，还更新待办列表（PB）。
18，敏捷五个事件：sprint，sprint规划会议、站会、评审会、回顾会。五大事件。
19，推进里程碑：进度压缩。
20，哪些文件能确保项目成功？组织过程资产、历史经验教训和问题日志。项目还没开始做，项目范围说明和管理计划只能说明项目要做什么，不能确保项目成果。
21，敏捷方法要什么因素才能交付产品？产品待办列表、产品愿景、产品路线图。项目刚开始，还没开始计算绩效指标，所以不涉及进度绩效等绩效指标。
22，为了确保快速交付，关于进度分析，预测型则关注进度压缩，敏捷型关注MVP、优先级等。主要关注两点：找到关键路径，对关键路径进行压缩。满足里程碑只能是按计划进行，而不是快速交付。

1，改善干系人关系，两个答案都正确的话，考虑完整性和优先操作。干系人参与计划是搞人策略，要更新的是干系人登记册。
2，混合方法对组织来说是新的，那么混合方法不一定能制定详细的进度计划，且同步干系人的不仅仅是计划。
3，敏捷项目拥抱变更，无需提交变更流程，变更要放到待办列表里下个sprint评估。
4，干系人存在分歧，要找PO负责沟通澄清。帕累托是查询问题的主要原因，28定律。
5，发现类似项目，优先考虑：组织过程资产（之前的经验教训）、类比估算。
6，仪表盘是工作绩效报告的一种形式，沟通将使用这种形式，属于沟通管理计划有关。
7，敏捷，细化用户故事是PO产品负责人的事，不是敏捷教练的事情。
8，干系人没有时间，本质上是干系人参与度不够，所以要加强干系人参与，要求他来开会等。
9，团队的角色和职责，记录在资源管理计划里，而不是RACI矩阵里。
10，需求不清楚应该先澄清需求，明确需求后再创建原型。
11，文件的版本不对，消息的迟发、缓发等，算沟通问题，查阅沟通管理计划。
12，项目经理上报：明确说 项目经理无能为力，现在要做的事情超出项目经理的权限。
PM难以获得干系人的验收，已经无能为力，只能上报领导/发起人。
13，确认到期是项目延期，还是资源日历冲突，但根源是资源日历冲突的问题，所以本质上要考虑资源管理计划里的冲突管理。
14，之前的经验教训——组织过程资产，在开工会议的作用是，传达项目目标，阐明干系人角色和职责，获得干系人对项目支持的承诺。在这个会议上，要让客户在这方面的职责。
15，莫斯科评估和卡伦模型是用来排优先级，成本效益分析是评估值不值得，投资回报比是财务指标，商业论述里的；挣值分析是说明绩效。
16，spi 1.8，cpi 0.1，进度快了一倍，成本超支10倍，说明资源投入不合理，资源过度使用导致成本超支，俗称盲目赶工，所以要修订资源管理计划。
17，团队建设：促进团队协同工作；减轻压力加强合作对应的工具是情商。
18，干系人变更，首先更新干系人登记册，沟通是更新沟通管理计划，但是项目团队更新什么文件来保持适当沟通？注意，团队不能直接更改计划，需要走变更流程。团队能直接修改项目文件。所以，项目经理让团队更新 <干系人登记册>，来进行适当的沟通。