申明：本笔记来自极客时间《项目管理实战20讲》，侵删。
【硬技能篇-上】4-15节
四、启动：识别项目中的四类干系人
-
“高利益 - 高权力”代表：项目发起人
需要与项目发起人确认的问题列表
与发起人确认的问题列表.png -
“低利益 - 高权力”代表：职能经理
职能经理是资源池的所有者，他们所管辖的团队通常覆盖多个项目或项目群，这也使得他们与单个项目的利益相关度通常比较低。
反对者：管理关键：建立信任、化解敌意
支持者：创造更多空间和机会，让他们能够深度参与到这个项目的决策或创意环节。这样可以增强他们的主人翁意识，也会给整个项目组带来最大的收益。
中立者：在条件合适时，进一步将其转化为支持力量。但如果你精力有限，可以先不管。
可以沟通了解的问题列表：
与职能经历确认问题列表.png -
“高利益 - 低权力”代表：项目组成员
这是与项目结果直接相关、但对决策影响不大的一类人。
管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难。
与项目组成员确认的问题列表.png - “低利益 - 低权力”代表：外围支持人员
五、规划：排除计划中的延期地雷
做计划的5个标准动作：
- 第一个标准动作：WBS 工作分解（Work Breakdown Structure），创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。
- 第二个标准动作：识别依赖并画出关键路径，这一步意味着我们开始从目标的角度对资源进行统筹思考。
- 第三个标准动作：定义完成标准，越早定义完成标准，计划按照期望完成的概率就越大。（如：需求/设计确认、功能完成/提测、里程碑）
- 第四个标准动作：达成共识并公开透明，没有达成共识的计划，是不具备任何效力的。（信息同步！）
-
第五个标准动作：及时调整变更
计划对照表
计划对照表
六、执行：打造品质，要从头开始“闭环”
在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制，系统根据反馈自动调节。
-
方案评审（OARP 决策机制）
负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
批准者 （Approver)：最终批准者；
审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。
方案决策机制.png - Bug Bash（Bug 大扫除）
是指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品。
组织：
时间：测试--全面功能结束后；需求审计--需求设计稿完成后）
地点：独立的作战室
参与者：研发和测试，产品、设计、市场、运营、销售等项
现场安排：展示反馈问题，调整排名
活动结束：公示结果，明确修复计划 - 冒烟用例评审
让开发和测试对标准的冒烟用例集达成约定，这个约定就会成为进入测试的准入标准。
七、监控：进展“巧”汇报，学会用数据说话
- 紧急汇报：直面问题有章法
紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告，5个基本元素：事件描述、影响后果、跟进分析（说明具体 情况）、相应措施（解决方案）、所需支持。
总结：在紧急时刻勇于站出来承担责任，尽可能简洁地描述清楚可能的影响和后果，目前的建议方案和所需支持，最大程度地争取各个相关环节的协同配合，共同应对问题。 -
常规汇报：项目周报回答的三个问题
整体项目状态评估、风险列表、项目概况及计划变更情况
周报模板图.png -
数据汇报：善用“透明”的力量
利用图表直观地进行过程预测和风险预警
Jira：发布倒计时、工作量燃尽倒计时、剩余工作量、工作状态分布
图表举例.png
wiki：周报晴雨表
周报晴雨表.png
八、收尾：项目复盘，小团队也要持续改进
项目复盘会：项目团队有意识地向过去的行为经验学习的过程，做得好的沉淀经验，做得不好的优化改进，
- 复盘会的基调设定：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的
- 复盘会的会前准备：项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些是客观数据的总结。同时，你还可以提前收集这个版本期间，团队满意度的问卷调查，为复盘会引入更多主观的输入
-
复盘会的简易流程
1.现场回顾总结项目过程
2.与会人员反馈：做得好、做得不好的点
3.讨论
4.投票总结，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。
复盘流程 - 打造团队持续改进能力
决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。复盘在于精准有效，不在多和形式。
九、需求变更：化解程序员的“头号噩梦”
-
常见的需求变更流程
需求变更流程 - 锦囊 1：达成最小共识，变更是有代价的
1.变更清单
2.成本估算
3.邮件通知 - 锦囊 2：源头治理，一次把事情做对
从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。产品、设计人员：小黑屋 + Deadline - 锦囊 3：快试错，不可抗力巧应对
老板需求，快速应对，小范围试错，用数据说话
