PMP项目管理介绍及指导
瀑布模型定义
瀑布模型是最典型的预见性方法论，核心是按工序将问题简化。瀑布模型需要严格遵循预先计划的需求，分析，设计，开发，测试步骤进行。步骤成果是作为衡量进度的方式。
瀑布的优点：
为项目提供按阶段划分的检查点
当前一阶段完成后，只需要关注后一阶段
可在迭代模型中应用瀑布模型
提供了模板，使得分析、设计、开发、测试和支持可以在该模板下有一个共同的指导
瀑布的缺点：
各阶段的划分完全固定，阶段之间产生大量文档，增加了工作量
由于开发模型是线性的，用户只有等到整个过程末期才能见到开发结果，增加了风险
通过过多的强制完成日期和里程碑来跟踪各个项目阶段
不适应用户需求的变化
适配项目类型
是否使用瀑布模型，主要取决于是否能够理解用户需求，以及在项目进程中这些需求的变化程度。对于经常变化的项目而言，瀑布模型毫无价值。
对于有明确项目需求，要求稳定安全，对快速响应能力和弹性架构要求较低，有丰富的行业实践经验的项目，多采用瀑布式项目管理方式。
瀑布虽然不如敏捷灵活，但是它仍然在项目管理中有很多优势，尤其是对项目的线性管理。所以现在很多项目管理，更多的是将瀑布和敏捷相结合，形成螺旋模型。
不管是使用哪种项目管理方法，其核心逻辑并没有冲突。我们都需要在项目开始前有一个大致计划，包括需要对整个项目交付什么，有哪些必须的流程，以及大致交付时间做到心中有数。
如何执行
五大关键环节：
启动：目标，授权
计划：基准，任务
执行：实施，协调
监控：偏差，验收
收尾：归档，复盘
启动&计划
启动：需要定义清楚目标，明确产出，了解项目的限制及上下游关系。
干系人通常包括：合伙人，依赖方，资源中心，资源竞争者等。
职责明确：对于复杂或长期的项目，建议使用RACI模型，定义明确各角色的职责分工。
计划：是各个角色协同工作的基准。项目管理是从全局视角出发，去推动项目整体目标的落地，优化各个角色的协同过程。而计划就是可以借助的重要工具。计划的本质是用来对焦拉齐的。做计划，就是集体对焦的过程。做计划容易遇到的雷区：
不够具体：使用WBS工作分解，把项目工作按阶段交付成功分解成较小的，更易于管理的组成部分
不够全面：识别关键路径，流程可视化
不够准确：定义完成标准，例如需求/设计确认，功能完成/提测，里程碑完成（例如，质量已达适当水平，如不存在P0,P1 bug，可以上线发布）
没有共识：达成共识并公开透明
不够及时：及时调整变更。计划永远是反复修正、逐渐明晰的过程。
任务拆解环节，尽量做到安排清晰，评估准确，防止有遗漏项。
渐进明细，持续更新，考虑充分
主动分配时间
关键路径分析。需要注意的是，关键路径并非不变，有时候会同时存在多条
具体拆解方法：
用户故事地图：每个用户路径相对独立，可以单独提测，一般用于大中型项目
独立场景划分：项目规模较小，用户路径之间耦合性较强
按页面或PRD功能划分：后台管理系统，APP等按页面功能划分的产品
风险评估：风险指影响最终达成项目目标的若干不确定因素。例如范围不确定，人员变动，方案不定等。在计划阶段，应该尽量识别风险，并判断风险发生的概率以及影响。越早发现风险，应对成本越低。
执行和监控
明确基准：
传统铁三角：范围，时间，成本
敏捷三角：价值，质量，约束。约束中，又需要考虑范围，时间，成本三者的相互制约
善用工具：规划拆解，追踪监控，实时归档，统一操作
变更评估：
需求变更：具体变更了什么，原因价值及影响，为什么现在变，是否有plan B，下一步计划是什么
时间变更：变更多少，为什么现在变，影响谁，备选方案/需要的支持，调整后的计划
资源变更：具体变更了什么及背景，对项目的影响，被影响的模块如何协调适配，是否可接受/规避/转移，新的计划和资源是什么
勿虚会：解决问题，作出决策，避免冗长
明确会议主题，主要成员到场，会议纪要同步，责任到人，控制节奏
日会(敏捷）：清除障碍，有留存，轻监控
里程碑会：例如评审，提测
收尾
复盘：中立，深挖，落地，跟进
中立：不同视角，群体智慧，pros & cons都应该复盘
深挖：追问和剖析。反推：这样真的可以解决问题吗？
落地：警惕“意识”，“注意”，“加强”。潜在决策者，实施人的充分参与
跟进：todo执行情况，执行todo后的情况
风险管理
项目风险是不断变化的，即使同一个项目的风险，在不同时候，风险等级也是不一样的。因此，识别和应对风险，贯穿于项目全流程中。项目管理的目标在于降低风险的概率和影响，从而提高项目成功的可能性。
单个项目风险管理
启动阶段：
项目目标和价值不确定：梳理项目目标，明确产品价值，内容细化并量化
里程碑不确定：设立目标完成时间，结合经验倒排期，check核心里程碑
参与团队和人员不确定：确定涉及项目的团队，确定唯一接口人，确定核心成员，明确第三方成员
设计阶段
需求范围不确定：用户故事地图，MVP确定需求范围
需求产出依赖技术方案评估：确定技术侧负责人，有结论性反馈，技术调研前置
时间不确定：项目节奏提前规划，信息透明
需求设计不完善：流程图，相关方串讲
评审阶段
需求评审会上提的问题很少：需求前置沟通，提前发出评审需求，明确评审要求
需求影响范围评估不到位：梳理需求上下游关系，确定依赖关系
参与评审会人员不到位：和相关方确认参会人，录制视频会后沟通问题，更改时间
设计稿完整交付时间晚：参照开发工作顺序分批输出，记录内容清单避免遗漏
排期阶段
需求太大太多：用户故事拆分迭代，分迭代确定需求优先级
排期信息不满足业务要求：关键路径压缩工期，串行边并行
排期信息不同步：统一工具管理并公示，多方指定接口人并建立定期沟通机制
前置环节排期不明确：先确定工作量，关键路径内容拆解，渐进明细
开发测试
无法按时提测：站会制度，阶段成果检查，相关方封闭开发
提测失败：明确开发自测范围
bug多解决不及时：明确bug优先级，bug日清机制
变更时未作好同步：有效管理变更，落实变更流程
上线运营阶段
排除问题影响当前项目进度：预留资源，线上紧急bug优先，优化迭代
灰度过程收集不到问题：加强核心用户管理，明确灰度内容
项目集风险
范围
风险：外部涉及或影响的业务线不确定
应对：梳理内部逻辑及影响，沟通自身方案，判断对各方的影响。与各方同步需求并沟通影响点
排期
风险：跨项目排期困难，外部排期无法对齐
应对：追本溯源，统一收益，了解难点，协助推动向上寻求帮助
进度
风险：没有按时交付，里程碑未达成
应对：联合站会，资源封闭，feature team