产品部项目过程改进办法.docx

产品部项目过程改进办法.docx

《产品部项目过程改进办法.docx》由会员分享，可在线阅读，更多相关《产品部项目过程改进办法.docx（21页珍藏版）》请在冰豆网上搜索。

产品部项目过程改进办法

产品部项目管理改进办法

为了解决项目管理过程的不规范行为，对项目的整个过程和各个方面实施完善的管理，进而提升项目质量和实施效率，在原先项目管理要求基础上制定了此改进办法，请各位严格遵守执行。

执行要求

任务项

考核要求

执行人

配合人员

负责人

监控人

考核

1

工程启动

项目组召开内部

启动会议，出启动报告

项目经理

售前、

PMO、QA

PMO

QA

二级部门

经理

2

配置管理

日常文档代码需

纳入配置管理

项目组

研发组

配置管理人

员

项目经理

产品经理

QA

PMO

3

项目计划

计划制定、需评

审

计划变更、需评审

项目经理

售前、

PMO、QA

PMO

QA

二级部门

经理

4

项目状态

管理

提交周报

项目经理

产品经理

项目经理

产品经理

PMO

研发经

理

PMO

研发经理

5

工时统计

填写人员工时

项目组

项目经理

QA

QA

6

需求分析

需求调研报告

需求规格说明书需求跟踪矩阵

（产品开发阶段）

项目组

项目经理

QA

测试

PMO

7

需求变更

需求变更单

需求跟踪表

（试运行阶段）

项目组

项目经理

QA

测试

PMO

8

需求评审

需求同行评审

项目经理

售前工程师、

PMO、QC

PMO

QA

二级部门

经理

9

概要设计

编写概要设计

提交同行评审

项目组

技术专家、

PMO、项目

组

PMO/主任

工程师

QA

QA

10

测试

测试于需求分析

过程介入，并编写测试用例

测试工程

师

测试

项目经

理

PMO

11

实施方案

实施方案评审

实施操作记录

项目组

技术专家、

PMO

项目经理

QA

PMO

12

故障处理

故障受理、处理、

分析报告及后续跟踪

项目组

PMO、技术

专家

项目经理

QA

PMO

考核要求

各执行人需按以上表式的任务要求执行（具体内容参考以下各章节）。

QA将在整个过程中监督各执行人的完成情况，并定期出QA报告向PMO

和产品经理汇报，每月绩效考核将以上述任务的执行完成质量、及时率为主要考核指标。

角色定义说明

项目经理――项目（开发）负责人

售前――项目对应的售前工程师

PMO－项目的分管高级项目经理（产品经理）

评审委员会：

⏹

⏹

⏹

⏹

销售阶段技术方案评审—主任工程师、PMO、专业领域技术专家、产品部经理、工程部经理

计划评审—PMO、售前、产品部经理、工程部经理

需求评审—PMO、售前

设计评审—专业领域技术专家、PMO

QA－专职过程控制人员，XXXXX

会议纪要模版：

一、

项目启动

1.编写项目启动报告

召开项目启动会（内部），明确项目要求、组织架构、工程分工界面、以及进度计划要求，编写会议纪要。

E:

\部门工作文档\

E:

\部门工作文档\

会议签到表模版：

项目过程改进1.0—0116\附件－××项目项_会目议过签程到改表进.1doc.0—0116\附件－××项目_会议纪要模

项目经理应按照根据合同要求收集招投标文件、技术方案、系统配置、实施进度计划，并编写《项目启动报告》。

E:

\部门工作文档\

项目启动报告模版：

项目过程改进1.0—0116\附件－××项目_项目启动报告.doc

具体内容包括客户组织架构，项目组成员及角色分工，项目范围、系统环境等。

2.

配置管理

项目启动后，项目经理通知配置管理人员建立配置库、分配权限即日起，所有的文档（包括需求开发文档、项目管理文档）、代码均纳入配置管理。

E:

\部门工作文档\

配置管理要求文件：

项目过程改进1.0—0116\附件－部门配置管理要求.doc

3.

制定项目计划

按合同要求制定项目计划，具体要求如下：

⏹

⏹

⏹

制定项目的重大里程碑

根据项目目标，对任务进行分解，具体到每项任务和负责人员。

使用MicrosoftProject制定项目计划

E:

\部门工作文档\

项目计划模版：

项目过程改进1.0—0116\附件－××项目_项目进度计划mpp.mpp

4.

二、

1.

项目计划评审

项目经理制定的项目计划必须提交评审，具体评审要求见同行评审：

项目状态管理

状态报告

a）周报

为了加强项目管理工作，让部门经理和产品部经理及时、准确、全面

地了解各项目实施情况，监督项目进度，控制项目风险，提高项目透明度。

因此，从正式启动到项目终验期间，每周需提交项目周报。

具体要求如下：

⏹

⏹

⏹

提交人员：

一般由项目经理提交项目周报，或者由项目经理的委托人代为提交

提交时间：

每周一提交上周的项目周报，截止为每周一晚24点（以邮件收到时间为准）。

重点内容：

着重填写本周项目进度、下周项目计划、目前进度与原计划的区别、问题/风险及解决办法等。

E:

\部门工作文档\

⏹

周报模版

项目过程改进1.0—0116\附件－××项目_周报YYMMDD－YYMMDD.xls

b）日报

在项目实施任务高峰期（例如系统联调、安装部署等关键阶段），PMO可要求项目经理在此阶段提交日报，便于及时跟踪项目的最新进展以及控制项目风险。

具体要求如下：

项目经理需每天提交工程日报，在日报里面需要描述当天工作情况，存在什么问题（如果需要协助解决的请在日报中注明）以及次日需计划安排。

E:

\部门工作文档\

日报模版：

项目过程改进1.0—0116\附件－××项目_日报模板YYMMDD.doc

2.

项目工时表

为了加强对资源使用情况的有效管理，要求项目组成员每周第一个工作

日的上午10：

00前，项目组成员应向项目经理提交上周的《个人工时统计表》，并提交配置库。

项目经理在星期一下班之前应汇总上周实际工时数据，填入对应项目的《项目状态报告－周报》。

项目经理要对项目组内工作人员每天填报的工时进行审核，以确保各人填写工时的正确性，不符合要求或者不准确的工时统计数据，应当责令其重新填写。

E:

\部门工作文档\

项目工时表模版（含填写说明）

项目过程改进1.0—0116\附件－××项目_（个人）工时统计表YYMMDD-YYMMDD

3.

4.

会议纪要

项目例会必须形成会议纪要提交配置库并发送与会人员及项目组领导会议纪要模版见一/1

项目计划变更

每周必须更新一次项目计划，并对后续的计划进一步细化

若项目实施过程中发现对后续里程碑节点有影响时，需即时更新计划.计划变更列明变更原因，提交同行评审组评审，评审后提交配置库，由

项目管理人员进行跟踪管理。

需提交内容：

最新版项目计划，同行评审疑问记录，模版见一/3，4

5.

项目沟通计划

角色

职责

项目经理

及时向项目干系人汇报项目实施状况

PMO

了解项目情况，对项目进展做跟踪指导

部门领导

了解项目情况，对重大问题做决策支持

客户\客户代表

了解项目情况，对里程碑的节点做相关确认

项目状态报告

项目经理

部门经理、PMO、售前支持、

研发经理、客户代表

每周

邮件

项目组例会

项目经理

项目经理，项目组成员、客户代表

定期

例会

项目实施问题汇报

项目经理

PMO、同行项目经理、技术专家

每二周

例会

重大问题紧急汇报

项目经理

部门经理、PMO、技术专家客户代表（可视情况）

不定期

――

项目工作指导

与评价

PMO

项目经理

每月

邮件

三、

1.

需求开发管理

需求调研

当项目启动后，项目组可以开展需求调研工作，由项目经理与用户沟

通后，制定需求调研开发计划，并收集与需求相关的各种资料，准备调研的内容和问题，并填写在《需求调研报告》中，项目调研人员依据需求调研开发计划及《需求调研报告》中的内容和问题展开调研；同时收集开发系统需要的各种相关样表、资料；调研完毕后整理《需求调研报告》，需求调研活动完成。

E:

\部门工作文档\

需求调研报告模版：

项目过程改进1.0—0116\附件－××项目_需求调研报告.doc

2.

需求分析

需求调研完成后，由参与调研的所有人员对需求调研阶段收集的用户

需求进行必要的汇总和整理，并把整理后得用户需求添加到《需求规格说明书》中。

之后，系统设计工程师根据需求分析结论整理软件系统需求，并形成软件系统的大致框架，划分子系统，最终形成《需求规格说明书》。

E:

\部门工作文档\

需求规格说明书模版：

项目过程改进1.0—0116\附件－××项目_需求规格说明书.doc

3.

需求评审

需求评审主要发生在以下几种阶段：

⏹

⏹

系统建设进入需求分析阶段，完成《需求规格说明书》后

系统处于工程实施阶段或试运行阶段，用户提出补充需求，提交《需求变更单》，每两周汇总一次需求，并进行统一分析归纳，形成《调研报告》和《需求跟踪表》后。

4.

以上两种情况均需进行需求同行评审；

需求确认

客户代表对评审通过的《需求规格说明书》进行确认，确认的方式可

以根据项目实际情况进行，建议的方式如下：

⏹

⏹

⏹

客户代表在《需求规格说明书》上签字确认；召开需求评审会，最后以会议纪要的形式加以确认；客户代表对需求确认的回复邮件。

5.

需求跟踪

需求跟踪主要是指在产品研发过程中，PMO必须对需求规格说明书中

的各项需求的开发情况进行跟踪管理，以便清楚地知道每个需求完成情况。

PMO根据评审通过的《需求规格说明书》，必须把所有功能需求、需求

编号等相关内容添加到《需求跟踪矩阵》。

在需求开发过程中，相关人员需及时更新数据库、数据表、类名称、程序代码文件名称以及系统测试用例填写到《需求跟踪矩阵》中对应的列，由PMO汇总，并提交配置库。

E:

\部门工作文档\

需求跟踪表式：

项目过程改进1.0—0116\附件－××项目_需求跟踪表.xls

6.

备注：

需求跟踪矩阵适用于项目启动――试运行阶段

需求变更和问题处理

需求变更和问题处理主要是指系统在系统试运行阶段，用户提出需求

变更请求后，必须填写《需求变更申请单》（第一部分），并提交项目组。

项目经理对变更进行分析，重点在于判断变更的性质和影响，完成《需求变更申请单》（第二部分）。

如果用户提出的需求变更是重大需求变更（重大需求指“变更工作量超过2小时，且涉及到重大逻辑更改”的需求），项目经理需组织相关人员进行同行评审，并决定变更请求是被接受还是拒绝，评审完毕，完成

《需求变更申请单》（第三部分）；如果用户提出的需求变更是非重大需求变更，授权由项目经理来审批，并完成《需求变更申请单》（第三部分）。

需求变更请求被接受后，如果是新增一个完整的、较大的模块，项目组必须再进行详尽的需求调研，完毕后整理《需求调研报告》，再对需求调研收集的用户需求进行必要的汇总和分析，把新增的需求编写到《需求规格说明书》中，然后项目经理发起同行评审，对《需求规格说明书》中新增的需求进行评审，评审通过后让用户进行签字确认，并填写《需求跟踪表》，安排开发人员执行变更请求；

若为一般需求，项目经理直接提交《需求变更申请单》给用户签字确认，并填写《需求跟踪表》，安排开发人员执行变更请求，同时要求开发人员在开发过程中及时更新《需求跟踪表》相关内容。

若为系统运行中出现的问题，项目经理可直接填写《需求跟踪表》，并安排开发人员进行修正，同时在开发过程中及时更新《需求跟踪表》相关内容。

E:

\部门工作文档\

需求变更申请单模版：

项目过程改进1.0—0116\附件－××项目_需求变更申请单.doc

E:

\部门工作文档\

需求跟踪表模板：

项目过程改进1.0—0116\附件－××项目_需求跟踪矩阵.xls

四、

1.

备注：

需求跟踪表适用于项目试运行――项目验收阶段

系统设计

概要设计

项目组根据《需求规格说明书》的要求，按项目计划进行概要设计，梳

理功能点、流程，并完成《概要设计说明书》

E:

\部门工作文档\

概要设计相关模版：

项目过程改进1.0—0116\附件－××项目_概要设计说明书.doc

2.

设计评审

设计评审主要发生在以下几种阶段：

⏹

⏹

系统建设进入系统设计阶段，完成《概要设计说明书》后

系统处于工程实施阶段或试运行阶段，用户提出的补充需求经过详细的需求分析和评审后，每两周进行一次概要设计评审

3.

以上两种情况均需进行设计同行评审，评审具体要求请参照《同行评审要求》；

详细设计

概要设计评审通过后，进一步细化，编写《模块设计说明书》、《页面设

计说明书》、《数据库设计说明书》等内容。

E:

\部门工作文档\

E:

\部门工作文档\

详细设计相关模版：

项目过程改进1.0—0116\项目过附程件改－进××1.0项—0116\目_模块附设件计－说××明书项.目doc_数据库设计说明书.doc

五、

测试

项目经理必须将应用软件提交测试工程师进行系统测试，由测试人员测

试通过后才可提交用户。

1.

测试人员要求

测试人员于需求分析阶段参与，并参与需求、概要、页面、数据库设计

评审，于开发阶段同步完成测试用例编写。

2.

测试准备

项目经理需提前一周以上提交《测试申请单》申请测试，便于测试人员

安排测试计划，同时编写《测试方案》，提交项目经理确认。

《测试方案》确认完成后，开发人员需向测试人员提供测试时环境清单，并和测试人员一起准备测试环境。

E:

\部门工作文档\E:

\部门工作文档\E:

\部门工作文档\

测试相关模版：

项目过程改进1.0—0116\项目过附程件改－进××1.0项—0116\目项_目测过试附程申件改请－进单××1.0doc项—0116\目_测试附方件案－.××doc项目_测试用例.doc

3.

测试执行

测试环境搭建完成后，项目开发人员配合测试人员进行系统测试。

如遇

重大bug导致测试无法进行，需要立即修改bug，同时要报告项目经理，便于项目经理掌控项目进度。

4.

缺陷跟踪

测试人员完成测试后，提供《测试报告》给开发人员，开发人员需及时

对缺陷进行修改，修改完成后，再发给测试人员进行测试。

测试人员会对缺陷进行跟踪，在可能的前提下会搭建TestDirectorBug管理环境，方便统计跟踪。

对于在测试过程中遇到的有争议的缺陷，需要项目经理决定此缺陷是否属于缺陷。

E:

\部门工作文档\

测试缺陷报告模版：

项目过程改进1.0—0116\附件－××项目_测试报告.xls

六、

同行评审

项目计划/计划变更、需求/需求变更、概要设计均需执行同行评审，详

细设计可项目组自行组织，具体要求如下：

⏹

⏹

评审成员范围：

项目计划/计划变更：

售前工程师、PMO、项目经理、项目组、QA；

需求/需求变更：

售前工程师、PMO、项目经理、项目组、测试概要设计：

技术专家、项目经理、项目组；

详细设计：

技术专家、项目经理、项目组

评审准备：

项目经理将需评审的文档、以及评审要求以邮件形式提交同行评审组，并确定评审形式及时间

E:

\部门工作文档\

计划评审要求模版：

项目过程改进1.0—0116\附件－××项目_计划评审要求.xls

E:

\部门工作文档\

需求评审要求模版：

项目过程改进1.0—0116\附件－××项目_需求评审要求.xls

E:

\部门工作文档\

概要设计评审要求模版：

项目过程改进1.0—0116\附件－××项目_概要设计评审要求.xls

E:

\部门工作文档\

详细设计评审要求模板：

项目过程改进1.0—0116\附件－××项目_详细设计评审要求.xls

⏹

⏹

⏹

评审形式：

1）会议――重大项目的项目计划、需求分析评审，以及重大功能的需求变更必须以会议形式进行，在评审会议开始前，每个同行评审者均需事先预评审

2）传阅――同行评审者以邮件形式将评审缺陷回复给项目经理，并与项目经理沟通，确认是否为缺陷

评审执行要求

同行评审者根据评审要求审阅评审文件，并在评审疑问记录表格中填写疑问，发送给项目经理，由项目经理汇总，填写《同行评审疑问记录报告》，并跟踪执行。

评审疑问记录报告：

特别说明：

其中每位同行评审者的疑问记录要求：

项目计划疑问不得少于3条，需求规格说明书不得少于10条，概要设计说明书不得少于10条。

评审结果：

由项目经理对评审疑问进行修正，经同行评审组确认后即提交配置库，由项目管理人员进行跟踪管理。

E:

\部门工作文档\

同行评审疑问记录报告模版：

项目过程改进1.0—0116\附件－××项目_同行评审疑问记录报告.xls

七、

1.

监控管理

项目计划汇总

项目计划提交到配置库后，此项目即纳入项目管理人员的监控范围，并

每月对当前的最新的项目计划进行汇总，并提交事业部经理和二级部门经理审阅。

同时，通过此汇总表可以清晰反映各项目所处的阶段，以及执行计划的

偏差情况。

E:

\部门工作文档\

项目计划汇总表模版：

项目过程改进1.0—0116\附件－部门项目计划汇总_2008年×月.xls

2.

人力资源分析汇总

为了能集中反映各项目组人力资源使用情况，便于对资源进行最优配置，

提升执行效率，PMO每月将根据项目经理提交的项目状态报告中的每周个人工时统计数据以及工作情况填写人力资源汇总表，并提交事业部项目管理人员汇总。

E:

\部门工作文档\

人力资源汇总表模版：

项目过程改进1.0—0116\附件－部门人力资源使用情况汇总_2008年×月.xls

3.

项目状态报告汇总

项目管理人员收到周报后，将周报提交事业部经理和产品部经理，并

根据周报的内容和项目实际情况，编写项目情况汇总表，提交事业部经理和产品部经理审阅。

同时，项目管理人员对每次周报的提交时间和周报的质量进行记录和评分，对于迟交和质量较差的项目，将以红色表示，在每周三下班前将总结报告发送到事业部经理、产品部经理和项目经理。

4.

执行过程监控

项目管理人员根据项目所在阶段，使用《项目管理检查单》、《软件工

程检查单》对项目的执行情况进行监督，并于每周一提交《项目控制报告》，报告上周对项目的检查情况，发给产品部经理和项目经理。

项目经理应对其中提出的偏差进行纠正，项目管理人员会进行跟踪，直到关闭偏差。

E:

\部门工作文档\E:

\部门工作文档\E:

\部门工作文档\

检查单表式：

项目过程改进1.0—0116\项目过附程件改－进××1.0项—0116\目项_目项过目附程管件改理－进检××1查.0单项—0116\.目xls_软件附工件程－检××查单项.目xls_项目执行控制报告.xl

同时，项目管理人员检查配置库上开发人员的工时提交情况，填写《工时提交情况检查表》，发给产品部经理，作为该月绩效考核的依据。

工时提交情况检查表式：

E:

\部门工作文档\

项目过程改进1.0—0116\附件－部门工时提交情况检查报告.xls

八、

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％以上

<30分钟

<1小时

较大故障

系统提供给用户

业务或服务部分

受到影响

1）影响20%以下的座席/话务10分钟以下

2）座席程序故障1天累计小于总座席数

的30%

3）接通率降低5%-10%

4）客户及业务数据处理错误，占日业务数据处理量20％－30％

<1小时

<24小时

一般故障

系统提供给用户

业务或服务能够正常运行，但是

影响客户感知

系统提供给