浅析软件产品化管理方向.docx

浅析软件产品化管理方向.docx

《浅析软件产品化管理方向.docx》由会员分享，可在线阅读，更多相关《浅析软件产品化管理方向.docx（14页珍藏版）》请在冰豆网上搜索。

浅析软件产品化管理方向

XXXXXXXXXX网络通讯有限公司

ZHEJIANGZHEJIANGUNIVERSITYINNOVATIONYUTONGNETWORKCOMMUNICATIONCO.’LTD.

软件产品化管理方向

2011年12月

密   级：

内部资料

状   态：

初稿 

文档修改/审批记录

版本号

修改人/审批人

修改/审批日期

修改内容

备注

1.0

2011-12-10

创建

1      综述

1.1   产品经理职位说明

产品经理是其所负责的产品线的守护者，负责产品规划、需求调研与管理以及产品输出审核。

产品经理必须确保产品线内的产品按照既定目标被实现，确保产品的功能属性和非功能属性达到要求。

产品经理必须了解产品在现场的使用情况。

总而言之，产品经理的工作是监督每件事情都确实做到，而且做的符合公司的期望和用户的期望。

1.2   工作领导关系

接受产品总监、产品部经理领导，产品总监在产品管理方面领导，产品部经理在日常工作计划上领导。

产品经理和项目经理、系统架构师属于同一级别的角色，三者不区分大小。

1.3  开展产品管理意义

产品经理的需求获取工作，由专业的产品经理负责对产品的功能属性和非功能属性进行收集，协助开发项目组明确开发目标和开发任务，解决沟通分散所带来的各个人员理解不同问题。

为项目组和客户之间建立一个专业的沟通渠道，解决研发人员频繁的和客户沟通而影响开发效率。

产品经理的需求跟踪管理过程对所获取并得到确认的需求进行跟踪，实时掌握需求处理进度，向项目相关人员通报项目进度及可能存在问题，解决项目组及项目相关人员对项目进展不能清楚掌握，项目实施没有独立人员跟踪和监督机制问题。

通过产品经理主持分析和设计工作，解决需求和设计、开发之间沟通不畅问题，减小设计人员对需求理解出入、产品设计不能支持需求的风险。

通过对产品各个阶段输出的审计，解决项目开发输出不完整、产品质量没有得到第三方确认的问题，将缺陷发现在早期阶段，减小返工率，降低到达用户现场发现问题的概率，节约维护成本。

通过对产品经理的奖惩考核，确保产品经理的工作质量。

分析考核结果，提高产品经理的工作能力。

2      产品经理工作职责及权利

2.1   产品经理级别说明

1、初级产品经理（A）

2、中级产品经理（B）

3、高级产品经理（C）

高一级的产品经理应该具备比其级别低的产品经理的所有能力，承担本身及比其级别低的产品经理的所有职责。

2.2   工作职责

1、需求获取；（B）

2、主持并参与需求分析；（B）

3、用户界面设计；（B）

4、主持需求评审；（B）

5、参与设计评审；（C）

6、需求状态统计；（A）

7、向客户通报需求处理计划和进度；（A）

8、测试结果审核；（B）

9、产品进度报告；（A）

10、产品介绍材料及演示环境建设；

11、产品输出审计及确认；（A）

12、产品使用情况跟踪；（A）

13、产品规划；（C）

14、协助产品总监进行产品策划和推广；（C）

15、产品外部资料管理和应用；（A）

2.3   产品经理工作权利

1、向开发经理提出产品变更要求权利；

2、向开发经理提出产品进度、质量、功能不满足风险及改进要求，如果无法和开发经理达成一致则可以直接上报产品部经理和产品总监；

3、在和开发经理对产品阶段性目标沟通后，拥有对产品的阶段性目标要求的决定权，当和开发经理无法达成一致时由产品总监和产品部经理共同商讨决定；

4、对于软件产品项目的结束与否拥有否决权；

2.4   产品实现流程

产品经理对其所负责的产品的需求受理、分析、评审及需求对应的输出验证审核起主导作用，由其负责。

在需求开发过程则起跟踪作用，由其执行需求跟踪。

具体每个步骤工作职责及输出由下文详细描述。

3      工作职责详细描述

3.1   需求获取（B）

3.1.1  工作内容

从各个渠道获取客户的确切需求，保留客户需求的原文及提供的附加材料，记录需求获取过程的关键信息。

将获取的需求按用户需求进行管理。

需求获取渠道包括客户和潜在客户直接或者通过第三者向产品经理提出的需求、系统调研的需求、系统培训过程提出的需求、其他厂家系统、系统维护过程提出的需求等。

需求获取过程的关键信息包括需求来源地区、提出者、提出者联系信息、受理者、期望完成时间。

将受理需求提交给项目经理，将获取的其他相关信息提供给产品总监。

3.1.2  工作关系

所负责产品线的所有客户及潜在客户、产品线的开发成员、产品线的维护成员。

3.1.3  工作输入

客户或者其他成员通过电话、EMail、传真等方式提供的信息和资料。

3.1.4  工作输出

客户需求及用户需求获取过程记录。

调研计划、调研总结报告（获取信息、本系统相关需求）、调研申请报告、客户资料。

3.1.5  工作流程

1、需求调研向主管部门提出申请、制定计划并根据调研计划执行；

2、记录客户需求并同客户确认是否记录有误，同客户确认需求完成时间或者答复时间。

3、整理客户需求并提交给项目经理。

4、根据协商的答复时间给予答复，如果无法安装预定目标完成，应该在答复时间之前向客户说明计划变动情况和变动原因。

5、将调研计划执行情况向审批者汇报；

3.1.6  考核内容

1、需求受理准确率：

作为能力考核，进行抽查统计，主要考虑需求描述是否和用户提出一直，需求描述是否完整。

对于分析过程发现描述不准确也作为一种。

2、需求及时回复率：

作为工作考核，从客户反馈或者系统中登记时间来判断是否安装要求时间回复客户。

3.2   主持并参与需求分析（B）

3.2.1  工作内容

根据用户提出的时间要求和项目组的项目开发计划，由产品经理根据需求难易程度和规模，决定是否需要组织相关人员分析。

需要分析的需求由产品经理组织项目的架构师、项目经理等人员共同分析客户需求，生成软件需求说明，修改该产品的软件需求规格说明书。

在分析过程如何还有不明确的需求内容，则负责和客户沟通，直到问题明确。

3.2.2  工作关系

客户需求提出者、项目经理、系统架构师、主要开发人员

3.2.3  工作输入

获取的客户需求及客户联系信息

3.2.4  工作输出

软件需求规格说明书，如果是变更需求则修改软件需求规格说明书需要变动部分及文档变动记录说明

3.2.5  工作流程

1、和项目经理、系统架构师沟通确定分析时间。

2、将相关客户需求提前发送给项目经理和系统架构师。

3、共同进行需求分析。

4、编写或者变更需求规格说明书。

3.2.6  考核内容

1、需求分析准确率：

作为能力考核，在评审过程认为分析有误、不完整的作为一次记录。

3.3   用户界面设计（B）

3.3.1  工作内容

产品经理界面设计主要完成功能性界面设计，功能性设计完成后对于主界面联系美工完成美工设计。

该工作根据需求变更情况决定是否涉及操作界面修改，如果有则根据需求分析结果进行界面设计或者修改已有的界面和界面操作说明，将界面设计结果发送给客户并联系客户沟通确认，同时发送给项目经理和架构师。

3.3.2  工作关系

客户需求提出者、项目经理、系统架构师

3.3.3  工作输入

需求分析结果：

软件需求规格说明书

3.3.4  工作输出

界面设计结果：

由Delphi设计的功能性界面、用户界面操作说明，本次修改说明（修改时间、修改者、修改需求）。

3.3.5  工作流程

1、阅读软件需求规格说明书的变更部分；

2、根据需求进行界面设计或者修改；

3、编写或者修改界面操作说明；

4、将界面设计结果发送给用户同时抄送给项目经理和架构师；

5、和用户确认界面；

3.3.6  考核内容

暂不考核

3.4   主持需求评审及跟踪（B）

3.4.1  工作内容

根据需求的紧要程度和项目开发计划，产品经理主持需求评审工作被执行。

需求评审方式不做严格要求，但是产品经理、项目经理和系统架构师对软件需求内容、界面、开发进度（根据具体需求细分到设计、编码、测试和产品输出阶段，至少需要编码和产品输出阶段）达成一致，评审结论需要有明确的记录。

在评审结束后三个工作日内明确阶段输出的具体时间。

对于无法达成一致的由产品部经理和产品总监讨论决定。

评审结束后，产品经理必须记录评审结果，如果有必要形成一个产品需求基线。

对于估计开发工作量在3个人月以上的需求，评审结果和需求必须抄送给产品总监；对于估计开发工作量在6个人月以上的需求，产品总监必须参加评审过程。

对于评审不通过的需求继续进行分析。

对于评审过的需求进行跟踪，及时需求需求跟踪矩阵中需求状态和相关信息。

3.4.2  工作关系

项目经理、系统架构师、产品总监、开发人员

3.4.3  工作输入

软件需求规格说明书、界面设计文档、界面操作说明、需求评审检查表格（记录需求中问题及需要在评审时确定的项目）

3.4.4  工作输出

评审后的软件规格说明书、评审后的界面设计文档和操作说明、需求评审检查表格、需求跟踪矩阵、评审记录（会议签到表或者邮件记录）、产品输出包内容。

3.4.5  工作流程

1、整理分析结果并和项目经理等人商量评审时间。

2、正常情况提前三个工作日将需要评审的内容、需求评审检查表格发送给相关参与评审的人员阅读。

参加评审人员必须在在评审之前阅读被评审内容、准备评审需要提出的问题。

3、主持评审并记录评审结果。

评审结果包括该需求是否评审通过、需求变更类型（分为新增、补充变更和错误变更三种类型）、估计设计完成时间、估计开发完成时间、估计测试完成时间、估计产品制作完成时间（或者补丁制作完成时间）。

4、根据评审结果整理软件需求规格说明书、界面设计文档和操作说明、需求跟踪矩阵并发布。

5、对于评审中不能确定的需求继续调研或者分析，对于评审中有争议的需求报产品总监处理。

3.4.6  考核内容

1、评审及时率：

作为工作考核，如果再用户再次提出需求还未评审，则认为评审延误。

2、评审误差率：

作为工作考核，评审后需求发生变化次数和总需求数的比。

3、评审问题跟踪及时率：

作为工作考核，采用抽查方式，对于评审过程发现问题的需求技术跟踪处理。

4、评审通过率：

作为能力考核，不通过指的时那些由于分析不彻底或者不明确而造成的不通过的需求。

5、调查表填写：

对于参加评审的人在规定时间内没有反馈，每次从项目奖金中扣罚50元，在项目考核时执行。

3.5   参与设计评审（C）

3.5.1  工作内容

参加项目经理安排的设计评审会议，在评审之前需要详细阅读设计文档，重点关注需求功能是否能够被实现、实现方式是否比较好、整个模块的扩展性等非功能属性是否能够达到要求等方面的内容。

在评审过程提出自己的意见。

3.5.2  工作关系

项目经理、架构师、开发人员

3.5.3  工作输入

设计文档

3.5.4  工作输出

评审建议、需求跟踪矩阵修改

3.5.5  工作流程

1、详细阅读设计文档。

2、评审过程发布自己的意见。

3、修改需求跟踪矩阵中需求对于的设计文档名称和评审时间。

3.5.6  考核内容

暂不考核

3.6   需求状态统计（A）

3.6.1  工