大师网-带你快速走向大师之路 解决你在学习过程中的疑惑,带你快速进入大师之门。节省时间,提升效率

十、拆分项目任务


当你被任命为项目经理,拿到授权之后,就需要开始展开工作了。现在我们看看手上有哪些信息:

1. 项目章程 (授权信息,需求信息,项目信息的一个概述文件)

2. 大而粗的项目时间节点

3. 干系人列表

接下去需要基于这些文件,归纳出具体需求,并且将需求转化成一项一项工作,最后将工作再次分解成每一个活动。大致的流程如下图:


大致分成几个阶段:

收集需求

定义范围

创建工作分解结构(WBS)

《一》收集需求

此时的收集需求,并不是之前的需求,而是基于之前确认的需求后,将需求具体化。此阶段的输入文件有项目章程和干系人管理列表。而输出需要三个文件,需求文件,需求管理计划以及需求跟踪矩阵(RQM)。

需求文件:需要将项目章程中的需求具体化。即具体罗列所有需要实施的需求。因为这会影响到后面任务以及工时,所以必要的时候需要相关干系人审阅批准。

需求管理计划:之前阶段对于需求,都是要明确,但是事实证明,需求是会变的。变化的需求会引起项目范围的变化,如果不加以管理,会导致项目需求肆意蔓延,造成最终失败的结局。所以在项目之初,制定需求管理计划是十分必要的。

在需求管理计划中,需要定义需求变更的流程,交由甲乙双方的专人提出沟通需求。务必做到双方只有一个人可以提出并接受需求。而每个需求变更需要分析影响,并且交由主要干系人批准后方可加入到项目中。

从这里可以看到,一旦需求变更流程能够有效的执行,给与项目组好处在于:

1. 每个需求变更,无论是通过的或者拒绝的,都可以追溯。

2. 每个通过的需求变更,会有对应的措施,比如增加工时,或者是增加资源等。从而避免在实施过程中只加功能不加工时,开发人员疲于奔命的现象。

3.每个通过的需求变更被统一加入到需求跟踪矩阵中,任何相关干系人都会被通知到。增加了项目组内信息的透明性。

需求更行矩阵(RQM):该矩阵是将需求和设计,实施,测试等一些列动作映射的文件。如果维护的好,可以从流程上规避交付时遗漏需求等问题。

《二》定义范围

对于整个项目来说,每个时间点都有一个明确的项目范围。如果有需求变更,相应的如果得到干系人批准,项目范围会更新。这些通过需求管理计划得以控制和实现。

所以这个阶段的输入为需求文件,亦或者是变更后,更新了的需求文件以及项目章程。而输出则是项目范围说明书,以及项目的中间文件,如需求管理计划,需求管理矩阵等等。

项目范围说明书会明确以下五个方面

1. 产品范围描述:逐步细化在项目章程和需求文件中所述的产品,服务或成果物。

2. 产品验收标注:定义已完成的产品,服务或者成果的验收过程和标准。

3. 项目可交付成果:包括中间产物,以及最后交付的实物。

4. 项目的除外责任:记录那些是不属于项目范围的。有助于项目干系人的期望管理。

5. 项目制约因素:由于还处于项目初期,会有很多问题并没有得到明确回答。或者当前阶段无从回答。而后续工作,如预算估算,工时估算等等由需要这些问题的答案。此时需要做一些假设,并且将这些假设罗列到项目范围说明书中。意思就是我是基于这些假设做的这些计划。如果后续出现不同,需要走需求管理计划。

《三》创建工作分解结构(WBS)

有了项目范围说明书,再加上之前的需求文件,就可以从中提取需要完成这些需求所要做的任务了。此阶段会产生三个产出物:工作分解结构,工作分解结构字典以及范围基准。

工作分解结构: 以可交付成果为向导的工作层级分解。工作分解结构每向下分解一层,代表着对项目工作更详细的定义。包涵了账户编码。工作内容,工作层级三个属性。如下图:


工作分解结构词典:对于工作分解结构的一个补充,具体描述每一个工作,负责的组织,所需要的资源,质量要求,验收标准。

范围基准: 即项目范围说明书,工作分解结构以及工作分解结构词典。

由此,完成了项目经理进入项目后的的第一步,将需求转化为了任务。并且建立了需求管理计划以及需求管理矩阵。