产品部项目过程改进办法Word格式.docx
- 文档编号:3458713
- 上传时间:2023-05-01
- 格式:DOCX
- 页数:21
- 大小:41.81KB
产品部项目过程改进办法Word格式.docx
《产品部项目过程改进办法Word格式.docx》由会员分享,可在线阅读,更多相关《产品部项目过程改进办法Word格式.docx(21页珍藏版)》请在冰点文库上搜索。
填写人员工时
6
需求分析
需求调研报告
需求规格说明书
需求跟踪矩阵
(产品开发阶段)
测试
7
需求变更
需求变更单
需求跟踪表
(试运行阶段)
8
需求评审
需求同行评审
售前工程师、PMO、QC
二级部门经理
9
概要设计
编写概要设计
提交同行评审
技术专家、PMO、项目组
PMO/主任工程师
10
测试于需求分析过程介入,并编写测试用例
测试工程师
11
实施方案
实施方案评审
实施操作记录
技术专家、PMO
12
故障处理
故障受理、处理、分析报告及后续跟踪
PMO、技术专家
考核要求
各执行人需按以上表式的任务要求执行(具体内容参考以下各章节)。
QA将在整个过程中监督各执行人的完成情况,并定期出QA报告向PMO和产品经理汇报,每月绩效考核将以上述任务的执行完成质量、及时率为主要考核指标。
角色定义说明
项目经理――项目(开发)负责人
售前――项目对应的售前工程师
PMO-项目的分管高级项目经理(产品经理)
评审委员会:
⏹销售阶段技术方案评审—主任工程师、PMO、专业领域技术专家、产品部经理、工程部经理
⏹计划评审—PMO、售前、产品部经理、工程部经理
⏹需求评审—PMO、售前
⏹设计评审—专业领域技术专家、PMO
QA-专职过程控制人员,XXXXX
一、项目启动
1.编写项目启动报告
召开项目启动会(内部),明确项目要求、组织架构、工程分工界面、以及进度计划要求,编写会议纪要。
会议签到表模版:
会议纪要模版:
项目经理应按照根据合同要求收集招投标文件、技术方案、系统配置、实施进度计划,并编写《项目启动报告》。
项目启动报告模版:
具体内容包括客户组织架构,项目组成员及角色分工,项目范围、系统环境等。
2.配置管理
项目启动后,项目经理通知配置管理人员建立配置库、分配权限
即日起,所有的文档(包括需求开发文档、项目管理文档)、代码均纳入配置管理。
配置管理要求文件:
3.制定项目计划
按合同要求制定项目计划,具体要求如下:
⏹制定项目的重大里程碑
⏹根据项目目标,对任务进行分解,具体到每项任务和负责人员。
⏹使用MicrosoftProject制定项目计划
项目计划模版:
4.项目计划评审
项目经理制定的项目计划必须提交评审,具体评审要求见同行评审:
二、项目状态管理
1.状态报告
a)周报
为了加强项目管理工作,让部门经理和产品部经理及时、准确、全面地了解各项目实施情况,监督项目进度,控制项目风险,提高项目透明度。
因此,从正式启动到项目终验期间,每周需提交项目周报。
具体要求如下:
⏹提交人员:
一般由项目经理提交项目周报,或者由项目经理的委托人代为提交
⏹提交时间:
每周一提交上周的项目周报,截止为每周一晚24点(以邮件收到时间为准)。
⏹重点内容:
着重填写本周项目进度、下周项目计划、目前进度与原计划的区别、问题/风险及解决办法等。
⏹周报模版
b)日报
在项目实施任务高峰期(例如系统联调、安装部署等关键阶段),PMO可要求项目经理在此阶段提交日报,便于及时跟踪项目的最新进展以及控制项目风险。
项目经理需每天提交工程日报,在日报里面需要描述当天工作情况,存在什么问题(如果需要协助解决的请在日报中注明)以及次日需计划安排。
日报模版:
2.项目工时表
为了加强对资源使用情况的有效管理,要求项目组成员每周第一个工作日的上午10:
00前,项目组成员应向项目经理提交上周的《个人工时统计表》,并提交配置库。
项目经理在星期一下班之前应汇总上周实际工时数据,填入对应项目的《项目状态报告-周报》。
项目经理要对项目组内工作人员每天填报的工时进行审核,以确保各人填写工时的正确性,不符合要求或者不准确的工时统计数据,应当责令其重新填写。
项目工时表模版(含填写说明)
3.会议纪要
项目例会必须形成会议纪要提交配置库并发送与会人员及项目组领导
会议纪要模版见一/1
4.项目计划变更
每周必须更新一次项目计划,并对后续的计划进一步细化
若项目实施过程中发现对后续里程碑节点有影响时,需即时更新计划.
计划变更列明变更原因,提交同行评审组评审,评审后提交配置库,由项目管理人员进行跟踪管理。
需提交内容:
最新版项目计划,同行评审疑问记录,模版见一/3,4
5.项目沟通计划
角色
职责
及时向项目干系人汇报项目实施状况
了解项目情况,对项目进展做跟踪指导
部门领导
了解项目情况,对重大问题做决策支持
客户\客户代表
了解项目情况,对里程碑的节点做相关确认
沟通内容
沟通负责人
沟通对象
沟通频度
沟通渠道
项目状态报告
部门经理、PMO、售前支持、
研发经理、客户代表
每周
邮件
项目组例会
项目经理,项目组成员、客户代表
定期
例会
项目实施问题汇报
PMO、同行项目经理、技术专家
每二周
重大问题紧急汇报
部门经理、PMO、技术专家
客户代表(可视情况)
不定期
――
项目工作指导
与评价
每月
三、需求开发管理
1.需求调研
当项目启动后,项目组可以开展需求调研工作,由项目经理与用户沟通后,制定需求调研开发计划,并收集与需求相关的各种资料,准备调研的内容和问题,并填写在《需求调研报告》中,项目调研人员依据需求调研开发计划及《需求调研报告》中的内容和问题展开调研;
同时收集开发系统需要的各种相关样表、资料;
调研完毕后整理《需求调研报告》,需求调研活动完成。
需求调研报告模版:
2.需求分析
需求调研完成后,由参与调研的所有人员对需求调研阶段收集的用户需求进行必要的汇总和整理,并把整理后得用户需求添加到《需求规格说明书》中。
之后,系统设计工程师根据需求分析结论整理软件系统需求,并形成软件系统的大致框架,划分子系统,最终形成《需求规格说明书》。
需求规格说明书模版:
3.需求评审
需求评审主要发生在以下几种阶段:
⏹系统建设进入需求分析阶段,完成《需求规格说明书》后
⏹系统处于工程实施阶段或试运行阶段,用户提出补充需求,提交《需求变更单》,每两周汇总一次需求,并进行统一分析归纳,形成《调研报告》和《需求跟踪表》后。
以上两种情况均需进行需求同行评审;
4.需求确认
客户代表对评审通过的《需求规格说明书》进行确认,确认的方式可以根据项目实际情况进行,建议的方式如下:
⏹客户代表在《需求规格说明书》上签字确认;
⏹召开需求评审会,最后以会议纪要的形式加以确认;
⏹客户代表对需求确认的回复邮件。
5.需求跟踪
需求跟踪主要是指在产品研发过程中,PMO必须对需求规格说明书中的各项需求的开发情况进行跟踪管理,以便清楚地知道每个需求完成情况。
PMO根据评审通过的《需求规格说明书》,必须把所有功能需求、需求编号等相关内容添加到《需求跟踪矩阵》。
在需求开发过程中,相关人员需及时更新数据库、数据表、类名称、程序代码文件名称以及系统测试用例填写到《需求跟踪矩阵》中对应的列,由PMO汇总,并提交配置库。
需求跟踪表式:
备注:
需求跟踪矩阵适用于项目启动――试运行阶段
6.需求变更和问题处理
需求变更和问题处理主要是指系统在系统试运行阶段,用户提出需求变更请求后,必须填写《需求变更申请单》(第一部分),并提交项目组。
项目经理对变更进行分析,重点在于判断变更的性质和影响,完成《需求变更申请单》(第二部分)。
如果用户提出的需求变更是重大需求变更(重大需求指“变更工作量超过2小时,且涉及到重大逻辑更改”的需求),项目经理需组织相关人员进行同行评审,并决定变更请求是被接受还是拒绝,评审完毕,完成《需求变更申请单》(第三部分);
如果用户提出的需求变更是非重大需求变更,授权由项目经理来审批,并完成《需求变更申请单》(第三部分)。
需求变更请求被接受后,如果是新增一个完整的、较大的模块,项目组必须再进行详尽的需求调研,完毕后整理《需求调研报告》,再对需求调研收集的用户需求进行必要的汇总和分析,把新增的需求编写到《需求规格说明书》中,然后项目经理发起同行评审,对《需求规格说明书》中新增的需求进行评审,评审通过后让用户进行签字确认,并填写《需求跟踪表》,安排开发人员执行变更请求;
若为一般需求,项目经理直接提交《需求变更申请单》给用户签字确认,并填写《需求跟踪表》,安排开发人员执行变更请求,同时要求开发人员在开发过程中及时更新《需求跟踪表》相关内容。
若为系统运行中出现的问题,项目经理可直接填写《需求跟踪表》,并安排开发人员进行修正,同时在开发过程中及时更新《需求跟踪表》相关内容。
需求变更申请单模版:
需求跟踪表模板:
需求跟踪表适用于项目试运行――项目验收阶段
四、系统设计
1.概要设计
项目组根据《需求规格说明书》的要求,按项目计划进行概要设计,梳理功能点、流程,并完成《概要设计说明书》
概要设计相关模版:
2.设计评审
设计评审主要发生在以下几种阶段:
⏹系统建设进入系统设计阶段,完成《概要设计说明书》后
⏹系统处于工程实施阶段或试运行阶段,用户提出的补充需求经过详细的需求分析和评审后,每两周进行一次概要设计评审
以上两种情况均需进行设计同行评审,评审具体要求请参照《同行评审要求》;
3.详细设计
概要设计评审通过后,进一步细化,编写《模块设计说明书》、《页面设计说明书》、《数据库设计说明书》等内容。
详细设计相关模版:
五、测试
项目经理必须将应用软件提交测试工程师进行系统测试,由测试人员测试通过后才可提交用户。
1.测试人员要求
测试人员于需求分析阶段参与,并参与需求、概要、页面、数据库设计评审,于开发阶段同步完成测试用例编写。
2.测试准备
项目经理需提前一周以上提交《测试申请单》申请测试,便于测试人员安排测试计划,同时编写《测试方案》,提交项目经理确认。
《测试方案》确认完成后,开发人员需向测试人员提供测试时环境清单,并和测试人员一起准备测试环境。
测试相关模版:
3.测试执行
测试环境搭建完成后,项目开发人员配合测试人员进行系统测试。
如遇重大bug导致测试无法进行,需要立即修改bug,同时要报告项目经理,便于项目经理掌控项目进度。
4.缺陷跟踪
测试人员完成测试后,提供《测试报告》给开发人员,开发人员需及时对缺陷进行修改,修改完成后,再发给测试人员进行测试。
测试人员会对缺陷进行跟踪,在可能的前提下会搭建TestDirectorBug管理环境,方便统计跟踪。
对于在测试过程中遇到的有争议的缺陷,需要项目经理决定此缺陷是否属于缺陷。
测试缺陷报告模版:
六、同行评审
项目计划/计划变更、需求/需求变更、概要设计均需执行同行评审,详细设计可项目组自行组织,具体要求如下:
⏹评审成员范围:
项目计划/计划变更:
售前工程师、PMO、项目经理、项目组、QA;
需求/需求变更:
售前工程师、PMO、项目经理、项目组、测试
概要设计:
技术专家、项目经理、项目组;
详细设计:
技术专家、项目经理、项目组
⏹评审准备:
项目经理将需评审的文档、以及评审要求以邮件形式提交同行评审组,并确定评审形式及时间
计划评审要求模版:
需求评审要求模版:
概要设计评审要求模版:
详细设计评审要求模板:
⏹评审形式:
1)会议――重大项目的项目计划、需求分析评审,以及重大功能的需求变更必须以会议形式进行,在评审会议开始前,每个同行评审者均需事先预评审
2)传阅――同行评审者以邮件形式将评审缺陷回复给项目经理,并与项目经理沟通,确认是否为缺陷
⏹评审执行要求
同行评审者根据评审要求审阅评审文件,并在评审疑问记录表格中填写疑问,发送给项目经理,由项目经理汇总,填写《同行评审疑问记录报告》,并跟踪执行。
评审疑问记录报告:
特别说明:
其中每位同行评审者的疑问记录要求:
项目计划疑问不得少于3条,需求规格说明书不得少于10条,概要设计说明书不得少于10条。
⏹评审结果:
由项目经理对评审疑问进行修正,经同行评审组确认后即提交配置库,由项目管理人员进行跟踪管理。
同行评审疑问记录报告模版:
七、监控管理
1.项目计划汇总
项目计划提交到配置库后,此项目即纳入项目管理人员的监控范围,并每月对当前的最新的项目计划进行汇总,并提交事业部经理和二级部门经理审阅。
同时,通过此汇总表可以清晰反映各项目所处的阶段,以及执行计划的偏差情况。
项目计划汇总表模版:
2.人力资源分析汇总
为了能集中反映各项目组人力资源使用情况,便于对资源进行最优配置,提升执行效率,PMO每月将根据项目经理提交的项目状态报告中的每周个人工时统计数据以及工作情况填写人力资源汇总表,并提交事业部项目管理人员汇总。
人力资源汇总表模版:
3.项目状态报告汇总
项目管理人员收到周报后,将周报提交事业部经理和产品部经理,并根据周报的内容和项目实际情况,编写项目情况汇总表,提交事业部经理和产品部经理审阅。
同时,项目管理人员对每次周报的提交时间和周报的质量进行记录和评分,对于迟交和质量较差的项目,将以红色表示,在每周三下班前将总结报告发送到事业部经理、产品部经理和项目经理。
4.执行过程监控
项目管理人员根据项目所在阶段,使用《项目管理检查单》、《软件工程检查单》对项目的执行情况进行监督,并于每周一提交《项目控制报告》,报告上周对项目的检查情况,发给产品部经理和项目经理。
项目经理应对其中提出的偏差进行纠正,项目管理人员会进行跟踪,直到关闭偏差。
检查单表式:
同时,项目管理人员检查配置库上开发人员的工时提交情况,填写《工时提交情况检查表》,发给产品部经理,作为该月绩效考核的依据。
工时提交情况检查表式:
八、运行维护规定
1.系统运行维护制度
a)系统硬件调整
已上线的生产系统,如需进行系统硬件的调整(包括硬件升级、设备重启、架构调整、系统参数调整等),必须提前编写调整方案(包括调整的工作内容、实施步骤、开始/结束时间、风险、对业务的影响、应急恢复方案、回退原则),书面提交用户。
硬件调整原则上安排在晚上23点以后,早上5点前需要完成。
如可能,尽量安排在周五晚上开始。
实施工作完成后,第二天需要安排现场维护人员,要求维护人员在业务高峰开始前半小时到达现场。
得到用户书面确认后,方可进行硬件调整。
必须严格按照方案步骤进行,不得提前进行,如规定时间未完成,必须按照应急方案进行恢复。
b)系统软件调整
已上线的生产系统,如需进行系统软件的调整(包括操作系统打补丁、系统软件升级、LISENCE变更、系统软件参数变更、系统软件重启等),必须提前编写调整方案(包括调整的工作内容、实施步骤、开始/结束时间、风险、对业务的影响、应急恢复方案、回退原则),书面提交用户。
系统软件调整原则上安排在晚上23点以后,早上5点前需要完成。
得到用户书面确认后,方可进行系统软件调整。
c)应用软件升级
已上线的生产系统,如需进行应用软件的升级,必须提前编写升级说明(包括升级影响的功能、功能说明、实施步骤、开始/结束时间、风险、对业务的影响、版本回退方案、回退原则),书面提交用户。
升级前必须做好现网版本的源代码和发布程序的备份。
升级前必须在测试平台由用户测试书面确认,如用户无测试的条件,则需编写内测的情况书面提交用户,由用户确认版本测试通过。
得到用户书面确认后,方可进行应用软件升级。
必须严格按照方案步骤进行,不得提前进行。
一旦发现程序有问题,必须第一时间进行回退,不得在现网平台进行程序修改。
d)数据库操作
大批量的数据操作,需事先书面告知用户,并得到用户的书面认可,方可进行操作。
必须在晚上闲时才可操作。
后台调整客户/业务数据,必须得到用户的书面确认,才可操作。
e)系统测试
系统测试必须在测试平台进行,现网运行的平台不得进行测试。
如个别功能无法在测试平台进行测试,只能在现网平台测试。
必须向用户提交书面的申请,说明测试的功能、可能的影响、测试步骤、开始/结束时间、应急处理等,用户书面确认后方可进行。
2.故障类别、处理时限、上报要求及故障报告
系统bug和平台运行中断/部分中断,统称为故障。
故障响应及处理时限如下:
故障类别
故障说明
故障定义
响应时间
处理时限
特大故障
系统提供给用户的业务或服务不能使用
1)全阻3分钟以上
2)影响50%以上座席/话务10分钟以上
3)接通率降低20%以上
<
15分钟
30分钟
重大故障
1)全阻3分钟以下
2)影响50%以上座席/话务3分钟以上或影响20%座席/话务10分钟以上
3)座席程序故障1天累计大于总座席数的30%
4)接通率降低10%-20%
5)客户及业务数据处理错误,超过日业务数据处理量30%以上
1小时
较大故障
系统提供给用户业务或服务部分受到影响
1)影响20%以下的座席/话务10分钟以下
2)座席程序故障1天累计小于总座席数的30%
3)接通率降低5%-10%
4)客户及业务数据处理错误,占日业务数据处理量20%-30%
24小时
一般故障
系统提供给用户业务或服务能够正常运行,但是影响客户感知
系统提供给用户业务或服务能够正常运行,但是影响客户感知或引起客户投诉
按实际情况决定,原则上不超过48小时
上报流程
故障处理要求
业务恢复时限
第一时间(3分钟内)上报PMO、二级部门经理、事业部部门
产品部牵头处理
30分钟内
全阻3分钟以上
影响50%以上座席/话务10分钟以上
接通率降低20%以上
第一时间(3分钟内)上报PMO、二级部门经理
30分钟,本地实施解决
超过30分钟,产品部牵头解决
全阻3分钟以下
影响50%以上座席/话务3分钟以上
或影响20%座席/话务10分钟以上
座席程序故障1天累计大于总座席数的30%
接通率降低10%-20%
如1天内无法解决,则上报PMO
1天内,本地实施解决
超过1天,产品部协助解决
影响20%以下的座席/话务10分钟以下
座席程序故障1天累计小于总座席数的30%
接通率降低5%-10%
故障发生后的24小时内,项目组需要向用户提交《故障报告》,对故障现象、处理过程及当前原因分析的现状进行详细描述,并根据分析情况填写解决方案。
待原因问题完全定位后,项目组需要将《故障报告》最终稿提交给用户,并在解决方案中明确各项解决措施的实施时间。
各项措施完成后,请用户配合填写反馈意见,并通过书面形式进行确认。
故障报告模板:
3.系统巡检制度
a)各项目上线后须建立巡检制度,包括日巡检、周巡检、月巡检。
b)根据各项目的实际情况,须完善日巡检表、周巡检表、月巡检表。
c)巡检计划必须按规定周期执行
d)对于巡检结果,需要分析的,须及时发送给相关责任人。
e)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品 项目 过程 改进 办法