三、规划、排除计划延期的问题

工作中我们总会嫌麻烦,同时又过于自信,觉得计划完全没有必要。甚至是一拍脑袋,有一个想法就开始干,如果怎么样,到时再怎么样,这种无规划的方式,将会大大延期项目,同时带来无法预测的风险。
在项目管理中,计划是贯穿始终的重要课题,是各个角色协同工作的基准。
导致计划失败的这五大雷区。

雷区 1:不够具体

好的计划,不仅要给出时间节点,还要给出依据和来源,有因果才能更有效地对焦。利用WBS工作分解,可以清晰表示各项目工作之间的相互联系,帮助团队更高效地管理项目。
WBS 是项目管理领域非常重要的方法。创建 WBS 的过程,也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。

雷区 2:不够全面

任务列表,只是任务、完成时间,没有识别关键资源和任务前后依赖关系,没有考虑研发之外环节。
识别依赖并画出关键路径,就是我要讲的做计划的第二个标准动作,这一步意味着我们开始从目标的角度对资源进行统筹思考。清晰了关键路径之后,我们要对其进行持续关注,把关键路径上的风险作为最高优先级应对。
除此之外,在核心部分计划出炉以后,我们还要对项目涉及到的其他合作环节,进行全面地规划和安排,为各个阶段设定合理的里程碑节点,确保考虑周全。

雷区 3:不够准确

计划在执行中出问题的时候,总是会产生很多纠纷,大多是因为大家对一些节点的定义理解不一致,比如什么叫提测,什么叫里程碑完成。
做计划的第三个标准动作了,就是定义完成标准。
以最关键的几个常见时间节点为例,完成标准如下:
需求 / 设计确认:执行所需的需求稿或设计稿已经完成,而且公开评审通过,团队已经准备好要编写产品代码了。值得一提的是,有些团队还会对需求稿或设计稿做一定的要求,比如把未处理的反馈意见数小于多少作为标准。
功能完成 / 提测:所有定义的功能都已经完成(比如冒烟测试通过率高于 90%),团队已经准备好将焦点转移到质量保证上,并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队,也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等,作为更加细节具体的完成标准。
里程碑完成:质量已经达到适当水平(如不存在 P0 及 P1 优先级的 Bug),可以上线发布,或者可以开始下一个里程碑。

雷区 4:没有共识

其实,做计划本身并不是最难的,真正难的是什么?对焦!没有达成共识的计划,是不具备任何效力的。
事实上,PM 在召开规划会之前,排期的内容已经准备得差不多了。在全员规划会上,除了对齐信息之外,更重要的是当面达成共识,这其实也是仪式感和承诺的象征,对计划后续的有效执行,是至关重要的。因此,达成共识并公开透明,就是做计划的第四个标准动作。

雷区 5:不够即时

在整个项目周期中,由于随时会可能出现变更,加上对估算的不断细化,做计划永远是个反复修正、渐进明晰的过程,我们要对计划进行持续地跟进与调整。重要的是,每一次进行调整,都要确保项目中的每个人知道当前的计划是什么,调整计划需要怎样的决策过程,都需要谁参与决策。而及时调整变更,就是做计划的第五个标准动作。

做计划的 5 个标准动作,分别是 WBS 工作分解,识别依赖及各环节关键路径,定义完成标准,达成共识并公开透明,即时调整变更。

原文地址:https://www.cnblogs.com/fanzou/p/14649535.html