- 先分析、后行动
- 先与第一责任人沟通
- 避免问题升级，先礼后兵
- 给机会，促改进
- 有变更，走流程
- 没有规矩，不成方圆
- 积极主动，解决问题
- 迭代途中，非紧急不中止
- 有效解决问题，而不是只将问题罗列展示出来
- WBS 工作分解结构与项目范围相关，与进度无关
- 需求变更提交给项目经理，基准变更提交给变更委员会CCB
- 项目组合是目标相同，但涉及到资源（优先级）的项目或项目集组合
- 解决方案架构是记录问题的；
- 待办事项列表是根据用户故事和价值排优先级的；
- 工作说明书是项目可交付成果描述的；
- 商业论证是关于成本、价值、效益分析、经济可行性分析的；
- 成本效益分析是用来比较项目成本和收益的分析工具，在商业论证时会用到成本分析技术；
- 效益管理计划包含效益、战略一致性、实现效益的时限、责任人、测量指标、风险；
- 组织过程资产包括可用于执行治理项目的任何工件、实践、知识，还包括组织以往项目的经验教训、历史信息、成本标准等；
- 项目章程记录了关于项目和预期交付产品、服务或成果的高层级信息，包含商业论证；
- 团队章程是为团队创建团队价值观、共识、工作指南的文件
- 项目管理计划可以帮助团队了解项目的范围、进度、成本、质量目标以及实现目标的方式；
- 资源分解结构：资源依类别和类型的层级展现
- 工作分解结构：团队为实现目标，创建所需可交付成果而需要实施的全部工作范围层级分解
- RACI 矩阵：指导成员了解谁应该承担哪些任务和责任、谁应该被咨询、应该被知情、应该对什么任务负责；减少团队成员之间的混淆和冲突
- 有曾经失败的经历，那优选吸取经验教训；
- 风险是未发生的，记录在风险登记册；问题是已发生的，记录在问题登记册；
- 留意题干中的“避免”“预防”“提前”“事先”等字眼，要选择前置措施；
- 新出现的问题，优选可行性分析、适用性分析等；
- 别动不动就选上报，百分之九十的题不会选择上报，只有题干中明确表示多次尝试解决无果，才会选上报；
- 项目经理被要求执行有悖于常规的操作，即使是项目发起人提出的，也不能直接遵循，首选向上级寻求帮助
- 事业环境因素：项目团队不可控，将对项目产生影响，可外可内；
- 组织过程资产：执行组织特有并使用的计划，包括知识库、经验教训、历史信息等；
- 管理储备应该应对未知-未知风险，不能用于已知风险，而且要走变更流程；
- 项目的可行性应该由发起人或高级管理层来判断；
- 项目经理的权限（大-小）：项目型、强矩阵、平衡矩阵、弱矩阵、职能型
- 启动项目 - 需求评估 - 商业论证/成本效益分析
- 人才三角：技术项目管理、领导力、战略和商务管理
- 每日站会是团队内部同步信息的，不适合所有干系人都参与
- 产品待办事项列表中的事项优先级是根据事项的价值来确定的
- 敏捷四个会议：
a. 迭代评审会议：演示完成的工作
b. 每日站会：内部会议。做了什么、要做什么、有什么障碍
c. 迭代回顾会议：检视自身，措施有效性、找出原因、提出改进
d. 冲刺计划会议：决定本次交付成果和为了达成目标如何工作 - 题干中出现“创新”等词汇，说明项目需求变更会频繁，会采用敏捷方式，特性：频繁小规模交付增量价值。分解为 sprint 逐步交付。
- Dod 工作完成准则
- 敏捷原则：最高目标，尽早、持续的交付有价值的软件来满足客户需求
- 敏捷奉行理论：自我要求高、追求自身价值、自我激励，主动性、归属感、精神激励大于物质激励
- CPI 成本绩效指数，小于一，超支，大于一，结余
- SPI 进度绩效指数，小于一，落后，大于一，超前
- 敏捷团队每日站会中团队成员抛出问题，项目经理不需要干涉，让他们自己去讨论就行（等待团队独立识别问题并解决）
- 敏捷。自组织的速度本身是根据团队实际能力来承诺的，承诺应该与团队能力匹配，如果承诺无法定期交付，需要调整承诺以符合团队实际能力
- 关键相关方的意见会影响整个项目，必要时可以找发起人协助
- 赶工是加班，会有额外成本；快速跟进是并行，会有额外风险。
- 敏捷——项目经理指导团队自主解决问题，而不是提供解决方案
- 识别相关方 - 需求、期望未满足
- 相关方分析 - 顺序、作用、优先级、权利、利益
- 相关方登记册 - 变化、了解相关方信息
- 相关方参与计划 - 规划参与策略
- 相关方参与评估矩阵 - 参与状态，确保参与
- 相关方参与计划 - 态度、冲突、输入相关方评估信息、相关方管理策略（包括沟通策略）
- 关键相关方成为阻力 - 尽快让其参与进来
- 相关方存在疑虑 - 展示（演示）有效信息
- 相关方态度有问题 - 先分析后行动
- 相关方存在需求冲突、抱怨、意见不合 - 沟通建立共识达成一致
- 会议管理 - 混乱 - 规范会议章程
- 会议 不积极 发言 - 鼓励
- 沟通 - 需求与计划不一致 - 优选达成一致
- 异地团队 - 重点考虑文化
- 管理沟通 - 根据沟通管理计划进行信息传递
- 审查沟通管理计划是否正确的实施以达成正确的效果
- 敏捷 - 也需要即使更新文档
- 敏捷 - 以价值为核心，小块交付 - 尽早 - 为 客户 - 持续 - 增量交付； 拥抱变化，即使后期也应该尽可能得满足客户需求，但是没价值的事不做（和客户解释原因）
- 敏捷沟通 - 公开透明面对面
- 产品负责人PO - 对接客户，收集需求，聚焦产品开发方向
a. 产品待办事项列表
ⅰ. （共同）创建PB并澄清需求
ⅱ. 排序（根据价值，高于成员）
ⅲ. 与团队或相关方共同讨论并梳理 PB
ⅳ. 创建/调整 PB 要考虑风险 - 敏捷 - 自组织团队
a. 自我管理，自领任务，专注于一个项目
b. 通才型专家，有效提升效率，减少孤岛、竖井
c. 首选集中办公、远程结对
d. 迭代待办事项列表（非特殊情况，不轻易变化，确保目标达成后再进行其他工作） - 敏捷教练 - 仆人
a. 辅助、服务、解决问题、协助团队（不直接上手干活儿，不直接干预团队，但可以提出建议）
b. 维护团队氛围、建立信任关系、鼓励探索、支持讨论
c. 促进合作、了解状态、指导、激励、承担对团队成员的培训
d. 需要出手：
ⅰ. 相关方/团队 违反敏捷原则 - 指导学习了解敏捷原则
ⅱ. 团队无法自行解决的障碍、外部障碍或影响绩效的障碍 - 清除
e. 不出手：
ⅰ. 碰到障碍问题 - 优先提倡团队自我纠正、团队合作
ⅱ. 业务、技术问题 - 不插手，优先让团队自行解决，内部无法解决再出手 - 五大过程：启动、规划、执行、监控、收尾
- 客户讨论 - 达成共识 - （项目愿景 - 项目章程） - （产品路线图 = 用户故事） - 发布计划（产品待办事项列表） - 细化（估算优先级、DOD 认领）（迭代规划会议） - 迭代计划（迭代待办事项列表） - 开发执行（每日站会） - 已完成的用户故事 - 迭代评审会议 - 未完成的交付+可交付增量产品 **** 迭代回顾会议 - 改进措施
- 启动（制定项目章程） - 参考组织过程资产，符合组织管理战略，整体目标、成功标准、高层需求、审批要求等。 需求与项目章程中内容不一致，上报发起人。 作用：正式启动项目，不可或缺，PM 的大保健
- 规划（制定项目管理计划） - 传达目标、阐明角色和职责，获得团队承诺，树立团队信心
- 执行（指导和管理项目工作） - 根据期望完成既定、超出权限上报
a. 问题日志，有问题先更新，确保问题得到解决
b. 解决问题：先分析，达成一致，确定措施，执行
c. 重复问题：找到根本原因，对症下药
d. 已知-已知风险 当做问题处理（还没有发生影响，但明确已知会发生影响的）
ⅰ. ★ 已知-已知 ： 已知风险存在，已知风险影响（包含影响已发生的和未发生的，只要明确指导会发生影响，就是已知）
e. 有问题：解决问题并考虑风险
f. 与项目无关的需求，建议新开合同 - 隐性知识优先通过人际交往分享，面对面 知识分享会议
- 不论隐性&显性，经验教训应该在整个项目周期向相关方收集
- 确保项目文件等经验教训存储在存储库或PMIS中
- 监控：监控项目文件。监控让项目目标得以实现
- 成本效益分析：不知道项目如何带来效益、通过成本效益分析来决策
- 变更：涉及到 范围、进度、成本、权限 都要走变更流程
- 变更流程提交给 PM
- 法律导致的影响，也要提交变更请求，提交之前要分析可行性和影响
- 批准变更后，相关方没有按照变更执行 - 没有通知到位
- 变更控制流程，确保相关方了解正确的变更重要性
- 未提交变更请求的情况下执行变更，即使是镀金，也需要补充变更流程
- 特殊情况：基准确定之前，无需变更流程；部分题目中，非 范围、进度、成本、权限等，且由项目经理来做的，会默认通过了变更流程审批这个步骤（因为本身就是提交给项目经理审批）
- 收尾，先验收通过， 可交付成果转移，测量相关方满意度，评估交付价值，访谈获取准确数据
- 最终版项目文件报告包含未能实现的效益后续监控方案
- 收尾 - 组织过程资产更新，需要更新，责任人 pm，提前终止也要收尾（包括组织过程资产更新）
- 收尾 - 上报 - 通过验收标准，但相关方拒收 - 寻求发起人帮助
- 收尾 - 上报 - 成果移交后不满足商业论证 - 上报处理
- 收尾 - 上报 - 提前终止，项目无法实现业务价值 - 上报重新评估商业价值获得审批后终止
- 收集需求 - 怎么做：
- 需求跟踪矩阵 - 需求&结果
- 定义范围 - 先收集需求，后定义范围
a. 专家判断 - 引导
b. 内容： 可交付成果，验收标准 - WBS - 定义范围的下一步，以可交付成果为导向
- 确认范围：正式验收，验收的依据 - 范围说明书、合同
- 可交付成果流向 - 控制质量 - 确认范围 - 收尾之间的顺序
- 控制范围：监督范围状态、管理范围基准变更。拒绝镀金，拒绝蔓延
- 成本：估算，前期粗略，后期确定
- 类比：参考类似，快速估算
- 上而下：精准估算，基于 WBS
- 三点估算：默认贝塔 悲 + 4 可 + 乐 /6
- 制定预算：
a. 参考相关方建议
b. 成本基准包括应急储备
c. 应急储备使用场景 - 已知风险，未知影响 - 偏差分析， < 0 或 < 1 的是不好的走向
- 成本绩效 CPI = EV /AV
- 进度： 赶工&快速跟进，赶工就是加班（高成本，低风险），快速跟进就是并行（低成本，高风险）
- 保证关键路径避免延期
- 进度落后，考虑时间储备
- 管理质量的重要性 - 过程
- 控制质量的重要性 - 结果
- 帕累托图 28 原则 找主要原因的
- 采购管理计划 指导采购活动和步骤
- 协议或合同，明确验收标准，约束供应商，有争议，先审查合同或采购说明书（SOW）
- 控制采购：谈判（首选）、ADR、仲裁、诉讼
- 合同内容与实际不一致，需变更合同
- 采购模块遇到问题，与采购部门沟通协商解决
- SWOT 识别风险的工具
- 定量风险，概率x收益
- 应对策略： 减轻 、 转移 、 接受
- 已识别风险：更新风险登记册，准备应对方案
- 未识别风险：先分析影响和风险，后行动
- 监督风险：持续监督，确保风险管理过程的有效性
- 出现偏差：与相关方沟通合作
- 迭代，不轻易改变
- 滚动式规划、愿景、产品路线图、、发布计划、迭代计划、每日计划
- 用户故事：
a. 故事不清晰，与用户沟通，有必要重写
b. MVP 最小可行产品
c. 故事太大：功能复杂、估算不准、需要拆分用户故事
d. 根据故事点估算来控制项目范围，预算或进度，计划扑克
e. DoD 确保产品增量满足需求（PO 确定和评估）
f. 以用户故事的价值为核心进行优先级排序
g. 不能通过完成的故事节点来评估不同团队的绩效 - 敏捷风险 - 持续监控、反馈、评估，原则上越早发现越好
- 团队绩效：挣值分析
- 速度
a. 越稳定越好：规划迭代工作事项时应该考虑以往迭代的速度
b. 燃尽图，了解速度和进度
c. 预期速度未达到 - 调整速度，发布计划
d. 依照速度计算所需要的迭代数： 迭代次数 = 总故事 ÷ 速度 结果向上取整 - 敏捷 - 五个事件：
a. 迭代冲刺：迭代规模应适合迭代持续时间
b. 迭代规划：接下来要进行的迭代及输入PB（迭代计划）输出SB（迭代目标）
c. 每日站会：同步信息，提出障碍（不解决），强调规则、共同讨论、共识优选；
ⅰ. 缺： 缺乏彼此了解
d. 迭代评审：演示/展示价值，获得相关方反馈；减少返工，找准方向；会后的问题解决
e. 迭代回顾：总结、改进、反思、找到根本原因提出解决办法 - 和预测相比：更提倡及时解决、轻文档、轻流程（轻不代表没有）
- 项目集合：依赖
- 项目组合：优先级
- 商业论证：确定经济可行性（PM无权拍板）
- 效益管理计划：分析商业价值（有形、无形）；目标效益、战略一致性、实现效益的时间；净现值、投资回收期（同时出现优选净现值）
- 事业环境因素：不可控
- 组织过程资产：内部，避免失败、未来参考、新人参考
- 特殊情况可以找 PMO
- 考虑合规影响，避免后续问题
- 根据项目特点选择生命周期类型
- 转型：
a. 预测不适用，转敏捷 === 混合过渡
b. 自上而下逆转思维、频繁沟通、蚕食、事先沟通、解决障碍、分享决策、设定愿景
c. 评估是否适合转型。PM 先分析，不站队
d. 相关方不支持，无敏捷经验 === 指导相关方，不强迫，获得相关方认可，宣传转型的好处 - 混合：
a. 混合项目的 PM：鼓励、支持、指导、解决障碍（偏向敏捷）
b. 建立团队章程、加强沟通、促进协作、优选沟通、合作、共同决定
c. 混合变更：根据题干背景判断走流程还是和 PO 合作或同时进行
d. 混合资源管理：先内后外，新人 == 帮助； 老人 ==共识 - 看板：可视化工作流动、共识信息、促进沟通（仪表盘、冲刺板、障碍板）
a. 限制在制品（WIP），任务过重或积压过多、出现瓶颈，考虑限制WIP - 结对编程：知识分享、老带新培养新人，激发工作热情
- 技术债务：跳过测试，可能会导致技术债务增加
a. scrums of scrums： 类比项目集管理， 问题 首选 - 内部提出的变更（先评估，走流程，评估不可行就不用走流程），外部提出的变更（记录，走流程，无论最终是否批准都要走变更请求）
- 合规的优先级高
- 敏捷 ====== 价值为导向。没有价值的提议，忽略，有价值的提议（不管是成本，还是进度）就让关系人参与进来一起讨论
- 分析协议边界的意思是，分析对方可以接受的范围，通过谈判，给项目团队一定范围内的特殊的规定
- 敏捷的成本和进度一般都是固定的，对于已经超支的，可以通过缩减范围或增加预算来满足进度
- 能解决的问题就先解决方案，不要当做风险来对待，风险有点消极处理
- 产品待办事项列表式产品负责人去搞的哦，项目经理不要瞎搞，至少也要和产品负责人一起
- 需要高度专业专家说明团队自组织能力强，向团队解释高层级目标，更清晰的了解情况，双方达成共识
- 报告： 整理数据 准备 纳入报告阶段， SOP 创建报告（包含数据分析、统计、解释）
- 预算、确定、数量 级估算 都是对项目的估算等级
- 故事点估算，是估算技术
- 趋势分析： 预测未来
- 进度分析： 检查进度是否符合预期
- 质量分析： 核对可交付成果和质量标准
- 根本原本分析：识别偏差
- 产品交付后的支持 === 就是售后！
- 敏捷中遇到变更，联系产品负责人、更新产品待办事项列表，重新进行优先级排序。
- 评审过程中 2 个重点： 可交付成果本身（质量、进展）、项目整体状态（绩效、成本、进度、风险）
- 风险管理计划是指南性文件，里面没有风险应对措施等等，区分风险登记册