华为产品开发项目计划模板之欧阳组创编.docx
《华为产品开发项目计划模板之欧阳组创编.docx》由会员分享，可在线阅读，更多相关《华为产品开发项目计划模板之欧阳组创编.docx（24页珍藏版）》请在冰点文库上搜索。
华为产品开发项目计划模板之欧阳组创编
密级ConfidentialityLevel
时间：
2021.02.16
创作：
欧阳组
陈述版本ReportVersion
页数TotalPages
陈述编号：
产品开发计划
项目号：
项目名称：
编制人：
部分：
日期：
初审PreReviewedby
日期Date
复审Reviewedby
日期Date
批准Approvedby
日期Date
版权所有XX
AllCopyrightReserve
内容简介
1.1文档目的
这部分要描述文档的目的，应该指明读者。
1.2文档规模
<描述项目计划的规模，明确文档涉及的各项内容>
简要描述本计划需要在该产品项目中完成的工作活动及其工作目标、项目采取的生命周期、项目交付物、相关人员的角色和职责、主要里程碑、进度计划、质量计划、配置管理计划、风险计划等。
项目概略
简要描述本项目的类型（新产品/改进/维护类）、项目的目的、规模、目标（例如：
项目的市场定位，产品需求等）。
项目组织结构
PDT组织结构图
PDT及系统阐发与设计组成员建议，产品开发成员建议
在决策评审点前与适当的PRB成员及相关资源部分经理对这些列表进行沟通的结果
描述项目的组织结构，建议采取图表的暗示方法。
也可参考下例：
下表界说了项目成员的角色和职责。
●在审核之前项目经理需指定所有文档和代码的审核人。
●对各个角色的职责界说可根据项目实际情况进行弥补。
●下表内容应当至少在项目的每个阶段结束时进行更新。
对项目阶段中/阶段间产生的组织结构的变更，项目经理应当通过邮件周知所有相关人员，然后更新项目计划。
表4项目的组织结构
No.
角色
姓名
向谁陈述
备份资源
1
客户代表
2
产品QA（PQA）
3
PDT经理
版本经理1
版本经理1
4
市场代表（MKTPDT）
5
技术支持代表（TSEPDT）
6
制造代表（MNFPDT）
7
推销代表（PROPDT）
8
财务代表（FPDT）
9
开发代表（RDPDT）
系统工程师（SE）
软件经理
硬件经理
结构经理
开发组长（PL）1
开发组长（PL）2
10
变动控制委员会（CCB）
11
技术评审专家（Reviewer）
项目依赖关系阐发
5.1项目关键路径阐发及包管办法
在本节中，阐发影响项目进度的关键步调/环节、关键因素，并提出包管办法
5.2项目依赖关系阐发
在本节中，说明项目的内部依赖关系（如：
开发测试工具、人力资源等）和对外部的依赖（如项目之间、与客户之间的技术、资源等方面）。
可用依赖性列表、活动网络图的办法描述。
列出所有影响项目计划的假设因素（相对已知的因素）。
如果这些假设因素有误，或者没有利用到假设因素，或者假设因素产生变更城市使项目受到影响。
另外还要描述项目对外部因素的依赖关系，例如，如项目作为整个年夜系统的一部分，需要其他部分提供接口界说或者PDT提供正在开发的仿真性能测试工具以取代实际环境测试等等>
请参考下例：
表1项目依赖关系
Sl.No
依赖于（通常指接口等）
责任人
状态OPEN（正在进行）/CLOSE（已经关闭）
最早提供日期
验收条件（如果有）
1
2
3
5.3项目关键胜利因素
关键胜利因素
影响
高/中/低
依赖关系
行动计划
5.3技术办法和工具
在本节中，描述对产品项目进行需求阐发、设计、实现、测试、文档写作、宣布、修改、或维护过程中采取的开发办法、组织结构和其他标识表记标帜、工具、技术和办法。
另外，对使用的技术标准、方针和流程也要用直接描述或参考到其它文档的方法进行说明。
参考下例，对产品项目所需要的硬件、软件和其他工具设备用下表描述：
表2技术办法和工具
分类
名称
型号
数量
开始使用日期
结束使用日期
仪表
专用仪表
开发工具
交付件
在本节中，应描述需要交付给下游部分的工作产品及其需求。
这些交付工作产品应包含各种设计文件、图纸、文档等。
交付工作产品应分化成可管理的年夜小粒度。
（这部额外容如在配置管理计划或文档计划中给出，则可以指出相关文档名称或者给予链接即可。
）可以采取列表方法。
举例如下：
表3项目交付工作产品
交付工作产品名称
产品描述
质量包管活动
验收标准
交付件形式
总体设计文档
XXX项目XX总体设计计划
正规检视及评审
归档/宣布
文档
详细设计文档
XXX项目XX详细设计
归档/宣布
文档
归档/宣布
归档/宣布
文档
归档/宣布
文档
归档/宣布
文档
归档/宣布
文档
……
……
……
……
……
项目计划
6.1项目的里程碑计划
▪关键里程碑计划可采取图形方法。
将项目的所有里程碑和关键活动标注在下面的时间轴上。
注意：
如果存在早期功能子集Beta和/或ESP交付件，PDT需要对交付件进行TR4A/TR5评审，以及对GA层产品交付件进行TR4A和TR5评审。
PDT不需要对每一个构件标注TR4，只需要标示第一个TR4的日期。
如果需要将所有里程碑和关键活动标注出来，可将时间轴划分红阶段，如上所示。
▪也可采取如下例子的形式描述里程碑计划。
表5项目里程碑计划
阶段
估计结束日期
交付件
验收准则
（可去失落）
TR1（需求评审）
和概念DR
市场调研陈述（立项阶段输出）
市场需求清单（立项阶段输出）
初始业务计划（立项阶段输出）
产品需求规格书
TR2（总体计划评审）和计划DR
产品可行性阐发陈述/产品业务计划
产品开发计划
总体设计计划书/产品设计说明书
产品测试与验证计划
工艺总体计划
装备总体计划
初始物料清单
供应商和物料选择计划
物料认证计划
提前推销决策
TR3（模块级概要设计评审）
模块级概要设计/总体设计
各模块级测试陈述
目标本钱跟踪表
市场教育和培训计划
测试计划
TR4（原型机评审）
原型机
原型机测试陈述
TR5（设计定型评审）
中试样机验证陈述
制造系统验证陈述
BETA测试结束
BETA测试陈述
外部认证结束
系统认证和标杆测试陈述
TR6（转产评审）
和宣布DR
产品可行性阐发陈述/产品业务计划（优化后）
市场宣布资料清单
受控销售阶段评估陈述
试产验证测试陈述
制造系统验证陈述
量产点GA
量产检查点确认通知
6.2项目WBS计划（highlevel计划）
拜见项目的WBS计划，请指出具体寄存位置。
6.3软件详细计划
6.4硬件详细计划
6.5结构详细计划
人力资源和技能需求
▪也可采取下表格式：
<罗列项目需要的人力资源及技能要求>
对项目组人员提出可能会影响项目进度的技能要求，例如：
CPU应用技能、VxWorksBSP技术等。
Sl.No.
资源名称
阶段1
（人数、技能要求）
阶段2
（人数、技能要求）
阶段3
（人数、技能要求）
阶段4
（人数、技能要求）
说明
1
项目经理
2
XX业务代表
3
硬件组
4
软件组
结构组
测试组
▪也可采取下表格式：
<罗列项目需要的人力资源及技能要求>
Sl.No.
资源名称
人数
起始日期
结束日期
技能要求
说明
1
2
3
4
项目所需其它资源
9.1关键物料需求计划
详细描述在不合阶段对关键物料的需求计划。
可单独形成《关键物料需求计划》。
或可单独形成《供应商※物料选择计划》
也可采取下表：
：
表6关键物料需求计划
关键物料描述
计划推销到货时间
预期最长推销周期
计划推销数量
概念、计划阶段物料
XXX器件
开发阶段物料
XXX器件
验证与宣布阶段物料
XXX器件
注：
项目组应充分估计各物料的推销周期，在各关键点应提前下达推销需求给推销部分。
增加提前推销，供应商选择
拜见提前推销计划表模板：
《新物料提前推销清单》，部分物料可以从该表COPY过来
项目组应该计划好首次量产前（包含工程样机、中试样机、首次量产）的所有物料，并根据后续量产的数量、时间结合市场的计划等给出建议。
9.2实验设备和环境资源计划
详细描述在不合阶段对不合的环境的需求计划。
如特殊的硬件平台、测试设备、软件工具等。
标准的办公硬件不必在这里列。
举例如下：
表6实验设备和环境资源计划
阶段
描述
数量
计划使用时间区段
说明
概念阐发
计划阶段
开发阶段
验证阶段
资料开发计划
表7资料开发计划
资料类别
资料名称
责任人
计划完成时间
验收准则
1.用户类资料
用户手册
客户产品布XXX
评审
2.营销类资料
市场部YYY
评审
3技术支持类资料
开发/测试
评审
4应用开发资料
开发/测试
对外合作计划
参照总体设计文档“外包外购的相应规格”列出需要对外合作的部分。
包含合作内容，进度要求等
外包任务
<本部分仅当项目中有外包时适用>
10.1子承包商资料
子承包商名
联系人
通讯地址
<其它>
10.2外包任务的规模
<指明项目外包给子承担商的工作内容，可以采取特性、需求、模块等来说明>
10.3里程碑、交付件
<指明协商后确定的子承包商的里程碑、交付件>
里程碑
分派给子承包商的工作产品
计划开始日期
计划完成日期
给公司的交付件
预算/分派（可选）
估计产品的预算及分派
讨论主要的未解决问题，包含资金投入的及时性及性质。
将实际日期的项目资源、本钱和时间进度与估计的整个项目的资源、本钱和时间进度进行比较。
验收标准（可去失落）
客户的验收标准就是产品应满足在需求规格文档中描述的需求。
系统测试和验收测试将证实产品与需求规格坚持了一致。
<请在这里注明客户特殊的验收标准。
验收标准是基于客户的需要，所以应由客户来制定，在需要的时候由项目组协助。
交付件的属性如：
质量目标，测试标准，验收结束后发明故障的处理方法，文档等。
>
质量计划（也可单独成文档）
12.1项目过程界说
1）选择开发模型
开发类，增强类，维护类
2）并可在此基础上进一步流程裁剪：
提供与标准开发流程的偏差，并说明裁剪原因。
12.2质量目标
可以定性或定量描述，为提高可控制性，尽量采取定量质量指标描述。
若能定量描述，请参考下表：
参考或直接引用项目怀抱表中质量目标部分的数据。
表9项目质量目标
NO.
项目质量目标
目标
基线
（暂不填）
上限
（暂不填）
下限
（暂不填）
说明
1
进度偏差率
80%
2
需求稳定性
90
3
硬件第一次样机制作完成前缺陷发明数目
<=3
4
样机投板次数
20%
5
软件宣布前缺陷发明密度
6
编码缺陷发明密度
7
硬件/软件总体设计缺陷发明数目
8
硬件/软件详细设计缺陷发明数目
9
需求更改/设计更改/工程更改数
10
文档齐套性
11
返修率
......
12.3通过技术手段包管质量
通过哪些技术手段可以包管质量目标和关键性能指标的告竣。
例如：
通过静态代码阐发工具和自动化软件测试工具可以有效提高软件质量。
12.4质量控制活动
罗列执行的质量控制活动。
12.4.1技术评审活动
产品开发过程中需要哪些技术评审活动，哪些技术评审点可以合并？
各技术评审点的评审要素的裁剪说明t
♦技术评审1和技术评审2合并
TR1与TR2的评审要素合并，并裁剪，评审要素重点放。
。
。
，而。
。
。
方面要素可免去。
♦技术评审3
TR3的评审要素需裁剪，评审要素重点放。
。
。
，而。
。
。
方面要素可免去。
♦技术评审4
TR4的评审要素需不裁剪；
♦技术评审5
TR4的评审要素需不裁剪；
♦技术评审6
TR4的评审要素需不裁剪；
12.4.2正规检视活动（同行评审）
产品开发过程中需要设置对哪些输出的正规检视活动？
♦软件模块测试计划
♦软件概要设计
♦软件代码
♦软件测试陈述
♦硬件总体设计
♦硬件电路原理图和PCB图
♦硬件测试陈述
12.4.3测试
对测试战略和测试活动进行说明：
也可合入文档《产品测试与验证计划》
●测试活动合并裁剪
例如：
增强类项目，集成测试和系统测试可以合并。
●单位测试
测试质量目标
测试依赖关系阐发
测试停止准则
●集成测试
测试质量目标
测试依赖关系阐发
测试重点
回归测试战略
测试停止准则
●系统测试
测试质量目标
测试依赖关系阐发
测试重点
回归测试战略
12.5质量包管活动
罗列应该执行的质量包管活动。
举例如下：
12.5.1内部审计
每个项目在开产生命周期中至少进行一次内部审计。
12.5.2交付件审计（按阶段）
♦技术评审1之后
♦技术评审2之后
♦技术评审3之后
♦技术评审4之后
♦技术评审5之后
♦技术评审6之后
12.5.3基线审计
规划在哪些阶段点需要进行基线审计。
♦技术评审1之后
♦技术评审2之后
♦技术评审3之后
♦技术评审4之后
♦技术评审5之后
♦技术评审6之后
项目沟通计划
14.1项目组会议
列举项目跟踪、监控的会议类型、频率以及介入人员，可以采取列表形式。
参考下例：
表7项目组会议
No
会议
频度
介入人
跟踪机制
1.
阶段结束会议
2.
项目总结会议
3.
14.2项目陈述机制
列举项目跟踪、监控过程中需要出示的陈述类型、频率、陈述人、汇报人信息。
参考下例：
表8项目陈述机制
No.
陈述
准备人
频度
向谁汇报
1.
项目状态陈述
2.
项目阶段结束陈述
3.
项目总结陈述
4.
项目的重用计划
需要对公司其他产品在本产品中实现重用进行阐发以及本产品可以共享给公司的其他产品以供重用，可以直接链接相应的文档或者在此加以说明。
15.1现有重用构件
Sl.No
构件/文档名
采取阶段
（Ifapplicable）
重用构件的资产ID
1
2
15.2新增重用构件
序号
构件/文档名
需求/文档id
说明
1
2
注：
资产库中已有的重用构件
2项目产生的新的重用构件
配置管理计划
项目的配置管理活动应该依照配置管理计划来执行。
拜见《XXX项目配置管理计划》。
问题
<描述与以后版本有关的问题或畴前一版本继承而来的问题>
列进项目早期任何其他已经发明的问题，包含组间协调、实验环境、工作场合等问题。
Sl.No
问题
责任人
状态（掀开/关闭）
最早关闭日期
1
2
风险管理计划
依照风险管理规程来管理项目的风险。
祥见《XXX项目风险管理计划》。
在此详细说明项目的风险项、风险描述、风险级别、规避办法、应急计划、触发条件。
具体操纵办法请参考风险评估和管理相关文档。
存在哪些技术、市场和财务风险？
已确认的风险和假设是否已解决？
有无遗留问题？
有无新的风险和假设？
提供简洁的风险管理计划。
为了减少风险，在各阶段必须做些什么？
如果在计划的时间规模内，这些风险不克不及解决，有没有准备其它的计划？
如果没有这些风险，对项目会有哪些影响？
与产品包相关的各方面的风险包含：
市场/客户风险；
技术风险；
财务风险；
制造风险；
推销风险；
技术支持风险；
项目风险
客户的介入
Sl.No序号
在哪些方面（阶段、工作产品等）介入
期望客户承担的职责
最年夜响应时间
说明
1
2
3
4
培训计划
在本节中，明确说明相应人员现有的水平、需要的技能、培训方法和培训效果评估方法信息。
举例如下：
表10培训计划
No
培训领域
需要的技能水平
项目组成员
已具备的技能水平
培训方法
培训效果评估方法
1
2
3
导师计划也应包含在本培训计划中，该类计划在“培训办法”一栏需标识“导师培训”。
计划更新战略
在本节中，应描述项目计划的更新战略，明确说明项目计划更新的宣布办法。
还要说明对项目计划进行变动控制和管理的机制以及其载体。
以下文字仅供参考：
在产生如下事件时，PM修订项目计划和参考文档：
达到某里程碑，在每个阶段结束后如果需要的话修订项目计划。
项目的规模产生变更
当风险成为现实时采纳了相应的行动
当进度、工作量超出控制的规模并需要采纳纠正行动时。
当与上阶段规模变更超出+/15%。
内部或外部审计招致的纠正活动
对修订后的项目计划依照项目管理规程来批准和签发。
项目计划的更新，存在阶段驱动性更新和事件驱动性更新两种类型。
阶段驱动性更新是指在每一阶段结束时，如果计划或者工作量估计的变动超出10％，就需要对项目计划进行更新；事件驱动性更新是指在计划执行过程中遇到项目突然变动或者其他影响项目正常运行的事件产生，需要对项目的计划进行更新。
项目计划更新需要对计划文档更新和项目里程碑计划的更新。
不管是阶段驱动性更新还是时间驱动性更新都需要对项目的更新计划进行评审，评审需要PDT经理、PQA以及功能领域代表介入。
时间：
2021.02.16
创作：
欧阳组
升级会员 