项目策划作业指导书

CMMI3-项目策划作业指导书:计划是最重要的

2011-03-02 11:01:55 作者：大步来源：浏览次数：67 网友评论 0 条

项目启动阶段，千头万绪，项目PM/PJL、Team Leader如何开展工作？如何制定好一个计划，让项目组的成员能够开展工作，是至关重要的。本章节件提供项目计划制定及修改的作业指导书。

1. 目的

项目经理最重要的职责之一就是制定计划、整合计划和执行计划。由于相对短的期限和资源的优先控制，几乎所有的项目都需要正式的、详细的计划。又因为每个职能单位可能只按照自己的计划文件来进行工作，而很少顾及其他单位，所以计划活动的整合是必要的。

项目启动阶段，千头万绪，项目PM/PJL、Team Leader如何开展工作？如何制定好一个计划，让项目组的成员能够开展工作，是至关重要的。本章节件提供项目计划制定及修改的作业指导书。

项目计划的目标之一就是去完整地定义所有需要完成的工作，以便每个项目参与者都能较容易地确认自己的角色。如果在执行前能很好地理解每项任务，大部分工作都可以预先计划。如果执行者对任务理解不够，则在执行过程中会反馈回来更多的信息，又会导致资源分配、进度计划和优先权的改变。任务越不确定，为保证项目有效执行需要处理的信息量就越大。

定义要求，显然这里要定义的要求就是要定义清楚计划，应该是第一步就做的事情。提升非参与人惩罚无辜者寻找责任负责人混乱幻想破灭疯狂的热情没有正确计划，工程和项目就会因初步计划阶段缺少明确的要求，而在“模糊状态下”启动。下面就是糟糕计划的典型结果：项目开始

项目计划是一个循序渐进的过程。第一，在需求或者任务不明确的情况下，应该首先考虑弄清楚需求或者任务的计划，然后在逐步制定各个阶段的工作计划。第二，随着项目的执行，制定计划时的假定条件会发生变化，需要判断并做必要的计划调整。

2. 适用范围

本章节适用于项目启动阶段项目综合计划的制定、以及项目执行过程中，各个计划的修改调整。本章节适合PM/PJL使用。

在阅读本章节之前，需要先阅读《项目开发章程》的<008_项目估算规程>、<009_项目计划制定以及修改规程>、<011_项目启动规程>这三个章节。

《项目开发章程》将作为本作业指导书的一个基础依据。

3. 名词解释

工作分解结构(Work Breakdown Structure-WBS)：WBS是英文Work Breakdown Structure（工作分解结构）的缩写。单从字面上进行理解，W—Work：为克服障碍、实现某种目标而通过身体或头脑付出努力或施展才能；B—Breakdown：划分成部件或分类；分离成基本物质；经受分解；S—Structure：事物在明确的组织形式下的排列。WBS是对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。WBS将项目的整个范围组织在一起并加以明确。每向下分解一个层次，就意味着项目工作的定义深入了一步。WBS最终分解为工作细节。WBS的层次结构以可交付成果为对象，包括内部和外部可交付成果。

里程碑：是一些事件，设立这些事件是为了表明当这些事件发生的时候，项目已经达到了某种程度。详细而明确的可以衡量的事件，用以定义产品开发中的发展的进程。

关键路径：是一系列（或者仅仅是一个）确定项目完成日期计算值的任务。也就是说，当关键路径上的最后一个任务完成时，整个项目也就随之完成了。

4. 流程

4.1. 理解项目的开发基本方针

目的：项目没有设定开发基本方针，就相当于项目没有一个指导方向，当项目执行过程中，发生问题，那么如何裁定这些问题的优先权时，将没有一个决策依据。所以我们要确认清楚项目的开发基本方针。

操作步骤：项目开发章程为项目设定了五个开发基本方针，即：成本、质量、进度、效率、客户满意度。这个内容在《011_CN_项目启动规程_项目任务书》写明。

1. 项目立项时，事业部总经理会根据项目的商务目标的要求，在任务书中明确项目开发基本方针优先级高的两项。

2. 项目经理需要与事业部总经理确认对开发基本方针选定的理解，并达成一致的认识。

解释：对于项目开发方针，如果选择两项，其他项限定要求，那么选中的两项是相互对立的，需要加强一项，则必然会影响另外一项（例如，项目的进度、效率、客户满意度要求限定，需要提高项目质量，则必然要加大项目的成本投入），因此任务初始，就应该确认好开发方针，以利于项目执行过程中，对这些对立统一的矛盾体进行决策时，选定符合项目任务要求的优先决策条件。多快好省是十分难做到面面俱到的，确认项目的开发基本方针就是给项目定义一个必要的平衡原则。

注意事项：

在制定项目计划时，需要综合考虑开发基本方针的优先级，以确定每个工作阶段或者是迭代阶段的各项任务之间的优先度。

4.2. 确认项目的范围

目的：项目工作范围的确定是为了有效地完成项目目标而界定的主要工作内容的活动，会将项目的可交付成果划分为可控的、易于管理的单元模块，并在此提出明确的要求，让项目组以及客户明确知道，项目组实施每个阶段或每次迭代需要什么样的输入，项目组需要通过自己的工作完成这些输入，客户也需要兑现提供这些输入的承诺。

操作步骤：项目的范围一般以《008_CN_项目估算规程_项目作业一览表》表现。其中需要说明项目承担的生命周期、入口资源（即输入）、开发功能一览、提交资料一览。

1. 开发功能一览：同客户获取并确认需要开发的机能。在项目初期需求还没有进行充分的调查获取，此时可能无法完整列举，此时可以根据项目的实际状况，进行基础的需求划分，以确认工作的基本部分。在项目执行的过程中，随着需求的不断细化和明确，进一步细化开发功能一览。

2. 承担的项目工作阶段：项目需要承担的作业阶段以及各阶段的管理模式。比如人员外派到客户现场的形式、DDU的形式等等。对于使用迭代的作业模式，不一定能够完整的采用软件工程阶段来说明，这里建议描述项目组与客户商讨确认的每次迭代的要求，并且，这里列举的每次迭代可以和项目的里程碑相对应起来。

3. 提交资料一览：列举需要正式发布给客户的资料列表（包含需求文档、设计文档、代码、测试用例、报告、手册、说明书等等），同时需要说明提交资料的相关的格式、提交的时间和频度、提交的方式、客户方的接收接口等等。这里列举了常见需要交付的内容，如果和客户另有约定，同样也需要在这里列举，例如：项目周报告、需求沟通记录等等。

4. 入口资源: 客户向项目组提供的资源。包括直接参考资料和参考资料的设计文档、工具、硬件、阶段或迭代要求、方法、将对项目组提供的技术支持服务等等。

注意事项：

入口资源这里尤其要注意，有一些客户提供的工作产品是会在我们即将执行的任务中使用的，客户是否能够及时提供这些工作产品，将直接影响到我们的工作进展，这一类的工作产品，必须要和客户确认明确的提供时间、方式，以及将要提供的技术支持等。

4.3. 制定项目的执行规范

目的：没有规矩不成方圆。项目规范的制定就是为了帮助确保项目组成员和相关人员实施一系列为建立项目的初始的需求和计划所必需的活动，并在整个项目生命周期中实时的对组织项目规范进行维护。

操作步骤：

作为欧美BU，承担的项目的类型与组织以前执行的项目的类型差别比较大，如客户的需求、客户的管理要求、技术特点等。因此在组织的项目执行过程全集上来进行裁剪，其适用性比较小。这种情况下，我们一般需要进行一下的方式来进行项目规范制定。

1. 第一步：项目经理需要组织项目的管理人员、PPQA、EPG等熟悉软件工程、项目管理技术的人员和项目的核心技术人员，进行项目需求理解，确定项目的要求。必要时可以由客户一起参与。

2. 第二步：基于项目的具体要求，由项目经理组织项目的管理人员、PPQA、EPG借鉴《008_CN_项目估算规程_项目过程裁剪定义》对项目的过程以及子过程进行

分析，并识别项目必须执行的过程和子过程，以及需要为达成项目目标而完成的成果物。

3. 第三步：对于识别出来的过程和子过程以及成果物，说明其为什么要执行，有什么作用。

4. 第四步：通过项目综合计划，对过程和子过程以及成果物需要遵循的规则进行描述，如描述过程执行的频次、成果物需要符合的规约采用的模板等等。

5. 第五步：随同项目综合计划发布项目规范，并获得成员的执行承诺。

解释：一般而言，组织都有一个项目执行过程的全集，在项目规范制定过程时，就是项目经理基于项目的基本任务以及客户的需求，对项目执行的全集进行裁剪，确认这个全集里面需要执行的、删除不需要执行的并说明不执行的理由、调整执行步骤之间的先后次序或者是频率、增加非组织级过程的全集内的活动步骤或者是方法。执行这个动作时，采用《008_CN_项目估算规程_项目过程裁剪定义》。

确定项目执行过程中，及子活动级活动的顺序，并给出这些活动的输出。在大部分项目在开始的时候依据项目的工作范围确定项目要执行的子过程以及输出的工作产品。这个全集里面包含项目需要执行的过程、子过程，以及执行这些过程需要形成的成果物。裁剪实际上就是针对这些要执行的过程、子过程以及成果物进行增、删、改。

注意事项：

在CMMI中把这个活动叫做项目过程裁剪定义，在这里我们要说明的是“裁剪”不是“裁减”，所以，我们做过程裁剪时要考虑“增、删、改”多个方面，在对项目过程裁剪的时候我们不是简单地考虑做或者不做，应该在不做的时候考虑是合并还是用其他的替代方法来执行。

在项目的进展过程中，《项目过程裁剪定义》需要被进一步细化以更好的满足项目的需求，以及组织的过程需要和目标。而且，组织标准过程变更时，项目定义过程需要同时更新。

《项目过程裁剪定义》关系到项目生命周期的定义以及各个阶段的出入口标准，必须经过EPG审核批准。

裁剪需要符合以下标准：

为了保证品质所必须进行的必须过程不能够删除。

在满足成本控制的前提下，可以对某些过程进行裁剪。

在成本、资源、工期等条件能够保证的前提下，尽量减少裁剪。

顾客对过程提出要求，则必须遵循。

依据流程标准选择合适的项目阶段，增加或删除流程子步骤描述。

裁剪后不得降低对工作进展的可视性（跟踪）。

裁剪后不会对产品增加不必要的管理和控制。

裁剪的标准要基于项目开发基本指标，如工作量、文档质量以及工程质量、团队规模等等。裁剪要在项目计划中明确反映并经过评审。

4.4. 定义项目里程碑

目的：里程碑就是详细而明确的可以衡量的事件，用以定义项目开发中的发展的进程。从里程碑定义上我们清晰的了解到，定义里程碑是项目定义一些开发过程中的发展进程，定义一些阶段性的目标，通过每一个里程碑的达成逐步实现项目整体目标的达成。设立里程碑，关键是有效分解目标，而不是简单地切割时间表，要保证分解后的目标是一个完整的小项目或有明确的主题或交付。

操作步骤：里程碑定义一般在《009_CN_项目计划制定以及修改规程_项目计划书》中描述。

1. 项目基本阶段划分,里程碑是满足阶段目标的时刻。列出该项目的各个里程碑；描述里程碑名称，目标，阶段的开始时间，结束时间，进入准则，结束点准则，所需要的资源。

2. 里程碑目标主要定义项目管理活动、业务需求获取和定义、需求分析、架构设计、详细设计、编码、页面、测试、用户文档、实施活动的状态；

3. 列出里程碑的关键工作产品。

4. 各里程碑的关键的作业方法和关键的工作路径。

解释：我们上面说了里程碑定义的准则，简单理解里程碑可以作为是项目的一个可交付并能给项目工作承上启下的点，所以里程的目标、准入和准出的定义，是在项目实施中对项目能否达成项目目标的检查依据。

在瀑布模型和增量模型的阶段就是我们说的需求开发、概要设计、详细设计、编码、单元测试、产品集成、系统测试、验收交付、维护这些阶段。一般瀑布模型的里程碑设立根据项目规模和特点为需求、设计、编码＋单元测试、产品集成＋系统测试、交付；增量模型一般里程碑是每次可交付产品为一个里程碑，如果规模很大可以按照瀑布模型设立子里程碑。迭代模型的里程碑一般是每次迭代就是一个里程碑。

注意事项：

里程碑的准入准则，就是输入里程碑的工作产品、资源是否满足该里程碑的要求。我们就要定义输入工作产品标准、要达到的质量目标。而里程碑的准出不仅仅是工作产品的标准和达到的质量目标。还要判断这个里程的进度、成本、工作量、规模的偏差以及项目的变更是否在控制范围内。

4.5. 项目WBS分解

目的：项目的目标是依据客户的需求而定的，实现这些目标实际就是要为客户提供一系列的最终交付物、服务等。做好WBS分解，就是分解为客户提供最终交付物、服务等需要执行哪些任务，完成这些任务又需要哪些不同的阶段或者是子任务的支撑。WBS分解是预算的一个基础，预算将基于WBS分解出来的任务来进行需要的资源的估算。WBS分解是详细时间计划的一个基础，详细时间计划可以直接基于WBS 分解来进行资源分配以及项目关键路径的识别和调整。在MS Project中制作详细时间计划时，就是在进行WBS分解，在WBS分解完成后，将每项任务的起止时间以及完成任务的人员加上去，并按照人员完成任务的先后顺序调整外项目的关键路径后，就完成了详细时间计划。

操作步骤：划分项目的WBS结构有许多方法，如按照专业划分、按照子系统、子工程划分、按照项目不同的阶段划分等，以上每一种方法度有其优缺点。一般情况下，确定项目的WBS结构需要组合以上几种方法进行，在WBS的不同层次使用不同的方法。

这里推荐一种WBS分解一般需要一下几个步骤。其模板可以参照《009_CN_项目计划制定以及修改规程_概要(详细)时间计划》。

1. 第一步，分解出实现项目的目标或者是每个迭代的目标，需要经过哪些阶段，如需求、设计、开发、测试等等。

2. 第二步，分解出每个阶段需要完成“开发功能一览”中的具体功能，这些功能将作为一个个任务进入下一步分解，如详细设计阶段的A功能、开发阶段的B

功能、测试阶段的C功能等等。

3. 第三步，分解出第二步中识别出来的任务的项目管理域、软件工程域、项目支持域的不同子任务，如详细设计阶段的A功能的设计文档编写、设计文档的评审、设计文档的确认，开发阶段的B功能的设计理解、编码实现、Debug、代码评审。

4. 第四步，识别出以上分解出来的各项任务之间的相互关系，这些关系中主要考虑任务之间存在的业务上的前后依赖关系、可并行关系等等。

以上步骤执行，推荐在MS Project中执行，这样将能够通过MS Project工具的功能，省去如WBS字典的编号、关系的描述等繁琐的工作。

在MS Project中，识别出来的任务可以通过任务名称进行描述，并在工具中直接进行任务层级关系的标识，通过前置任务的设置可以标识清楚任务的依赖关系。并且为后面进行详细计划的排定提供一个基础。

解释：最终交付物或服务的完成实际是随着不同的阶段或者是迭代完成而达到的。因此WBS分解正式将这些达成后能够逐步实现目标的任务分解出来。

WBS是一个网状的结构。WBS中的各个任务是有相关的关联关系的，有的是属于上下层次关系，有的是属于前后依赖关系，也有的是属于并行的关系。

下图是一种简单的层级关系的WBS图：

注意事项：

某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。

WBS中某项任务的内容是其下所有WBS项的总和。

一个WBS项只能有一个人负责，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。

WBS必须与实际工作中的执行方式一致。

应让项目团队成员积极参与创建WBS，以确保WBS的一致性。

WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。

在实际的项目计划编制时，WBS分解可以用MS Project来制作。

WBS项颗粒度需要尽量控制在2人日以下，以利于项目的任务控制。

WBS项之间的关联关系要识别和理解，并在WBS中标识清楚。（即任务的先后关系）

WBS项的识别需要详尽，不要遗漏重要的任务项，如项目中常见的评审任务、版本发布任务、项目管理的相关任务、配置管理、度量分析任务等等。这些任务可以参照模板，进行统一的分类并识别，然后规划相应的资源来对照执行。

4.6. 估算项目规模、成本、时间、资源、风险

目的：对于已确定的项目范围，进行了过程裁剪定义，定义了阶段和里程碑，那么我们每个阶段的输出的工作产品的工作量、成本、质量如何估算就十分重要，这些也是判断阶段目标和里程碑是否达成的重要判断依据，而要估算工作量、成本等工作产品属性，我们就必须先估算出工程阶段每个工作包的工作产品规模。

操作步骤：估算首先要描述需求的范围。然后，将问题分解成为一组比较小的问题，在以历史数据和经验为指南，对每个问题进行估算。

1. 确定估算的方法

估算方法有：经验值估算、功能点估算。具体的估算作业指导书参见《008_CN_项目估算规程_工程预算及计划作业指导书》、《008_CN_项目估算规程_功能点估算作业指导书》这两本作业指导书。

2. 确定估算范围以及问题分解

估算就是对项目范围陈述中描述的功能进行评估，软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题非常复杂，不能作为一个整体考虑。因此我们要对问题进行分解，把它分解成为一组较小的问题，再定义他们的特性，这部分工作可以等同前面所说的WBS分解。

3. 估算工作量和成本

一般工作量和成本的估算是依据项目的估算模型，依据工作产品的规模去估算工作产品的工作量。

规模的估算可以对应到代码行数或者是功能点的个数。规模估算具体请参照《008_CN_项目估算规程_工程预算及计划作业指导书》、《008_CN_项目估算规程_功能点估算作业指导书》。

估算出规模后，然后根据组织积累的生产效率度量数据或者是参照作业指导书的计算要求，推算工作量和成本。工作量=规模/生产效率。

4. 估算项目的时间

依据已经估算出的项目规模，每个阶段的工作量，结合现有资源估算项目的概要时间，时间估算的结果是阶段、里程碑、项目的起至时间。

5. 估算资源

项目工作量和成本、时间估算完成后，项目组的各个阶段时间范围内需要完成的工作任务也基本确定，此时需要进行资源估算。

资源估算时，根据各个阶段需要完成的工作量和已有的时间周期天数进行计算，需要标准人力资源人数=各个阶段需要完成的工作量÷已有的时间周期天数。

计算出这个人数后，还需要进一步考虑各个阶段工作中的核心工作内容、关键路径上的工作内容、技术公关工作内容等必须要特定的人力资源来完成的。

6. 估算项目的风险

依据历史项目积累的风险，在项目开始阶段对项目的技术、管理、质量、资源、需求等方面可能出现的风险进行全面评估。并评估出来的风险制定规避和管理措施。

7. 估算的评审

项目的估算结果一般就是项目预算，我们一般先要对这些预算进行技术评审，以确定预算的合理性。然后还应通过到由公司高层的管理评审。

评审时，参考《008_CN_项目估算规程_工程预算评审检查单》。

解释：这里主要描述实施的基本步骤，具体的实施方法参照《008_CN_项目估算规程_工程预算及计划作业指导书》、《008_CN_项目估算规程_功能点估算作业指导书》。

注意事项：

估算要考虑项目管理类、支持类及返工的工作量。在建立项目度量能力和模型的时候我们可以从历史项目中推出这些工作量的估算模型。一般每个开发阶段都要预留15～20％的工作量用于返工。管理类的工作量一般是项目总开发工作量的10％，质量保证、MA及其他支持类的工作量一半是项目总工作量的2～5%。

软件成本和工作量的估算从来都没有成为一门精确的科学，因为变化的因素太多——人员、技术、环境和行政，都会影响软件的最终成本和开发所用的工作量。

如果对项目范围不太了解，或者项目需求经常改变，不确定性和估算风险会非常高。迭代的生命周期模型，当客户改变需求时，应该能够重新审查估算，并进行修正。对于这个情况，如果对项目范围的不了解，那么将无法估计这些变化，也就谈不上进行修正了。

4.7. 概要时间计划

目的：编写概要时间计划，是依据项目的最终交付时间要求，对完成项目任务进行各阶段和里程碑的时间进行划分，将项目的整体时间周期切分为必要的多个阶段时间要求，以利于项目的整体控制。

操作步骤：

概要时间计划可以从两种不同的角度来安排。

第一种情况——

1. 项目的最终交付时间已经确定；

2. 项目组分解工作阶段或迭代次数，并识别各个阶段或者是每个迭代的依赖关系；

3. 对各个阶段或者是每次迭代进行时间安排，以满足项目的最终交付时间。

第二种情况——

1. 项目组分解工作阶段或迭代次数，并识别各个阶段或者是每个迭代的依赖关系；

2. 对各个阶段或者是每次迭代进行时间安排。

解释：

划分，必须将项目划分成多个可以管理的阶段或者是迭代，每个阶段或者迭代必须要有明确的目标。为了实现项目的划分，需求范围涉及到的要求以及阶段和过程都可能进行划分。

依赖关系，划分后的各个阶段或者迭代之间的相互依赖关系必须是明确的。依赖关系将决定项目的串行任务的要求，这个将会直接决定项目的最短周期。

时间安排，划分后的阶段或者是迭代都是有一定数量的工作量的，时间安排就是需要将这些工作量分解在一个开始时间和完成时间取决的任务周期内。

注意事项：

在时间安排时需要注意人员与工作量之间的关系，人月神话中给出的结论：人月≠人×月，项目进度拖后，可以增加更多的程序员来追赶进度，这在一定程度上是能够实现的。但是，我们必须要考虑增加人手对项目造成的影响，新增加人员，要对项目有一个较长的理解过程，这个过程直接带来了项目的需求理解的成本。新加入人员将会增加人员之间交流的路径数量和整个项目交流的复杂度以及管理的复杂度。因此在定义项目概要时间计划时，必须要考虑这些会影响项目阶段时间的因素，要遵守客户的时间要求，但也要符合人员和工作量之间的关系的科学理论，尽量缩小团队规模，降低团队成本。

在时间安排上，要考虑各个迭代之间的依赖关系，以及每次迭代内部的关键路径。（虽然现代软件工程的一些办法已经使得项目能够切断项目的关键路径进行并行作业，但是关键路径上的任务的依赖关系不可能完全切断，而且项目的资源还是优先的。）这些关键路径和迭代关系将决定项目总体的关键路径和最短周期。因此，科学的时间安排如果不能满足客户初始提出的最终交付时间要求时，必须要与客户进行合理的沟通，调整项目的时间或者是需求的范围。

在安排概要时间计划是，需要结合已经设定的项目里程碑进行，对各阶段和里程碑都需要有明确的时间要求，并要有目标要求。

4.8. 制定项目计划书

目的：项目计划的目的就是去完整地定义所有需要完成的工作，以便每个项目参与者都能较容易地确认自己的角色。为了与客户交流风险分析和管理、项目成本估计、进度和组织结构，我们通常编写一个文档，称之为项目计划书。

操作步骤：写这些内容参照《009_CN_项目计划制定以及修改规程_项目计划书》模板。

项目计划常见包含——

项目概要

项目背景

项目的基本任务和目标

项目整体资源(组织)结构

用户的基本目标和需求

项目主要的阶段及里程碑

项目规范

对于迭代开发的项目，主要的阶段是指每次有效的迭代，迭代可以和里程碑相互对应，也可以是多次小的迭代完成后对应一个里程碑，也可以是一个大的迭代对应多个里程碑。项目的主要阶段

项目的里程碑

参见《009_CN_项目计划制定以及修改规程_项目质量计划》质量计划

需求变更管理计划

参见《009_CN_项目计划制定以及修改规程_项目监控与度量计划》项目监控与度量计划

参见《028_CN_配置管理规程_配置管理计划》项目配置管理计划

人员培训计划

评审计划

说明项目组将如何进行周例会、小组例会等相关会议，会议的流程要求。

会议管理计划

列举项目组相关的干系人，并明确与干系人的管理沟通的频次、方式等。干系人需要包含项目的核心成员、公司高层、客户以及其他与本项目相关的主要人员。干系人管理计划

项目决策计划

外协管理计划

明确风险管理时，如何界定重大风险，对重大风险如何进行集体的分析和跟踪管理。风险管理计划

数据管理计划

注意事项：

有些人理解项目计划就是一个时间表，这个理解是不正确的。项目计划书就是将项目策划的各个部分写入到计划书中，通过计划书的记录和描述，将项目策划的信息以正式的文档发布给项目组的全员。

4.9. 项目组织建立

目的：组织的高效运行，需要要设计合理的组织结构，并为组织结构指派合适的人员承担角色。

操作步骤：

Member的三层的组织结构。TeamLeader第一步，建立项目组织，这里推荐PM/PJL

第二步，为组织结构设定其他必须的角色，如项目评审专家组、配置管理组、开发技术（环境）组、需求管理组等等。

第三步，为组织结构的每个角色配备必要的人员，配备人员是，需要参照估算资源的结果进行，并且需要考虑将资源进行必要的小组划分，并指派Team Leader

负责管理。即在《011_CN_项目启动规程_项目组组织图》将各个角色实际的人员名单列举出来。

解释：

项目在项目将要交付时，由项目组根据实际的需要，再指定人员执行。

PPQA不隶属于项目组，而是直接向项目的高层负责。

实施维护组一般是根据项目执行的情况，计算实施维护需要对应的变更工作量和缺陷修复的量后，再从项目组的人员中进行选择，并组建实施维护组。

需求管理组是负责需求管理和变更管理的组织，可以由需求接口人、项目经理、设计、开发、测试等相关的人员组成。

注意事项：

在安排人员时，需要考虑人员的技能是否能够适应岗位的要求。

组织的建立同时也是一个授权的过程，因此组织体系发布后，需要各个角色的人员根据要求各司其职。

随着项目的进展，组织结构是需要调整的，项目经理需要及时调整项目组织体系，并重新发布。

为了控制TeamLeader的沟通工作量，使得TeamLeader能够更加有效的管理各个小组，一般建议小组的Member为4~5人，最多不超过8人，这里的人数主要是从沟通接口量上面考虑的。

4.10. 详细时间计划

目的：详细时间计划就是将项目WBS分解出来的每一个任务做出时间安排、工作量确认和资源的配备。

操作步骤：一般在MS Project中进行编排。

1. 将WBS工作分解结构任务导入MS Project中。

2. 导入预算对每个任务的工作量估计。

3. 导入资源，确认各个资源的系数。

4. 根据概要时间计划要求，限定阶段或者是迭代的完成时间要求。

5. 为每项任务指定合适的资源。

注意事项：

任何一个人接受新鲜事物都是有一个过程的，是存在一个学习曲线的，刚开始进入项目时，效率相对偏低，而随着时间的推移，对工作要求和业务要求的熟悉，效率会提升，并进入到一定的水平，因此，在编排计划时，需要考虑这个特性，对于某个人力资源刚开始进入某个作业状态，需要将其完成任务的时间适当加长一些，在项目进行一段时间（根据润和软件执行项目的经验，这个时间一般要1~2周），

其生产效率会得到较大的提升，在这个时间后面，其完成任务所需实际工作量会比预算工作量略低，例如可以采用实际投入工作量：预算工作量=1：0.9来计算，当然，在实际执行过程中，还需要根据进度控制来判断这个比例是否合适并及时调整。

估算时，各项任务是基于一个基准值进行估计的，为每项任务指派资源时，每个人员的技能、经验等都是有偏差的，在指派资源时，必须考虑这些偏差，并通过一定的系数折算，然后将工作量分配给这些资源。

排详细时间计划不是一次就全部完成的，一般是按阶段或者是迭代来编排计划，在启动下一个阶段之前，做好下个阶段的工作计划和时间计划。

时间表的Stoneline(各阶段,如设计,开发,测试等等)是否合理(时间, 比例, 人员等等)。

项目的作业任务列表是否完整。 (以列出来的WBS点为准)

作业任务的内容,条件(开始的限制条件, 结束条件)是否是清晰的,非二意的。分配的人员是否适合。

各项作业任务的时间是否可控。对每项任务安排时间的以1到2天为宜。小于1天, 日程表太过零碎而且健壮性也差。超过2天, 不宜控制。

各任务的时间顺序是否匹配。

各任务的估计时间是否正确。注意, 不同的人员的时间是不同的。

各成员的工作量是否均衡。

项目的关键路径是否设定，安排小组/人员是否合理？

阶段工程的成果物检查点(review点)是否设定。设定是否合理？

阶段工程中的时间控制点(release点)是否设定。设定是否合理？

各个工作组(开发，测试)之间的时间结合点是否设置。设置是否合理？

工作组划分是否合适,工作人员的搭配是否合适。

对照项目的作业误差,是否有足够的时间余量对应意外事件。

4.11. 计划评审

目的：计划评审的目的是为了及时和高效地消除项目计划中的缺陷，同时能够对工作产品及可预防的缺陷有一个全面了解，消除时间计划的不一致性。

操作步骤：计划评审时，参考《009_CN_项目计划制定以及修改规程_项目计划书评审检查单》

? 《概要时间计划》或者《详细时间计划》的工作安排应该同项目的干系人员进去充分的交流和确定。

? 项目经理完成《项目综合管理计划》包含《概要时间计划》或者《详细时间计划》后，将上述内容提交事业部总经理并组织召开评审会议，详细流程参考025_评审规程。

组织者：项目经理

参与方：项目经理及项目组主要骨干、项目PPQA人员及必要时邀请客户参与。对于A/B类项目，评审工作应该由项目总监或技术总监参与组织并负责召集安排项目利益相关方进行。对于D类项目以上事业部总经理必须参与评审。

活动：如果其评审结果要求对项目计划进行修正，则项目经理进行修正，然后再次评审，直至评审通过。评审会议形成一份《项目综合管理计划评审会议纪要》以及一份《项目综合管理计划评审报告》。

? 项目评审通过后各相关方要签名确认，确保项目计划所要求的资源落实和计划实施。评审通过后的《项目综合管理计划》要纳入基线。

解释：评审涉及到的内容有项目综合计划级子计划。《009_CN_项目计划制定以及修改规程_项目计划书》内列举到的全部内容，概要时间计划、详细时间计划、各个阶段或者是迭代的计划，项目执行规范，PPQA计划等。

4.12. 项目启动会议和计划承诺