启动：识别项目中四类干系人
干系人分析，是指对项目干系人进行分析和归类，有针对性地规划管理其核心诉求和期望，让干系人可以更好地参与项目，对项目产生积极影响，从而更好地保障项目目标的成功达成
需要通过积极的干系人管理，尽可能把反对的力量变成支持的力量，同时发掘和调动中间力量。
干系人分四类
高利益-高权利
项目发起人Sponsor
目标
背景跟初衷是什么
整体目标跟愿景是什么
如何做到
资源
哪些资源短缺或限制因素
涉及到哪些外部资源的管理
哪些是项目获得成功的关键资源
流程
项目组的决策流程怎么样的
如何通过审核
如何确认变更
团队
组织结构
团队组建多长时间
各个角色合作状况如何
是否有特别需要关注的状况
沟通
通过什么渠道了解项目状况
以什么样方式保持信息同步
哪些风险和问题需要经过特别审批
期望
看得项目哪个要（进度/质量/成本/范围）
极端情况下，要素如何排序
能带来哪些方面提升
高利益-低权利
职能经理
是资源池的所有者
强烈的态度背后，一定反映干系人对现状的某种认知，只有真正理解了对方的逻辑，才有可能进一步对其施加影响
问题
目标
整体目标是什么
目前完成情况如何
信心如何
潜在风险
合作
团队与团队间合作是否顺畅
不同团队沟通渠道
最需要什么支持
团队
团队构成与分布，比如总人数、资深工程师的分布。
团队稳定性
成员分工
沟通
成员信息渠道有哪些
你需要参加哪些项目会议，成员需要参加 哪些会议
低利益-高权利
项目组成员
流程
项目计划如何确定
变更是否周知
任务分配、跟踪流程是怎么样的
文档管理、发布流程、需求变更流程是什么样的
使用哪些工具
期望
管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难。
规划：排除计划中的“延期地雷”
计划是贯穿始终的重要课题，是各个角色协同工作的基准
利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具
从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程。省去对焦的步骤，就会给后续的执行工作埋下很多“地雷”
扫雷游戏
雷区 1：不够具体
好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。
WBS 工作分解（Work Breakdown Structure）
第一步：创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。
做计划的方式的转变，背后其实是思维方式的根本转变
雷区 2：不够全面
识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考。
第二步：关键路径是决定项目工期的进度活动序列。它是项目中最长的路径，关键路径的工期决定了整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间。
雷区 3：不够准确
第三步：做计划的第三个标准动作了，就是定义完成标准。
雷区 4：没有共识
没有达成共识的计划，是不具备任何效力的。
达成共识并公开透明，就是做计划的第四个标准动作
雷区 5：不够即时
重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。
及时调整变更，就是做计划的第五个标准动作。
5 个标准动作
WBS 工作分解，识别依赖及各环节关键路径，定义完成标准，达成共识并公开透明，即时调整变更
执行：打造品质，要从头开始“闭环”
需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制
开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节。
三种闭环验证方法
方案评审（OARP 决策机制）
OARP 是 Owner、Approver、Reviewer、Participant 的缩写
负责人OWNER:负责给出方案，组织各方讨论并推进做出最终的决定
批准者： APPROVER:最终批准者
审核者REVIEWER：负责和批准挑选出的审核人。讨论分析并提出反馈意见，负责人必须重视并给予回复。
参与者PARTICIPANT：其他提供意见人。
Bug Bash（Bug 大扫除）
指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品。
组织一场 Bug Bash 活动
时间
地点
参与者
现场安排
活动结束
冒烟用例评审
做计划时要明确定义完成标准，而冒烟测试用例，可以说是开发和测试之间最基础的合约。
先从测试人员记录冒烟测试通过率开始，冒烟通过率的要求通常是 100%，你可以选择从一个合适的起点开始，比如 80%
评审的精髓不在会，而在于背后的决策机制
监控：进展“巧”汇报，学会用数据说话
紧急汇报：直面问题有章法
紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告
5 个基本元素
事件描述
影响后果
跟进分析
响应措施：包含负责人及时间表
所需支持
常规汇报：项目周报回答的三个问题
整体项目状态评估、风险列表、项目概况及计划变更情况
收尾：项目复盘，小团队也要持续改进
复盘是对思维的训练，而项目复盘会，可以说是项目团队有意识地向过去的行为经验学习的过程
复盘会的基调设定
在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要。
首先，我们自己要先进入反思区
这次复盘不是来挑问题的，而是为了找到问题的根源并改进的
复盘会的简易流程
现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论
对大家总结出的好和不好的点，进行集体投票。
由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案
决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。
认真地做好一次复盘，每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了！畅所欲言
