|
当你被任命为项目经理，拿到授权之后，就需要开始展开工作了。现在我们看看手上有哪些信息： 1. 项目章程 (授权信息，需求信息，项目信息的一个概述文件） 2. 大而粗的项目时间节点 3. 干系人列表 接下去需要基于这些文件，归纳出具体需求，并且将需求转化成一项一项工作，最后将工作再次分解成每一个活动。大致的流程如下图：
大致分成几个阶段： 收集需求 定义范围 创建工作分解结构（WBS） 《一》收集需求 此时的收集需求，并不是之前的需求，而是基于之前确认的需求后，将需求具体化。此阶段的输入文件有项目章程和干系人管理列表。而输出需要三个文件，需求文件，需求管理计划以及需求跟踪矩阵（RQM）。 需求文件： 需要将项目章程中的需求具体化。即具体罗列所有需要实施的需求。因为这会影响到后面任务以及工时，所以必要的时候需要相关干系人审阅批准。 需求管理计划：之前阶段对于需求，都是要明确，但是事实证明，需求是会变的。变化的需求会引起项目范围的变化，如果不加以管理，会导致项目需求肆意蔓延，造成最终失败的结局。所以在项目之初，制定需求管理计划是十分必要的。 在需求管理计划中，需要定义需求变更的流程，交由甲乙双方的专人提出沟通需求。务必做到双方只有一个人可以提出并接受需求。而每个需求变更需要分析影响，并且交由主要干系人批准后方可加入到项目中。 从这里可以看到，一旦需求变更流程能够有效的执行，给与项目组好处在于： 1. 每个需求变更，无论是通过的或者拒绝的，都可以追溯。 2. 每个通过的需求变更，会有对应的措施，比如增加工时，或者是增加资源等。从而避免在实施过程中只加功能不加工时，开发人员疲于奔命的现象。 3. 每个通过的需求变更被统一加入到需求跟踪矩阵中，任何相关干系人都会被通知到。增加了项目组内信息的透明性。 需求更行矩阵（RQM）：该矩阵是将需求和设计，实施，测试等一些列动作映射的文件。如果维护的好，可以从流程上规避交付时遗漏需求等问题。 《二》定义范围 对于整个项目来说，每个时间点都有一个明确的项目范围。如果有需求变更，相应的如果得到干系人批准，项目范围会更新。这些通过需求管理计划得以控制和实现。 所以这个阶段的输入为需求文件，亦或者是变更后，更新了的需求文件以及项目章程。而输出则是项目范围说明书，以及项目的中间文件，如需求管理计划，需求管理矩阵等等。 项目范围说明书会明确以下五个方面： 1. 产品范围描述： 逐步细化在项目章程和需求文件中所述的产品，服务或成果物。 2. 产品验收标注： 定义已完成的产品，服务或者成果的验收过程和标准。 3. 项目可交付成果：包括中间产物，以及最后交付的实物。 4. 项目的除外责任：记录那些是不属于项目范围的。有助于项目干系人的期望管理。 5. 项目制约因素：由于还处于项目初期，会有很多问题并没有得到明确回答。或者当前阶段无从回答。而后续工作，如预算估算，工时估算等等由需要这些问题的答案。此时需要做一些假设，并且将这些假设罗列到项目范围说明书中。意思就是我是基于这些假设做的这些计划。如果后续出现不同，需要走需求管理计划。 《三》创建工作分解结构（WBS） 有了项目范围说明书，再加上之前的需求文件，就可以从中提取需要完成这些需求所要做的任务了。此阶段会产生三个产出物：工作分解结构，工作分解结构字典以及范围基准。 工作分解结构： 以可交付成果为向导的工作层级分解。工作分解结构每向下分解一层，代表着对项目工作更详细的定义。包涵了账户编码。工作内容，工作层级三个属性。如下图：  工作分解结构词典：对于工作分解结构的一个补充，具体描述每一个工作，负责的组织，所需要的资源，质量要求，验收标准。 范围基准： 即项目范围说明书，工作分解结构以及工作分解结构词典。 由此，完成了项目经理进入项目后的的第一步，将需求转化为了任务。并且建立了需求管理计划以及需求管理矩阵。 |
|
|
