产品项目管理规范.docx

产品项目管理规范.docx

《产品项目管理规范.docx》由会员分享，可在线阅读，更多相关《产品项目管理规范.docx（16页珍藏版）》请在冰点文库上搜索。

产品项目管理规范

密级：

■保密□通用

项目管理规范

版

编写日期：

2009-2-5

北京xxx科技有限公司

地址：

北京市西城区xxx室

邮编：

xxx

电话：

010-xxxxx传真：

010-xxxxxxxx

目录3

1．文档版本控制4

文档说明4

文档更新纪录4

2．职能5

产品管理部5

需求管理员5

技术部/手机软件部5

需求提出人员5

3．需求判别流程5

4．工单管理流程6

5．产品制作流程7

5．1立项阶段流程8

5．2研发阶段流程10

6．需求变更流程13

7．附录13

7．1文档命名规则13

附件一：

事件工作单14

附件二：

立项工作单14

附件三：

需求变更工作单14

1．文档版本控制

文档说明

本文档为金色经纬项目管理流程专用说明文档。

文档总括性的叙述了因需求可能产生的项目/事件的制作流程，以及各个阶段的划分方法和工作产物。

本文不包括产品开发过程中各个角色的工作流程，具体工作流程请参考各个部门的具体工作流程文档。

文档主要包括以下内容：

1．小型项目/事件管理流程；

2．产品化项目管理流程；

3．需求变更管理流程；

文档更新纪录

作者

日期

版本

内容

参与者

备注

罗心晶

2009-2-5

2．职能

应当阅读此文档的人员为任何参与到产品开发过程中的角色，包括：

中高层管理人员（总监及高管）、产品策划人员、技术开发人员、运维人员、市场/销售人员。

重要角色包括：

产品管理部、需求管理员、产品经理（需求提出人）、技术人员。

其中对重要角色职能及相关要求定义如下：

产品管理部

负责产品和项目开发规范的制订，并监督其执行情况。

需求管理员

检查相关文件，签名是否齐备，落实阶段需求文档到位，向开发人员提交开发任务，负责将需求，项目状态更新到TD，ProjectServer中。

技术部/终端部

所有开发需求必须经过产品管理部需求管理员同意，确认方可开始进行开发；

发布人员必须经过需求管理员同意，确认签字方可发布程序。

需求提出人员

工作量大于1人/天的任务，必须经过需求管理员同意，确认后方可提交给开发人员。

3．需求判别流程

根据公司现阶段发展及实际工作情况，总结因需求可能产生的项目/事件，发起的过程相同，整理归纳大致流程如下：

其中关键部份为判断需求级别。

①产品经理发起需求草案，并与技术部进行可行性分析和工作量预判工作，根据技术部提供的建议对方案进行调整；并根据调整后的需求草案发起讨论会议。

在会议上将确认该需求进入相应流程。

草案需求讨论会议为非常规流程，但判断需求级别最简要求：

CTO或COO签字或邮件确认；

需求类型分两种：

需求变更——对已实施产品或项目进行变更需求；

新需求——新需求根据工作量及重要性分为工单和项目两种流程；

③判断新需求级别

分类

项目

项目

工单

说明：

现技术部分为两个工作组，一组5人，一组7人，工作量评估建议以重要性较高，且独立工作组一半人数以上/日列为项目

④进入工单管理流程——产品经理启动《事件工作单》，产品总监&技术总监签字或回复邮件确认生效；

进入产品化项目管理流程——产品经理启动《项目工作单》；

进入需求变更管理流程——产品经理启动《需求工作单》。

4．工单管理流程

经确认需求为工单，应进入如下流程：

产品经理需填写《事件工作单.doc》（见附件1），描述事件要点，并单独附事件详细设计文档，交由产品管理进行分析评估，如需求与事件工作描述差异较大，或事件工期超过3个工作日，将提交产品总监&技术总监确认，明确开发要求及需求后，转交技术部相关负责人进行研发并跟踪进度。

如事由紧急，事件需求负责人可直接以邮件/文档等形式向产品总监&技术总监确认，技术总监确认同时安排指定工程师，确认同时抄送产品管理组进行控制及跟踪进度。

启动工单流程后，在整个研发过程中状态如下：

进入暂停状态后，如需恢复，重新启用工单流程。

5．项目管理流程

如判断某个草案将形成产品化项目，应按以下流程进行管理和控制。

除指定物料和里程碑，所有细节可由具体操作人自行把握，仅供参考。

项目管理流程将产品的制作过程分为两个部分：

立项阶段和开发阶段。

经过这两个过程后，产品将脱离制作流程，进入运营流程。

运营流程的具体情况请参阅运营流程文档。

为了更清晰的表达各个阶段的进行流程，给出一个整体示意图：

在每个阶段中，项目将分割为如下状态：

下面对于每一个过程，分别给出流程图，并对整个流程的概述。

流程中的每一个阶段，都将安排一个评审会议，在评审会议上，产品、技术、管理测试和市场/销售代表对相应的提交物进行评估和评论，其目的是在每一个阶段加强公司内部各个部门对产品整体质量、进度的了解和认识，并在下阶段优化和改进产品。

从另一方面说，如果项目进展或质量达不到要求的话，任何一个阶段评审会，都给高层管理一个终止项目，规避风险的机会。

在整个项目管理流程中，以下物料分别为各个阶段的必备文档，产品经理应严格遵从模板样式，按时提交：

规划文档（可为邮件，大纲等非正式文档）——规划阶段；

功能规格说明书（模板待定）——概计阶段；

需求分析说明书（模板待定）——详设阶段；

产品设计原型——详设阶段；

产品使用说明书——内测阶段。

5．1立项阶段流程

立项阶段过程是产品的立项和设计过程。

主体人员为公司高管和产品经理。

立项阶段过程主要是产品的规划、计划过程，还包括一部分设计过程。

1.规划和立项阶段

本阶段的主要工作为对项目进行整体规划，并由相关人员进行风险评估，最后立项，并初步确定项目规模和分配公司资源。

这个阶段将产生3个工作成果：

1．总体规划文档

这个文档描述产品主要概念，指出产品的关键特性和市场机会，以及与众不同的关键点，特性集和产品范围。

产品规划人完成产品描述后，由技术负责人进行技术风险评估，并在文档中描述技术规划和技术风险。

2．产品讨论会议

总体规划文档产生后，产品经理召开产品讨论会议，参与人员包括公司高管、市场/销售、技术、管理/测试，大家通过产品经理或者策划的讲解，对产品概念进行了解和探讨，并将草案和构思形成产品雏形。

3．产品立项会议

产品讨论会议完成后，决策层通过总体规划文档和相关会议了解产品前景和风险，决定是否立项，如果立项，则召开产品立项会议，初步敲定项目规模并分配公司资源。

确认立项情况下，启动《立项工作单.doc》（见附件2）

2.计划及设计阶段

本阶段的工作目标主要集中在计划和设计上。

本阶段将产生项目的整体计划，并初步划分项目里程碑，同时，各个生产部门完成生产所需设计文档。

本阶段产生的工作成果如下：

1．计划

计划包括：

a）产品策划计划

本计划即需求实施计划。

计划为本阶段所有计划中最明确、最详细的计划。

计划界定产品策划工作进度，从产品功能和设计层面拆分模块和险峻段需求。

计划结束后，整个项目的需求已经基本清晰。

可视为需求里程碑已到达。

b）程序预研计划

在策划文档没有到位之前，程序研发计划可能是一个较为粗略的计划。

但也可以对技术摸索和前期技术底层构架进行详细计划，如果项目经理经验足够丰富，也可能根据经验提供一个较为详细的研发计划。

c）测试计划

测试计划情况跟程序研发计划类似。

d）市场/销售计划

市场/销售计划可能需要跟产品策划计划一同探讨制定。

这个计划跟整个开发流程关联不大。

e）项目综合计划

综合计划由产品管理人员汇总所有的执行计划后决定。

综合计划包含有明确的项目里程碑日期，供高层管理人员跟踪和掌控产品整体工作情况。

2．产品设计文档

产品实现方法的详细说明书，详细描述了这个产品的所有功能点。

这份文档需要包括UI设计、可视化设计图、核心运作机制、操作模式、操作流程、菜单/对话框，元素列表，可配置元素，产品原型等等。

这些文档将为程序制作和测试检验提供最重要的执行和检验依据。

3．技术设计文档

4．测试需求和测试用例

根据产品定义测试需求，并制定相应的测试用例。

5．2研发阶段流程

研发阶段发生在立项阶段之后。

主体人员为程序研发人员、产品经理及产品管理人员。

整个过程中主要是按产品需求实施计划进行编码和测试验收模块的过程，还包括一部分评审和运营环节。

1．研发阶段

研发阶段是技术部门对产品策划的技术实现过程。

参与人员主要为产品经理（代表客户）和技术人员，研发阶段工作成果如下：

1．程序研发计划细化；

2．产品模块的迭代开发计划的实施，这里需要把产品的每一个特性都分解为单独的任务，尽可能的使任务细化。

并在研发过程中积极参与，从产品角度及时的响应和控制变更。

2．验收阶段

Pre-Alpha版本

这个版本是一个主体核心功能已经实现了的版本，并且已经整合了美术制作成果。

版本目的是为了让决策层、产品经理能够产生对产品的第一印象。

第一印象的目的是评审产品的核心体验，以及确定策划、美术和技术实现的生命力。

在这个版本过后，通常有一些产品元素需要重新设计和优化以改善产品质量。

在产品验收阶段产品管理部测试专员负责功能测试。

在产品验收阶段，单元测试/集成测试/性能测试由技术负责。

其他相关由产品经理负责。

3．内测阶段

内测阶段在Alpha版本发布后开始。

Alpha阶段的产生工作成果如下：

1．Alpha版本

Alpha版本标志着所有产品特性已经完成，但通常会在具体的操作应用的友好性易用性上有所欠缺。

Alpha版本的发布由产品经理、产品管理和技术人员共同决定。

这个版本将提交产品部门进行优化。

优化工作包括对这个版本进行初始的整体的平衡性调整\以及细节的操作流程最优化。

如果产品质量达不到设计的质量标准或者产品标准，可能会对产品机制作较大的重新设计。

2．代码评审工作

技术在Alpha这个阶段开始进行代码评审。

代码评审由一组高级程序员进行。

如果没有这么多高级程序员，则由程序员团队内部互审。

评审工作通常包括设计模式、数据结构、程序健壮性、代码风格等方面。

评审者各自花1个工作日左右的时间来逐行检查代码，然后集中讨论提供反馈意见。

4．公测阶段

公测阶段在Beta版本发布后开始。

Beta阶段产生的工作成果如下：

1．Beta版本

产品的Beta版本已经没有较大的Bug，所有产品特性和元素在这个版本都已经完成。

由运营部门对这个版本的产品做最后的使用验收，以发现遗留问题。

2．公测

公测需求由产品经理和市场部门提出，由运维部门实施。

为了配合市场运营，并且进一步发掘遗留问题。

Beta阶段通常将安排对产品的公测。

4．发布阶段

发布阶段研发已经基本完成。

经过Release阶段后，研发工作全部结束，后续工作交由运营部门负责。

技术部在获得《立项工作单.doc》上的签署确认发布后安排产品上线。

Release阶段工作成果如下：

1．代码冻结

2．产品发布

将产品发布到产品环境中。

至此，这个研发过程结束。

后续工作将由运营部接管。

针对已发布的产品发起修改需求仅重复研发阶段流程，由产品经理发起，填写工单和提交详细修改策划启动流程。

6．需求变更流程

面向不同对象的需求变更主要分为两种：

对原有需求的变更；

在原有需求基础上产生新需求。

对任意项目及产品或事件的变更流程可参考事件管理流程，根据不同的变更需求酌情处理，主要如下：

1．填写《需求变更工作单.doc》递交产品管理部，如产品经理在收到需求变更人递交的申请后自判断事件较小且已事先沟通，或紧急需求，可通过邮件形式发送技术总监/产品总监，确认后马上进入研发流程，事后补填工作单；

2．产品管理部对需求变更引起的影响进行分析，如属高危需求，立即通知受影响部门，得到确认后递交技术部；

3．技术部获得明确的需求变更后，反馈评估意见，产品管理部进行跟踪。

7．附录

7．1文档命名规则

规范文档命名是为了便于对项目及公司内部文档进行管理和维护。

项目文档：

文档主题（版本）_部门_姓名_日期

如：

产品策划策划部门_常智山_

说明：

1.文档主题——当前文档内容，如页面策划，市场调研，工作计划，会议纪要、等，可附加版本，如，。

。

。

。

仅对其中部份内容进行修改可升级小版本号，阶段成果可升级大版本号。

2.部门——所属部门，如产品部

3.姓名——提交文档人姓名

4.日期——yyyymmdd，YYYY为年，如2002，mm为月，如08（不足两位的前面补零），dd为日，同足两位前面补零。

部门文档：

文档主题（版本）_部门_日期

如：

文档命名规范_产品部_

附件一：

事件工作单

附件二：

立项工作单

附件三：

需求变更工作单

［　　　　　　　　　］事件工作单

提交日期

期望完成日期

事件阐述

事件描述

重要性

□高□中□低

紧急性

□高□中□低

需求发起人

所属部门

产品经理

主管签章

工作实施计划及审批

工作量

人/日

预计开始开发时间

预期完成时间

风险度

□低□中□高

评估意见

评估人签字：

是否需提交原型

□需要□不需要

指派技术负责人

参与开发人员

技术总监签字

产品总监签字

工作暂停/取消—恢复

暂停/取消原因

暂停/取消时间

产品总监签字

技术总监签字

产品管理签字

恢复时间

产品总监签字

技术总监签字

产品管理签字

工作完毕审核

是否延期

□是□否原因：

实际完成时间

产品管理签字

是否发布

□同意□不同意

产品经理签字

产品总监签字

技术总监签字

备注：

事件相关物料

规划文档

是否提交□

功能规格说明书

是否提交□

需求分析说明书

是否提交□

产品设计原型

是否提交□

产品使用说明书

是否提交□

［　　　　　　　　　　］立项工作单

提交日期

期望完成日期

项目阐述

项目需求及设计

重要性

□高□中□低

紧急性

□高□中□低

需求发起人

产品经理

所属部门

主管签章

项目实施评估及审批

工作量

人/日

预期开始开发时间

预期完成时间

是否需要提交原型

□需要□不需要

项目风险度

□低□中□高

评估意见

评估人签字：

参与开发人员

技术总监签字

产品总监签字

CTO签字

产品管理签字

项目暂停/取消—恢复

暂停/取消原因

暂停/取消时间

产品总监签字

技术总监签字

产品管理签字

恢复时间

产品总监签字

技术总监签字

产品管理签字

项目完毕审核

实际完成时间

测试工程师签字

是否延期

□是□否原因：

是否发布

□同意□不同意

产品管理

产品经理签字

产品总监签字

技术总监签字

CTO签字

备注：

项目相关物料

规划文档

是否提交□

功能规格说明书

是否提交□

需求分析说明书

是否提交□

产品设计原型

是否提交□

产品使用说明书

是否提交□

需求变更工作单

事件/项目名称

需求编号

需求修改原因

提交日期

期望完成日期

修改类别

□添加新需求□修改原需求

重要性

□高□中□低

紧急性

□高□中□低

需求修改阐述

需求修改描述

需求提交人

产品经理

影响分析

对原需求影响程度

□高□中□低

受影响部门

受影响部门意见

产品经理

产品管理

工作实施计划及审批

工作量

人/日

开始开发时间

预期完成时间

风险度

□低□中□高

评估意见

评估人签字：

是否需提交原型

□需要□不需要

指派技术负责人

技术总监签字

产品总监签字

项目暂停/取消—恢复

暂停/取消原因

暂停/取消时间

产品总监签字

技术总监签字

产品管理签字

恢复时间

产品总监签字

技术总监签字

产品管理签字

工作完毕审核

实际完成时间

产品管理签字

是否延期

□是□否原因：

是否发布

□同意□不同意

产品经理签字

产品总监签字

技术总监签字