PMP项目管理介绍及指导

发布于 2021-01-03  225 次阅读


PMP项目管理介绍及指导

瀑布模型定义

瀑布模型是最典型的预见性方法论,核心是按工序将问题简化。瀑布模型需要严格遵循预先计划的需求,分析,设计,开发,测试步骤进行。步骤成果是作为衡量进度的方式。

瀑布的优点:

为项目提供按阶段划分的检查点

当前一阶段完成后,只需要关注后一阶段

可在迭代模型中应用瀑布模型

提供了模板,使得分析、设计、开发、测试和支持可以在该模板下有一个共同的指导

瀑布的缺点:

各阶段的划分完全固定,阶段之间产生大量文档,增加了工作量

由于开发模型是线性的,用户只有等到整个过程末期才能见到开发结果,增加了风险

通过过多的强制完成日期和里程碑来跟踪各个项目阶段

不适应用户需求的变化

适配项目类型

是否使用瀑布模型,主要取决于是否能够理解用户需求,以及在项目进程中这些需求的变化程度。对于经常变化的项目而言,瀑布模型毫无价值。

对于有明确项目需求,要求稳定安全,对快速响应能力和弹性架构要求较低,有丰富的行业实践经验的项目,多采用瀑布式项目管理方式。

瀑布虽然不如敏捷灵活,但是它仍然在项目管理中有很多优势,尤其是对项目的线性管理。所以现在很多项目管理,更多的是将瀑布和敏捷相结合,形成螺旋模型。

不管是使用哪种项目管理方法,其核心逻辑并没有冲突。我们都需要在项目开始前有一个大致计划,包括需要对整个项目交付什么,有哪些必须的流程,以及大致交付时间做到心中有数。

如何执行

五大关键环节:

启动:目标,授权

计划:基准,任务

执行:实施,协调

监控:偏差,验收

收尾:归档,复盘

启动&计划

启动:需要定义清楚目标,明确产出,了解项目的限制及上下游关系。

干系人通常包括:合伙人,依赖方,资源中心,资源竞争者等。

职责明确:对于复杂或长期的项目,建议使用RACI模型,定义明确各角色的职责分工。

 

计划:是各个角色协同工作的基准。项目管理是从全局视角出发,去推动项目整体目标的落地,优化各个角色的协同过程。而计划就是可以借助的重要工具。计划的本质是用来对焦拉齐的。做计划,就是集体对焦的过程。做计划容易遇到的雷区:

不够具体:使用WBS工作分解,把项目工作按阶段交付成功分解成较小的,更易于管理的组成部分

不够全面:识别关键路径,流程可视化

不够准确:定义完成标准,例如需求/设计确认,功能完成/提测,里程碑完成(例如,质量已达适当水平,如不存在P0,P1 bug,可以上线发布)

没有共识:达成共识并公开透明

不够及时:及时调整变更。计划永远是反复修正、逐渐明晰的过程。

 

任务拆解环节,尽量做到安排清晰,评估准确,防止有遗漏项。

渐进明细,持续更新,考虑充分

主动分配时间

关键路径分析。需要注意的是,关键路径并非不变,有时候会同时存在多条

具体拆解方法:

用户故事地图:每个用户路径相对独立,可以单独提测,一般用于大中型项目

独立场景划分:项目规模较小,用户路径之间耦合性较强

按页面或PRD功能划分:后台管理系统,APP等按页面功能划分的产品

风险评估:风险指影响最终达成项目目标的若干不确定因素。例如范围不确定,人员变动,方案不定等。在计划阶段,应该尽量识别风险,并判断风险发生的概率以及影响。越早发现风险,应对成本越低。

 

执行和监控

明确基准:

传统铁三角:范围,时间,成本

敏捷三角:价值,质量,约束。约束中,又需要考虑范围,时间,成本三者的相互制约

善用工具:规划拆解,追踪监控,实时归档,统一操作

变更评估:

需求变更:具体变更了什么,原因价值及影响,为什么现在变,是否有plan B,下一步计划是什么

时间变更:变更多少,为什么现在变,影响谁,备选方案/需要的支持,调整后的计划

资源变更:具体变更了什么及背景,对项目的影响,被影响的模块如何协调适配,是否可接受/规避/转移,新的计划和资源是什么

勿虚会:解决问题,作出决策,避免冗长

明确会议主题,主要成员到场,会议纪要同步,责任到人,控制节奏

日会(敏捷):清除障碍,有留存,轻监控

里程碑会:例如评审,提测

收尾

复盘:中立,深挖,落地,跟进

中立:不同视角,群体智慧,pros & cons都应该复盘

深挖:追问和剖析。反推:这样真的可以解决问题吗?

落地:警惕“意识”,“注意”,“加强”。潜在决策者,实施人的充分参与

跟进:todo执行情况,执行todo后的情况

风险管理

项目风险是不断变化的,即使同一个项目的风险,在不同时候,风险等级也是不一样的。因此,识别和应对风险,贯穿于项目全流程中。项目管理的目标在于降低风险的概率和影响,从而提高项目成功的可能性。

单个项目风险管理

启动阶段:

项目目标和价值不确定:梳理项目目标,明确产品价值,内容细化并量化

里程碑不确定:设立目标完成时间,结合经验倒排期,check核心里程碑

参与团队和人员不确定:确定涉及项目的团队,确定唯一接口人,确定核心成员,明确第三方成员

设计阶段

需求范围不确定:用户故事地图,MVP确定需求范围

需求产出依赖技术方案评估:确定技术侧负责人,有结论性反馈,技术调研前置

时间不确定:项目节奏提前规划,信息透明

需求设计不完善:流程图,相关方串讲

评审阶段

需求评审会上提的问题很少:需求前置沟通,提前发出评审需求,明确评审要求

需求影响范围评估不到位:梳理需求上下游关系,确定依赖关系

参与评审会人员不到位:和相关方确认参会人,录制视频会后沟通问题,更改时间

设计稿完整交付时间晚:参照开发工作顺序分批输出,记录内容清单避免遗漏

排期阶段

需求太大太多:用户故事拆分迭代,分迭代确定需求优先级

排期信息不满足业务要求:关键路径压缩工期,串行边并行

排期信息不同步:统一工具管理并公示,多方指定接口人并建立定期沟通机制

前置环节排期不明确:先确定工作量,关键路径内容拆解,渐进明细

开发测试

无法按时提测:站会制度,阶段成果检查,相关方封闭开发

提测失败:明确开发自测范围

bug多解决不及时:明确bug优先级,bug日清机制

变更时未作好同步:有效管理变更,落实变更流程

上线运营阶段

排除问题影响当前项目进度:预留资源,线上紧急bug优先,优化迭代

灰度过程收集不到问题:加强核心用户管理,明确灰度内容

 

项目集风险

范围

风险:外部涉及或影响的业务线不确定

应对:梳理内部逻辑及影响,沟通自身方案,判断对各方的影响。与各方同步需求并沟通影响点

排期

风险:跨项目排期困难,外部排期无法对齐

应对:追本溯源,统一收益,了解难点,协助推动向上寻求帮助

进度

风险:没有按时交付,里程碑未达成

应对:联合站会,资源封闭,feature team

 

 

 


人生有無數種可能,人生有無限的精彩,人生沒有盡頭。一個人只要足夠的愛自己,尊重自己內心的聲音,就算是真正的活著。