项目管理手册.doc

项目管理手册 项目管理手册 版本A0 目录 1项目运作指南9 1.1PDT核心团队的运作模式9 1.1.1PDT组织关系图9 1.1.2PDT组织架构图10 1.1.3PDT核心团队人员的职责11 1.1.4PDT与相关部门的运作关系11 1.1.5PDT的业务汇报关系11 1.2PDT子团队运作模式11 1.2.1MKTPL子团队运作模式11 1.2.2RDPL子团队运作模式11 1.2.3PPL子团队运作模式11 1.2.4TE子团队运作模式12 1.2.5PQA运作模式12 1.2.6IPL子团队运作模式12 1.2.7FPL子团队运作模式12 1.2.8TSPL子团队运作模式12 1.3PDT的组织运作13 1.3.1PDT组建13 1.3.2PDT解散13 1.4PDT授权与决策13 1.5项目分类定义13 1.6产品开发流程裁剪原则16 1.7项目优先级排序的规则16 1.7.1设置项目优先级的原因和目的16 1.7.2适用范围16 1.7.3优先级设置规则16 1.7.4实施方法16 1.8公司所用项目管理工具及项目管理监控库介绍17 1.8.1项目管理工具17 1.8.2项目管理监控库17 2项目综合管理18 2.1项目综合管理定义18 2.2项目综合管理知识领域18 2.3项目综合管理过程域18 2.3.1项目启动规则19 2.3.2项目的计划编制20 2.3.3项目的实施20 2.3.4项目的控制20 2.3.5整体变更控制21 2.3.6项目结尾21 3项目范围管理21 3.1启动22 3.2范围规划22 3.3范围定义22 3.4范围核实22 3.5范围控制22 3.6产品开发各阶段范围管理控制要点23 4项目计划管理24 4.1计划管理关键概念24 4.1.1WBS、PBS、OBS24 4.1.2（非）关键路径24 4.1.3工作量，工期 产品开发周期24 4.1.4GANTT图24 4.1.5PERT图24 4.1.6计划完成率25 4.2计划体系25 4.3任务、角色与计划体系26 4.4计划制定的原则26 4.5计划制定的时机27 4.6任务工作量估计的方法27 4.6.1专家估计法27 4.6.2三点法 （对高度不确定性任务时间的估算）27 4.6.3类比/比较法27 4.6.4业界估计经验28 4.7计划监控点设置的原则28 4.8计划监控的方式28 4.9计划的测评28 4.10项目计划管理的输出29 4.10.1立项论证阶段项目详细计划29 4.10.2计划到发布阶段概要计划29 4.10.3计划阶段项目详细计划29 4.10.4开发到发布阶段项目详细计划30 5项目质量管理30 5.1项目质量管理定义30 5.2项目质量管理在PCP上映射31 5.2.1项目质量管理模型图31 5.2.2质量规划31 5.2.3实施质量保证31 5.2.4实施质量控制32 5.3阶段技术评审32 5.3.1TR132 5.3.2TR232 5.3.3TR332 5.3.4TR4A32 5.3.5TR4B32 5.3.6TR532 5.3.7技术评审结论32 5.3.8技术评审操作方式33 5.4流程审计33 5.4.1流程审计的方式33 5.4.2流程审计的频度33 5.4.3审计内容及报告33 6项目成本管理33 6.1成本管理的范围34 6.2成本管理职责34 6.3成本管理的控制34 6.4项目成本评估细则35 6.4.1项目成本评估的要素35 6.4.2项目成本评估的输入35 6.4.3项目成本评估的结果36 6.4.4项目成本评估的优化36 6.5项目成本核算细则36 6.5.1研发项目费用的统计、核算36 6.5.2研发项目费用的发生与预算的比较36 6.5.3研发项目费用超预算预警36 7项目人力资源管理37 7.1人力资源规划37 7.1.1定义37 7.1.2项目角色、职责37 7.1.3请示汇报关系37 7.1.4人员配备管理计划37 7.2PDT团队组建37 7.2.1组建的时机37 7.2.2扩充的时机37 7.2.3人员配备管理计划更新37 7.2.4项目生命周期阶段统筹责任人说明38 7.3PDT团队建设38 7.4PDT团队管理38 7.4.1人力资源变更管理38 7.4.2PDT解散38 8项目沟通管理38 8.1沟通管理概述38 8.2沟通管理规划38 8.3沟通汇报机制39 9风险管理41 9.1风险管理规划41 9.2风险识别42 9.3风险评估43 9.3.1风险的定量评估43 9.3.2风险的定性评估43 9.4风险防范措施44 9.5风险的监控45 9.6风险的跟踪45 9.7风险管理流程46 10项目采购管理46 10.1项目采购管理定义46 10.2项目采购管理团队的构成46 10.3项目采购管理的工作流程46 10.4项目采购过程主要活动46 11项目变更管理47 11.1项目变更管理规划47 11.2项目变更管理的定义47 11.3项目变更评估48 11.4项目变更实施49 11.5项目变更流程50 12项目问题管理50 12.1相关定义50 12.2问题管理流程图及行为图51 12.2.1流程图51 12.2.2行为图52 12.3问题管理步骤52 12.3.1提出“问题”52 12.3.2“问题”的确认52 12.3.3“问题”记录53 12.3.4确认问题解决责任人53 12.3.5解决问题53 12.3.6问题解决的确认54 12.3.7问题关闭54 12.4问题解决管理流程中问题的状态54 12.4.1开启状态（Open）54 12.4.2关闭状态（Close）54 12.4.3挂起状态（Hang out）54 12.5问题级别及升级54 12.5.1问题的级别54 12.5.2最典型的升级渠道54 问题级别55 13文档管理55 13.1文档管理概述55 13.2文档管理清单56 13.2.1立项论证阶段文档管理清单56 13.2.2计划阶段文档管理清单57 13.2.3开发阶段文档管理清单58 13.2.4验证阶段文档管理清单59 13.2.5发布阶段文档管理清单59 版权所有，侵权必究 第 59 页 共 58 页 1 项目运作指南 1.1 PDT核心团队的运作模式 1.1.1 PDT组织关系图 PDT核心团队由LPDT领导，核心团队包括POP、MKTPL、RDPL、PQA、TE、FPL、PPL、IPL、TSPL九个成员，组织关系图如下 PAC 产品线 LPDT1 LPDT2 POP1 MKTPL1 RDPL1 PQA1 TE1 TSPL1 PPL1 IPL1 POP2 MKTPL2 RDPL2 PQA2 TE2 TSPL2 PPL2 IPL2 FPL1 FPL2 LPDT3 POP3 MKTPL3 RDPL3 PQA3 TE3 TSPL3 PPL3 IPL3 市场平台 研发平台 质量平台 采购平台 制造平台 财务平台 FPL3 图1-1 PDT组织关系图 MEID/ID PCB工程师 硬件工程师 结构工程师 系统工程师 软件工程师 平面工程师 EMC工程师 研发费用核算员 财务评估师 营销专员 销售专员 FPL MKTPL 研发物料员 PPL TE PQA IPL RDPL 质量成本分析工程师 FCR改善工程师 Kits服务支持工程师 客户文件制作工程师 客户需求调查工程师 IPQC OQA IQC 采购员 部品工程师 场地测试工程师 软件测试工程师 部品测试工程师 电子工程师 工艺工程师 结构工程师 计划员 成本管理工程师 物料计划员 图1-2 PDT组织架构图 1.1.2 PDT组织架构TSPL POP LPDT 图 1.1.3 PDT核心团队人员的职责 参考产品开发流程-角色和职责说明 1.1.4 PDT与相关部门的运作关系 1、 PDT位于产品线与资源线的节点，PDT是产品开发的责任主体，PDT的设立主要根据产品开发实际情况进行，一般起于任务书下达，终止于产品发布后。 2、 PAC对PDT任务执行情况进行考核。 1.1.5 PDT的业务汇报关系 1、LPDT接受PAC的领导，并向其汇报工作； 2、PDT核心团队成员和外围团队成员在相关资源部门的指导下，完成LPDT交给的各项工作，并定期向LPDT和资源部门汇报工作； 3、 POP向LPDT汇报工作并接受领导； 1.2 PDT子团队运作模式 1.2.1 MKTPL子团队运作模式 子团队组成市场代表（MKTPL）、营销专员（MKT）、销售专员（SALES） 子团队角色说明参见MKTPL子团队角色说明 子团队工作流程参见MKTPL子团队工作流程图 子团队活动说明参见MKTPL子团队活动说明 1.2.2 RDPL子团队运作模式 子团队组成研发代表（RDPL）、系统工程师（SE）、硬件工程师（EE）、PCB工程师（PCBE）、软件工程师（SWE）、结构工程师（ME）、结构工业设计工程师（MEID）、平面工程师（ADE）、认证工程师（AE）、工业设计（ID）、研发物料员（RDPMC） 子团队角色说明参见RDPL子团队角色说明 子团队工作流程参见RDPL子团队工作流程图 子团队活动说明参见RDPL子团队活动说明 1.2.3 PPL子团队运作模式 子团队组成采购代表（PPL）、采购员（PRO）、成本管理工程师（CME）、物料计划员（PMC）、部品工程师（SQE） 子团队角色说明参见PPL子团队角色说明 子团队工作流程参见PPL子团队工作流程图 子团队活动说明参见PPL子团队活动说明 1.2.4 TE子团队运作模式 子团队组成测试代表（TE）、部品测试工程师（CTE）、软件测试工程师（STE）、场地测试工程师（FTE） 子团队角色说明参见TE子团队角色说明 子团队工作流程参见TE子团队工作流程图 子团队活动说明参见TE子团队活动说明 1.2.5 PQA运作模式 角色说明参见PQA角色说明 活动说明参见PQA活动说明 1.2.6 IPL子团队运作模式 子团队组成工业化代表（IPL）、试产计划员（TPPP）、量产计划员（BPPP）、外发计划员（OPPP）、物料计划员（PMC）、出货计划员（SPP）、产品试制电子工程师（TPEE）、产品试制结构工程师（TPME）、整机试产（TP）、量产（MP）、电装工艺工程师（PCBIE）、整机工艺工程师（IE）、IQC、IPQC、OQA 子团队角色说明参见IPL子团队角色说明 子团队工作流程参见IPL子团队工作流程图 子团队活动说明参见IPL子团队活动说明 1.2.7 FPL子团队运作模式 子团队组成财务代表（FPL）、财务评估师（FV）、研发费用核算员（RDEA） 子团队角色说明参见FPL子团队角色说明 子团队工作流程参见FPL子团队工作流程图 子团队活动说明参见FPL子团队活动说明 1.2.8 TSPL子团队运作模式 子团队组成客服代表（TSPL）、客户需求调查工程师（CRIE）、客户文件制作工程师（CDSE）、FCR改善工程师（FCRE）、Kits服务支持工程师（KITE）、质量成本分析工程师（QCAE） 子团队角色说明参见TSPL子团队角色说明 子团队工作流程参见TSPL子团队工作流程图 子团队活动说明参见TSPL子团队活动说明 1.3 PDT的组织运作 1.3.1 PDT组建 在PAC下达项目任务书后，开始组建PDT，并进行PDT核心团队任命。 1.3.1.1 LPDT确定 1、 PDT核心为LPDT，全权代表PAC全面统筹及监管项目自启动到发布的运行过程。 2、 LPDT的来源 a. PAC的提名； b. 相关资源部门提名； c. PAC最终批准。 1.3.1.2 PDT扩充 立项论证决策评审通过后，根据情况增扩PDT；根据项目任务书进行任务分解，制定各级计划。计划决策评审通过后，由LPDT与相关资源部门协商并最终确定核心团队成员，进行核心团队成员任命；由核心团队成员与相关资源部门确定子团队成员，组建全员小组。 1.3.2 PDT解散 PDT的解散分为正常解散和异常解散两种情况。正常解散是产品研发任务顺利完成，PDT完成历史使命而宣告解散；异常解散是指产品撤项或转向情况下的PDT解散。 1、 正常解散 a PDT达成项目目标、完成历史使命而宣告解散。PDT成员回归资源部门安排工作。 2、 异常解散 由于市场等原因项目须中途停止，通过PAC决策PDT是否须继续运作。PDT异常解散后PDT成员回归资源部门安排工作。 1.4 PDT授权与决策 PAC在项目的各个阶段决策点给PDT分配资源并授予PDT对该产品开发过程中所有具体事务执行上的决策权，以保证PDT获得充分授权。 获得充分授权的PDT决策过程是一种集体决策行为，确保产品过程决策更具效率及效果。 1.5 项目分类定义 为达到有目的、针对性地实施新项目，从而缩短新项目周期并确保项目质量，对AV产品、便携式产品、STB产品等新项目分类进行详细细分，具体定义如下 基础型自主开发的全新ID、全新方案、电源等产品； 派生型以某基础型产品为基础，通过增、减功能或换壳、改变机壳颜色等开发的产品。 说明对于全新方案或新ID的产品原则上须在首批量产通过后才可试生产派生产品，但特殊情况下（市场急需），根据实际情况由PDT评估可行性后明确产品开发流程如何裁减，以保证产品的质量。 具体项目分类如下表 按结构划分 全新主方案 增加复杂功能 增加简单功能 替换关键部品 替换重要部品 减少功能 （更改）外观丝印 新机壳 全新工业设计 基础 1 A1改主板） B1（改主板） C1 D1 E1 F1 局部更改 重开重要模具 基础 2 A2（改主板） B2（改主板） C2 D2 E2 F2 旧机壳 换颜色 基础 3 A3（改主板） B3（改主板） C3 D3 E3 F3 各派生项目细节定义说明 PDVD AND DPF明细说明 序号 全新主方案 复杂功能 简单功能 替换关键部品 替换重要部品 1 全新解码方案 增加DVBT功能 耳机功能 更换光头光头接口相同） 更换电源管理电路 2 更改光头，导致主板更改 PTV增加DPF 更换PANNEL接口不同 更换功放电路 3 模拟屏更改为数字屏，导致主板大改 AV IN 更换高频头接口不同 更换TFT驱动电路 4 WI-FI 更换电池 更换机芯支架光头/接口同 5 USB功能 更改适配器 6 CR功能 更改遥控器 STB明细说明 序号 全新主方案 复杂功能 简单功能 替换关键部品 替换重要部品 1 全新硬件平台 硬件增加或删减功能，导致PCB修改 软件做小的修改，例如LOGO更换，UI颜色更改等 2 软件设计重大变更，例如操作系统，中间件，CA系统，数据广播等 增加较大软件功能，例如增加VOD,马赛克，更换菜单等 修改包装方案 3 更换芯的关键器件，导致PCB修改 更换关键部品，不更改PCB，但是需要GTR试验验证 DVD PLAYER明细说明 序号 全新主方案 复杂功能 简单功能 替换关键部品 替换重要部品不改PCB 1 全新硬件平台 增加HDMI S-VIDEO/CVBS/YUV等视频端口 更改光头（光头接口不变） 更换FLASH 2 更改光头，导致主板更改 增加CARD READER 6CH更改为8CH 更改主芯片，主板不更改 更换SDRAM 3 语音评分 增加COAXIAL/OPTIACL 更换马达驱动 4 增加USB 前控板重新LAYOUT或改板 更换电源组件 5 2CH变更到6CH OK板重新LAYOUT 更换VFD/LED显示屏 6 增加SCART 更改所涉及的元器件数小于25个 更换VFD/LED驱动IC 7 更换A/D,D/A，导致修改PCB 8 更改所涉及的元器件数超过（包含）25个 9 增加DIVX 1.6 产品开发流程裁剪原则 产品开发流程裁剪在项目立项论证及计划阶段由LPDT及PDT核心团队根据项目类别及情况确定，具体实施原则如下 1、立项论证阶段项目KO后，由PQA组织PDT团队根据项目类别及情况，参照产品开发流程裁剪操作指引确定本项目自立项论证至发布的实施流程，并上报PAC决策批准。 2、计划阶段项目经PAC确认通过立项论证决策点进入计划阶段后，由LPDT、PQA及各PL再次核实并确定本项目实施的流程，并在计划决策点上报PAC批准。 详细裁剪原则见产品开发流程裁剪操作指引 1.7 项目优先级排序的规则 1.7.1 设置项目优先级的原因和目的 1、 原因是解决资源冲突 2、 目的是识别项目优先级，合理投放资源，更好的符合公司的客户/产品战略； 3、 用在公司层面职能方面分配资源，而不是个人岗位的工作优先级指导； 1.7.2 适用范围 适用于公司产品项目/技术项目，不含管理改善项目。 1.7.3 优先级设置规则 1、 分开产品项目和技术项目分别排列； 2、 两个维度重要程度/紧急程度； 3、 重要/次重要；紧急/次紧急； 4、 重要紧急重要次紧急紧急次重要次重要次紧急 分别对应A B C D 1.7.4 实施方法 1、 制定项目优先级的时机立项前； 2、 参与人员业务部门，产品线总监，项目管理； 3、 产品线刷新频度每月； 4、 发表范围公司各业务职能部门； 5、 职能部门遵照执行为主； 6、 产品线协调为辅； 7、 当产品线冲突时上报PAC决策。 1.8 公司所用项目管理工具及项目管理监控库介绍 1.8.1 项目管理工具 在项目管理手册的指导下，通过Excel or Project（待定）为表现载体，用项目管理计划表进行管理。 项目管理计划表包括下述几个方面内容 1、 Project organization描述项目的组织架构； 2、 Project KO Assignment新项目开工任务书，用于记录PDT核心团队成员及主要里程碑计划等； 3、 Schedule项目主计划，用指针形式描述PDT核心团队项目计划； 4、 WBS项目详细计划，根据schedule将项目各阶段各项工作任务按天分解落实到各子团队成员； 5、 SampleQty样机需求计划，包含ES/GTR/ RTR/PP等各阶段样机需求情况； 6、 Risk风险管理计划，内容包括项目风险清单及应对行动计划等； 7、 Attendance记录项目会议PDT核心成员的出席情况； 8、 meeting minutes项目周例会纪要； 9、 contact windowPDT团队联系方式清单； 10、change history项目变更历史记录清单； 11、Calender项目周历表。 12、问题管理记录项目问题管理记录列表。 1.8.2 项目管理监控库 1、 项目管理文件资料存储方式 项目资料统一存放在CPC系统产品管理/项目管理区相应机型名的文件夹下。 2、 项目管理区标准文件夹模板的说明 项目管理工作区的文件分一至四级目录，每级对应存放不同的资料。 详细描述见附件一“CPC系统项目管理工作区目录树”的存放文件清单的描述。 3、 对文件模板的使用说明 详见附件一“CPC系统项目管理工作区目录树”中的权限管理说明。 4、 项目管理区文件夹的管理 新建项目KO后，POP根据申请按机型名称类别在项目管理区相应位置建文件夹模板。 权限POP按权限管理分别给PDT成员授权。 2 项目综合管理 2.1 项目综合管理定义 公司项目管理知识领域由十二个部分组成项目综合管理，项目范围管理，项目时间管理，项目费用管理，项目质量管理，项目人力资源管理，项目沟通管理，项目风险管理，项目采购管理，项目变更管理，项目问题管理，项目文档管理。 项目综合管理是指识别、确定，统一与协调各项目管理知识领域在项目管理活动中所需进行的各种过程活动。 2.2 项目综合管理知识领域 项目综合管理知识领域包含其它十一个知识领域，在项目实施过程中，将各个项目管理知识领域形成一个有效的整体，确保项目按照确定的目标完成。各个知识领域的详细说明，请参考后面的章节，它们之间的关系如下图 项目管理知识领域 项目范围管理 项目计划管理 项目成本管理 项目质量管理 项目人力资源管理 项目沟通管理 项目风险管理 项目采购管理 项目变更管理 项目问题管理 项目文档管理 项目综合管理 2.3 项目综合管理过程域 项目综合管理包括五个过程域，如下图 启动 计划编制 控制 实施 收尾 五个过程域在PCP项目管理活动中的映射 5个过程域是可以重复的，可以在某阶段或跨阶段进行，如下图示意 计划DCP 可获得性DCP 立项论证DCP 生命周期管理 立项论证 计划 开发 验证 发布 项目任务书 Initiating Planning cuting Controlling Closing Initiating Planning cuting Controlling Closing Initiating Planning cuting Controlling Closing Initiating Planning cuting Controlling Closing 2.3.1 项目启动规则 启动规则定义指项目启动条件及新项目开工任务书应该符合的规则。 项目启动的前提有两种情况 1、 年度产品规划中的项目需求按计划到了预定启动时间，由产品管理部门组织产品管理团队进行预评审，评审通过后提交PAC审批并下达新项目开工任务书。 2、 年度规划外的项目需求 1） 业务部门或PAC临时提出客户化项目需求，由业务部门提出业务需求确认书，产品管理部门组织产品管理团队进行预评审，评审通过后提交PAC审批并下达新项目开工任务书。 项目预评估要素包括五部分假设的合理性、产品规划、产品实现、财务分析及风险管理。各部分评审内容概述如下 1、 假设的合理性从政策、法规符合性；公司战略符合性；市场规模、产品销量、价格预测及技术成熟度等方面评估。 2、 产品规划从产品线路标、公司业务目标符合性；目标细分市场、竞争对手分析明确性；产品卖点竞争力情况；售后及服务模式可行性等方面评估。 3、 产品实现从进度、质量、成本、人力资源、开发和制造可行性等方面评估。 4、 财务分析投入产出合理性、盈利水平吸引力及资金回笼可接受度等方面评估。 5、 风险管理成本、进度、质量、技术等风险可控性方面评估。 详细预评估要素参见项目开工评估要素表。 2.3.2 项目的计划编制 将确定、编写、协调与组合所有部分计划所需要的行动形成文件，使其成为项目管理计划。 项目管理计划包括项目进度计划、质量管理计划、风险管理计划、沟通管理计划、人力资源计划、成本管理计划、采购管理计划等。具体详见后面计划管理、质量管理、风险管理、沟通管理、成本管理、采购管理章节内容。 2.3.3 项目的实施 执行项目计划确定的工作，实现项目计划确定的项目实施目标。项目经理与项目团队一起指导计划项目活动的开展，并管理项目内部各种技术与组织接口，这些行动包括 1、 开展活动实现项目目标 2、 付出努力与资金实现项目目标； 3、 配备、培训及管理项目团队人员； 4、 获取并管理所有项目资源； 5、 管理风险并实施风险应对活动； 6、 管理变更并实施变更的控制活动； 7、 建立项目团队内外的沟通汇报机制； 8、 收集并报告项目进度、质量、成本、技术等绩效； 9、 收集并总结项目经验教训，并实施获得批准的过程改善活动等。 2.3.4 项目的控制 监视和控制项目的启动、规划、执行和结束过程，实现项目计划确定的项目实施目标。监视是贯穿项目始终的项目管理的一个方面。监视包括收集、测量并散发绩效信息，并评价测量结果和实施过程改进的趋势。监控项目工作过程的对象是 1、 对照项目管理计划比较项目的实际表现； 2、 评价项目绩效，判断是否出现了是否需要采取纠正或预防措施的迹象，并在必要时提出采取行动的建议； 3、 分析、跟踪并监视项目风险，确保及时识别及管理风险、执行适当的风险应对计划； 4、 建立有关项目的信息库； 5、 监控已批准的变更实施过程等。 2.3.5 整体变更控制 审查所有的变更请求，批准变更并控制可交付成果和组织过程资产。整体变更控制过程贯穿于项目始终，整体变更控制过程包括下列变更管理活动 1、 确定是否需要变更或者变更是否已经发生； 2、 审查和批准请求的变更； 3、 控制申请变更的流程，在发生变更时管理已经批准的变更； 4、 审查与批准所有的纠正与预防措施建议等。 具体内容见项目变更管理章节。 2.3.6 项目结尾 项目收尾定义包括阶段性收尾、项目结束后的收尾、项目开发过程中的暂停。 1． 阶段性收尾指每个商业决策阶段（立项论证决策、计划决策、早期销售决策、可获得性决策）结束，由LPDT组织PDT核心团队进行该阶段项目经验教训总结并更新项目数据库及环境后，此阶段结束，根据PAC决策确定项目结束或进入下一阶段。具体参见产品开发流程图及活动说明。 2． 项目结束的收尾根据项目合同书约定的最终里程碑完成后，LPDT组织ＰＤＴ核心团队进行项目结束总结，形成项目经验教训总结报告，并关闭项目数据库环境，项目团队解散，资源释放。具体报告参见项目经验教训总结报告及项目总结报告。 3． 项目开发过程中的暂停项目开发过程中由于市场需求变化、关键部品供货停止等原因，须对项目进行暂停处理，由PDT相关核心代表提出变化的需求及原因，LPDT统筹组织项目暂停会议，评估项目目前的情况及暂停的影响（计划、成本、物料等），完成项目暂停变更，并获得产品线总监或PAC批准后项目正式暂停并释放资源。具体操作参见项目变更通知书。 3 项目范围管理 项目范围是指为了成功达到项目的目标，项目所规定要做的。简单地说，确定项目范围就是为项目界定一个界限，划定哪些方面是属于项目应该做的，而哪些是不应该包括在项目之内的，定义项目管理的工作边界，确定项目的目标和主要可交付成果。 在项目环境中，“范围”一词可能指 产品范围即一个产品或一项服务应该包含哪些特征和功能； 产品规范即产品所包含的特征和功能具体是怎样的； 项目范围即为了交付具有所指特征和功能的产品所必须要做的工作。即项目做什么、如何做、才能交付该产品。 项目范围管理是指在项目计划中定义的一定要完成的工作，以创造和交付“产品”，使其具有预先认同的规格与功能。项目范围管理贯穿于项目开发始终，从项目启动时的项目任务书发布到立项论证阶段的业务计划书起草及发布，再到项目计划阶段的优化业务计划书和项目合同书签订等等，详细内容见“3.6 产品开发各阶段范围管理控制要点”。 分为五个步骤启动，范围规划，范围定义，范围核实和范围控制。 3.1 启动 授权新项目或批准现有项目进入下一阶段，制定任务书或通过DCP进入下一阶段 3.2 范围规划 制定一份范围说明作为项目未来决策的依据。项目范围说明明确定义项目目标和项目可交付成果，即在项目不同阶段，采用项目任务书、项目合同书及业务计划书等文件描述和体现。 3.3 范围定义 接受任务并将其分解为更小可管理单元的过程，诠释任务书的需求，并制定WBS计划以支持产品开发。 3.4 范围核实 验证项目交付的正确性并在允许范围内（评审TR./DCP等）。 范围核实是项目的利益相关者（如项目发起人、客户等），对项目范围进行最终确认和接受的过程。核实过程要求重新审查项目产品和工作结果以确保一切都正确无误并令人满意地完成了。如果项目被提前终止，范围核实过程应确定项目完成的层次及程度，并将其形成文件。 3.5 范围控制 对项目范围的变化进行控制。范围变更控制包括 1、 对造成范围变化的因素施加影响，以保证变化是有益的； 2、 判断范围变化是否已发生； 3、 当实际变化发生时对变化进行管理。 对范围变更控制必须与其他控制过程（范围变更通常导致进度、资源、成本等的变化）结合起来，所以范围变更一定要经过PDT团队的评估并获得批准后实施。范围变更主要分为以下两个大的方面 1、 技术层面的变更走DCN流程 2、 非技术层面的变更规格、计划、人力资源、成本等 详细内容在第十一章变更管理章节中阐述。 3.6 产品开发各阶段范围管理控制要点 对应产品开发各阶段范围管理控制要点说明如下 阶段 步骤 立项论证 计划 开发 验证 发布 范围启动 任务书,CRS/立项论证DCP CRS/计划DCP 早期销售DCP 可获得性DCP / 范围规划 任务书，CRS/业务计划书 CRS/业务计划书 / 业务计划书 / 范围定义 立项论证阶段详细计划 计划阶段详细计划 / / / 计划到发布阶段概要计划 开发到发布阶段详细计划 / / / 范围核实 立项论证阶段详细计划 计划阶段详细计划 / / / 计划到发布阶段概要计划 开发到发布阶段详细计划 / / / TR1 TR2 TR3 TR4A、TR4B、TR5 / 立项论证DCP 计划DCP 早期销售DCP 可获得性DCP / 范围控制 技术层面的变更走DCN流程 非技术层面的变更规格、计划、人力资源、成本等 详细内容在第十一章变更管理章节中阐述。 4 项目计划管理 4.1 计划管理关键概念 4.1.1 WBS、PBS、OBS 1、WBS工作分解结构以可交付成果为导向对项目要素进行的分组，将各项工作内容进行详细分解的一种安排图形。它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。 2、PBS产品分解结构按照一定的定义对产品研发项目的工作范围进行分解的一种结构图形。 3、OBS组织分解结构按照层次将工作细目与组织单位形象地有条理地联系起来的一种项目组织安排图形。 4.1.2 （非）关键路径 关键路径一般是指通过项目（从始点到终点）的最长路线。是决定项目持续时间长短的计划活动序列。也就是说，当关键路径上的最后一个任务完成时，整个项目也就随之完成了。 非关键路径是指除了关键路径以外的其他路径。 4.1.3 工作量，工期 产品开发周期 1、工作量是指在一定时间内所需要完成任务的数量。 2、工期完成任务所需要的有效工作时间的总范围。通常按照项目日历和资源日历的定义，为从任务的开始时间到完成时间的工作时间总量。 3、产品开发周期产品从开始设计到验证、发布上市的一系列活动完成所需要整个周期称为产品开发周期。 4.1.4 GANTT图 甘特图， 也叫横道图。一种显示与进度有关信息的图形。在典型横道图中，计划活动和工作分解结构组成部分自上而下列于该图左侧，日期自左而右显示于该图上部，活动持续时间用标有日期的横道表示。 4.1.5 PERT图 Program uation and Review Technique，简称PERT。 PERT（网络计划评审技术）是以网络图的形式制定计划，求得计划的最优方案。PERT图也叫活动图，将一项任务分解成各个活动，并将活动用一定的先后顺序关联起来的图形。图中的每个圆圈表示开发工程中的一项具体任务，圈内的数字表示完成该项具体任务所需时间单位为星期，圆圈之间的箭头表示各项任务完成的先后顺序和相互依赖关系。较适合复杂的工程项目。 1、用网络图来表达一项开发计划中各工作（阶段、模块等）的先后顺序和相互关系； 2、通过计划找出计划中关键路径； 3、通过不断改善网络计划，选择最优方案并付诸实施； 4、在计划执行的过程中进行有效的控制和监督，保证合理地使用人、财、物，按预定目标完成任务。 PERT图示例 4.1.6 计划完成率 一定时间内实际完成的工作数量同计划完成工作的总数量的比值。 4.2 计划体系 公司项目管理中执行3级计划体系一级计划，二级计划， 三级计划。 4.3 任务、角色与计划体系一级计划 LPDT 产品版本计划 项目合同书 特性计划一级二层） PDT 二级计划 PQA PPL PDT任务书 IPL MKTPL KTL RDPL FPL TSPL TE PDT计划 技 软件测试工程师 部品测试工程师 结构工程师 工艺工程师 电子工程师 计划员 IQC OQA 硬件工程师 P CB工程师 软件工程师 结构工程师 平面工程师 客户文件制作工程师 FCR改善工程师 三级计划 子团队任务 子团队计划