项目策划作业指导书

项目策划作业指导书
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. 对各个时期或者是每次迭代进行时刻安排，以满足项目的最终交付时刻。

第二种情形——。