项目管理实战20讲个人总结（二）

申明：本笔记来自极客时间《项目管理实战20讲》，侵删。

【硬技能篇-上】4-15节

四、启动：识别项目中的四类干系人

• “高利益 - 高权力”代表：项目发起人
  需要与项目发起人确认的问题列表

  
  
  与发起人确认的问题列表.png

• “低利益 - 高权力”代表：职能经理
  职能经理是资源池的所有者，他们所管辖的团队通常覆盖多个项目或项目群，这也使得他们与单个项目的利益相关度通常比较低。
  反对者：管理关键：建立信任、化解敌意
  支持者：创造更多空间和机会，让他们能够深度参与到这个项目的决策或创意环节。这样可以增强他们的主人翁意识，也会给整个项目组带来最大的收益。
  中立者：在条件合适时，进一步将其转化为支持力量。但如果你精力有限，可以先不管。
  可以沟通了解的问题列表：

  
  
  与职能经历确认问题列表.png

• “高利益 - 低权力”代表：项目组成员
  这是与项目结果直接相关、但对决策影响不大的一类人。
  管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难。

  
  
  与项目组成员确认的问题列表.png
• “低利益 - 低权力”代表：外围支持人员

五、规划：排除计划中的延期地雷

做计划的5个标准动作：

• 第一个标准动作：WBS 工作分解（Work Breakdown Structure），创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。
• 第二个标准动作：识别依赖并画出关键路径，这一步意味着我们开始从目标的角度对资源进行统筹思考。
• 第三个标准动作：定义完成标准，越早定义完成标准，计划按照期望完成的概率就越大。（如：需求/设计确认、功能完成/提测、里程碑）
• 第四个标准动作：达成共识并公开透明，没有达成共识的计划，是不具备任何效力的。（信息同步！）

• 第五个标准动作：及时调整变更
  计划对照表

  
  
  计划对照表

六、执行：打造品质，要从头开始“闭环”

在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制，系统根据反馈自动调节。

开闭环系统.png

• 方案评审（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：快试错，不可抗力巧应对
  老板需求，快速应对，小范围试错，用数据说话